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

作者 高俊 编辑 邓艳琴

在今年2月份的QCon全球软件开发大会（北京站）上，Apache SeaTunnel PPMC Member高俊分享了题为《EtLT架构下的数据集成平台—Apache SeaTunnel》，本文由此整理，复制链接下载完整PPT：https://qcon.infoq.cn/202302/beijing/presentation/5173

此次分享的主要内容分为6块，分别是——

1. ETL到EtLT架构演进

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

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

4. SeaTunnel的核心架构及设计

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

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

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年开始到未来，这是架构的演变趋势。

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

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

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

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是都能解决的。

下一代数据集成平台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。

核心设计和架构

整体架构

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

与引擎解耦的连接器API

这套API设计上的核心是与引擎进行解耦，专门针对数据集成场景，分为Source的API，Transform API，其实就是我们之前说到的小t，Sink API，以及CDC API。借助于Trans lation 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提交。

下一代数据集成引擎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云测试环境下的性能表现。

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

近期规划＆参与社区

SeaTunnel近期计划完成一些新特性的支持，包括：

• Spark3支持

• Flink15、16支持

• Schema evolution

• 多表同步

• ……

对我们的工作感兴趣的小伙伴欢迎加入到SeaTunnel社区！

作者简介

高俊，白鲸开源数据集成产品负责人，10年大数据相关工作，主要从事大数据平台建设、OLAP引擎设计研发工作。开源爱好者，参与多个开源项目的贡献，是Apache DolphinScheduler PMC、Apache SeaTunnel (incubator) PPMC、Trino Contributor以及Apache Ar row-DataFusion Contributor。