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

Posted 2023-03-20

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 会有更好的性能表现。

「集成架构」ETL工具大比拼：Talend vs Pentaho

Talend和Pentaho的区别

数据总是巨大的，任何行业都必须存储这些“数据”，因为它带有巨大的信息，从而导致他们的战略规划。正如人们需要房子感到安全一样，数据也必须得到保障。这个数据主页在技术上称为数据仓库。

此外，并非所有数据都是真实数据。企业的增长与数据的增长成正比。而这种增长可能会对数据效率产生影响。为了消除这种情况，数据必须没有重复和错误，因为这样的数据不会产生预期的结果。这是数据集成很重要的地方。当数据转向可访问数据时，它使员工的工作变得更加容易，让他专注于有效的计划和预测。

获得此数据后，重要的是从系统中提取数据，并通过各种工具在环境中进一步分析以满足业务需求。这些工具通常称为ETL（提取，转换和加载）工具，Talend和Pentaho是两种这样的ETL工具，广泛用于各个行业。

在深入研究之前，让我们在这里了解基础知识。

以下是ETL工具实际含义的简单说明：

• 提取：通常从化合物数据库收集数据。'E'的功能是从源读取数据。

• 变换：与'E'相比，'T'功能相当具有挑战性，但并不复杂。它遵循一个简单的过程，其中提取的数据从其原始形式适应它需要的形式（目标），以便它可以与另一个数据库相关联。尽管该过程看起来很简单，但该过程涉及通过从多个数据库合并和同步来实现规则或查找表

• 加载：“L”功能仅遵循一条路线。将数据写入目标数据库。

管理员在没有任何工具的帮助下关联不同数据库是一项艰巨的任务。因此，这些工具不仅可以简化工作，还可以节省时间和金钱。

Talend与Pentaho之间的比较（信息图表）

以下是Talend与Pentaho的比较

Talend与Pentaho之间的主要区别

Talend和Pentaho Kettle在他们自己的市场中是无可挑剔的工具，下面是显着的差异：

Talend：

1. Talend是一个开源数据集成工具，而Pentaho Kettle是一个商业开源数据集成工具

2. Talend提供与并发数据库和其他形式数据的有限连接，但具有连接到数据源的Java驱动程序的依赖因子，而Pentaho提供与大量数据库和其他形式数据的广泛连接

3. Talend的支持主要存在于美国，而Pentaho的支持不仅存在于美国，而且还针对英国，亚太市场

虽然Talend和Pentaho工具都具有相似的特性，但是需要理解Pentaho Kettle具有轻微优势的GUI。

下面我们看到Pentaho Kettle到Talend的显着特征和突出产品：

1. Pentaho水壶比Talend快两倍

2. 与Talend的GUI相比，Pentaho kettle的GUI更易于运行

3. 适应系统

4. 可以轻松处理不同的数据集群

5. 在转换处理时可以在许多机器上用作从属服务器

6. 拥有成本

当存在已经运行/正在实现Java程序的现有系统时，Talend更有用。

下面列出了Talend代码生成方法的优点

• 轻松部署（适用于独立Java应用程序）

• 节省时间

• 经济有效

任何人都同意这样一个事实，即实现ETL工具的整个目的是帮助实体利用数据集成来使用各种部署模型和基础架构来规划其策略。这些工具需要对现有系统和目标系统都具有灵活性，并提供广泛的交付能力。虽然Talend是一个开源数据集成工具，但如果他们利用其提供更多附加功能的订阅，则可以从该工具中获益更多。

Talend与Pentaho之间的比较表

比较Talend和Pentaho Kettle是一项具有挑战性的任务。不是因为一个人向另一个人挑战的挑战，而仅仅是因为这些工具在彼此之间提供了相似之处。

Talend和Pentaho Kettle可以与两个不同的人进行比较，他们通过自己的优势，能力和能力为社会提供理想的结果。

因此，人们应该非常重视理解这两种工具所提供的并不是最重要的，而是; 取决于辛迪加/企业在战略要求和规划方法方面的回应方式。

比较表详细设计了这两种工具如何在一般情况下发挥作用。

* Pentaho是一个BI套件，使用名为Kettle的产品进行ETL

Talend遵循代码生成器方法，处理数据管理网络

Pentaho Kettle遵循元驱动方法，也是网络中的解释器

结论 - Talend与Pentaho

Talend和Pentaho Kettle都是强大的，用户友好的，可靠的开源工具。

Talend更像是我们在数据集成，数据质量和数据管理平台方面遇到的所有复杂挑战的答案

Pentaho Kettle更像是一款易于使用的智能商务智能套件

如上所述，虽然说明了两种工具的正面比较，但结果取决于最终客户的需求方式。

原文：https://www.educba.com/talend-vs-pentaho/

本文：https://pub.intelligentx.net/talend-vs-pentaho-8-useful-comparisons-learn

讨论：请加入知识星球或者小红圈【首席架构师圈】

以上是关于从ETL走向EtLT架构，下一代数据集成平台Apache SeaTunnel核心设计思路解析的主要内容，如果未能解决你的问题，请参考以下文章

「集成架构」ETL工具大比拼：Talend vs Pentaho

新一代商业智能分析平台的九种应用

kettle集成开发及源代码分析

今日指数项目之ETL数据业务开发(功能实现)

AR眼镜走向独立，从一个配件开始

BAT架构师2019年最新总结，从程序员到CTO，从专业走向卓越