2024-2030数据集成成熟度曲线(一)

作者 | 郭炜

导读：最新发布的《技术成熟度曲线2024》全面评估数据集成技术架构的7个维度，包括技术成熟度、技术难度、业务价值、技术成熟周期、管理协作难度、大模型结合等评估维度，报告篇幅较长，我们将报告分为3篇系列文章，本文为报告第一篇，描述了 「从ETL 到ELT，到 EtLT的趋势」。接下来系列文章将于近期陆续发布，敬请期待！

提到数据集成，业内同仁觉得这有什么可讲的，不就是ETL么？也就是从各种数据库读取，然后转化，最后落到不同数据仓库里。其实随着大数据，数据湖，实时数据仓库和大模型的兴起，数据集成的架构已经从过去的数据仓库时代的ETL到大数据时代的ELT到现阶段的EtLT。全球科技领域里，也诞生了像FiveTran，Airbyte，Matllion的新兴EtLT企业，更有IBM23亿美元鲸吞这个领域的StreamSet和 webMethods来完成自身产品线从ETL到EtLT（DataOps）的升级。

所以，无论你是企业中的管理者或者是专业领域数据从业者都不得不重新审视数据集成在最近的时代里的变化和未来的趋势。

从ETL 到ELT，到 EtLT的趋势

ETL架构

大多数数据领域的专家，都熟悉ETL这个词，在当年数据仓库盛行时，IBM DataStage，Informatica，Talend，Kettle为代表的的ETL工具红极一时，现在还有不少公司依然在使用上述工具负责从不同数据库当中获取数据，进行转化，在进入统一的数据存储做报表展示和数据分析，这样的架构优劣如下：

• ETL架构优势：
  • 数据一致性和质量：ETL架构通过数据转换和清洗过程确保数据的一致性和质量。它可以处理来自不同源的数据，将其标准化并转换为企业所需的格式。
  • 复杂数据源整合：ETL架构可以整合多种复杂的数据源，包括关系型数据库、非关系型数据库、文件系统等，使得数据集成变得可能。
  • 技术架构清晰：ETL架构具有明确的步骤和流程，易于理解和实施。它将数据的提取、转换和加载分开处理，使得每个阶段都可以独立优化。
  • 业务规则实现：通过ETL过程，可以嵌入业务规则和逻辑，确保数据转换符合企业的业务需求。
• ETL架构劣势：
  • 实时性不足：传统的ETL架构通常是基于批处理的，这意味着数据的处理和分析存在延迟，不适合实时数据处理和分析需求，无法满足实时数据要求。
  • 硬件成本高：ETL过程可能需要大量的硬件资源，尤其是在数据量大的情况下，可能会导致硬件投资成本增加，几乎和数据仓库处理数据量线性增长。
  • 灵活性不足：ETL作业一旦定义，修改和调整可能比较困难。对于快速变化的业务需求，ETL架构可能不够灵活。
  • 技术通用性：尽管ETL流程清晰，但实现复杂的数据转换和集成可能需要专业的数据工程师和大量的技术知识，往往升级平台非常困难，因为大量业务逻辑都偶尔在拖拽的组件当中，而这些组件是不通用的，也很难读懂。
  • 维护成本：随着数据源和业务逻辑的增加，ETL作业的维护和扩展可能会变得复杂和昂贵，
  • 对非结构化数据处理能力有限：ETL架构在处理非结构化数据时处理非常复杂，需要用UDF或者单独变成可以实现完整功能。

ELT架构

在大数据时代来临时后， 面对ETL的数据仓库无法加载复杂数据源，实时性比较差的问题，曾经有一个ETL的变种架构被各种公司方法采用，ELT架构，典型就是各个数据仓库厂商自带的工具，例如，当年数据仓库最大厂商Teradata的BETQ/Fastload/TPT、Hadoop Hive 体系的Apache Sqoop，阿里推出的DataX架构都是ELT架构。它们的特点就是，将数据通过各种工具，几乎不做join,group等复杂转化，只做标准化（Normolization）直接抽取到数据仓库里数据准备层（Staging Layer），再在数据仓库中通过SQL、H-SQL，从数据准备层到数据原子层（DWD Layer or SOR Layer）；后期再将原子层数据进入汇总层（DWS Layey or SMA Layer），最终到指标层（ADS Layer or IDX Layer）。ELT架构的优劣如下：

