引言

在现代大数据应用中，数据集成和同步成为企业数据管理的关键环节。随着数据源和数据库的多样化，如何高效地进行数据集成成为企业面临的重要挑战。

Apache SeaTunnel 作为一款开源的数据集成工具，致力于解决这一问题。本文将详细介绍 SeaTunnel 的架构、工作流程、Connector 设计及实现，并分享其最新的发展与未来展望。

摘要

Apache SeaTunnel 是一个高效、易用的数据集成工具，支持多种数据源和计算引擎。

本文首先介绍 SeaTunnel 的背景和设计目标，接着详细解析其架构演变和工作流程，重点探讨 SeaTunnel Connector 和 Catalog API 的设计与实现。

最后，本文展望了 SeaTunnel 的未来发展方向，旨在帮助读者全面理解和应用这款优秀的开源工具。

自我介绍与分享主题

大家好，我是周尧，Apache SeaTunnel 的 committer。今天非常高兴有机会与大家分享关于数据集成工具 SeaTunnel 的内容。

本次分享的主题主要包括 SeaTunnel Connector Catalog API 的核心实践以及社区的最新进展。

分享内容概览

今天的分享主要分为以下六个部分：

1. Apache SeaTunnel 简介
2. 架构总览
3. 工作流程
4. Connector 的发展及设计实现
5. Catalog 的设计实现
6. SeaTunnel 近期计划

SeaTunnel 简介

在当今大数据快速发展的背景下，出现了越来越多的数据源、数据仓库和数据库。对于企业而言，如何实现这些异构源与目标端之间的数据同步成为了一个越来越重要的问题。Apache SeaTunnel 提出了一个新的愿景，即成为下一代数据集成工具。

设计目标

SeaTunnel 的设计目标主要包括以下六个方面：

1. 简单易用：通过简单的配置文件（config）和 shell 命令即可完成数据同步任务。
2. 监控与指标：提供完善的监控和性能指标，能够清晰地展示数据读取和写入量、性能指标以及数据延迟等信息。
3. 丰富的数据源生态：在设计初期，SeaTunnel 选择了国内外约 300 家数据源，虽然目前实现了其中约 100 家，但这个数字还在不断增加。
4. 全场景支持：包括离线、实时全量增量、CDC 整库同步、DDL 加表、动态加表等功能。
5. 数据一致性保障：确保数据不丢失、不重复、精准一致，并且支持断点续传。
6. 资源优化：优化内存和 CPU 线程的使用，多表同步时实现数据源连接共享，减小数据源的连接压力。

SeaTunnel 发展历史

SeaTunnel 项目于 2017 年开源，当时还未捐献给 Apache 社区。直到 2021 年，SeaTunnel 正式进入 Apache 孵化器，现在已成为顶级项目。

Apache SeaTunnel 的架构

在讲解 SeaTunnel 现在的架构之前，我们先了解一下 SeaTunnel V1 的架构。

SeaTunnel V1 的架构主要依赖 Spark 和 Flink 两个数据计算引擎，并依赖于 Spark 或 Flink 的自身 Connector 进行数据传输计算。

SeaTunnel V1 架构痛点

V1 架构存在许多痛点，比如 Spark 和 Flink 对同一个数据源实现的 Connector 可能不一致。对于 Connector 参数和自身内容的改造较为困难，且支持不同 Spark 和 Flink 版本的兼容性较差。

SeaTunnel V2 架构

基于上述痛点，我们提出了 SeaTunnel V2 架构。

V2 架构主要分为以下几个模块：数据源模块（data source）、引擎模块（engine），以及 SeaTunnel Web。V2 架构通过对 Connector API 和 engine 的解耦，实现了一套统一的 Connector API，可以同时运行在 Spark SeaTunnel engine（即 Zeta）和 Flink 引擎上。

SeaTunnel 架构升级的五个要点

1. 引擎依赖：V1 强依赖于 Spark 和 Flink 的 Connector，而 V2 通过解耦，成为一套独立的 API。
2. 连接器实现：V1 需要分别实现 Spark 和 Flink 的 Connector，而 V2 只需实现一遍，即可在三个引擎上同步数据。
3. 引擎版本升级：V1 升级复杂，特别是对于不通用的 Connector，版本支持较旧；V2 中，所有 Connector 支持的 Flink 版本和 Spark 版本或 Zeta 版本均一致。
4. 参数一致性：V1 中 Spark 和 Flink 的 Connector 参数不一致，而 V2 中参数实现了统一。
5. 自定义分片逻辑：在数据同步过程中，分片逻辑非常重要。V2 支持完全自定义的分片逻辑，无需对 Spark 和 Flink 的 Connector 进行深入了解和改造。

Apache SeaTunnel 的工作流程

支持的引擎框架

SeaTunnel 目前支持三个主流的框架：

1. Flink
2. Spark
3. SeaTunnel 自研引擎 Zeta

多引擎支持可以更好地兼容企业现有的技术生态，降低 Apache SeaTunnel 的学习成本。

大多数企业都有自己的数据平台，可能已经在使用 Flink 或 Spark，这样可以采用 SeaTunnel Flink 或 SeaTunnel Spark。如果企业没有数据平台，或不想依赖这些数据平台，则可以使用 SeaTunnel Zeta引擎。

SeaTunnel 的执行流程

SeaTunnel 的执行流程如下：

