从ETL走向EtLT架构，下一代数据集成平台Apache SeaTunnel核心设计思路解析

1. ETL 到 EtLT 架构演进

2. 数据集成领域的痛点 & 常见的解决方

3. 下一代数据集成平台 ApacheSeaTunnel

4. SeaTunnel 的核心架构及设计

5. 下一代数据集成引擎 SeaTunnelZeta

6. 近期规划 & 如何快速参与社区建设

1 ETL 到 EtLT 架构演进

为让你更好地理解接下来的内容，我们先来介绍一下数仓从 ETL 到 EtLT 的架构演进。

回顾过去，我们会发现其实整个数仓在 1990 年到 2015 年都是 ETL 的架构，在这个架构下数据源主要是结构化数据，如 MySQL、SQL、Server、Oracle、ERP、CRM 等。同时，数据仓库计算主要由 OLTP 时代的 Oracle，DB2 来承担，就是用来做查询和存储历史数据的数据库。在这个时代，其实 Oracle、DB2 这样的数据库本身计算能力还是比较弱的，很难满足所有场景的数仓计算任务需求。

在这个过程中就诞生了 Information、Talend，还有 Kettle 等专业化 ETL 软件。这些软件目前很多企业还在用，随着新的技术的出现，比如 MPP 技术，还有分布式架构技术流行，比如 Hadoop、Hive 等，这些技术的出现让大家发现，其实可以用一些很低成本的硬件，代替以前昂贵的 Oracle、DB 的硬件服务。伴随着这些技术，我们已经进入到了 ELT 时代。

这个时代的核心特性，来自不同数据源的数据，包括结构化非结构化数据，日志等等，其实都可以不经过任何处理，或者只是经过一些简单的标准化，比如清洗、字数删减等，就可以加载到数仓中。在数仓中再经过 MapReduce、Spark 等引擎层层计算。这个时候因为数据源还不是太多，太复杂，大家处理从数据源到数仓的过程，主要还是通过写 MR 程序或者 写 Spark 程序来完成。

随着数据源越来越复杂，很多新兴的技术不断出现，数据源更加复杂，一些 SaaS 服务和云上数据存储出现了很多，进一步导致数据源更复杂。同时，在目标端，数仓和以前的数仓已经很不一样了，随着数据湖、实时数仓技术的出现，数据集成的目标端也更加复杂。这时，如果还像以前那样由数据工程师去开发 MR 程序，集成效率会非常低，这时迫切需要一些专业的团队和专业工具，来解决这样的 ELT 过程。

于是，数据集成这样一个领域就诞生了。SeaTunnel 就是下一代数据集成的平台。

在 ELT 场景下，有个概念叫做 EtLT，这里的小 t 区别于后面的大写 T，表示数据标准化的事情，比如字段筛选，对非结构化数据进行结构化转换等，它不涉及到 join，也不涉及到聚合。我们把这两套体系下的人员也是进行了拆分，数据 EL 的过程，也就是前面 EtL 的过程，主要由一些不需要太懂业务的数据工程师来处理，他们只需要足够了解不同数据源之间的数据特性和差异就可以。当数据加载到数仓后，再由专业的 AI 数据科学家、数据分析师、SQL 开发人员等更懂业务的人，基于原始数据去做计算。

这就是从 ETL 到 EtLT 架构的演进历程。2020 年，James Densmore 在《Data Pipelines Pocket Reference》这本书中提出了 EtLT 这个架构，他预测从 2020 年开始到未来，这是架构的演变趋势。

2 数据集成领域的痛点 & 常见的解决方案

由此，我们再引申到数据集成领域的一些常见的痛点和解决方案。

我在之前的技术探索中发现了一些数据集成领域的核心痛点，包括：

1.数据源多，SeaTunnel 社区目前统计到的数据源已经接近 500 个而且还在迅速的增长；版本不兼容，随着数据源版本迭代，兼容性上会出现问题，而且随着新技术的不断出现，数据集成领域需要快速地适配数据源，这是需要解决的一个核心痛点；

