Apache InLong 的 SPI 擴展實踐

1 - Apache InLong 簡介

1.1 項目簡介

InLong 官網 的介紹:

Apache InLong(應龍)是一個一站式的海量數據集成框架,提供自動、安全、可靠和高性能的數據傳輸能力,方便業務構建基於流式的數據分析、建模和應用。

該項目最初於 2019 年 11 月由騰訊大數據團隊捐獻到 Apache 孵化器,2022 年 6 月正式孵化畢業,成爲 Apache 頂級項目(TLP)。

inlong-structure

https://inlong.apache.org/img/inlong-structure-zh.png

1.2 適用場景

Apache InLong 依託騰訊百萬億級別的數據接入和處理能力,整合了數據採集、匯聚、存儲、分揀數據處理全流程,擁有簡單易用、靈活擴展、穩定可靠等特性。

目前 InLong 正廣泛應用於廣告、支付、社交、遊戲、運營商、人工智能等領域,爲廣大客戶提供高效、便捷的數據採集、服務。

2 - InLong Manager 的作用

InLong 支持數據的採集、匯聚、緩存和分揀功能,用戶只需要簡單的配置就可把數據從源端導入到實時計算引擎或者寫入離線存儲系統。

從前面的架構圖可以看出,InLong 系統涉及採集、匯聚、緩存、分揀 4 個主要流程,如何將這些流程串聯起來?

答案是,我們通過 InLong Manager 來管理系統和任務的元數據,串聯任務的全流程。

這裏的元數據主要包括:
InLong 系統中的用戶信息、審批信息、集羣配置信息;
用戶創建的數據源端、數據目標端,以及數據 schema 等信息。

其結構如下:arch-img

用戶可在 InLong Dashboard 提供的 Web UI,或 通過 Manager Client 創建數據流任務,任務審批通過後,即可串聯起全部流程,主要包括:

  1. 創建 MQ 的 Topic 和消費者;
  2. 創建目標端的庫表結構;
  3. 啓動 Flink 任務,從 MQ 消費數據,寫入目標端。

3 - InLong Manager 的 SPI 實踐

3.1 存在的問題

InLong 源於騰訊內網業務,在近10年的發展中,主要支持的數據源和數據存儲如下:

以數據存儲爲例,由於存儲系統的類型有限,且考慮到不同的存儲類型的參數差異較大,因此我們的配置表是這樣設計的:

由於篇幅所限,沒有列出來狀態、創建者、修改者、是否刪除的標誌,以及相關的時間、版本號等字段,可以看到,每張表裏都有10多個相同的字段


在 InLong 上雲的過程中,數據源端和目標端的類型急劇增多,而且隨着雲上客戶規模的增加,還會繼續擴展更多類型的數據源和目標端。下圖是在上面已有類型的基礎上,新增的類型:

在擴展的過程中,我們很快發現了原有設計的痛點:

1)字段重複,增加了 DB 的存儲成本(雖然有限)

2)配置管理存在大量的相似代碼(比如修改、刪除),即使提取出公共方法,也會存在大量的 if-else / switch-case 語句來分別處理不同的邏輯,比如(還有創建 MQ 資源、創建存儲端庫表結構、下發任務等類似邏輯):

3)【更重要】如果要擴展1個新的存儲類型,不僅要添加一張表(頻繁變更 DDL 是大忌),還要入侵已有的代碼,添加 else / case 語句並補充特殊邏輯(不符合開閉原則

3.2 什麼是 SPI

在遇到上述問題後,

3.3 我們的實踐

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章