1. 获取任务参数：从配置文件或 Web 等方式获取任务参数。
2. 创建组件：通过参数以 SPI 的方式获取对应的 Factory，创建对应的 Source、Sink 和 Transform 组件。
3. 初始化 Catalog：在 Source 初始化时创建 Catalog，以获取 CatalogTable，CatalogTable 通过 TableFactoryContext 在内部传递。
4. 翻译 Connector：将 SeaTunnel 的 Connector 翻译为引擎内部的 Connector。
5. 执行任务：通过 Source-Transform-Sink 完成任务的执行。

连接器的执行流程（以 Spark 为例）

1. SourceCoordinator：负责发现 Split 以及协调 SourceReader。
2. SourceReader：进行数据的实际读取，将数据发送到 Transform 转换后流转到 SinkWriter。
3. SinkWriter：进行数据的实际写入，或者预提交后将提交信息发送给 SinkCoordinator。
4. SinkAggregatedCommitter：负责协调 SinkWriter，进行正式提交或触发中止。
5. SinkWriter：进行最终的提交或中止。

Coordinated Source 与 CDC 的实现

Coordinated Source

Coordinated Source 的典型代表是 CDC（Change Data Capture）。CDC 实现了对于低版本 Flink 和 Spark 的支持，因为在低版本中，source split 的分片枚举器必须是单实例的。这是因为 SourceReader 在消费完数据后，会向分片枚举器请求分发下一个 split。

CDC 的工作流程

CDC 的主要流程包括两个阶段：快照阶段和增量读取阶段。

1. 快照阶段：

   • 分片枚举器生成表的多个快照切分，并分配给 reader。
   • 当快照切分读取完成时，reader 会将拆分的高水位报告给枚举器。
   • 当所有的快照切分都报告为高水位，枚举器开始增量阶段，报告一个完成的 split 通知所有 reader 快照阶段结束。

2. 增量阶段：

   • 枚举器结合所有快照拆分和水位信息，获得一个 log 的 split，并通过分片枚举器分发给 reader。
   • 在增量阶段，reader 通常是单并行度，一般分配给 reader 0。

多库多表支持

SeaTunnel 的 JDBC 连接器已经支持多表连接，这减轻了配置的工作量。用户只需配置一个 source，即可进行整库同步或多表同步，减轻 Source 源的连接压力，减少资源浪费。

链接：https://cwiki.apache.org/confluence/display/SEATUNNEL/STIP4-JDBC+source+supports+multi-table+reading+in+one+task

SeaTunnel 的 Sink

Sink Coordinator

Sink Coordinator 需要支持 Exactly-Once 语义。Sink Writer 接收上游数据并写入目标端，支持状态存储。HDFS 状态存储支持基于状态的重启，分布式事务支持两阶段提交，结合 checkpoint 机制保证 Sink 数据只写一次。

Sink API 特性

SeaTunnel 的 Sink API 主要应对以下功能：

1. 并行读取
2. 分布式事务
3. 聚合提交
4. 多表实现
5. 状态存储

Sink Committer

SeaTunnel 的 Sink Committer 有多种实现模式，主要包括：

1. GlobalCommit Run In Driver
2. GlobalCommit Run In Worker
3. Commit In Worker

Sink 支持多表实现，将不同的 Sink 包裹在一个多表 Sink 中，通过共享连接来减轻 Sink 端的压力和配置的复杂性。

Catalog API 的设计

设计目标

Catalog API 主要面向应用，旨在简化同步作业的配置，提供可视化作业配置的基础。它的设计具有以下四个特点：

1. 数据源管理：SeaTunnel 可以通过定义一套 API 来创建数据源插件，基于 SPI 实现即可集成此数据源的配置和连接工作。
2. 元数据获取：主要用于获取 source 的 schema 信息。
3. 数据类型定义：SeaTunnel 有自己的 SeaTunnel row 数据类型定义，以支持多引擎。
4. 连接器创建：基于不同的 Connector，可以实现不同的连接器。

Zeta 引擎概览

Zeta 引擎的架构分为 master 和 worker 两个部分：

1. 协调服务（Coordinator Service）：负责任务的解析和分发。
2. 任务执行服务（Task Execution Service）：负责实际的任务执行。

未来展望

连接器支持

• 目前 SeaTunnel 规划支持 300 多个连接器，但目前仅支持了 100 多个。
• 多表读取和写入的支持仍在完善中，某些连接器已支持多表的读取和写入。
• 自动建表功能：当源端不存在表时，Sink 端可以自动创建表。

Zeta 引擎发展

• 资源管理器支持：目前 Zeta 是 standalone 模式，未来将支持 Yarn 或 K8S 资源管理器。
• Master 和 Worker 的分离：目前 Zeta 的 master 既负责任务解析和分发，也负责任务执行。未来计划将 master 与 worker 分离，让 master 只负责任务解析和分发，提升系统的可扩展性和性能。

结论

Apache SeaTunnel 作为一款高效、易用的数据集成工具，通过其丰富的功能和灵活的架构设计，为企业的数据同步和集成提供了强有力的支持。无论是其多引擎支持、全场景数据集成功能，还是优化的资源利用和数据一致性保障，SeaTunnel 都展示了其在大数据领域的卓越能力。

未来，随着更多连接器的支持和 Zeta 引擎的不断发展，SeaTunnel 将继续引领数据集成工具的发展方向。希望通过本文的介绍，读者能够深入理解 SeaTunnel 的设计理念和实现细节，充分利用这款工具为企业数据管理带来更多价值。

本文由 白鲸开源科技 提供发布支持！