2.同步场景复杂：数据同步包括离线、实时，全量、增量同步，CDC，多表同步等，CDC 的核心需求是要解决直接读物数据库的变更日志并解析，将其应用到下游，这个过程中，如何解析不同数据库的日志数据格式，事务处理，整库同步，分库分表等很多场景都有待适配支持；

3. 过程如何监控、指标如何量化：同步过程中的监控缺失会带来信息的不透明，例如不确定已经同步的数据数量等；

4. 有限资源下如何实现高吞吐、低延时，以降低成本；

5. 如何降低对数据源的影响：多个表需要实时同步时，频繁读取 binlog 对数据源造成的压力较大，影响数据源的稳定性。同时 JDBC 连接数过多时，也会导致数据源不稳定，甚至在数据源限制了最大连接数的情况下，同步作业可能无法正常运行。数据集成平台需要尽量降低对数据源的影响，比如减少连接占用，限制同步速度等。

6. 如何做到数据一致性、不丢失、不重复：有些数据一致性要求高的系统，是不允许出现数据丢失和重复的。

为了满足这些需求，我们需要一个简单易用、易扩展、易管理、已维护的数据集成产品。我们为此做了方案调研。

我们发现，不同的数据集成产品大多是针对以下几个场景：

1. 全量离线增量

这个场景下，早期大家使用较多的是 Sqoop，它之前也是 Apache 基金会下的项目，但它的核心问题在于支持的数据源很少，而且依赖于 MapReduce 架构，很慢。而且它已经从 Apache 退役了，属于是上一代的数据集成项目了。

目前 DataX 也比较流行，这是一个很好用的数据同步工具，但问题在于其开源版本不支持实时同步，所以无法支持多级并行处理。而且因为内部设计没有分布式快照算法，无法保证数据的一致性，且无法支持断点续传。

2. 实时同步场景

在实时场景下，大家用得比较多的是 Flink 和 Spark Streaming。但由于这两个产品的定位是计算引擎，核心能力其实更多的是在于处理复杂的数据计算，很难像一个专业的数据同步产品一样支持足够多的数据源。而且两者从设计上来说容错力比较大，这就会导致在做多表同步时，一张表同步失败，整个作业都需要停掉重新执行。而且有些情况下需要写 Flink 和 Spark 代码，学习成本也有。

3. CDC 场景

对于 CDC 场景，目前大家使用比较多的还是 Flink CDC，但它的问题在于其底层还是 Flink，Flink 本身存在的问题它也有，而且不支持表结构的变更和单个 Source 读取多表（每个 Source 只能读取一张表，意味着 CDC 同步时，需要使用的 JDBC 连接数和表的个数相等）。

综合下来，在数据集成场景下，用户如果想要支持所有场景，这三个组件都需要用到，整体的架构会非常复杂，而且需要公司有大数据平台，学习成本也相当高，在不同场景下，不同的代码管理也很难。

这些痛点，下一代数据集成平台 SeaTunnel 是都能解决的。

3 下一代数据集成平台 Apache SeaTunnel

6 大设计目标

SeaTunnel 的设计目标主要有总结为 6 个。第一个是它一定要简单易用，能够通过很少的配置，一些简单的命令，就能去起一个同步作业。

第二个点是它一定要能够做到同步的过程可监控，指标一定要可量化，让用户清晰地知道当前同步作业的情况，不能是一个黑盒。

第三个是要有丰富的数据源支持，社区统计到的 500 多个数据源，目前社区已经支持了 100 多个，而且数据源支持增速很快，基本上一个 Q 能增长四五十个新数据源。

第四个很重要是要做到全场景支持，支持实时同步、离线同步、增量全量、CDC、多表同步等场景，不需要用户用各种工具去组合。

第五是要解决数据一致性的问题，保证那些对于数据一致性要求高的系统能够做到不丢失数据，数据也重复。

