提到数据处理，常常有人把它简称为“ETL”。但认真说来，数据处理经验了ETL、ELT、XX ETL（例如，Reverse ETL、Zero-ETL）到当初风行的EtLT架构几次更迭。目前大家应用大数据Hadoop时代，次要都是ELT形式，也就是加载到Hadoop里进行解决，然而实时数据仓库、数据湖的风行，这个ELT曾经过期了，EtLT才是实时数据加载到数据湖和实时数据仓库的规范架构。

本文次要解说下几个架构呈现的起因和善于的场景及优缺点，以及为什么EtLT逐渐取代了ETL、ELT这些常见架构，成为寰球支流数据处理架构，并给出开源实际办法。

ETL时代（1990-2015）

在数据仓库晚期时代，数据仓库提出者Bill Inmmon把数据仓库定义为分主题的存储和查问的数据存储架构，数据在存储时就是按主题分门别类荡涤好的数据。而理论状况也如此，大部分数据源是架构化数据源（例如，mysql、Oracle、SQLServer、ERP、CRM等等），而作为数据集中处理的数据仓库大部分还是以OLTP时代查问和历史存储为主的数据库（DB2、Oracle），因而数据仓库在面对简单ETL解决时并不得心应手。而且这些数据库购买老本都比拟高，解决性能较弱，同时，各种各样的软件数据源越来越多。为了更不便地整合简单的数据源、分担数据计算引擎累赘、大量的ETL软件呈现，大家耳熟能详的Informatica、Talend、Kettle都是那个年代的典型软件产品，很多软件至今还在很多企业的传统架构当中配合数据仓库应用。

长处：技术架构清晰、简单数据源整合顺畅、ETL软件分担靠近50%的数据仓库工作

毛病：所有解决都由数据工程师实现，业务需要满足工夫较长；硬件老本简直投入双份，数据量大时硬件老本过高

在数据仓库晚期和中期，数据源复杂性比拟高的时候，ETL架构简直成为行业标准风行了20多年。

ELT时代（2005-2020）

随着数据量越来越大，数据仓库的硬件老本与ETL硬件老本双向增长，而新的MPP技术、分布式技术呈现导致在数据仓库中后期和大数据衰亡时代，ETL的架构逐渐走向ELT架构。例如，当年数据仓库最大厂商Teradata、至今风行的Hadoop Hive架构，都是ELT架构。它们的特点就是，将数据通过各种工具，简直不做join,group等简单转化，只做标准化（Normolization）间接抽取到数据仓库里数据筹备层（Staging Layer），再在数据仓库中通过SQL、H-SQL，从数据筹备层到数据原子层（DWD Layer or SOR Layer）；前期再将原子层数据进入汇总层（DWS Layey or SMA Layer），最终到指标层（ADS Layer or IDX Layer）。尽管Teradata面向的结构化数据，Hadoop面向非结构化数据，但寰球大数据和数据仓库简直用的同一套架构和方法论来实现3-4层数据存储架构。

长处：利用数据仓库高性能计算解决大数据量解决，硬件ROI更高；同时，简单业务逻辑能够通过SQL来用数据分析师和懂业务逻辑的技术人员来解决，而无需懂ETL(如Spark, MapReduce)升高数据处理人员总成本。

毛病：只实用于数据源比较简单、量比拟大的状况，面对简单的数据源显著解决形式有余；同时间接加载，数据筹备层到数据原子层简单度过高，无奈通过SQL解决，往往利用Spark、MapReduce解决，而数据反复存储率较高；无奈反对实时数据仓库等需要。

面对ELT的数据仓库无奈加载简单数据源，实时性比拟差的问题，已经有一个过渡性解决方案被各种公司办法采纳，叫做ODS（Operational Data Store）计划。将简单的数据源通过实时CDC或者实时API或者短时间批量（Micro-Batch）的形式ETL解决到ODS存储当中，而后再从ODS ELT到企业数据仓库当中，目前，还有很多企业采纳此种形式解决。也有局部企业，把ODS搁置在数据仓库当中，通过Spark、MapReduce实现后期的ETL工作，再在数据仓库（Hive、Teredata、Oracle、DB2）当中实现前期的业务数据加工工作。

其实此时，EtLT初期的人群曾经造成，它的特点是人群划分开，简单的数据抽取、CDC、数据结构化、规整化的过程，往往由数据工程师实现，咱们叫做小“t”，它的指标是从源零碎到数据仓库底层数据筹备层或者数据原子层；而简单的带有业务属性的数据原子层到数据汇总层到数据指标层的解决（带有Group by、Join等简单操作）往往是善于应用SQL的业务数据工程师或者数据分析师来解决。
而ODS架构的独立我的项目也随着数据量级变大和EtLT架构的呈现逐渐淡出历史舞台。

