ELT 已死，EtLT 才是现代数据处理架构的终点！

提到数据处理，经常有人把它简称为 “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 的目标就是是 “连接万源，同步如飞”。