最后在性能上，我们需要在满足这些功能的基础上，思考如何减少资源的占用，减少对数据源的影响。

项目发展历程

这里也简单讲一下 SeaTunnel 项目的发展历程。这个项目其实在 2017 年的时候就已经开源了，当时是叫 Waterdrop，有些公司可能早期用的还是 OPPO 的版本，我们在 2021 年 12 月份贡献给了 Apache 基金会，全票通过。经过三个月，在 2022 年 3 月份我们发布了第一个 SeaTunnel 版本，10 月份完成了一次大版本的重构，重构主要带来的效果是它能够支持多引擎的运行，而且将整个设计和引擎进行了重构，扩展性更好了。11 月，我们发布 SeaTunnel Zeta 这样一个专门用来做数据集成的引擎，12 月份就支持了 CDC 连接器，同时连接器的数量突破了 100 个。今年，我们很快会发布新的版本，可以支持 Flink 和 Spark 更高版本，Zeta Engine 会支持多表同步，表结构变更等特性。

用户遍布全球

SeaTunnel 社区目前有接近 5000 人，社区的贡献者超过 200，PR 的提交速度和合并的速度也比较快。另外，我们的用户覆盖了国内的互联网企业，比如 B 站、腾讯云等企业。在海外，Shopee，印度第二大电信运营商巴帝电信等也在使用 SeaTunnel。

4
核心设计和架构

整体架构

SeaTunnel 架构主要分为三个模块，第一个是数据源，包含了一些国内外的数据库；第二部分是目标端，其实目标端和数据源可以合成在一起，都叫数据源，主要也是数据库，SaaS 服务，以及数据湖、仓等产品组件。从数据源到目标端，我们定义了一套专门用来做数据同步的 API，它是和引擎解耦的，理论上能扩展到很多引擎里。目前我们支持的引擎包括 SeaTunnel Zeta，Flink 和 Spark。

与引擎解耦的连接器 API

这套 API 设计上的核心是与引擎进行解耦，专门针对数据集成场景，分为 Source 的 API，Transform API，其实就是我们之前说到的小 t, Sink API，以及 CDC API。借助于 Translation API 进行翻译，可以让这些连接器在不同的引擎上执行。

在整个所有的引擎里，连接器 API 基于 checkpoint 机制，核心的目标是能够集成不同引擎里面的分布式快照算法，并应用底层引擎的 checkpoint 能力，实现两阶段提交等特性，保证数据的一致性。

Source Connector

基于这套 API，我们实现了Source 连接器，以 JDBC 连接器为例，支持离线和实时两种运⾏⽅式，同⼀个连接器，只需要在 env 配置中指定 job.mode 为 BATCH 或 STREAMING 即可轻松切换离线和实时同步两种模式。

Source 连接器主要提供的能力包含并行读取、动态发现分片、字段投影、Exactly-once 语义保证，底层借助了引擎提供的 checkpoint 能力，加上 Source API 支持底层的引擎调用 checkpoint API，能够保证同步中数据不会丢失，也不会重复。

Sink Connector

Sink Connector 主要支持的特性包括：

• SaveMode 支持，灵活选择目标表现有数据的处理⽅式
• 自动建表，支持建表模板修改，多表同步场景下解放双⼿
• Exactly-once 语义支持，数据不丢失也不会重复，CheckPoint 能⼒适配 Zeta,Spark,Flink 三种引擎
• CDC 支持，支持处理数据库日志事件

Transform Connector

Transform Connector 的主要功能包括

• 支持复制一列到新列
• 支持字段改名、改顺序、类型修改、删除列
• 支持替换数据中的内容
• 支持将一列拆分成多列

CDC Connector 设计

CDC Connector 主要具有以 下功能：

• 支持无锁并行快照历史数据
• 支持动态加表
• 支持分库分表和多结构表读取
• 支持 Schemaevolution
• 支持 Checkpoint 流程，保证数据不丢失不重复
• 支持离线批量 CDC 同步

