Apache SeaTunnel 分布式数据集成平台

Posted 2022-03-26 大数据生态

当前版本：2.1.0

1. 简介

随着互联网流量爆发式增长，越来越多的公司业务需要支撑海量数据存储，对高并发、高可用、高可扩展性等特性提出了更高的要求，这促使各种类型的数据库快速发展，至今常见数据库已经达到 200 多个。与之相伴的便是，各种数据库之间的同步与转换需求激增，数据集成便成了大数据领域的一个亟需优秀解决方案的方向。当前市面上没有一个简单易用且支持每天数百亿条海量数据同步的开源软件，于是 SeaTunnel 应运而生。

SeaTunnel 是一个非常好用的、超高性能的、分布式数据集成平台，架构于 Apache Spark 和 Apache Flink 之上，实现海量数据的实时同步与转换。每天可以稳定高效的同步数百亿数据，目前已接近百家公司在生产上使用。

SeaTunnel 原名 Waterdrop，于 2017 年由乐视创建，并于同年在 GitHub 上开源，2021 年 10 月改名为 SeaTunnel。2021 年 12 月，SeaTunnel 正式通过世界顶级开源组织 Apache 软件基金会的投票决议，以全票通过的优秀表现正式成为 Apache 孵化器项目，成为 Apache 基金会中第一个诞生自中国的数据集成平台项目。

2. 目标

SeaTunnel 尽所能为您解决海量数据同步中可能遇到的问题：

使用 Spark、Flink 作为底层数据同步引擎使其具备分布式执行能力，提高数据同步的吞吐性能;

集成多种能力缩减 Spark、Flink 应用到生产环境的周期与复杂度;

利用可插拔的插件体系支持超过 100 种数据源;

引入管理与调度能力做到自动化的数据同步任务管理;

特定场景做端到端的优化提升数据同步的数据一致性;

开放插件化与 API 集成能力帮助企业实现快速定制与集成;

3. 使用场景

SeaTunnel 的使用场景广阔，包括如下场景：

海量数据同步

海量数据集成

海量数据 ETL

海量数据聚合

多源数据处理

4. 特性

数据集成平台要围绕解决海量数据同步这一目标进行，核心理念是保持海量数据能快速同步的同时还能保持数据的一致性，具体到 Apache SeaTunnel 来说，Apache SeaTunnel 具有以下核心特性:

高扩展性：模块化和插件化，支持热插拔, 带来更好的扩展性;

插件丰富：内置丰富插件，支持各种数据产品的传输和集成;

成熟稳定：经历大规模生产环境使用和海量数据的检验，具有高性能、海量数据的处理能力;

简单易用：特有的架构设计，简单易用，灵活配置，无需开发;

SQL支持：支持通过 SQL 进行数据处理和聚合;

流式支持：支持实时流式处理;

5. 架构与工作流程

Apache SeaTunnel 发展上有 2 个大版本，1.x 版本基于 Spark 构建，现在在打造的 2.x 既支持 Spark 又支持 Flink。在架构设计上，Apache SeaTunnel 参考了 Presto 的 SPI 化思想，有很好的插件化体系设计。

在技术选型时，Apache SeaTunnel 主要考虑技术成熟度和社区活跃性。Spark、Flink 都是非常优秀并且流行的大数据计算框架，所以 1.x 版本选了 Spark，2.x 版本将架构设计的更具扩展性，用户可以选择 Spark 或 Flink 集群来做 Apache SeaTunnel 的计算层，当然架构扩展性的考虑也是为以后支持更多引擎准备，说不定已经有某个更先进的计算引擎在路上，也说不定 Apache SeaTunnel 社区自己会实现一个为数据同步量身打造的引擎。

如下图是 Apache SeaTunnel 的整个工作流程，数据处理流水线由 Source、Sink 以及多个 Transform 构成，以满足多种数据处理需求:

Source[Data Source Input] -> Transform[Data Processing] -> Sink[Result Output]

如果用户习惯了 SQL，也可以直接使用 SQL 构建数据处理管道，更加简单高效。目前，SeaTunnel 支持的 Transform 列表也在扩展中。你也可以开发自己的数据处理插件。

6. SeaTunnel 支持的插件

Source 插件：

File

Hdfs

Kafka

Druid

InfluxDB

S3

Socket

自研输入插件

Transform 插件：

Add

Checksum

Convert

Date

Drop

Grok

Json

Kv

Lowercase

Remove

Rename

Repartition

Replace

Sample

Split

Sql

Table

Truncate

Uppercase

Uuid

自研过滤器插件

Sink 插件:

Elasticsearch

File

Hdfs

Jdbc

Kafka

Druid

InfluxDB

mysql

S3

Stdout

自研输出插件

7. 生产应用案例

唯品会：唯品会早在 1.0 版本时就引用了 SeaTunnel，使用 SeaTunnel 进行一些 Hive 到 ClickHouse 之间数据交互的工作。

Oppo：基于 SeaTunnel 进行的二次开发搭建 ETL 特征生产处理平台。

Bilibili：基于 SeaTunnel 二次开发实现 AlterEgo 项目。SeaTunnel 在 B 站每天完成千亿级记录、百T级数据的出入仓，解决了电商、直播、创作中心等场景核心任务出入仓难题。

微博：微博某业务有数百个实时流式计算任务使用内部定制版 SeaTunnel，以及其子项目 Guardian 做 Seatunnel On Yarn 的任务监控。

新浪大数据运维分析平台：新浪运维数据分析平台使用 SeaTunnel 为新浪新闻，CDN 等服务做运维大数据的实时和离线分析，并写入 Clickhouse。

搜狗奇点系统：搜狗奇点系统使用 SeaTunnel 作为 ETL 工具, 帮助建立实时数仓体系。

趣头条数据中心：使用 SeaTunnel 支撑 MySQL To Hive 的离线 ETL 任务、实时 Hive To Clickhouse 的 backfill 技术支撑，很好的 cover 离线、实时大部分任务场景。

永辉超市子公司-永辉云创会员电商数据分析平台：SeaTunnel 为永辉云创旗下新零售品牌永辉生活提供电商用户行为数据实时流式与离线 SQL 计算。

水滴筹：水滴筹在 Yarn 上使用 SeaTunnel 做实时流式以及定时的离线批处理，每天处理 3～4T 的数据量，最终将数据写入 Clickhouse。

腾讯云：将业务服务的各种日志收集到 Apache Kafka 中，通过 Seatunnel 消费和提取 Apache Kafka 中的部分数据，然后存储到 Clickhouse 中。

参考：

Introduction

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