EtLT （2020-将来）

EtLT的架构是由James Densmore 在《Data Pipelines Pocket Reference 2021》中总结提到的一个古代寰球风行的数据处理架构。EtLT也是随着古代数据架构（Modern Data Infrastructure）变动而产生的。

EtLT架构产生的背景

古代数据架构架构有如下特点 ，导致EtLT架构呈现：

  • 云、SaaS、本地混合简单数据源
  • 数据湖与实时数据仓库
  • 新一代大数据联邦(Big Data Federation)
  • AI利用大暴发
  • 企业数据社群（Data Community）决裂

简单数据源呈现

当初寰球企业运行当中，除了传统的软件、数据库之外，云和SaaS的呈现将本曾经很简单的数据源状况更加简单，于是面对SaaS的解决，北美企业提出了新的数据集成（Data Ingestion）的概念，例如 Fivetran，Airbyte，以解决SaaS数据进入数据仓库（例如Snowflake）当中的ELT问题，它是传统ELT架构在SaaS环境下的降级。而云端数据存储（例如，AWS Aruroa，AWS RDS，MongoDB Service等）和传统线下数据库与软件（SAP、Oracle、DB2等）在混合云架构（Hybrid Cloud）也在迅速减少数据源复杂性。传统的ETL和ELT架构就无奈满足如此简单环境的数据源解决。

数据湖与实时数据仓库

在古代数据架构环境下，数据湖的呈现交融了传统的ODS和数据仓库的特点，它能够做到贴源的数据变更和实时数据处理（例如 Apache Hudi, Apache Iceberg，Databricks Delta Lake），针对传统的CDC（Change Data Capture）和实时数据流计算都做了数据存储构造变动（Schema Evolution）和计算层面的反对。同时，实时数据仓库理念呈现，很多新型计算引擎（Apache Pinnot、ClickHouse、Apache Doris）都将反对实时ETL提上日程。而传统的CDC ETL软件或者实时计算流计算（Datastream Computing）对于数据湖和实时数据仓库的反对，要么是在新型存储引擎反对要么是在新型数据源连贯方面存在很大问题，不足很好的架构和工具反对。

新一代大数据联邦

在古代数据架构当中还有一种新型架构呈现，它们以尽可能减少数据在不同数据存储间流动，间接通过连接器或者疾速数据加载后间接提供简单数据查问而见长，例如 Starburst的TrinoDB（前PrestDB）和基于Apache Hudi的OneHouse。这些工具都以数据缓存以及即席跨数据源查问为指标，各种ETL、ELT工具亦无奈撑持新型的Big Data Federation架构。

大模型大暴发

随着2022年ChatGPT的呈现，AI模型曾经具备在企业应用中遍及的算法根底，妨碍AI利用模型落地的更多的是数据的供应，数据湖和Big Data Federation呈现解决了数据存储和查问问题。而数据供应侧，传统的ETL和ELT和流计算都造成了瓶颈，亦或无奈疾速买通各种简单传统、新兴数据源、亦或无奈用一套代码同时反对AI训练和AI线上的数据差异化需要。

企业数据社群决裂

随着数据驱动和应用的深刻，企业外部的数据使用者也疾速减少，从传统的数据工程师到数据分析师、AI人员甚至销售分析师、财务分析师都有从企业数据仓库当中提取数据的需要。因而，经验了No-SQL，New-SQL各种变动之后，SQL还是成为企业最初面对简单业务剖析的唯一标准。大量分析师、业务部门工程师应用SQL来解决企业数据最初一公里的问题，而简单的非结构化数据处理，留给了业余数据工程师应用Spark、MapReduce、Flink解决。因而，两批人群的需要产生了比拟大的差别，传统ETL，ELT架构无奈满足新型企业使用者的需要。

EtLT架构应运而生！

在上述背景下，数据处理逐渐演变成为EtLT架构：

