隨著大數(shù)據(jù)技術(shù)的發(fā)展，各種各樣的數(shù)據(jù)庫、數(shù)倉平臺(tái)、數(shù)據(jù)湖等技術(shù)不斷產(chǎn)生，如何將這些數(shù)據(jù)在各個(gè)數(shù)據(jù)源和目標(biāo)端之間進(jìn)行同步、集成已經(jīng)成為了企業(yè)面臨的最大的問題。伴隨著 Sqoop 從 Apache 退役，實(shí)時(shí)同步，CDC、整庫同步等場(chǎng)景也漸漸被企業(yè)所重視和需要。在這個(gè)背景下，下一代數(shù)據(jù)集成平臺(tái) Apache SeaTunnel 專注于解決數(shù)據(jù)集成領(lǐng)域的核心需求，以支持的數(shù)據(jù)源多、同步速度快、簡(jiǎn)單易用被眾多企業(yè)接受和使用。

一、SeaTunnel 的設(shè)計(jì)目標(biāo)

首先和大家分享下 SeaTunnel 的設(shè)計(jì)目標(biāo)。

1、整體目標(biāo)

作為一個(gè)整體的數(shù)據(jù)平臺(tái)，SeaTunnel 的總體設(shè)計(jì)目標(biāo)是成為一個(gè)簡(jiǎn)單易用的、分布式、可擴(kuò)展的、支持超大數(shù)據(jù)級(jí)的高吞吐低時(shí)延的數(shù)據(jù)集成平臺(tái)。

當(dāng)前，數(shù)據(jù)集成面臨的問題主要有五個(gè)：

• 數(shù)據(jù)源多：已知的數(shù)據(jù)庫、湖、倉等數(shù)據(jù)源類型非常多，包括一些 saas 網(wǎng)站、軟件等，總數(shù)量甚至到達(dá)幾百種，伴隨著新技術(shù)的出現(xiàn)，這個(gè)數(shù)字還在不斷上漲；不同數(shù)據(jù)源之間也容易出現(xiàn)版本不兼容的情況，為數(shù)據(jù)集成平臺(tái)造成了一些困難；
• 質(zhì)量難以保證，監(jiān)控缺失：最常出現(xiàn)的問題是數(shù)據(jù)的丟失和重復(fù)，很難保證數(shù)據(jù)的一致性；另一方面，在數(shù)據(jù)同步過程中出現(xiàn)問題無法進(jìn)行回滾或者斷點(diǎn)執(zhí)行；同步過程中的監(jiān)控缺失也會(huì)帶來信息的不透明，例如不確定已經(jīng)同步的數(shù)據(jù)數(shù)量等；
• 資源使用高：對(duì)于 CDC 的同步來說，多個(gè)表需要同步時(shí)，頻繁讀取 binlog 對(duì)數(shù)據(jù)源造成的壓力較大；數(shù)據(jù)源側(cè)一些大事務(wù)或者 Schema 變更等都會(huì)影響下游；JDBC 這類同步，當(dāng)連接數(shù)過多時(shí)，有時(shí)無法保證數(shù)據(jù)及時(shí)到達(dá)；
• 管理維護(hù)難：很多企業(yè)離線同步和實(shí)時(shí)同步是分開的，甚至需要寫兩套代碼，不僅日常管理運(yùn)維非常困難，在進(jìn)行離線和實(shí)時(shí)切換時(shí)，數(shù)據(jù)割接甚至需要人工進(jìn)行；
• 技術(shù)棧復(fù)雜：企業(yè)的技術(shù)棧差異非常大，選擇同步組件時(shí)學(xué)習(xí)成本較高。

二、SeaTunnel 的現(xiàn)狀

接下來和大家分享下 SeaTunnel 的現(xiàn)狀。

1、支持連接器數(shù)量

目前 SeaTunnel 已經(jīng)支持 50+ 的連接器數(shù)量，包括 Source 和 Sink 的連接器，例如 ClickHouse、ClickHouseFile、Doris 等；還有 10+ 的 Transform；當(dāng)然，現(xiàn)在還有許多的連接器正在開發(fā)。

2、批流一體

針對(duì)同一個(gè)連接器，只需要寫一套代碼，就可以通過配置使用批處理或流處理的模式進(jìn)行同步處理。流處理的方式中目前實(shí)現(xiàn)的純流和微批兩種模式，主要是考慮到要同時(shí)支持以 Flink 為代表的純流和以 Spark 為代表的微批的方式。

