亞信科技基於 Apache SeaTunnel 的二次開發應用實踐

亞信科技在Apache SeaTunnel的實踐分享

自我介紹

各位同學好，很榮幸透過Apache SeaTunnel社群和大家進行分享交流。我是來自亞信科技的潘志宏，主要負責公司內部資料中臺產品的開發。

本次分享的主題是Apache SeaTunnel在亞信科技的整合實踐，具體講我們的資料中臺是如何整合SeaTunnel的。

分享內容概述

在本次分享中，我將重點講解以下幾個方面：

• 為什麼選擇SeaTunnel
• 如何整合SeaTunnel
• 整合SeaTunnel過程中遇到的問題
• SeaTunnel的二次開發
• 對SeaTunnel的期待

為什麼選擇SeaTunnel

首先介紹一下，我主要負責亞信資料中臺產品DATAOS的迭代開發。DATAOS是一個比較標準的資料中臺產品，涵蓋資料整合、資料開發、資料治理、資料開放等功能模組。與SeaTunnel相關的主要是資料整合模組，該模組主要負責資料的整合。

在引入SeaTunnel之前，我們的資料整合模組的功能架構如下：

• 批採：分為庫表採集和檔案採集。
  • 庫表採集：主要使用DataX實現。
  • 檔案採集：自研的DP引擎。
  • ETLt採集：自研的ETLt採集引擎。DataX偏向於ELT（抽取、載入、轉換），適用於資料抽取入庫後再進行復雜的轉換，但在某些場景下需要進行EL小T（抽取、載入、簡單的轉換），DataX並不適合。因此，我們基於Spark SQL自研了一個引擎。
• 流採：日誌採集主要基於Filebeat，CDC採集主要基於Flink CDC。

在我們的資料整合模組中，整體架構分為三層，分別是資料整合前臺、排程平臺以及資料整合服務。

下面是每一層的詳細描述：

第一層：資料整合前臺

資料整合前臺主要負責資料整合任務的管理。具體包括任務的開發、排程開發和執行監控。這些任務透過DAG（有向無環圖）的方式將各個整合運算元組合起來，實現複雜的資料處理流程。前臺介面提供了直觀的任務管理介面，使得使用者可以方便地配置、監控資料整合任務。

第二層：排程平臺

排程平臺負責任務執行的排程管理。它支援批處理和流處理兩種模式，並能夠根據任務的依賴關係和排程策略拉起相應的任務。

第三層：資料整合服務

資料整合服務是整個資料中心服務的核心，它提供了一系列關鍵功能：

• 任務管理介面：包括任務的建立、刪除、更新和查詢等功能。
• 任務啟停介面：允許使用者啟動或停止特定的任務。
• 任務狀態查詢介面：查詢任務的當前狀態資訊，便於監控和管理。

資料整合服務還負責任務的具體執行。由於我們的採集任務可能包含多個引擎，這就需要在任務執行時實現多引擎的協調和排程。

任務執行流程

任務的執行主要包括以下幾個步驟：

1. 任務排程：根據預定的排程策略和依賴關係，排程平臺拉起相應的任務。
2. 任務執行：任務執行過程中，根據任務的DAG配置，依次執行各個運算元。
3. 多引擎協調：對於包含多個引擎的任務（如DataX和Spark混合任務），需要在執行過程中協調各個引擎的執行，確保任務的順利執行。

資源分配

同時為了使DataX這種單機執行的任務能夠更好地分散式執行，並實現資源複用，我們對DataX任務進行了資源分配的最佳化：

• 分散式排程：透過資源分配機制，將DataX任務分佈到多個節點上執行，避免單點瓶頸，提高任務的並行度和執行效率。
• 資源複用：透過合理的資源管理和分配策略，確保不同任務在資源使用上的高效複用，減少資源浪費。

任務執行代理

我們對每個執行引擎實現了相應的任務執行代理，以實現任務的統一管理和監控：

• 執行引擎代理：在資料整合服務中，代理管理各個執行引擎，如DataX、Spark、Flink CDC等。代理負責任務的啟動、停止以及狀態監控。
• 統一介面：提供統一的任務管理介面，使得不同引擎的任務可以透過相同的介面進行管理，簡化了運維和管理工作。

老的資料整合架構存在的一些問題

我們整合了一些開源專案，如DataX、Spark、Flink CDC、Filebeat等，形成了一個功能強大的資料整合服務平臺。但也面臨一些問題：

