随着大数据技术的发展，各种各样的数据库、数仓平台、数据湖等技术不断产生，如何将这些数据在各个数据源和目标端之间进行同步、集成已经成为了企业面临的最大的问题。伴随着 Sqoop 从 Apache 退役，实时同步，CDC、整库同步等场景也渐渐被企业所重视和需要。在这个背景下，下一代数据集成平台 Apache SeaTunnel 专注于解决数据集成领域的核心需求，以支持的数据源多、同步速度快、简单易用被众多企业接受和使用。
一、SeaTunnel 的设计目标
首先和大家分享下 SeaTunnel 的设计目标。
1、整体目标
作为一个整体的数据平台，SeaTunnel 的总体设计目标是成为一个简单易用的、分布式、可扩展的、支持超大数据级的高吞吐低时延的数据集成平台。
当前，数据集成面临的问题主要有五个：
- 数据源多：已知的数据库、湖、仓等数据源类型非常多，包括一些 saas 网站、软件等，总数量甚至到达几百种，伴随着新技术的出现，这个数字还在不断上涨；不同数据源之间也容易出现版本不兼容的情况，为数据集成平台造成了一些困难；
- 质量难以保证，监控缺失：最常出现的问题是数据的丢失和重复，很难保证数据的一致性；另一方面，在数据同步过程中出现问题无法进行回滚或者断点执行；同步过程中的监控缺失也会带来信息的不透明，例如不确定已经同步的数据数量等；
- 资源使用高：对于 CDC 的同步来说，多个表需要同步时，频繁读取 binlog 对数据源造成的压力较大；数据源侧一些大事务或者 Schema 变更等都会影响下游；JDBC 这类同步，当连接数过多时，有时无法保证数据及时到达；
- 管理维护难：很多企业离线同步和实时同步是分开的，甚至需要写两套代码，不仅日常管理运维非常困难，在进行离线和实时切换时，数据割接甚至需要人工进行；
- 技术栈复杂：企业的技术栈差异非常大，选择同步组件时学习成本较高。
二、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 已经被许多用户使用，包括互联网企业、传统企业等。
三、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 等实例。
四、SeaTunnel 近期规划
SeaTunnel 的核心目标为更多、更快、更好用，为了达到这个目标，SeaTunnel 近期规划目标为以下三点：
- 连接器数量翻倍，总共能支持 80+ 连接器。
- 发布 SeaTunnel Web，支持可视化作业管理，支持编程式和引导式的作业配置，支持内部调度（处理简单任务，crontab 为主）和第三方调度（以 dolphin scheduler 为主）。
- 发布 SeaTunnel Engine，支持通过减少 JDBC 的连接和 binlog 的重复读取以达到更省资源的效果；通过拆分任务为 pipeline，pipeline 之间的报错不会相互影响，也支持独立重启操作；借助共享线程以及底层的处理，推动整体同步任务更快的完成；过程中加入监控指标，监控同步任务运行中 Connector 的运行状态，包括数据量和数据质量。
