隨著大數據技術的發展，各種各樣的數據庫、數倉平臺、數據湖等技術不斷產生，如何將這些數據在各個數據源和目標端之間進行同步、集成已經成為了企業面臨的最大的問題。伴隨著 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 的運行狀態，包括數據量和數據質量。