3、多引擎支持

SeaTunnel 的多引擎支持主要是為了更好的兼容企業(yè)現(xiàn)有的技術(shù)棧，降低企業(yè)在引入 SeaTunnel 的技術(shù)成本。當(dāng)前主要支持的引擎為：

• Flink：支持多個(gè)版本的 Flink 引擎，并支持 Flink 的分布式快照算法等。
• Spark：支持 Spark 的微批處理模式，并能像 Flink 一樣保存 checkpoint，以支持?jǐn)帱c(diǎn)續(xù)傳和失敗會(huì)滾。
• SeaTunnel Engine：為數(shù)據(jù)同步設(shè)計(jì)的專用引擎，主要用于企業(yè)環(huán)境中沒有 Flink 和 Spark 的引擎情況下，想要簡(jiǎn)單使用 SeaTunnel 同步數(shù)據(jù)的場(chǎng)景。SeaTunnel Engine 解決了 Flink 和 Spark 等計(jì)算引擎中出現(xiàn)的一些問題，例如容錯(cuò)粒度大，JDBC 連接過多，binlog 重復(fù)讀取等。

4、性能和一致性

SeaTunnel 擁有高吞吐、精確性和低時(shí)延的特性。

• 高吞吐：當(dāng)前 SeaTunnel 所有的連接器都做了并行化處理，從而提高整個(gè)數(shù)據(jù)同步的吞吐量。
• 精確性：SeaTunnel 支持分布式快照的算法，在連接器內(nèi)部實(shí)現(xiàn)了兩階段提交和冪等寫入，保證數(shù)據(jù)只會(huì)處理一次。
• 低延遲：借助實(shí)時(shí)處理和微批處理的特性，實(shí)現(xiàn)數(shù)據(jù)低延遲。

5、社區(qū)活躍

SeaTunnel 去年年底進(jìn)入 Apache 孵化，Star 數(shù)量驟升，微信用戶群已達(dá)十多個(gè)，近五千人左右的規(guī)模。

6、用戶繁多

SeaTunnel 已經(jīng)被許多用戶使用，包括互聯(lián)網(wǎng)企業(yè)、傳統(tǒng)企業(yè)等。

三、SeaTunnel 整體設(shè)計(jì)

第三部分給大家介紹下 SeaTunnel 的整體設(shè)計(jì)。

1、SeaTunnel 整體架構(gòu)

從之前的介紹中大家應(yīng)該能感受到，SeaTunnel 的核心就是連接器。SeaTunnel 設(shè)計(jì)了一套獨(dú)立于引擎的 API，與引擎解耦，并保證基于 API 開發(fā)的連接器都能夠運(yùn)行在多個(gè)引擎之上。在實(shí)際運(yùn)行中，通過 Translation 層將連接器包裝成對(duì)應(yīng)引擎的連接器執(zhí)行。例如針對(duì) Spark 執(zhí)行引擎，在實(shí)際執(zhí)行中，連接器會(huì)包裝成 Spark 的 Source、Transform 和 Sink，同樣的道理也適用于 Flink。當(dāng)然針對(duì)前面提到的 SeaTunnel Engine，就不存在轉(zhuǎn)換的這一步了。轉(zhuǎn)換后，SeaTunnel 會(huì)將作業(yè)提交到對(duì)應(yīng)的引擎中執(zhí)行，將數(shù)據(jù)同步到對(duì)應(yīng)的存儲(chǔ)中。當(dāng)然，作為一個(gè)完整的系統(tǒng)，以及為了用戶的友好程度，SeaTunnel 還提供了 Web 頁面，包括代碼開發(fā)模式的提交，或者引導(dǎo)式任務(wù)提交，調(diào)度服務(wù)，監(jiān)控和報(bào)警服務(wù)等。

整個(gè)架構(gòu)涉及六大關(guān)鍵點(diǎn)：

• Engine Independent Connector API：獨(dú)立的連接器 API
• Connector Translation：連接器翻譯層
• Source Connector：Source 連接器
• Transform Connector：Transform 連接器
• Sink Connector：Sink 連接器
• 多引擎支持

2、SeaTunnel 使用方式

SeaTunnel 的使用方式非常簡(jiǎn)單，只需要填寫配置文件，SeaTunnel 會(huì)自動(dòng)解析并生成任務(wù)，進(jìn)行提交開啟同步。

3、SeaTunnel 執(zhí)行流程

