扫码下载：技术成熟度曲线-数据集成篇
引言
提到数据集成，业内同仁觉得这有什么可讲的，不就是ETL么？也就是从各种数据库读取，然后转化，最后落到不同数据仓库里。其实随着大数据，数据湖，实时数据仓库和大模型的兴起，数据集成的架构已经从过去的数据仓库时代的ETL到大数据时代的ELT到现阶段的EtLT。全球科技领域里，也诞生了像FiveTran，Airbyte，Matllion的新兴EtLT企业，更有Salesforce准备110亿美元鲸吞Informatica，IBM23亿欧元鲸吞这个领域的StreamSet和 webMethods来完成自身产品线从ETL到EtLT（DataOps）的升级。
所以，无论你是企业中的管理者或者是专业领域数据从业者都不得不重新审视数据集成在最近的时代里的变化和未来的趋势。
专家介绍： 郭炜先生毕业于北京大学，现任中国通信学会开源技术委员会委员，中国软件行业协会智能应用服务分会副主任委员，全球中小企业创业联合会副会长，TGO鲲鹏会北京分会会长，ApacheCon Asia DataOps论坛主席，波兰DataOps峰会、北美Big Data Day演讲嘉宾，虎啸十年 杰出数字技术人物，中国开源社区最佳33人，中国2021年开源杰出人物。郭炜先生曾任易观CTO，联想研究院大数据总监，万达电商数据部总经理，先后在中金、IBM、Teradata任大数据方重要职位，对大数据前沿研究做出卓越贡献。同时郭先生参与多个技术社区工作，Presto, Alluxio,Hbase等，是国内开源社区领军人物。
ETL架构
大多数数据领域的专家，都熟悉ETL这个词，在当年数据仓库盛行时，IBM DataStage、Informatica、Talend、Pentaho为代表的的ETL工具红极一时，现在还有不少公司依然在使用上述工具负责从不同数据库当中获取数据，进行转化，在进入统一的数据存储做报表展示和数据分析，这样的架构优劣如下：
● ETL架构优势：
○ 数据一致性和质量：ETL架构通过数据转换和清洗过程确保数据的一致性和质量。它可以处理来自不同源的数据，将其标准化并转换为企业所需的格式。○ 复杂数据源整合：ETL架构可以整合多种复杂的数据源，包括关系型数据库、非关系型数据库、文件系统等，使得数据集成变得可能。○ 技术架构清晰：ETL架构具有明确的步骤和流程，易于理解和实施。它将数据的提取、转换和加载分开处理，使得每个阶段都可以独立优化。○ 业务规则实现：通过ETL过程，可以嵌入业务规则和逻辑，确保数据转换符合企业的业务需求。
● ETL架构劣势：
○ 实时性不足：传统的ETL架构通常是基于批处理的，这意味着数据的处理和分析存在延迟，不适合实时数据处理和分析需求，无法满足实时数据要求。○ 硬件成本高：ETL过程可能需要大量的硬件资源，尤其是在数据量大的情况下，可能会导致硬件投资成本增加，几乎和数据仓库处理数据量线性增长。○ 灵活性不足：ETL作业一旦定义，修改和调整可能比较困难。对于快速变化的业务需求，ETL架构可能不够灵活。○ 技术通用性：尽管ETL流程清晰，但实现复杂的数据转换和集成可能需要专业的数据工程师和大量的技术知识，往往升级平台非常困难，因为大量业务逻辑都偶尔在拖拽的组件当中，而这些组件是不通用的，也很难读懂。○ 维护成本：随着数据源和业务逻辑的增加，ETL作业的维护和扩展可能会变得复杂和昂贵，○ 对非结构化数据处理能力有限：ETL架构在处理非结构化数据时处理非常复杂，需要用UDF或者单独变成可以实现完整功能。
ELT架构
在大数据时代来临时后， 面对ETL的数据仓库无法加载复杂数据源，实时性比较差的问题，曾经有一个ETL的变种架构被各种公司方法采用，ELT架构，典型就是各个数据仓库厂商自带的工具，例如，当年数据仓库最大厂商Teradata、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部分类似的架构。这在全球范围里有多家在这方面的专业公司，例如StreamSets、Attunity、Fivetran、Flink CDC、Apache SeaTunnel以及WhaleTunnel这些厂商都在新一代数据湖、实时数据和新兴数据源支持卓有成效。而EtLT架构优劣如下： ● EtLT架构优势：
○ 实时数据处理：EtLT架构支持实时数据抽取和转换，使得数据可以从消息组件、Binlog或者数据底层通过CDC模式及进行获取，可以快速地被处理和分析，满足实时业务智能的需求。○ 支持复杂数据源：EtLT架构能够有效地处理来自云、SaaS、本地等混合复杂数据源，适应现代数据架构的多样性，例如FiveTran支持500+种数据源，而WhaleTunnel支持200+种数据源。○ 降低成本：EtLT架构通过减少数据的重复存储和不必要的数据转换，可以整体降低存储和计算成本；同时在t(ransform)组件中，大量采用了SQL-Like的脚本和可视化来面对数据变换，从而让人员上手难度大幅较低，人员成本也大幅降低。○ 灵活性和可扩展性：EtLT架构允许数据在加载到数据湖或数据仓库之前进行初步转换，然后在需要时进行更深入的分析和二次转换，这提供了更高的灵活性和可扩展性，提高整体数据质量。○ 优化性能：通过在数据加载后进行二次转换，EtLT架构可以优化查询性能和数据处理速度，尤其是在处理复杂查询和实时数据分析时。○ 大模型支持：因为实时性的增强以及多种复杂数据源的支持，使得EtLT架构在大模型环境下有更多的延展性，曾经有开发者利用SeaTunnel结合ChatGPT将整个图书馆数据语义化《图书搜索领域重大突破！用Apache SeaTunnel、Milvus和OpenAI提高书名相似度搜索精准度和效率》，未来大模型普及的情况下，数据供给是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报告中也有提到，具体可以看下面的数据集成成熟度模型解读。
▼
数据生产
数据生产部分指的是数据集成中数据如何获取、如何分发、如何转化、存储的问题。这部分是整合数据集成工作量最大，最有挑战的地方，业内用户在使用数据集成工具的时候，首先考虑到的是是否支持自己使用的数据库、云、SaaS系统的集成支持。如果这里无法支持用户自有系统，那么数据集成就需要客户需要额外的成本来定制化实现接口或导出成兼容文件，那么对于数据的实时性、准确性都会有挑战。● 数据采集：目前大部分数据集成工具都已经支持了批量采集、限流、Http采集的部分，但是在实时数据获取(CDC)，DDL变更是否可以采集部分还是在成长期和热门期。特别是DDL变更部分，如果无法实现源系统字段变化时，目标端做响应的处理那么实时数据处理基本就成了一段空话，因为系统的实时性经常要被源系统变更所打断。但是，如何有效的处理DDL变更技术复杂性还是非常高的，业内各个厂商也都是在探索过程中。● 数据转换：在ETL架构逐步衰退的情况下，在集成工具中进行复杂的业务处理（例如，Join，Group By）已经逐步退出历史舞台，特别是在实时长场景下，很难有很大的内存可以用于流窗口的Join和聚合。所以，整体ETL工具都在初步迁移到ELT和EtLT架构当中。而利用SQL-Like的语言做轻量级数据转化几乎成为了主流，这样既可以不让开发人员学习各种各样的数据集成工具，同时又给开发人员足够的空间来满足数据清洗工作。同时，针对数据内容的监控、DDL变更的转化处理在结合通知、告警和自动化处理，让数据转化变为更智能的处理部分整个行业都在探索。● 数据分发：传统的JDBC加载、Http和块加载已经成为每个主流数据集成工具必备的功能，比拼的都是数据源支持的多少。而DDL自动变更这可以答复降低开发人员的工作量，同时可以保证数据集成任务的顺利进行。在这部分，各个厂商都用出各自的绝活，来支持各种复杂场景的数据表定义变化情况下的处理。而大模型的对接是新兴的场景，让企业内部数据都可以对接大模型，这是未来几年的趋势，不过目前还属于一些开源社区极客在进行的工作。● 数据存储：新一代的数据集成工具都会带缓存，这部分缓存过去是存在本地，现在开始利用分布式存储、分布式CheckPoint/快照来存储数据，特别是有大量数据缓存的情况下，需要进行数据回放、录制等场景时，有效利用云存储也是一种新兴方向。● 数据结构迁移：这部分是在数据集成处理过程中，是否可以进行自动建表和自动检查工作。自动建表是指可以在目标系统中自动源系统建立兼容数据架构的表/数据结构。这将极大的减少数据开发工程师的工作量，目前业内头部的工具都具有自动建表功能。而模型推演是更加复杂场景下，在EtLT架构中，出现小t的情况下，针对实时数据DDL变更、数据增减字段的场景下自动推演其合理性，从而让用户在数据集成任务运行前确定任务是否存在问题。这部分行业还在尝试阶段。计算模型
计算模型这部分是随着ETL、ELT、EtLT在不断变化的，从早期重视计算到中期重视传输，到现在重视在实时传输中做轻量计算，一直不停在迭代：● 离线数据同步：这部分已经成为每个企业最基本的数据集成诉求，不过在不同架构下各自的性能各不相同，总体上ETL架构的工具是远低于ELT和EtLT在大批量数据情况下的性能。● 实时数据同步：随着实时数据仓库、数据湖的普及，实时数据同步在现在成为每个企业在考虑数据集成的时候必不可少的一个因素，越来越多的企业开始使用实时同步。● 批流一体：在新一代的数据集成引擎里都在设计之初就考虑批流一体，从而针对企业不同场景下给出更有效的同步方法，而过去大部分引擎在设计的时候只考虑实时或离线其中一种场景，因此很多实时引擎在批量数据同步的时候性能表现不佳，新兴引擎在此方面具有优势。而批量和流式的统一使用，可以在数据初始化、批流混合数据环境下有更好的表现。● 云原生：在海外数据集成工具这方面更加激进，因为海外工具都是按量计费，所以，是否每个任务可以快速获取/释放响应计算资源是每个公司的核心竞争力和利润来源；反观国内，大数据云原生进展还比较缓慢，因此在国内还属于少数公司在探索中。数据类型&典型场景
● 文件采集：这是每个集成工具必备的功能，与过去有所不同的是，除了标准的文本文件，现在Parque，ORC等大数据格式的文件数据采集也成为标准。● 大数据采集：随着SnowFlake，Redshift，Hudi，Iceberg，ClickHouse，Doris，StarRocks等新兴数据源的普及，传统的数据集成工具在这方面明显落后，中美用户基本在大数据使用层面上在同一个步骤，因此要求厂商必须适配这些新兴数据源。● Binlog采集：这在中国是一个新兴的产业，因为在信创化过程中，取代了传统的DataStage，Informatica等工具，但是Oracle，DB2等数据库的替换没有这么迅速，因此出现大量了专业Binlog采集数据公司来解决海外数据CDC问题。● 信创数据采集：这也是中国特色的场景，信创化过程中出现大量国产数据库，是否可以适配这些数据库的批量和实时采集，也给中国厂商提出了更高的挑战。● 分库分表：在大多数大型企业中，一般都采用分库分表来降低数据库的压力，因此，数据集成工具是否支持分库分表基本成为一个专业数据集成工具的标配。● 消息队列：在数据湖和实时数据仓库的带动下，一切和实时相关的上下游都火爆起来，以消息队列为代表的的企业实时数据交换中心几乎成为先进企业必备的选项。而数据集成工具是否支持足够多的内存/磁盘的消息队列类型已经成为最热门的功能之一。● 非结构化数据：现在企业数据源当中，MongoDB，ElasticSearch等非结构数据都成为企业必备数据之一，数据集成也相应支持这方面数据源。● 大模型数据：如何让企业的数据快速和大模型交互，在全球有大量创业公司在做，这里有些是基于大模型直接做Embedding，有些是和向量数据库进行集成，在未来几年内，支持大模型数据源将成为数据集成工具的热门功能。● SaaS集成：这在海外是非常热门典型的功能，几乎海外的数据集成工具都以支持多少SaaS接口为系统衡量标准，在中国这方面还难以构成大量需求。● 数据统一调度：数据集成和调度系统的整合，特别是实时数据通过调度系统和后期数据仓库任务的相互配合是打造实时数据仓库必备的技能，因此全球新一代的DataOps平台都具有管理实时CDC数据和后期数据仓库批量数据的“批流一体”的调度能力。从而让企业从顺利从非实时到实时化过渡。● 实时数据仓库/数据入湖：这两个场景都是现在企业最火爆的场景，让企业数据实时入仓/湖，从而让新一代的数据仓库/湖才可以发挥优势出来，因此，全球在推广新一代技术的时候，往往是以一套新数据生态的面目出现，例如 New Data Stack在美国非常流行。● 数据容灾备份：随着数据集成实时性增强和CDC的支持，数据集成和传统灾备领域里出现了交叉，部分数据集成厂商和部分灾备厂商都开始做对方领域的工作和场景。不过，因为灾备场景和集成场景在细节上差异还是较大，所以相互渗透的厂商在对方领域里的功能都会比较缺乏，需要一段时间迭代。运维监控
在数据集成当中，运维监控是非常重要的功能，如果数据出现问题，如果有比较好的运维监控和处理手段，可以配合断点续传，单步调试等功能大幅度降低整个系统运维工作量和开发人员的工作量：● 流量控制：为了不影响原有系统，现代的数据集成工具从任务并行度、单任务JDBC并行度，单JDBC读取量等多个方面对流量进行控制，确保不影响源系统。● 任务/表级统计：在数据集成过程中，每个任务以及任务中每个数据表同步的情况，出错情况对于管理运维人员都非常重要，而在全球厂商里只有头部厂商才CDC场景下对表级别监控进行了支持，因为技术难度原因，大部分小厂商还停留在任务级别统计上，很难对表级别进行监控。● 逐条试运行：因为实时数据的支持,SaaS的支持和轻量级的tranform的加入，让直接运行一个比较复杂的数据流程更加复杂，因此部分前沿公司针对数据加入了逐条试运行的功能，让开发和运维更加高效。● 表变更事件捕捉：这是在实时数据处理中的新兴功能，一般针对源系统的表变更的时候有机会让用户以约定好的方式进行改变或者告警，这样可以最大力度保证实时数据的稳定性。● 批流一体调度：在实时CDC和流处理之后，势必会和传统的批量数据仓库任务需要结合，但是如何让实时流数据进入数据仓库后，准确的启动批量数据还不影响数据流的运行，这是为什么数据集成和批流一体调度相关的原因。目前市面的厂商对这方面支持程度都比较低，但相信未来在实时数据仓库流行起来的时候，这个功能也会成为必备功能。● 智能诊断/调优/资源优化：在集群和云原生情况下，如何更好的利用现有资源以及如果出现问题的时候，如何推荐用户可以用正确的解决方案解决数据集成问题，都是全球最前沿的数据集成公司讨论的热门话题。不过整体落地可能还要比较长的时间才可以达到生产级别智能化的应用。核心能力
对于数据集成来讲有非常多的功能都很重要，但是以下几点是数据集成赛道最核心的能力，如果在这方面缺乏，很可能在企业具体使用过程中产生比较大的影响：● 全量/增量同步：单独的全量/增量同步已经成为每一个数据集成工具必备功能，不过从先全量自动切换到增量模式还没有在中小厂商普及，用户需要手工进行切换。这部分可以缺分厂商的专业度。● CDC捕捉：随着企业对实时性要求变高，CDC捕捉成为了数据集成的核心竞争力，支持多少个数据源的CDC，是否支持本企业的数据库的CDC，以及CDC对源库的要求的权限和影响，往往成为数据集成工具的核心竞争力。● 数据多样性：支持多少个数据源，现在成为数据集成工具里面的“红海竞争”，往往更好的支持用户已有系统的数据源，就能在商业竞争中取得更优势的地位。● 断点续传：对于实时数据和批量数据是否支持断点续传，这在很多场景下可以帮助企业在很多场景下更快的恢复错误数据现场，或者在一些异常情况下的恢复很有帮助，不过还只是有少量工具支持这个功能。● 并发/限速：数据集成工具需要要快的时候可以高并发，需要慢的时候可以有效降低对源系统的影响。这几乎成为集成工具的必备功能。● 多表同步/整库迁移：这指的不仅仅是在界面的便捷选择，而是在底层引擎层面可否复用JDBC或者现有的集成任务，从而可以更好的利用现有资源，快速完成数据集成。性能优化
在核心能力之外，性能的优劣往往代表用户是否需要更多的资源或者数据集成工具的硬件和云的成本是否足够低，不过当前也不需要追求极致的性能，相对于接口支持程度、核心能力之外，性能往往是被排在第三位考虑的因素：● 时效性：分钟级别的集成已逐步退出历史舞台，支持秒级别的数据集成已经成为非常热门的功能。而毫秒级别数据集成场景还比较少，大部分还是灾备特殊场景下才会有这种需求。● 数据规模：目前大部分场景是在Tb级别的数据集成，Pb级别的数据集成基本在互联网大厂使用开源工具实现，Eb级别数据集成短期内还不会出现。● 高吞吐：高吞吐主要是看集成工具是否可以把网络和CPU有效的用满，从而达到理论数据集成的最大值。这方面ELT和EtLT的工具明显对ETL工具有优势。● 分布式集成：动态容错相对于动态扩缩容和云原生更加重要，一个大的数据集成任务是不是可以在一些硬件、网络出错的情况下可以自动容错是做大批量数据集成的时候的基本功能。而扩缩容和云原生基本是这个场景下的衍生需求。● 准确性：数据集成如何确保一致性是一个复杂任务，除了引擎本身需要利用多种技术确保“Exactly Once”之外，做了CRC校验之外。还需要有第三方的数据质量检查工具，而不能只是“自证清白”，因此数据集成工具往往会和数据调度工具相互配合以验证数据准确性。● 稳定性：这是一个多种功能下的结果，从可用性，任务隔离、数据隔离、权限、加密控制等方面来确保单一任务的问题不会影响其他任务，单一数据库/部门出现问题的时候，不会影响其他任务和部门。● 生态： 优秀的数据集成工具具有庞大的生态，可以支持多种数据源的同步，也可以和上下游调度、监控系统相互整合。同时，工具是否易用也是涉及到企业用人成本的重要指标。趋势
数据集成在未来几年随着EtLT架构的普及，很多新型的场景会出现，同时数据虚拟化、DataFabric对于未来数据集成也会有重大影响：● 多云集成：这在全球已经很普及，大部分的数据集成都具有跨云的集成能力，在中国因为云尚未普及，所以这方面还在早期孵化阶段。● ETL一体化：随着ETL周期性的衰退，大部分的企业会从Kettle，Informatica，Talend等工具逐步迁移到新兴的EtLT架构，从而支持批流一体的数据集成，也支持更多的新兴数据源。● ELT：目前主流的大数据架构基本都ELT架构，随着实时数据仓库、数据湖的兴起，ELT相关工具会逐步升级到EtLT工具，或者在原有ELT架构上增加实时EtLT工具以弥补ELT架构对实时数据支持的缺失。● EtLT：全球范围里，包括像JpMogan、Shein、Shoppe等企业嵌入到EtLT架构当中，会有更多的企业会讲内部数据集成工具进入到EtLT架构，配合批流一体的调度系统满足企业DataOps相关需求。● 自动化治理：随着数据源和实时数据的增加，传统的治理流程已经无法满足实时分析对于时效性的分析，自动化治理在未来几年内会在企业内部逐步兴起。● 大模型支持：在大模型深入企业应用中后，如何给大模型供数成为数据集成必备的技能，传统的ETL和ELT架构都比较难适配大模型这种实时性高，批量数据比较大的场景，因此EtLT架构会和大模型普及一起深入多数企业当中。● ZeroETL：这是亚马逊提出的概念，认为数据存储在S3上，可以通过各种引擎直接来访问，而不需要进行不同引擎之间的ETL。某种意义来讲，如果数据场景不复杂，数据量不大，少量引擎就可以满足OLAP和OLTP需求这种存算分离是企业最佳方案。但是由于场景支持过少，性能不佳等问题，导致未来一段时间还需要一段时间沉淀才可以得到更多企业的认可。● DataFabric：现在多家企业提出利用DataFabric的元数据来管理所有数据，查询不用再进行ETL/ELT，而是直接访问底层数据。目前这种技术还处于实验阶段，查询的响应和场景适配难度都比较大。针对简单场景的少量数据查询是可以满足需求的，未来很长的一段时间，针对大数据复杂场景，还是需要EtLT架构来进行。● 数据虚拟化：基本思路类似于DataFabric的执行层，数据不需要挪动，通过即席查询接口和计算引擎（例如 Presto,TrinoDB）来直接翻译底层数据存储或者数据引擎的数据进行查询。但是，问题也是在大量数据情况下，引擎查询效率、内存消耗往往达不到需求预期，因此只在少量数据情况下使用。从整体趋势来看，随着全球数据爆炸性增长，大模型的出现，处理各种场景的数据引擎也如雨后春笋般层出不穷，而实时数据的兴起也让数据集成这个赛道重新回到数据领域兵家必争之地的局面。如果说数据是一种新能源，那么数据集成就像是新能源的管道，数据引擎越多，要求管道的效率、数据源兼容性、易用性就会越来高。虽然数据集成在最终会面临Zero ETL、数据虚拟化、DataFabric的挑战，但是在可见的未来，这些技术的性能、准确率和ROI一直无法达到数据集成的普及程度，否则美国最流行的数据引擎不应该是SnowFlake或者DeltaLake，而应该是TrinoDB。当然，我相信，未来10年在DataFabric x 大模型情况下，虚拟化+EtLT+数据路由的方式可能才是最终数据集成的解决方案。总之，只要数据永远在扩张，数据之间的管道就会永远存在。首先针对可以根据成熟度模型可以看到全面的当前及未来10年内数据集成可能使用到的技术点，对于个人技术发展，企业技术架构设计、选型给了一个全面的地图，同时也对数据集成行业发展重点给出启示。对于企业来讲，技术成熟度可以判断一个技术投入程度，对于成熟期的技术现有企业一定已经使用了类似的技术很多年了，支持业务已经非常成熟；因为技术发展已经进入瓶颈，如果有更优秀的热门期的技术可以考虑更新以换取更高的业务价值；在衰退期的技术，大部分企业在使用当中开始发现它在支持业务方面的瓶颈和问题，基本在未来3-5年内就会逐步被热门期或者成长期技术所取代，这部分技术企业如果要新引入这类技术可以考虑其业务价值和企业现状；对于热门期的技术，企业选择会优先考虑，因为这部分技术已经在早期大众（Early Majoniy ，超过70%的人群）中得到了充分验证，大部分企业和技术公司都在热捧这类技术，同时它的业务价值得到验证，未来1-2年很快占据市场主导地位；成长期的技术，企业选择时要根据它对自己的业务价值考虑，这部分技术已经度过前瞻期，技术价值和业务价值已经在早期使用者（Early Adopter）当中得到验证，不过因为市场品牌宣传等原因还未全面普及，对于业务价值比较高的技术企业可以考虑采用，成长期的技术有很大概率会成为热门期技术以及未来的企业标准；前瞻期的技术一般都是比较前沿的技术，属于早期尝鲜者正在使用的技术，都具有一定的业务价值，但是技术通用性和ROI还未得到验证，一般对企业业务价值比较大的部分可以考虑小范围使用。对于个人来讲，成熟期和衰退期的技术已经没有学习和钻研价值，大部分是已经普及的技术，会使用即可；钻研热门期的技术有利于找工作，因为这部分是业界热捧的技术，企业需求旺盛、学习材料也非常多，不过这方面的学习的竞争者也比较多，需要有一定深度才可以脱颖而出；成长期的技术值得个人选择其中一些方向深入学习，因为这部分技术在未来有很大概率成为热门技术，而个人前期在成长期阶段积累的经验可以在这些业务成为热门阶段的时候，你成为“专家”而脱颖而出，快人一步；而前瞻期的技术，对于技术极客来讲，可以投入精力来研究，这部分的技术往往可能酝酿着“颠覆式”创新，成为未来热点，但是也可能被验证失败，普通技术人员根据自己的爱好来选择，这部分技术对于找工作和日常实战来讲距离还比较远，对于一些前瞻性的公司来讲，这些技术面试的时候会被提问来考察个人技术的前瞻性。
技术成熟度定义：
● 前瞻期：技术仍处于研究开发阶段，技术社群主要探索技术的实际应用可行性和潜在的市场价值，尽管业界对此技术的认识尚浅，但已经识别到高价值的需求。
● 成长期：随着技术开始进入实际应用阶段，市场上出现越来越多的竞争者，伴随着各种技术路径的并行发展。此时，技术社群重点关注如何克服实际应用中的挑战，并最大化其商业价值，尽管业界对这些技术的兴趣日益浓厚，其在商业上的价值仍未完全显现。
● 热门期：技术发展达到高潮，技术社群力求推动技术性能达到极致，业界对该技术的关注也达到顶峰，并且技术开始显著体现出商业价值。
● 衰退期：技术路径开始呈现优劣分明，市场对于技术的优化和整合提出更高要求，此外，业界开始认识到技术在提升业务价值方面的局限性和边界。
● 成熟期：技术路径趋于统一并标准化，技术社群关注点转向如何降低成本并提高效率，业界同样关注成本效益，基于成本效益分析来评估技术的优先级和应用广度。
业务价值定义：
5星：相关技术点/业务单元的降本/收益贡献占部门总收入的50%及以上，或由高级总监及以上级别（如VP等）的管理人员负责。
4星：相关技术点/业务单元的降本/收益贡献占部门总收入的40%至50%之间，或由总监级别的管理人员负责。
3星：相关技术点/业务单元的降本/收益贡献占部门总收入的30%至40%，或由高级经理级别的管理人员负责。
2星：相关技术点/业务单元的降本/收益贡献占部门总收入的20%至30%，或由经理级别的管理人员负责。
1星：相关技术点/业务单元的降本/收益贡献占部门总收入的5%至20%之间，或由主管级别的管理人员负责。
技术难度定义：
5星：投入顶级行业专家团队12个月以上。
4星：投入行业专家或高级架构师团队12个月以上。
3星：投入架构师团队6个月左右。
2星：投入高级程序员团队1-3个月。
1星：投入普通程序员团队1-3个月。
大模型助力收益定义：
（参考业务价值定义）
管理协作难度定义：
5星：相关技术点/业务单元的管理成本占部门总成本的50%及以上，或由高级总监及以上级别（如VP等）的管理人员负责。
4星：相关技术点/业务单元的管理成本占部门总成本的40%至50%之间，或由总监级别的管理人员负责。
3星：相关技术点/业务单元的管理成本占部门总成本的30%至40%之间，或由高级经理级别的管理人员负责。
2星：相关技术点/业务单元的管理成本占部门总成本的20%至30%之间，或由经理级别的管理人员负责。
1星：相关技术点/业务单元的管理成本占部门总成本的5%至20%之间，或由主管级别的管理人员负责。
大模型结合周期定义：
0-6月：大模型助力价值在0-6月内饱和；
6月-1年：大模型助力价值在6-1年内饱和；
1-2年：大模型助力价值在1-2年内饱和；
2-3年：大模型助力价值在2-3年内饱和；
3年以上：大模型助力价值在3年以上饱和；
▌项目特邀专家
扫码下载：技术成熟度曲线-数据集成篇