从 ETL 到 EtLT：数据集成架构演进

本文基于 Apache SeaTunnel 技术分享整理，约 1100 字。

一、数仓架构的三段演进

1990 年至 2015 年以 ETL 架构为主：数据源多为结构化数据（MySQL、Oracle、ERP、CRM 等），计算由 Oracle、DB2 承担，催生了 Informatica、Talend、Kettle 等专业 ETL 软件。

进入 ELT 时代：Hadoop、Hive、MPP 等分布式技术让低成本硬件替代昂贵数据库，原始数据先入仓，再由 MapReduce、Spark 在仓内层层计算。

数据源与目标端同时复杂化：SaaS、云存储、数据湖、实时数仓涌现，靠手写 MR/Spark 程序集成效率低下，专业数据集成平台（如 SeaTunnel）应运而生。

二、EtLT 的提出与含义

2020 年 James Densmore 在《Data Pipelines Pocket Reference》中提出 EtLT，并预测其将成为未来架构趋势。

小写 t 表示轻量标准化（字段筛选、非结构化转结构化），不涉及 join 与聚合；大写 T 表示入仓后的复杂业务计算。

人员随之分工：EtL 阶段由懂数据源特性的数据工程师完成，入仓后的 T 阶段由更懂业务的 AI 科学家、分析师、SQL 开发人员完成。

三、数据集成的核心痛点

数据源多（社区统计已接近 500 个且快速增长）、版本不兼容、同步场景复杂（离线、实时、增量、CDC、多表同步）。

过程监控与指标量化缺失，有限资源下如何实现高吞吐低延时，如何降低对数据源的影响（频繁读 binlog、JDBC 连接过多）。

如何做到数据一致性——不丢失、不重复，对一致性要求高的系统尤为关键。

四、下一代集成平台的应对

以 SeaTunnel 为例，其六大设计目标：简单易用、过程可监控、丰富数据源、全场景支持、数据一致性、省资源。

与引擎解耦的连接器 API（Source / Transform / Sink / CDC），基于 checkpoint 机制集成分布式快照算法，实现 Exactly-once。

Zeta 引擎：无主集群、Pipeline 级容错、动态线程与连接池共享、多表同步，在大量小表场景下性能可提升 2 倍以上。