• 首先會(huì)針對(duì)來源引擎不同的 Source Connector 進(jìn)行翻譯，翻譯后由 Source Connector 開始讀取數(shù)據(jù)。
• 接下來由 Transform Connector 進(jìn)行數(shù)據(jù)的標(biāo)準(zhǔn)化
• 最終通過 Sink Connector 進(jìn)行寫出操作。

當(dāng)然上述流程中還涉及到引擎內(nèi)部的一些處理，包括分流，Spark 和 Flink支持 SQL 的語法等。

4、Connector 執(zhí)行流程

目前可以分為 Driver 端和 Worker 端。在 Driver 端存在SourceCoordinator 管理 Worker端的 Source Split，之后存在枚舉器將拆分后的數(shù)據(jù)任務(wù)交給 SourceReader 進(jìn)行讀取。在讀取之后會(huì)將數(shù)據(jù)發(fā)送給 SinkWriter，此時(shí)會(huì)對(duì)分布式快照進(jìn)行處理，最終把數(shù)據(jù)寫入目標(biāo)端。

5、Engine Independent Connector API

獨(dú)立于引擎的 API 是在今年 3 月份正式進(jìn)行設(shè)計(jì)的，核心設(shè)計(jì)目標(biāo)是與引擎解耦，專門為數(shù)據(jù)集成的場(chǎng)景設(shè)計(jì)。核心目標(biāo)有以下四點(diǎn)：

• 多引擎支持：定義一套 SeaTunnel 自己的 API，解耦底層計(jì)算引擎
• 多版本支持：因?yàn)?Connector 和不同引擎的 Connector 之間設(shè)計(jì)了 Transform 層，就可以解決引擎多版本問題，Transform 可以針對(duì)不同的版本進(jìn)行翻譯。
• 流批一體：同樣的一套代碼，支持在批處理的場(chǎng)景下使用，也支持在流處理的場(chǎng)景下使用。
• JDBC 復(fù)用/數(shù)據(jù)庫日志多表解析：解決 JDBC 連接過多的情況，盡可能通過一個(gè)連接同步多張表的數(shù)據(jù)。同理，對(duì)于一個(gè)庫下的表，盡可能也只同步一次，多個(gè)表獨(dú)立解析即可。

6、Connector Translation

正如之前介紹了，使用 Spark Connector API 可以將獨(dú)立 API 翻譯成Spark 的連接器進(jìn)行執(zhí)行，同理也適用于 Flink。

7、Source API

Source API 主要支持五個(gè)特性：

• 通過 Boundedness 接口，實(shí)現(xiàn)批流統(tǒng)一。
• 通過 SourceReader 和 SourceSplit 支持并行讀取。
• 通過 SourceSplit 和 Enumerator 支持動(dòng)態(tài)發(fā)現(xiàn)分片。這個(gè)在流處理中更為常見，需要及時(shí)發(fā)現(xiàn)新增的文件分片；還有一種場(chǎng)景是通過正則表達(dá)式匹配 Topic，當(dāng)新的可以匹配上的 Topic 出現(xiàn)的時(shí)候，可以自動(dòng)讀取。
• 通過 SupportCoordinate 和 SourceEvent 支持協(xié)調(diào)讀取。這個(gè)主要用于 CDC 同步場(chǎng)景，在初次同步數(shù)據(jù)時(shí)，需要以批處理的方式全量同步數(shù)據(jù)，同步完成后主動(dòng)切換成流處理的方式同步增量數(shù)據(jù)。
• 通過 SnapshotState 支持狀態(tài)存儲(chǔ)和恢復(fù)。當(dāng)前針對(duì) Flink 引擎是直接使用 Flink 自帶的 Snapshot 功能，對(duì)于Spark引擎，SesTunnel 定制實(shí)現(xiàn)了 Snapshot 保存到 HDFS 的功能。

8、CoordinatedSource Connector

這個(gè)連接器支持協(xié)調(diào)器，主要用于 CDC 的場(chǎng)景。它的主要執(zhí)行流程為：通過 SourceSplitEnumerator 將一些信息（包括 checkpoint、批流情況等）分發(fā)到 ReaderThread 里面的 SourceReader 中。

9、ParallelSource Connector

這個(gè)連接器不支持協(xié)調(diào)器，支持并行處理。具體實(shí)現(xiàn)中需要在連接器中定義分區(qū)的邏輯，自定義分區(qū)的算法。該連接器類型支持多并發(fā)。

