数据集成平台 - SeaTunnel V2 架构演进

导读 随着大数据技术的发展，各种各样的数据库、数仓平台、数据湖等技术不断产生，如何将这些数据在各个数据源和目标端之间进行同步、集成已经成为了企业面临的最大的问题。伴随着 Sqoop 从 Apache 退役，实时同步，CDC、整库同步等场景也渐渐被企业所重视和需要。在这个背景下，下一代数据集成平台 Apache SeaTunnel 专注于解决数据集成领域的核心需求，以支持的数据源多、同步速度快、简单易用被众多企业接受和使用。

今天的介绍会围绕下面四点展开：

1. SeaTunnel 的设计目标

2. SeaTunnel 现状

3. SeaTunnel 整体设计

4. 近期规划

01

SeaTunnel 的设计目标

首先和大家分享下 SeaTunnel 的设计目标。

1. 整体目标

作为一个整体的数据平台，SeaTunnel 的总体设计目标是成为一个简单易用的、分布式、可扩展的、支持超大数据级的高吞吐低时延的数据集成平台。

当前，数据集成面临的问题主要有五个：

数据源多：已知的数据库、湖、仓等数据源类型非常多，包括一些 saas 网站、软件等，总数量甚至到达几百种，伴随着新技术的出现，这个数字还在不断上涨；不同数据源之间也容易出现版本不兼容的情况，为数据集成平台造成了一些困难；

质量难以保证，监控缺失：最常出现的问题是数据的丢失和重复，很难保证数据的一致性；另一方面，在数据同步过程中出现问题无法进行回滚或者断点执行；同步过程中的监控缺失也会带来信息的不透明，例如不确定已经同步的数据数量等；

资源使用高：对于 CDC 的同步来说，多个表需要同步时，频繁读取 binlog 对数据源造成的压力较大；数据源侧一些大事务或者 Schema 变更等都会影响下游；JDBC 这类同步，当连接数过多时，有时无法保证数据及时到达；

管理维护难：很多企业离线同步和实时同步是分开的，甚至需要写两套代码，不仅日常管理运维非常困难，在进行离线和实时切换时，数据割接甚至需要人工进行；

技术栈复杂：企业的技术栈差异非常大，选择同步组件时学习成本较高。

02

SeaTunnel 的现状

接下来和大家分享下 SeaTunnel 的现状。

1. 支持连接器数量

目前 SeaTunnel 已经支持 50+ 的连接器数量，包括 Source 和 Sink 的连接器，例如 ClickHouse、ClickHouseFile、Doris 等；还有 10+ 的 Transform；当然，现在还有许多的连接器正在开发。

2. 批流一体

针对同一个连接器，只需要写一套代码，就可以通过配置使用批处理或流处理的模式进行同步处理。流处理的方式中目前实现的纯流和微批两种模式，主要是考虑到要同时支持以 Flink 为代表的纯流和以 Spark 为代表的微批的方式。

3. 多引擎支持

SeaTunnel 的多引擎支持主要是为了更好的兼容企业现有的技术栈，降低企业在引入 SeaTunnel 的技术成本。当前主要支持的引擎为：

Flink：支持多个版本的 Flink 引擎，并支持 Flink 的分布式快照算法等。

Spark：支持 Spark 的微批处理模式，并能像 Flink 一样保存 checkpoint，以支持断点续传和失败会滚。

SeaTunnel Engine：为数据同步设计的专用引擎，主要用于企业环境中没有 Flink 和 Spark 的引擎情况下，想要简单使用 SeaTunnel 同步数据的场景。SeaTunnel Engine 解决了 Flink 和 Spark 等计算引擎中出现的一些问题，例如容错粒度大，JDBC 连接过多，binlog 重复读取等。

4. 性能和一致性

SeaTunnel 拥有高吞吐、精确性和低时延的特性。

高吞吐：当前 SeaTunnel 所有的连接器都做了并行化处理，从而提高整个数据同步的吞吐量。