它拆分了原有ETL和ELT的构造，并力求实时和批量对立在一起解决以满足实时数据仓库和AI利用的需要：

  • E(xtract)抽取：从数据源角度来看，反对传统的线下数据库、传统文件、传统软件同时，还要反对新兴云上数据库、SaaS软件API以及Serverless数据源的抽取；从数据抽取形式来看，须要反对实时CDC（Change Data Capture）对数据库Binlog日志的解析，也要反对实时计算（例如Kafka Streaming），同时也须要反对大批量数据读取（多线程分区读取、限流读取等）。
  • t(ransform)规范化：绝对于ETL和ELT，EtLT多出了一个小t，它的指标是数据规范化（Data Normalization）将简单、异构的抽取进去数据源，疾速地变为指标端可加载的结构化数据，同时，针对CDC实时加载Binlog进行拆分、过滤、字段格局变更，并反对批量和实时形式疾速散发到最终Load阶段。
  • L(oad)加载：精确的说，加载阶段曾经不是简略的数据加载，而是配合Et阶段，将数据源的数据结构的变更、数据内容的变更以适宜数据指标端（Data Target）的模式疾速、精确的加载到数据指标当中，其中，对于数据结构的变动要反对同源数据结构变更（Schema Evolution），数据加载也应该反对大批量加载（Bulk Load）、SaaS加载（Reverse ETL）、JDBC加载等。确保既反对实时数据和数据结构的变动，还要反对大批量数据疾速加载。
  • (T)ransform转化：在云数据仓库、线下数据仓库或新数据联邦的环境下，实现业务逻辑的加工，通常应用SQL形式，实时或批量地将简单业务逻辑精确、疾速变为业务端或者AI端应用的数据。

在EtLT架构下，使用者人群也有了明确的分工：

  • EtL阶段：以数据工程师为主，他们将简单异构的混合数据源，变为数据仓库或者数据联邦可加载的数据，放到数据存储当中，他们无需对企业指标计算规定有深刻了解，但须要对各种源数据和非结构化数据变为结构化数据转化有深刻了解。他们须要确保的是数据的及时性、数据源到结构化数据的准确性。

  • T阶段：以数据分析师、各业务部门数据SQL开发者、AI工程师为主，他们深刻理解企业业务规定，能够将业务规定变为底层结构化数据上的SQL语句进行剖析统计，最终实现企业外部的数据分析和AI利用的实现，他们须要确保的是数据逻辑关系、数据品质以及最终数据后果满足业务需要。

    EtLT 架构开源实际

在新兴的EtLT架构下，其实寰球有不少开源实际，例如在大T局部，DBT帮忙企业分析师和业务开发者疾速基于Snowflake开发相干数据利用。而以大数据工作可视化调度协同(Workflow Orchestration)见长的Apache DolphinScheduler也在布局Task IDE，让企业数据分析师能够在DolphinScheduler上间接调试Hudi、Hive、Presto、ClickHouse等的SQL工作并间接拖拽生成Workflow工作。
作为EtLT架构当中代表Apache SeaTunnel则是从云、本地数据源多种反对开始起步，逐渐反对SaaS和Reverse ETL，大模型数据供应等方面，逐步完善EtLT的幅员，能够看到SeaTunnel最新的Zeta计算引擎把简单的Join，Groupby等简单操作交给最终的数据仓库端来实现，本人只实现归一化、标准化的动作以达到实时数据和批量数据一套代码和高效引擎解决的指标，而大模型反对也放入反对列表当中:

目前Apache SeaTunnel从2022年底退出Apache孵化器的20个连接器倒退到当初1年增长了5倍，目前反对的数据源超过100（https://seatunnel.apache.org/docs/Connector-v2-release-state/），从传统数据库到云上数据库最终到SaaS的反对都在逐步完善。

（参见https://seatunnel.apache.org/docs/2.3.2/category/source-v2浏览最新反对组件）

而Apache SeaTunnel 2.3.0 公布的SeaTunnel Zeta引擎也反对数据分布式CDC，指标源数据表变更（SchemaEvolution）和整库和多表同步诸多Feature和针对大数据量优异的性能博得寰球大量用户（例如，印度第二大运营商Bharti Airtel，新加坡电商Shopee.com，唯品会Vip.com等）。置信随着Connector数据量增多，SeaTunnel会博得更多的企业用户的青眼。

大模型的反对

更有意思的是当初SeaTunnel曾经反对了对大模型训练和向量数据库的撑持，让大模型能够间接和SeaTunnel撑持的100多种数据源交互（参见《图书搜寻畛域重大突破！用 Apache SeaTunnel、Milvus 和 OpenAI 进步书名类似度搜寻精准度和效率》），而当初SeaTunnel更能够利用ChatGPT间接生成SaaS Connector让你的大模型和数据仓库疾速获取互联网上多种信息。

随着AI、云、SaaS的复杂性减少，企业对于实时CDC、SaaS和数据湖、实时数据仓库装载的需要，简略的ETL架构曾经很难满足现有企业的需要，而具备面向企业不同阶段的EtLT架构会在古代数据架构当中大放异彩。

而Apache SeaTunnel的指标就是是“连贯万源，同步如飞”。

SeaTunnel社区十分沉闷，以后版本也在疾速迭代，退出Apache SeaTunnel社区，以后2.3.x版本还有不少中央在疾速变动，也欢送大家一起来奉献！

本文由 白鲸开源科技 提供公布反对！