Checkpoint 功能设计

最后需要强调的是，SeaTunnel 所有的 Connector 都是基于 checkpoint 逻辑来设计的。作业从 Split 枚举器开始，进入到 Source 的 reader 中，经过读取后将数据发送给 Sink Writer，最终由 AggregateCommitter 提交。

5 下一代数据集成引擎 SeaTunnel Zeta

下一代数据集成引擎 SeaTunnel Zeta 的定位是一个简单易用，全场景数据集成的专用引擎，并在此基础上实现更快、更稳定、更省资源。

SeaTunnel Zeta 集群管理

SeaTunnel Zeta 的集群管理方式有以下几个特点：

不需要依赖三方组件，不依赖大数据平台

• 无主（自选主）
• WAL，整个集群重启也可恢复之前正在运行的作业
• 支持分布式快照算法，保障数据一致性

接下来介绍一下 SeaTunnel Zeta 引擎里的一些专有属性，以及其解决了什么核心问题。

SeaTunnel Zeta PipelineBase Failover

• 无论是批作业，还是流作业，以 Pipeline 为单位进行资源分配，Pipeline 分配到所需资源后即可开始执行，不会等待所有 task 都获取到资源。这可以解决 Flink 等引擎在数据同步时的一些痛点问题，也就是作业中有多个 Source 和 Sink 进行同步时，如果任何一端出现问题，整个作业都会被标为失败而被停止。
• 以 Pipeline 为粒度进行容错（Checkpoint, 状态回滚），目标表出现问题后，只会影响到上下游任务，其他任务会正常执行。
• 问题解决后，支持对单个 Pipeline 进行手工恢复。

SeaTunnel Zeta 动态线程共享

动态线程核心是要减少 CDC 多表同步，尤其是大量小表存在的场景下，由于资源有限而且线程多而导致性能下降的问题。动态线程可以根据运行时间和数据量对线程进行动态匹配，节约资源。经过测试，在单个 JVM 场景下运行 500 个小表的 job，开启动态线程之后性能可以提升 2 倍以上。

SeaTunnel Zeta 连接池共享

连接池共享主要用于解决大量 JDBC 占用的场景，比如单个非常大的表，有很多个并行 Task 去处理，或者多表离线同步，多表 CDC 同步等。连接池共享可以让同一个 TaskExecutionService 节点上的同一个 Job 共享 JDBC 连接，从而减少 JDBC 使用。

SeaTunnel Zeta 多表同步

最后是多表同步，主要应用于 CDC Source 读完了之后进行 tablel partition transform 处理，将数据分发到不同的 Sink 里，每个 Sink 会处理一张表的数据。在这个过程中会利用到连接器共享来降低 JDBC 连接的使用，以及动态线程共享来降低线程使用，从而提高性能。

性能对比

我们进行了性能测试，主要包括 SeaTunnel 从 MySQL 数据同步至 Hive 等本地环境下，以及 MySQL 同步至 S3 云测试环境下的性能表现。

测试环境：

本地测试场景：MySQL-Hive, Postgres-Hive, SQLServer-Hive,Orache-Hive

云测试场景：MySQL-S3列数：32，基本包含大部分数据类型

行数：3000w 行

Hive 文件 text 格式 18G

测试节点：1， 8C16G

结果：

本地测试：SeaTunnel Zeta VS DataX

SeaTunnel Zeta 比 DataX 同步数据快 30-50% 左右。

内存对 SeaTunnel Zeta 的性能没有显著影响。

云数据同步：SeaTunnel 在 MySQL 到 S3 场景下性能是 Airbyte 的 30 多，是 AWS DMS 和 Glue 的 2 到 5 倍。

可以看到，SeaTunnel 在很小的内存下就能够完成同步，而且还是在单点的情况下，因为 Zeta 支持分布式，相信在数量级更大，多机并行下，SeaTunnel 会有更好的性能表现。