• 單機執行限制：DataX只支援單機執行，這導致我們需要在其基礎上實現分散式排程功能，增加了系統的複雜度。
• 技術棧過於多樣化：引入了多個技術棧（如Spark和Flink），雖然功能豐富，但也導致研發成本較高，每次開發新功能都需要應對多個技術棧的相容性和整合問題。

架構演進

為了最佳化架構並降低複雜度，我們對現有架構進行了演進：

• 整合多引擎功能：引入SeaTunnel後，我們可以統一多個引擎的功能，實現單一平臺上的多種資料處理能力。
• 簡化資源管理：透過SeaTunnel的資源管理功能，簡化了DataX等單機任務的分散式排程，降低了資源分配和管理的複雜度。
• 降低研發成本：透過統一的架構和介面設計，減少了多技術棧帶來的開發和維護成本，提高了系統的可擴充套件性和易維護性。

透過對架構的最佳化和演進，我們成功地解決了DataX單機執行限制和多技術棧帶來的高研發成本問題。

引入SeaTunnel後，我們能夠在一個平臺上實現多種資料處理功能，同時簡化了資源管理和任務排程，提高了系統的整體效率和穩定性。

為什麼選擇 SeaTunnel？

我們與 SeaTunnel 的接觸可以追溯到Waterdrop時期，針對於Waterdrop進行過多次應用實踐。

去年，SeaTunnel 推出了 Zeta 引擎，支援分散式架構，併成為 Apache 頂級專案，這使得我們在去年找到了一個合適的時間節點，進行了深入的調研，並決定引入 SeaTunnel。

以下是我們選擇 SeaTunnel 的幾個主要原因：

1. 優秀的架構設計
   • SeaTunnel 具有分散式架構，能夠很好地適應我們的需求。
   • 它的 API 設計標準化，採用了 SPI（Service Provider Interface）模式，便於擴充套件和整合。
2. 活躍的社群支援
   • SeaTunnel 是 Apache 頂級專案，社群氛圍良好，活躍的開發者和使用者群體為問題的解決和功能的擴充套件提供了強大的支援。
   • 國內開源專案的背景，使我們在溝通和協作上更加順暢。
3. 豐富的功能和資料來源支援
   • SeaTunnel 支援多種資料來源，功能豐富，能夠滿足我們多樣化的資料處理需求。
   • 支援 CDC（Change Data Capture），可以進行實時資料同步和處理。
   • 支援一抽多送（one-to-many）的資料傳輸模式，提升了資料傳輸的靈活性。
4. 技術棧的貼合
   • SeaTunnel 相容 Java，並且支援 Flink 和 Spark，使我們能夠在現有技術棧上無縫整合和應用。
   • 使用 Debezium 進行 CDC 資料捕獲，技術實現成熟穩定。
5. 多引擎支援
   • SeaTunnel 支援多種計算引擎，包括 Zeta、Flink 和 Spark，能夠根據具體需求選擇最適合的引擎進行計算。
   • 這一點非常重要，因為它允許我們在不同場景下選擇最優的計算模式，提升了系統的靈活性和效率。
6. 出色的效能
   • SeaTunnel 設計了諸如二階段提交（two-phase commit）、異常恢復（fault-tolerance recovery）以及執行緒共享（thread sharing）等效能最佳化機制，確保資料處理的高效和穩定。

引入SeaTunnel後解決的問題

SeaTunnel 能夠解決我們之前提到的兩個主要問題：

1. 分散式排程
   • DataX 只能單機執行，我們需要額外實現分散式排程功能。而 SeaTunnel 天生支援分散式架構，無論是使用 Zeta、Flink 還是 Spark 作為計算引擎，都能輕鬆實現分散式資料處理，大大簡化了我們的工作。
2. 技術棧整合
   • 我們之前使用了多種技術棧，包括 DataX、Spark、Flink CDC 等，這使得研發成本高昂且系統複雜。而 SeaTunnel 透過統一封裝這些技術棧，提供了一個整合化的平臺，能夠同時支援 ELT 和 ETL 流程，極大地簡化了系統架構，降低了開發和維護成本。

如何整合 SeaTunnel

在整合 SeaTunnel 之前，我們的舊架構已經存在並執行了一段時間，整體上分為三層：前臺、排程平臺以及資料整合服務。前臺負責任務的管理與開發，排程平臺負責任務的排程與依賴管理，而資料整合服務則是執行和管理所有資料整合任務的核心部分。

以下是我們在整合 SeaTunnel 後的新架構。

首先，我們將舊架構中涉及 DataX 的資源分配部分取消了。由於 SeaTunnel 本身支援分散式架構，不再需要額外的資源分配管理。這一調整極大地簡化了我們的架構。

技術棧的替換

