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

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

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

1、整體目標(biāo)

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

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

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

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

3、多引擎支持

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

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

4、性能和一致性

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

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

5、社區(qū)活躍

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

6、用戶繁多

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

三、SeaTunnel 整體設(shè)計

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

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

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

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

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

2、SeaTunnel 使用方式

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

3、SeaTunnel 執(zhí)行流程

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

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

4、Connector 執(zhí)行流程

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

5、Engine Independent Connector API

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

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

6、Connector Translation

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

7、Source API

Source API 主要支持五個特性：

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

8、CoordinatedSource Connector

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

9、ParallelSource Connector

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

10、Sink Api

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

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

11、GlobalCommit Run In Driver

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

12、GlobalCommit Run In Worker

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

13、Commit In Worker

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

14、SeaTunnel Table & Catalog API

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

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

四、SeaTunnel 近期規(guī)劃

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

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