• ELT架构优势：
  • 处理大数据量：ELT架构允许数据首先被加载到大数据平台和数据仓库（如Teradata, Hadoop或云存储解决方案）中，这些平台能够高效地处理和存储大量数据，由于不做Transform，也让这类ELT工具性能远高于ETL工具。
  • 开发与运维效率提高：ELT架构把复杂的业务逻辑放到数据仓库当中，只做贴源层的映射，因此学习和运维门槛很低，可以让数据工程师完成贴源层映射，数据应用工程师直接利用SQL在数据仓库当中进行开发，开发效率、人员交接、工具替换都变得更简单。
  • 成本效益：通过将数据直接加载到数据仓库中，可以减少传统ETL过程中所需的中间数据存储和转换步骤，从而降低了硬件和软件的成本，开发和排查错误效率也高很多。
  • 灵活性和扩展性：数据仓库提供了一个灵活的环境，可以存储原始数据，直到需要时再进行转换。这种方法支持多种数据类型和格式，便于扩展以适应新的数据源和分析需求。
  • 易于集成新技术：随着大数据技术的快速发展，ELT架构可以更容易地后续集成新的数据处理工具和引擎，如Apache Spark和云上的EMR处理。
• ELT架构劣势：
  • 实时性支持不足：ELT架构还是针对批量数据处理，无法支持CDC、数据流等实时场景，因此在新一代数据湖、实时数据仓库生态中，ELT架构在逐步被新架构取代。
  • 数据存储成本高：ELT通常将数据加载到数据湖或数据仓库等存储系统中，然后再进行转换和处理。这意味着需要更多的存储空间来存储原始数据，而且数据量越大，存储成本就越高。
  • 数据质量问题：将原始数据直接加载到目标存储系统后再进行转换处理可能会导致数据质量问题被忽略或延后处理。如果源数据存在问题，这些问题可能会被传播到目标系统中，影响后续的数据分析和决策。因为没有任何T的环节，所以在类型转化，脏数据过滤等方面都存在缺陷。
  • 依赖目标系统的能力：ELT架构依赖于目标存储系统的处理能力来进行数据转换和处理，因此对目标系统的性能、稳定性和扩展性有较高的要求。如果目标系统无法满足这些要求，可能会影响整个数据处理流程的效率和可靠性。

EtLT架构