我們逐步使用 SeaTunnel 替換了舊有的技術棧。具體步驟如下：

1. 替換批處理任務：我們先替換了舊架構中使用 DataX 和 Spark 進行批處理 ETL 的部分。
2. 替換流處理任務：接下來，我們將逐步替換使用 Flink CDC 進行流處理的部分。
   透過這種分步走的方式，我們可以確保系統在逐步過渡過程中始終保持穩定。

元件化 SeaTunnel Connector

我們基於 SeaTunnel 的 Connector 進行了元件化設計，並在前臺透過表單方式進行配置和 DAG 編排。雖然 SeaTunnel Web 也在進行類似的工作，但我們根據自身需求進行了定製化開發，以便更好地與現有系統整合。

任務執行代理

在任務執行代理方面，我們透過 SeaTunnel 客戶端提交任務，並監聽 SeaTunnel 客戶端的狀態和執行日誌。透過解析這些日誌，我們可以獲取任務的執行狀態資訊，確保任務執行的可監控性和可追蹤性。

多引擎混編開發

我們支援多引擎混編開發，在前臺頁面可以對一個排程任務進行多引擎的 DAG 編排。這樣，我們可以在一個排程任務中同時使用不同的引擎（如 SQL 引擎和 DP 引擎）進行任務開發，提高系統的靈活性和擴充套件性。

整合SeaTunnel過程中遇到的問題

在整合 SeaTunnel 的過程中，我們遇到了一些問題，以下是幾個具有代表性的問題及其解決方案：

問題一：報錯處理

在使用 SeaTunnel 的過程中，我們遇到了一些報錯，這些報錯涉及到框架的程式碼。由於官方文件中沒有相關說明，我們透過加入社群微信群，向群內的開發者求助，及時解決了問題。

問題二：任務割接

我們的舊採集任務是使用 DataX 實現的，在替換為 SeaTunnel 時，需要考慮任務的割接問題。

我們透過以下方案進行解決：

• 元件化設計：我們的資料中臺採集任務是元件化設計的，前臺的元件和後臺的執行引擎之間有一層轉換層。前臺配置表單，後臺透過轉換層生成 DataX 需要執行的 JSON 檔案。
• 相似的 JSON 檔案生成：SeaTunnel 的配置與 DataX 類似，前臺同樣是透過表單配置，後臺生成 SeaTunnel 需要執行的 JSON 檔案。透過這種方式，我們能夠無縫地將舊任務轉移到新的 SeaTunnel 平臺上，確保任務的平滑過渡。
• SQL 指令碼轉換：編寫 SQL 指令碼，對舊有的 DataX 任務進行清洗和轉換，使其能夠適配 SeaTunnel。這種方法更具靈活性和適應性，因為 SeaTunnel 會頻繁更新，直接寫硬編碼進行相容不是長久之計。透過指令碼轉換，可以更高效地遷移任務，適應 SeaTunnel 的更新。

問題三：版本管理

我們在使用 SeaTunnel 的過程中遇到了版本管理的問題。SeaTunnel 的更新頻繁，而我們團隊的二開版本需要持續跟進最新版本。以下是我們的解決方案：

本地分支管理：我們基於 SeaTunnel 2.3.2 版本拉了一個本地分支，對其進行二次開發，包括修復個性化需求和臨時修復的 bug。為了儘量減少本地維護的程式碼，我們僅保留必要的改動，其他部分儘量使用社群的最新版本。

定期合併社群更新：我們定期將社群的新版本合併到本地分支，特別是對我們改動的部分進行更新和相容。雖然這種方法比較笨拙，但可以保證我們及時跟進社群的最新功能和修復。

回饋社群：為了更好地管理和維護程式碼，我們計劃將我們的一些改動和個性化需求提交給社群，爭取社群的接納和支援。這不僅有助於減少我們本地的維護工作，也有助於社群的共同發展。

SeaTunnel 二次開發與實踐

在 SeaTunnel 的使用過程中，我們針對實際業務需求進行了多項二次開發，特別是在聯結器（Connector）層面。以下是我們在二次開發中遇到的問題及解決方案。

Hive Connector 的改造

• 原始的 SeaTunnel Hive Connector 需要依賴 Meta URL 來獲取後設資料。然而，在實際應用中，很多第三方使用者因安全問題無法提供 Meta URL。為了應對這一情況，我們進行了如下改造：
• 使用 Hive Server 2 的 JDBC 介面來獲取表的後設資料資訊，從而避免了對 Meta URL 的依賴。
• 透過這種方式，我們能夠更靈活地為使用者提供 Hive 資料的讀寫能力，同時確保資料安全。