10、Sink Api

Sink API 主要是配合 Source 支持 Exactly Once 的語義。Sink API 包含幾個(gè)部分：

• Sink Writer，接收上游數(shù)據(jù)并寫入目標(biāo)端。
• State 存儲(chǔ)，支持狀態(tài)存儲(chǔ)，由 Connector 將狀態(tài)存儲(chǔ)在 HDFS 中，支持基于狀態(tài)重啟 Connector。
• 支持分布式事務(wù)，支持兩階段提交的分布式事務(wù)，配合引擎的 checkpoint 機(jī)制，保證 Sink 數(shù)據(jù)只寫一次。
• Commiter，支持每個(gè) Task 獨(dú)立進(jìn)行事務(wù)的提交，主要依賴 Flink 提供的這樣的功能。
• 支持聚合提交，主要用于 Spark 場(chǎng)景下，checkpoint 狀態(tài)保存，需要使用到。

11、GlobalCommit Run In Driver

Sink API 內(nèi)部 Commit 的類型之一，在 Driver 端運(yùn)行，也就是上面提到的聚合提交。在這種模式下，Global Commiter 運(yùn)行在 Driver 端，但是SinkWriter 運(yùn)行在 Worker 端，主要適用于 Spark v2.3+ 以及 Flink v1.12+ 版本的情況。

12、GlobalCommit Run In Worker

Sink API 內(nèi)部 Commit 的類型之一。這種模式下，Global Commiter 和SinkWriter 均運(yùn)行在 Worker 端，主要適用于 Flink v1.11- 的版本，Spark 不適用。

13、Commit In Worker

Sink API 內(nèi)部 Commit 的類型之一。這種模式下支持在 Worker 端，每個(gè) Task 單獨(dú)的 Commit 操作。這個(gè)模式適用于 Flink 所有版本，Spark 不適用。

14、SeaTunnel Table & Catalog API

這套 API 主要為面向應(yīng)用的 API，能夠簡(jiǎn)化同步配置，提供可視化作業(yè)配置的基礎(chǔ)。主要包含下面四個(gè)方面：

• 數(shù)據(jù)源管理：SeaTunnel 定義了一套 API 來支持創(chuàng)建數(shù)據(jù)源插件，基于 SPI 實(shí)現(xiàn)后即可集成該數(shù)據(jù)源的配置、連接測(cè)試工作等。
• 元數(shù)據(jù)獲取：主要用于引導(dǎo)式界面，選擇數(shù)據(jù)源后，支持自動(dòng)獲取元數(shù)據(jù)的表結(jié)構(gòu)，方便可視化的配置同步作業(yè)的源和目標(biāo)端的表名映射，字段映射等。
• 數(shù)據(jù)類型定義：所有連接器都使用 SeaTunnel 定義的格式，在 Connector Translation 會(huì)轉(zhuǎn)換為對(duì)應(yīng)引擎的格式。
• 連接器創(chuàng)建：SeaTunnel 提供了一套 API 用于創(chuàng)建自動(dòng)獲取信息創(chuàng)建 Source、Sink 等實(shí)例。

四、SeaTunnel 近期規(guī)劃

SeaTunnel 的核心目標(biāo)為更多、更快、更好用，為了達(dá)到這個(gè)目標(biāo)，SeaTunnel 近期規(guī)劃目標(biāo)為以下三點(diǎn)：

• 連接器數(shù)量翻倍，總共能支持 80+ 連接器。
• 發(fā)布 SeaTunnel Web，支持可視化作業(yè)管理，支持編程式和引導(dǎo)式的作業(yè)配置，支持內(nèi)部調(diào)度（處理簡(jiǎn)單任務(wù)，crontab 為主）和第三方調(diào)度（以 dolphin scheduler 為主）。
• 發(fā)布 SeaTunnel Engine，支持通過減少 JDBC 的連接和 binlog 的重復(fù)讀取以達(dá)到更省資源的效果；通過拆分任務(wù)為 pipeline，pipeline 之間的報(bào)錯(cuò)不會(huì)相互影響，也支持獨(dú)立重啟操作；借助共享線程以及底層的處理，推動(dòng)整體同步任務(wù)更快的完成；過程中加入監(jiān)控指標(biāo)，監(jiān)控同步任務(wù)運(yùn)行中 Connector 的運(yùn)行狀態(tài)，包括數(shù)據(jù)量和數(shù)據(jù)質(zhì)量。