精确性：SeaTunnel 支持分布式快照的算法，在连接器内部实现了两阶段提交和幂等写入，保证数据只会处理一次。

低延迟：借助实时处理和微批处理的特性，实现数据低延迟。

5. 社区活跃

SeaTunnel 去年年底进入 Apache 孵化，Star 数量骤升，微信用户群已达十多个，近五千人左右的规模。

6. 用户繁多

SeaTunnel 已经被许多用户使用，包括互联网企业、传统企业等。

03

SeaTunnel 整体设计

第三部分给大家介绍下 SeaTunnel 的整体设计。

1. SeaTunnel 整体架构

从之前的介绍中大家应该能感受到，SeaTunnel 的核心就是连接器。SeaTunnel 设计了一套独立于引擎的 API，与引擎解耦，并保证基于 API 开发的连接器都能够运行在多个引擎之上。在实际运行中，通过 Translation 层将连接器包装成对应引擎的连接器执行。例如针对 Spark 执行引擎，在实际执行中，连接器会包装成 Spark 的 Source、Transform 和 Sink，同样的道理也适用于 Flink。当然针对前面提到的 SeaTunnel Engine，就不存在转换的这一步了。转换后，SeaTunnel 会将作业提交到对应的引擎中执行，将数据同步到对应的存储中。当然，作为一个完整的系统，以及为了用户的友好程度，SeaTunnel 还提供了 Web 页面，包括代码开发模式的提交，或者引导式任务提交，调度服务，监控和报警服务等。

整个架构涉及六大关键点：

Engine Independent Connector API：独立的连接器 API

Connector Translation：连接器翻译层

Source Connector：Source 连接器

Transform Connector：Transform 连接器

Sink Connector：Sink 连接器

多引擎支持

2. SeaTunnel 使用方式

SeaTunnel 的使用方式非常简单，只需要填写配置文件，SeaTunnel 会自动解析并生成任务，进行提交开启同步。

3. SeaTunnel 执行流程

首先会针对来源引擎不同的 Source Connector 进行翻译，翻译后由 Source Connector 开始读取数据。

接下来由 Transform Connector 进行数据的标准化

最终通过 Sink Connector 进行写出操作。

当然上述流程中还涉及到引擎内部的一些处理，包括分流，Spark 和 Flink支持 SQL 的语法等。

4. Connector 执行流程

目前可以分为 Driver 端和 Worker 端。在 Driver 端存在SourceCoordinator 管理 Worker端的 Source Split，之后存在枚举器将拆分后的数据任务交给 SourceReader 进行读取。在读取之后会将数据发送给 SinkWriter，此时会对分布式快照进行处理，最终把数据写入目标端。

5. Engine Independent Connector API

独立于引擎的 API 是在今年 3 月份正式进行设计的，核心设计目标是与引擎解耦，专门为数据集成的场景设计。核心目标有以下四点：

多引擎支持：定义一套 SeaTunnel 自己的 API，解耦底层计算引擎

多版本支持：因为 Connector 和不同引擎的 Connector 之间设计了 Transform 层，就可以解决引擎多版本问题，Transform 可以针对不同的版本进行翻译。

流批一体：同样的一套代码，支持在批处理的场景下使用，也支持在流处理的场景下使用。

JDBC 复用/数据库日志多表解析：解决 JDBC 连接过多的情况，尽可能通过一个连接同步多张表的数据。同理，对于一个库下的表，尽可能也只同步一次，多个表独立解析即可。

6. Connector Translation

正如之前介绍了，使用 Spark Connector API 可以将独立 API 翻译成Spark 的连接器进行执行，同理也适用于 Flink。

7. Source API

Source API 主要支持五个特性：

通过 Boundedness 接口，实现批流统一。

通过 SourceReader 和 SourceSplit 支持并行读取。

通过 SourceSplit 和 Enumerator 支持动态发现分片。这个在流处理中更为常见，需要及时发现新增的文件分片；还有一种场景是通过正则表达式匹配 Topic，当新的可以匹配上的 Topic 出现的时候，可以自动读取。

