數智洞見｜數棧“產品家族”進階之路—

《數智洞見》

數字化浪潮席捲而來，顛覆性創新正在加速。企業面臨著前所未有的挑戰和機遇，數字化轉型成為其生存與領先發展的關鍵突破口。據研究資料顯示，數字化轉型程度高的企業獲得快速增長的機率是程度低的企業四倍之多。如何進行數字化轉型、如何透過利用大資料，找到新的機遇和價值增長點成為越來越多企業關注的話題。

袋鼠雲數棧賦能20+行業，服務3000+客戶，是研究數字化轉型解決方案的先行者，產品融合了大資料行業雲原生、信創、湖倉一體、批流一體、多引擎相容、跨雲能力等多項前沿技術，在金融、政府、教育、軍工等眾多行業領域積累了豐富的解決方案經驗。本次袋鼠雲數棧以“數智洞見”專欄為交流視窗，將先進的技術和產品方案經驗進行傳遞、分享，旨在幫助解決數字化轉型的痛點與困惑；同時探討轉型思路和機遇，助力更多行業夥伴完成數智化升級、成為資料價值釋放的“受益者”。

本專欄每週更新1-2篇，敬請關注。

Vol.01

作者｜牧雲

編輯｜雨濛

本文2521字閱讀約8分鐘

寫在前面的話

數棧

從「產品代號」到「自有專利技術產品品牌」

，從只有離線+實時2個模組，演變成現在的8個模組，在產品設計方面曾經遇到過不少問題，本文主要分析了數棧產品演變過程中的一些全域性性的問題與解決方式，有助於理解產品背後的設計理念。

傳統解耦模式

數棧的1。0版本，由離線開發+實時開發2個模組耦合在一起，還談不上模組解耦。在建立專案初始化時，需要連線Spark Thrift做元資料同步。但在幾次POC時，發現部分客戶只需要實時開發模組，而功能設計上又必須依賴離線的SparkThrift元件，這顯然是不合理的。此為各模組解耦的起源。

在數棧進行2。0迭代時，除了離線與實時的解耦之外，還新增了資料質量、資料API等模組，在功能設計、導航設計上均採用了獨立解耦的思路，為後續每個模組單獨輸出做好了鋪墊。

在數棧的3。0及之前的版本，解耦一直是產品的主要方向，但在4。0版本中，我們也逐漸投入到了各模組的「打通」設計中，下面重點解釋一下各產品之間的一些打通類的功能設計。

新的松耦合模式

隨著產品模組的逐漸增多，一些跨模組之間需要相互打通的需求也越來越強烈，例如資料來源的重複配置、離線任務與質量校驗的相互打通等，為了解決這些跨模組的問題，數棧在每個應用模組之外，增加了「基礎能力層」的概念，「基礎能力層」是實現公共模組或跨模組操作的中心。

基礎能力層內的設計目標可分為以下3類：

第一類：簡化操作

從操作體驗上，將重複性的功能合併統一，使用者僅需一次配置即可各處引用，例如資料來源中心、資料模型。

（1）統一資料來源

在較早的版本中，每個獨立應用都需要重複配置資料來源，例如：同一個MySQL，如果作為BI查詢的資料庫，同時也有API呼叫，對使用者來說，就需要在離線開發、實時開發和資料API這3個模組反覆配置同樣的連線資訊，如果發生了host變更、使用者名稱或密碼的變更，也需要反覆修改多次。另外，從內部的研發/測試資源投入上也存在反覆投入的問題。

基於上述背景，數棧已在最近的版本中抽象形成統一的資料來源中心，由管理員進行一次配置便可以授權給各個應用模組使用，降低了使用者重複操作的成本。

（2）資料模型

資料模型是透過頁面嚮導化的方式建立數倉中多張表之間的關聯關係，並對這些模型進行統一的管理。資料模型可以應用在離線開發、智慧標籤和指標管理中，由於多個模組都依賴於此功能，因此將其抽象為統一的模組，類似資料來源，已配置好的模型可以應用於平臺其他模組。目前可將資料模型應用於智慧標籤和指標管理，未來會將其擴充套件到離線開發和實時開發模組中，使用者可建立規範化的資料模型來建立離線數倉和實時數倉。

第二類：靈活擴充套件

不僅要滿足當前產品的場景和需求，更要為適配未來新增的模組充分預留空間，例如排程引擎、FlinkX的外掛化設計，以及其他的諸多擴充套件性較強的功能設計。拿排程引擎來說，目前是離線、演算法、標籤、指標幾個應用強依賴，但未來會產生新的模組，新的任務型別，均需要依賴於週期排程能力，要預留一些擴充套件性。

排程引擎

