[禮物]關注公衆号“大話數智”，回複知識地圖，下載下傳資料內建知識地圖
導讀 随着大資料技術的發展，各種各樣的資料庫、數倉平台、資料湖等技術不斷産生，如何将這些資料在各個資料源和目标端之間進行同步、內建已經成為了企業面臨的最大的問題。伴随着 Sqoop 從 Apache 退役，實時同步，CDC、整庫同步等場景也漸漸被企業所重視和需要。在這個背景下，下一代資料內建平台 Apache SeaTunnel 專注于解決資料內建領域的核心需求，以支援的資料源多、同步速度快、簡單易用被衆多企業接受和使用。
今天的介紹會圍繞下面四點展開：
1. SeaTunnel 的設計目标
2. SeaTunnel 現狀
3. SeaTunnel 整體設計
4. 近期規劃
分享嘉賓｜高俊 白鲸開源 架構師
編輯整理｜李銘 多點dmall
出品社群｜DataFun
01
SeaTunnel 的設計目标
首先和大家分享下 SeaTunnel 的設計目标。
1. 整體目标
作為一個整體的資料平台，SeaTunnel 的總體設計目标是成為一個簡單易用的、分布式、可擴充的、支援超大資料級的高吞吐低延遲時間的資料內建平台。
目前，資料內建面臨的問題主要有五個：
- 資料源多：已知的資料庫、湖、倉等資料源類型非常多，包括一些 saas 網站、軟體等，總數量甚至到達幾百種，伴随着新技術的出現，這個數字還在不斷上漲；不同資料源之間也容易出現版本不相容的情況，為資料內建平台造成了一些困難；
- 品質難以保證，監控缺失：最常出現的問題是資料的丢失和重複，很難保證資料的一緻性；另一方面，在資料同步過程中出現問題無法進行復原或者斷點執行；同步過程中的監控缺失也會帶來資訊的不透明，例如不确定已經同步的資料數量等；
- 資源使用高：對于 CDC 的同步來說，多個表需要同步時，頻繁讀取 binlog 對資料源造成的壓力較大；資料源側一些大事務或者 Schema 變更等都會影響下遊；JDBC 這類同步，當連接配接數過多時，有時無法保證資料及時到達；
- 管理維護難：很多企業離線同步和實時同步是分開的，甚至需要寫兩套代碼，不僅日常管理運維非常困難，在進行離線和實時切換時，資料割接甚至需要人工進行；
- 技術棧複雜：企業的技術棧差異非常大，選擇同步元件時學習成本較高。
--
02
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 已經被許多使用者使用，包括網際網路企業、傳統企業等。
--
03
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 等執行個體。
--
04
SeaTunnel 近期規劃
SeaTunnel 的核心目标為更多、更快、更好用，為了達到這個目标，SeaTunnel 近期規劃目标為以下三點：
- 連接配接器數量翻倍，總共能支援 80+ 連接配接器。
- 釋出 SeaTunnel Web，支援可視化作業管理，支援程式設計式和引導式的作業配置，支援内部排程（處理簡單任務，crontab 為主）和第三方排程（以 dolphin scheduler 為主）。
- 釋出 SeaTunnel Engine，支援通過減少 JDBC 的連接配接和 binlog 的重複讀取以達到更省資源的效果；通過拆分任務為 pipeline，pipeline 之間的報錯不會互相影響，也支援獨立重新開機操作；借助共享線程以及底層的處理，推動整體同步任務更快的完成；過程中加入監控名額，監控同步任務運作中 Connector 的運作狀态，包括資料量和資料品質。
今天的分享就到這裡，謝謝大家。
｜分享嘉賓｜
｜《資料智能知識地圖》下載下傳｜
上下滑動⬆️⬇️，檢視《資料智能知識地圖》資料采集子產品，完整版請關注公衆号“大話數智”下載下傳
｜DataFun新媒體矩陣｜
｜關于DataFun｜
專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章900+，百萬+閱讀，16萬+精準粉絲。