通过 SupportCoordinate 和 SourceEvent 支持协调读取。这个主要用于 CDC 同步场景，在初次同步数据时，需要以批处理的方式全量同步数据，同步完成后主动切换成流处理的方式同步增量数据。

通过 SnapshotState 支持状态存储和恢复。当前针对 Flink 引擎是直接使用 Flink 自带的 Snapshot 功能，对于Spark引擎，SesTunnel 定制实现了 Snapshot 保存到 HDFS 的功能。

8. CoordinatedSource Connector

这个连接器支持协调器，主要用于 CDC 的场景。它的主要执行流程为：通过 SourceSplitEnumerator 将一些信息（包括 checkpoint、批流情况等）分发到 ReaderThread 里面的 SourceReader 中。

9. ParallelSource Connector

这个连接器不支持协调器，支持并行处理。具体实现中需要在连接器中定义分区的逻辑，自定义分区的算法。该连接器类型支持多并发。

10. Sink Api

Sink API 主要是配合 Source 支持 Exactly Once 的语义。Sink API 包含几个部分：

Sink Writer，接收上游数据并写入目标端。

State 存储，支持状态存储，由 Connector 将状态存储在 HDFS 中，支持基于状态重启 Connector。

支持分布式事务，支持两阶段提交的分布式事务，配合引擎的 checkpoint 机制，保证 Sink 数据只写一次。

Commiter，支持每个 Task 独立进行事务的提交，主要依赖 Flink 提供的这样的功能。

支持聚合提交，主要用于 Spark 场景下，checkpoint 状态保存，需要使用到。

11. GlobalCommit Run In Driver

Sink API 内部 Commit 的类型之一，在 Driver 端运行，也就是上面提到的聚合提交。在这种模式下，Global Commiter 运行在 Driver 端，但是SinkWriter 运行在 Worker 端，主要适用于 Spark v2.3+ 以及 Flink v1.12+ 版本的情况。

12. GlobalCommit Run In Worker

Sink API 内部 Commit 的类型之一。这种模式下，Global Commiter 和SinkWriter 均运行在 Worker 端，主要适用于 Flink v1.11- 的版本，Spark 不适用。

13. Commit In Worker

Sink API 内部 Commit 的类型之一。这种模式下支持在 Worker 端，每个 Task 单独的 Commit 操作。这个模式适用于 Flink 所有版本，Spark 不适用。

14. SeaTunnel Table & Catalog API

这套 API 主要为面向应用的 API，能够简化同步配置，提供可视化作业配置的基础。主要包含下面四个方面：

数据源管理：SeaTunnel 定义了一套 API 来支持创建数据源插件，基于 SPI 实现后即可集成该数据源的配置、连接测试工作等。

元数据获取：主要用于引导式界面，选择数据源后，支持自动获取元数据的表结构，方便可视化的配置同步作业的源和目标端的表名映射，字段映射等。

数据类型定义：所有连接器都使用 SeaTunnel 定义的格式，在 Connector Translation 会转换为对应引擎的格式。

连接器创建：SeaTunnel 提供了一套 API 用于创建自动获取信息创建 Source、Sink 等实例。

04

SeaTunnel 近期规划

SeaTunnel 的核心目标为更多、更快、更好用，为了达到这个目标，SeaTunnel 近期规划目标为以下三点：

连接器数量翻倍，总共能支持 80+ 连接器。

发布 SeaTunnel Web，支持可视化作业管理，支持编程式和引导式的作业配置，支持内部调度（处理简单任务，crontab 为主）和第三方调度（以 dolphin scheduler 为主）。

发布 SeaTunnel Engine，支持通过减少 JDBC 的连接和 binlog 的重复读取以达到更省资源的效果；通过拆分任务为 pipeline，pipeline 之间的报错不会相互影响，也支持独立重启操作；借助共享线程以及底层的处理，推动整体同步任务更快的完成；过程中加入监控指标，监控同步任务运行中 Connector 的运行状态，包括数据量和数据质量。

 

 

来源：志明与数据

作者：高俊