瀚高資料庫的支援

• 瀚高資料庫在我們的專案中有廣泛應用，因此我們增加了對瀚高資料庫的資料來源讀寫支援。同時，針對瀚高資料庫的一些特殊需求，我們開發了轉換元件：
• 支援行轉列、列轉行等複雜轉換操作。
• 編寫了多種 UDF（使用者自定義函式），用於資料脫敏等操作。

檔案聯結器的改造

• 檔案系統聯結器在我們的使用中佔有重要地位，因此我們對其進行了多項改造：
• HDFS Connector：增加了目錄遞迴和正規表示式掃描檔案的功能，同時支援讀取和寫入多種檔案格式（如 RC、Sequence、XML、JSON）。
• FTP 和 SFTP Connector：修復了 I/O 洩露的 bug，並最佳化了連線快取機制，確保同一 IP 不同賬號之間的獨立性。

二段提交機制的最佳化

在使用 SeaTunnel 的過程中，我們深入瞭解了其二段提交機制，以確保資料的一致性。以下是我們在此過程中遇到的問題及解決方案：

問題描述：在使用 FTP 和 SFTP 進行檔案寫入時，報錯提示沒有寫入許可權。排查發現，SeaTunnel 為了保證資料一致性，會先將檔案寫入臨時目錄，然後再進行移動。

然而，由於不同賬號對臨時目錄的許可權設定問題，導致寫入失敗。

解決方案：在建立臨時目錄時，設定更大的許可權（如 777），以確保所有賬號都有許可權寫入。同時，解決了檔案移動過程中由於跨檔案系統導致的 rename 命令失敗的問題，透過在同一檔案系統下建立臨時目錄，避免了跨檔案系統操作。

二次開發管理

在二次開發過程中，我們面臨著如何管理和同步 SeaTunnel 新版本的問題。我們的解決方案如下：

• 本地分支管理：基於 SeaTunnel 2.3.2 版本拉了一個本地分
• 定期合併社群更新：定期將社群的新版本合併到本地分支，確保我們能夠及時獲得社群的新功能和修復。
• 回饋社群：計劃將我們的一些改動和個性化需求提交給社群，以期獲得社群的接納和支援，從而減少本地維護的工作量。

SeaTunnel 整合與應用

在整合 SeaTunnel 過程中，我們主要關注以下幾點：

• 資源分配最佳化：利用 SeaTunnel 的分散式架構，簡化了資源分配問題，不再需要額外的分散式排程功能。
• 技術棧整合：將 DataX、Spark、FlinkCDC 等不同技術棧的功能整合到 SeaTunnel 中，統一封裝，實現 ETL 和 ELT 的一體化。

透過以上步驟和策略，我們成功地將 SeaTunnel 整合到我們的資料整合服務中，解決了舊有系統中的一些關鍵問題，最佳化了系統的效能和穩定性。

在這個過程中，我們積極參與社群，尋求幫助並反饋問題，確保整合工作的順利進行。這種積極的互動不僅提高了我們的技術水平，也推動了 SeaTunnel 社群的發展。

參與開源社群的心得體會

在參與 SeaTunnel 的過程中，我有以下幾點體會：

• 時間合適：我們在 SeaTunnel 快速發展的階段選擇了這個專案，時機非常好。SeaTunnel 的發展給了我們很大的信心，讓我們覺得有很多事情可以做。
• 個人目標：我在今年年初就定下了參與開源社群的目標，並積極付諸行動。
• 社群的友好：SeaTunnel 社群非常友好，大家交流順暢，相互幫助。這種積極的氛圍讓我覺得參與其中非常值得。

對於那些一直想參與開源社群但還沒有邁出第一步的人，我想鼓勵大家勇敢地邁出這一步。社群最重要的是人，只要你加入，你就是社群中不可或缺的一部分。

對 SeaTunnel 的期待

最後，我想分享一下對 SeaTunnel 的一些期待：

• 文件改進：希望社群能進一步完善文件，包括資料來源的版本清單和壓測報告。
• 叢集管理：希望 SeaTunnel 在叢集內部能實現資源隔離，並提供更豐富的叢集狀態監控資訊。
• 資料容錯：雖然 SeaTunnel 已經有容錯機制，但希望未來能進一步最佳化。
• AI 整合：希望 SeaTunnel 能提供更多介面，方便 AI 輔助接入。

感謝 SeaTunnel 社群的每一位成員，感謝你們的付出。我的分享就到這裡，謝謝大家！

本文由 白鯨開源 提供釋出支援！