随着数据湖和实时数据仓库的流行，ELT架构的实时性和非结构化数据处理能力的弱点被放大，于是全球出现了新的架构，EtLT架构。这是在E(xtract)数据源部分增加了实时获取SaaS, Binlog, 云组件的部分；处理部分增加了小t(ransform)，这是针对非业务逻辑的数据处理部分（例如类型转化，脏数据过滤，数据字段映射等），后续和ELT部分类似的架构。这在全球范围里有多家在这方面的专业公司，例如被IBM收购的SteamSets，被Qlik收购的Attunity，美国Snowflake的深度合作伙伴Fivetran，Apache 基金会针对流处理引擎FlinkCDC，Apache基金会批流一体同步工具SeaTunnel，以及白鲸开源针对SeaTunnel的商业版WhaleTunnel(http://www.whaleops.com/marketing.html)。 这些厂商都在新一代数据湖、实时数据和新兴数据源支持卓有成效。而EtLT架构优劣如下：

• EtLT架构优势：
  • 实时数据处理：EtLT架构支持实时数据抽取和转换，使得数据可以从消息组件、Binlog或者数据底层通过CDC模式及进行获取，可以快速地被处理和分析，满足实时业务智能的需求。
  • 支持复杂数据源：EtLT架构能够有效地处理来自云、SaaS、本地等混合复杂数据源，适应现代数据架构的多样性，例如FiveTran支持500+种数据源，而WhaleTunnel支持200+种数据源。
  • 降低成本：EtLT架构通过减少数据的重复存储和不必要的数据转换，可以整体降低存储和计算成本；同时在t(ransform)组件中，大量采用了SQL-Like的脚本和可视化来面对数据变换，从而让人员上手难度大幅较低，人员成本也大幅降低。
  • 灵活性和可扩展性：EtLT架构允许数据在加载到数据湖或数据仓库之前进行初步转换，然后在需要时进行更深入的分析和二次转换，这提供了更高的灵活性和可扩展性，提高整体数据质量。
  • 优化性能：通过在数据加载后进行二次转换，EtLT架构可以优化查询性能和数据处理速度，尤其是在处理复杂查询和实时数据分析时。
  • 大模型支持：因为实时性的增强以及多种复杂数据源的支持，使得EtLT架构在大模型环境下有更多的延展性，曾经有开发者利用SeaTunnel结合ChatGPT将整个图书馆数据语义化《图书搜索领域重大突破！》，未来大模型普及的情况下，数据供给是EtLT架构的一大优势。
  • 数据质量和治理：EtLT架构允许在数据加载之前进行初步清洗和转换，有助于提高数据质量，并在数据存储后进行进一步的数据治理。
• EtLT架构劣势：
  • 技术复杂性：EtLT架构相对于传统的ETL和ELT架构更为复杂，需要更多的技术知识和专业技能来设计数据获取、小转化和加载部分。
  • 依赖目标系统的处理能力：EtLT架构依赖于目标系统的处理能力来进行第二次转换处理，因此对目标系统的性能和稳定性有较高的要求。特别是在实时计算场景下，如果目标系统无法满足这些要求，可能会影响整个数据处理流程的效率和可靠性。
  • 管理和监控挑战：EtLT架构的多阶段处理可能需要更复杂的管理和监控工具，以确保数据流程的稳定性和可靠性，
  • 数据变更管理复杂性提高：由于EtLT架构中数据转换的分离，源系统变化时，为了确保整体数据实时性，可能需要对多个阶段进行DDL变更自动或人工的调整，增加了数据变更管理的复杂性。
  • 对工具和平台的依赖：EtLT架构的实施通常依赖于先进的数据处理工具和平台，如Apache SeaTunnel、Apache Spark、Apache Flink等，这可能需要额外的投资和集成工作。

整体上，数据集成的架构在近几年随着数据、实时数据仓库、大模型的兴起，EtLT架构在全球范围逐步成为主流，具体历史更迭细节可以参考在笔者《ELT已死，EtLT才是现代数据处理架构的终点!》中的相关内容。在整体这样一个大趋势下，我们来解读整个数据集成赛道的成熟度模型，整体看可以看到4点明显趋势：

1. 在ETL变为EtLT趋势当中，数据集成的热点已经从传统的批量进入到实时数据采集和批流一体的数据集成，热度最高的场景也从过去单一数据库批量集成场景，现在也变为混合云、SaaS多种数据源下批流一体的数据集成；
2. 数据复杂转换，从过去ETL工具中变换逐步为在数据仓库中处理复杂Transform，同时，针对实时数据集成时DDL（字段定义）变化的情况也开始支持不暂停支持字段自动变更（Schema Evolution），甚至在轻量级转化中适配DDL变更也成为一种趋势。
3. 数据源类型支持，从文件、传统数据库已经开始向信创数据源、开源大数据体系、非结构化数据体系、云数据库、大模型支持方向，这些也是未来每个企业当中遇到的最多的场景，未来企业内实时数仓、湖、云、大模型都会在不同场景里使用。
4. 核心能力和性能部分，数据源多样性、准确率高、容易排错成为大多数企业使用的优先选择，反而大吞吐、实时性高这些能力考察点并不多。

针对数据虚拟化、DataFabric、ZeroETL报告中也有提到，具体可以看下面的数据集成成熟度模型解读。

专家介绍：

郭炜先生毕业于北京大学，现任中国通信学会开源技术委员会委员，中国软件行业协会智能应用服务分会副主任委员，全球中小企业创业联合会副会长，TGO鲲鹏会北京分会会长，ApacheCon Asia DataOps论坛主席，波兰DataOps峰会、北美Big Data Day演讲嘉宾，虎啸十年 杰出数字技术人物，中国开源社区最佳33人，中国2021年开源杰出人物。郭炜先生曾任易观CTO，联想研究院大数据总监，万达电商数据部总经理，先后在中金、IBM、Teradata任大数据方重要职位，对大数据前沿研究做出卓越贡献。同时郭先生参与多个技术社区工作，Presto, Alluxio,Hbase等，是国内开源社区领军人物。

本文由 白鲸开源 提供发布支持！