隨著最近1、2年，產品模組的持續增加，尤其是智慧標籤、指標管理、演算法開發等模組的快速發展，排程打通的需求也越來越強烈，主要體現在以下幾種場景：

離線開發完成SQL加工後，輸出原子標籤表、原子指標表，需要觸發下游標籤任務、指標任務執行

在「強規則」模式下，離線開發完成SQL加工後，需觸發質量校驗任務，檢查資料準確性，檢查完畢後，觸發離線開發的下游任務繼續執行

在「弱規則」模式下，只觸發質量校驗執行，同時下游任務繼續執行，不受質量校驗結果的影響

演算法開發完成資料探勘後，需要將結果表同步到查詢資料庫中

上述幾種場景，都可以歸結為排程的打通，即整個數棧使用統一的排程引擎（DAGScheduleX），所有周期排程任務都可以便捷的建立上下游依賴關係。

第三類：元資料互通

對於公有云平臺或統一的SaaS平臺，血緣打通、功能許可權、資料許可權的全域性統一併不復雜，但數棧將解耦作為一項基礎前提，不同客戶的產品售賣組合方式不同，有些是隻要單獨模組，有些是多個模組，在這個前提下，元資料的互通會帶來較大的挑戰。

為了解決這種元資料互通的問題，數棧單獨建立了「業務中心」模組，將血緣關係、功能許可權以及其他必要的通用。

（1）血緣關係

傳統的血緣關係都集中在離線數倉領域，但隨著實時數倉、標籤加工、資料API的逐漸發展與完善，對資料進行「全鏈路」血緣跟蹤的能力就顯得愈發重要。例如：實時採集模組將MySQL Binlog資料一路寫入Kafka，經FlinkSQL加工後寫入MySQL結果表，另一路寫入Hive表做備份，經離線加工後作為原子標籤表，後經標籤加工後產出衍生標籤、組合標籤，並輸出標籤API介面，可能形成下面的血緣關係：

目前平臺已完成離線開發與資料資產模組的血緣關係打通，離線開發每天跑批的SQL，資料資產模組可自動完成血緣解析，並直觀的呈現出離線開發過程中形成的血緣關係，後續版本中會逐漸補充其他模組的血緣關係。

（2）功能許可權

在進行跨模組的依賴配置時（例如離線+質量校驗），使用者在資料質量中需關聯一個離線任務，在進行關聯配置時，需按照「租戶→所屬產品→所屬專案→任務名稱」來選擇，使用者只能配置自己有許可權的任務作為上游。

這種跨模組的元資料互動，需要每個模組將基礎的許可權資訊儲存在統一的「業務中心」，每個產品之間都透過業務中心來解決跨模組的元資料查詢問題。採用統一的業務中心，為每個模組都帶來了較大的改造成本，但優點是一勞永逸，未來各個模組的類似需求都無需相互之間建立整合關係，而是透過業務中心來過渡。

展望未來

除了上述幾個點之外，基礎能力層還有以下幾個方面需完善：

體驗一致：運維中心

隨著排程引擎的統一，同時每個模組對週期排程的功能是雷同的，抽象為統一的「運維中心」，為各個模組提供體驗一致的週期例項運維能力，也已經規劃在下一步的Roadmap中。除離線外，標籤、指標、演算法等模組均需要基本的例項狀態管理、日誌檢視、重跑、補資料等操作，基於需求的一致性，所以需要形成統一的運維中心，實現操作體驗的統一，降低重複造輪子的出現。

統一的資料同步/資料傳輸

數棧已經在3。0版本已經完成了離線同步和實時同步的框架統一，由FlinkX來統一承擔離線和實時的同步和採集。

當前的設計模式將離線同步和實時同步分別做在了離線開發和實時開發模組中，但也有不少的客戶有交叉性的需求：

某客戶需要同步大量的離線資料，但也需要同步少量的實時表

某客戶主要使用演算法模組，但需將其他各系統的資料同步到演算法底層的Hadoop儲存中

某客戶使用Greenplum做資料倉庫，同時需要智慧標籤模組，需要將Greenplum資料同步到智慧標籤模組的Hive表中

以上幾種交叉場景較好的解決方式，是將資料同步單獨拆分，可以與其他模組靈活組合輸出，一方面實現輕量化的部署模式，另一方面是提升使用者的使用體驗。

結束語

從傳統的解耦模式到目前的松耦合模式，數棧始終秉承著“讓資料產生價值”這一核心理念，致力為行業夥伴和終端客戶提供更加優質的資料處理方案，在使用體驗、靈活性、擴充套件性和開放性等方面進行最最佳化設計，助推各行各業加快數智化轉型升級。

-End-

作|者|介|紹

牧雲-袋鼠雲數棧產研部產品專家