用戶案例 | 蜀海供應鏈基於 Apache DolphinScheduler 的數據表血緣探索與跨大版本升級經驗

導讀

蜀海供應鏈是集銷售、研發、採購、生產、品保、倉儲、運輸、信息、金融為一體的餐飲供應鏈服務企業。2021年初，蜀海信息技術中心大數據技術研發團隊開始測試用DolphinScheduler作為數據中台和各業務產品項目的任務調度系統工具。本文主要分享了蜀海供應鏈在海豚早期舊版本實踐過程中的探索創新和在跨大版本升級部署過程中的經驗，希望對大家有所啟發和幫助。

作者簡介

杜全，蜀海供應鏈大數據工程師，參與蜀海大數據平臺和數據中台建設。

業務背景介紹

我們公司的主要業務如下圖所示：

• 領導駕駛艙：提供給高層領導查看的數據準實時分析，T+1經營分析、產品毛利類、市場價格等報表
• 財務：各類日報、月報、年度報表；對賬、毛利報表、指標表等
• 客戶銷售：客戶採銷類實時報表、日報、月報各個維度的數據分析及查詢銷售明細數據
• 供應商類：採購分析、詢價報表、供應商等級、供應商工作台、供應商對賬分析，採購策略優化等
• 倉儲：庫存周轉、庫位、實時庫存等各種維度數據指標及報表需求
• 物流運輸類：準點率、溫控、運輸成本，調度等分析
• 數據分析師：快速響應各種數據分析需求，及高層領導各種臨時數據需求，數據挖掘及各種實時互動式分析
• 各業務運營/策略/負責人：主要查看各自業務運營的整體情況，查詢數據中台的各該業務各種維度實時聚合數據
• 以及一些其他業務的數據報表及分析需求。

集成升級經驗

在數據中台建設過程中，好的大數據調度組件往往能達到事半功倍的作用，我們團隊也深知這一點，因此選擇了海豚調度作為蜀海供應鏈數據中台的調度系統，並經過從v1.3.6的耦合集成部署改造到v3.1.8解耦集成部署的改造的階段，在這個過程中也遇到了各種各樣的問題並及時提供瞭解決方案，現就這些做一下分享，希望可以幫助到各位小伙伴。

海豚調度舊版本集成

之前團隊集成的舊版本為v1.3.6，已經在生產環境穩定運行兩年多了，這裡主要簡單介紹下當時集成到數據中台的細節及隨著業務量劇增帶來的痛點。

（1）API服務、UI改造對接集成到中台

• 前端UI改造

基於dolphinscheduler-ui項目二次開發（改動量大）適配中台樣式，集成各海豚調度菜單（首頁、項目管理、資源中心、數據源中心、監控中心、安全中心）到中台，統一走中臺路由網關。

• 後端API介面服務改造

基於dolphinscheduler-api項目二次開發，融合中台用戶體系改造。核心改造點如下：

①　改造點1：LoginHandlerInterceptor攔截器類preHandle()方法重構

②　改造點2：每個Controller控制層類中介面方法增加獲取登錄用戶方法getLoginUser()方法

③　改造點3：返回數據及分頁數據方法改造

（2）告警改造增加釘釘告警

v1.3.6版本告警組組類型僅支持：郵件、簡訊兩種。公司平時是通過釘釘接收告警信息，因此需要集成釘釘告警類型。核心改造點如下：

①　步驟1：定義DingAlertPlugin釘釘告警插件類實現AlertPlugin介面，重寫getId()、getName()及process()方法

②　步驟2：定義DingManager釘釘發送管理類

③　步驟3：編寫DingUtils釘釘發送消息工具類

④　步驟4：向AlertServer註冊釘釘告警插件

⑤　步驟5：打包部署並修改dolphinscheduler-daemon.sh

打包部署根據具體修改邏輯，這裡修改了dolphinscheduler-alert-1.3.6.jar和dolphinscheduler-dao-1.3.6.jar 因此打包這兩個包即可。另外，安裝路徑下增加alertlib文件夾併在dolphinscheduler-daemon.sh中增加alter-server載入邏輯。

（3）集成成果展示

數據中台集成菜單與v1.3.6海豚調度保持一致，主要包括：首頁、項目管理、資源中心、數據源中心、監控中心、安全中心，這些菜單都是集成到了我們的數據中臺中，前端走平臺統一的路由網關。

（4）v1.3.6舊版本業務痛點問題

• 工作流定義表 process_definition_json欄位大JSON 任務和工作流耦合度高，解析json，非常耗費性能，且任務沒法重用；否則會導致數據大量冗餘，性能差，資源消耗嚴重

• 升級困難，1.3.6集成到數據中台系統中，相當於二次開發了API服務，集成了中台用戶體系走統一路由網關，前端UI組件每一次升級，海豚調度就會出現各種前端樣式問題（SUB_PROCESS 子工作流 進入不到該子節點下）、菜單顯示不全、日誌全屏看不全、項目主頁上下滑動不了等等一系列UI交互問題

• 任務間自定義參數上下不能依賴傳參

• 工作流實例任務交叉沒有任務執行策略 ，預設是並行處理的，不保證單例模式，比如調度頻率高時 前一個工作流實例還未執行完，後一個又開始，造成數據錯亂、不准確

• 自帶數據質量從3.0.0開始

• 支持多種告警插件類型和告警組及實例管理（不限於釘釘），從3.0.0開始

• 前端UI大調整、優化

鑒於第一版集成的v1.3.6以上的業務痛點，升級並重構集成方式變得尤為重要。

海豚調度新版本升級

v1.3.6版本在數據分析師進行業務分析流轉過程中面臨的痛點，結合海豚調度新版本更優的特性，升級到更新版本迫在眉睫，以下是對我們在將海豚調度集成到數據中台以及升級過程的細節做一下介紹，希望對遇到跨大版本升級的你有所幫助。

（1）新版本（v3.1.1）集成到中台

• 海豚調度集成中台項目整體架構

主要分為：數據中台-前端、數據中台-後端、海豚調度API服務及集群。

• 海豚調度集成中台調用流程

主要流程：數據中台-前端請求打開海豚調度菜單->調用數據中台後端獲取海豚調度用戶登錄信息介面->返回用戶名密碼->登入海豚調度系統->數據中台-前端請求退出平臺賬號->海豚調度介面登出介面->退出系統

• 數據模型及設計細節

海豚調度集成數據中台項目中間用戶模型設計

模型設計的目的主要建立數據中台和海豚調度用戶的關係，便於在數據中台用戶登錄後，點擊海豚調度菜單時獲取到對應的海豚調度用戶登錄信息成功登錄。

（2）v1.3.6滾動遷移並升級到v3.1.8+

這裡我以我們生產環境升級版本v1.3.6為起點，經過v2.0.0->2.0.9>3.0.0>3.1.0->3.18這些版本迭代升級<當然可以跨度步伐邁的再小一點，出現的問題可能就更少了，因為畢竟官網提供的update_schema.sh腳本是適用於小版本的，對於大版本相容性支持不完善。

在升級過程中主要在v2.0.0需要修改部分源碼相容升級，其他版本基本都是需要修改schema對應的ddl腳本相容升級，主要升級流程總結如下：

• 下載目標升級安裝包（需要滾動升級的源碼包和二進位包下載）

下載新穩定版本（待升級版本）的所有二進位安裝包，並將二進位包放到與當前 DolphinScheduler 舊服務不一樣的路徑中，升級步驟需在新版本的目錄進行。

註意：如果存在跨大版本升級需求，尤其是跨v2.0.0版本，需要下載2.0.0源碼包，修改詳見（3）

• Dolphin Scheduler元數據備份（獲取生產舊版本SQL腳本）

從生產環境轉儲或用dump命令備份資料庫腳本文件，一些非必要的日誌表數據可以不要，但需要備份表結構。

• 修改升級版本的配置文件

這裡按版本分為≤v2.0.9和≥v3.0.0，在v2.0.9版本之前，目錄結構大致如下：

在v3.0.0版本之後，目錄結構大致如下：

一般修改遵循先配置升級schema，再配置基礎部署文件的原則。

對於≤v2.0.9而言，配置升級schema需要修改conf/datasource.properties文件並將資料庫驅動包放在lib目錄下即可；而配置基礎部署文件需要修改conf/common.properties、conf/config/install_config.conf、conf/env/dolphinscheduler_env.sh。

對於≥v3.0.0而言，配置升級schema則需要修改bin/env/dolphinscheduler_env.sh並將資料庫驅動包放在tools/libs目錄下即可；而配置基礎部署文件則需要修改bin/env/install_env.sh、alert/master/worker/api-server/conf下的common.properties、application.yaml。

• 更新資料庫、執行資料庫升級腳本

這裡說明一下，如果剛好是v2.0.0之前的舊版本，那就會遇到一個棘手問題：工作流定義表大JSON未拆分。首先需要通過官方提供的update-schema.sh拆分大JSON並且在執行過程中會出現很多問題，除非你們公司的舊版本的工作流定義ID未經過刪減一直保持自增並且不間斷，因為官方對於工作流定義中tasks的拆分邏輯是自增的，找不到就會報錯，因此需要修改v2.0.0源碼相容。

• 安裝部署、啟用最新版本的服務

這裡會遇到一個問題，當執行bin/install.sh後，應該在3.1.x版本後都會遇到， 在install.sh的第四步<即：4.delete zk node>中會出現如下報錯：

大概分析了下，經過排查定位確定是缺jar包，我用的Zookeeper版本為v3.8.0。而worker-server/master-server/api-server的libs下commons-cli-1.2.jar源包中也確實沒有DefaultParser類，是因為1.2的版本過低。

解決辦法：下載≥1.4的common-cli包分別放到各服務對應的libs下，再次安裝部署就沒問題了，https://mvnrepository.com/artifact/commons-cli/commons-cli/1.4，效果如下：

這裡會出現一個顯眼的ERROR信息：ERROR org.apache.zookeeper.util.ServiceUtils - Exiting JVM with code 0，雖然看著不舒服，但請忽略這個是Zookeeper正常執行完命令的退出碼，0表示程式正常終止，如果仍存在疑惑可以打開一個Zookeeper客戶端（bin/zkCli.sh）Ctrl+D試一下退出。

• 初始化數據、驗證新版本功能

初始化數據主要包括：租戶、用戶、告警組及實例、資源中心、數據源中心、環境管理等數據信息維護，這些需要根據公司具體業務場景自行維護，功能驗證這裡不再贅述。

（3）滾動升級過程中遇到的問題總結

• OutOfMemoryError：Java heap space (v1.3.6->v2.0.0)

出現這種問題的原因是：在升級到v2.0.0過程中需要拆分工作流定義表process_definition_json欄位，而我們的工作流定義數為6463個（隨著業務量還在增長中），拆分需要大量耗費記憶體，Java堆空間不足，導致無法分配更多的記憶體，這個需要根據伺服器配置適當調大-Xmx參數，這裡我調整到了-Xmx4g，然後升級就沒問題了。

• json split error && NullPointException：null (v1.3.6->v2.0.0)

這個問題說實在的，剛開始是一臉懵逼啊，差點讓我放棄了跨大版本的升級之路，然後直覺告訴我遇到問題不要慌，要淡定，於是果斷下載v2.0.0源碼，定位到了源代碼位置，分析後對其進行了修改並列印記錄錯誤日誌，以便後續分析，先讓程式正常運行起來，這裡我在調試過程中主要修改了以下幾處：

源碼修改第1處主要是規避processDefinitionMap為空，導致的空指針異常，如下圖所示：

源碼修改第2處主要是規避task對象節點獲取description描述信息為空，導致的空指針異常，如下圖所示：

源碼修改第3處主要是規避task對象節點獲取preTasks前置任務為空，導致的空指針異常，如下圖所示：

• Data too long for column 'task_params' (v1.3.6->v2.0.0)

這個問題需要修改官方提供的DDL腳本，具體需要修改dolphinscheduler_ddl.sql中t_ds_task_definition_log 的task_params欄位長度text->longtext以及t_ds_task_instance的task_params欄位長度text->longtext，text已經滿足不了任務參數的存儲大小要求了，如下圖所示：

• Duplicate column name 'alter_type' (v2.0.9->v3.0.0)

這個問題是因為在v2.0.9及之前某個版本已經添加過，官方腳本未註釋掉。

• class path resource [sql/upgrade/2.0.0_schema/mysql/dolphinscheduler_dml.sql] cannot be opened because it does not exist （v2.0.0->v3.1.7 這個是前提調研嘗試的）

這個問題個人總結是版本跨度太大導致的，也印證了升級腳本只能小碎步，不能大跨步升級，如果你也遇到跨大版本升級，可以參考我的滾動升級版本，少走彎路。

• Unknown column 'other_params_json' in 't_ds_worker_group' (v3.0.0->v3.1.0)

修改官方提供的DDL腳本，需要調整dolphinscheduler_ddl.sql，t_ds_worker_group表增加other_params_json欄位，t_ds_process_instance表增加state_history欄位，如下圖所示：

• Unknown column 'description' in 't_ds_worker_group' (v3.1.0->v3.1.8)

修改官方提供的DDL腳本（在v3.1.8中3.1.1_schema下），需要調整dolphinscheduler_ddl.sql，t_ds_worker_group表增加description欄位，如下圖所示：

• 不向前相容性的更新

這個相容性主要涉及v3.0.0和v3.1.1版本，對於v3.0.0一個是複製和導入工作流時去掉了copy首碼；使用分號;作為SQL預設分隔符。對於v3.1.1就是改變了unix執行shell的方式由sh改為bash，這些影響基本可以忽略。

（4）集成成果展示

數據中台集成菜單是平臺定義的，只有一個入口菜單，即：海豚調度，這裡嵌入中台的截圖的是v3.1.1的版本，v3.1.8隨後會快速集成進去，除了狀態和定時狀態樣式基本大差不差。

技術創新之數據表血緣

基於海豚調度工作流定義，我們也做了創新性的數據表血緣實踐，總體邏輯通過解析工作流定義，在數據流轉過程中基本都是以Insert...Select這種語法，以輸入表（Select語句）、輸出表（Insert語句）作為流轉過程構建數據血緣DAG流圖來賦能我們的業務，相當於為數據中台插了一雙眼，真正做到數據表流轉過程的可視化，這些都是以海豚調度作為核心點展開的。

數據血緣解析及全量查詢

（1）數據血緣解析

• 整體架構

• 解析流程及展示

• 解析SQL的核心代碼

解析SQL表血緣，我們採用的是阿裡的Druid，建議版本（≥V1.2.6），Druid解析SQL還是很強大的，它的TableStat支持Merge、Insert、Update、Select、Delete、Drop、Create、Alter、CreateIndex、DropIndex這些類型並且可以按照語法組合，比如：InsertSelect，我們的血緣解析執行多個insert...select語句解析，多個用分號;分割

（2）數據血緣查詢

（3）全量血緣查詢

全量血緣查詢可以以輸入、輸出表的形式直觀的展示海豚調度項目工作流定義，快速查詢定位到某個任務，給我們數據分析師帶來了極大的便利。

（4）血緣異常處理

在數據血緣解析過程中，難免會出現SQL語句解析異常的情況，我們也考慮到了這一點，總體異常處理流程如下：

用戶收益

• 支撐公司數據中台每日累計近7000的工作流定義任務個數，78個項目基本涵蓋數據中台的所有業務模塊；
• 基於工作流和任務定義構建的表級上下游血緣解析及查詢，真正做到了表血緣關係的統一化檢索和可視化管理，極大提升了數據中台開發人員和數據分析師的日常檢索表的效率；
• 提供了設置任務執行策略模式，在同一工作流實例下任務交叉執行時，保證了數據的準確性；解決了任務間自定義參數上下游依賴傳參問題；
• 後續迭代升級可以做到快速高效地響應數據中台生產需求。

總結與致謝

不得不說基於Apache DolphinScheduler提供的強大集成擴展插件能力大幅提升了企業數據加工、集成、開發的效率，真正做到了為企業業務數據分析高效流轉賦能。

我們第一版數據中台集成部署時使用的是v1.3.6 版本。目前社區已經發佈了v3.1.8，並且這次我們也是滾動升級到了最新版本v3.1.8，也是緊跟社區步伐，官方社區v3.2.0也在預熱中，迭代速度之快，也側面反映了用戶群體在日益倍增。如果你們公司正在為選擇大數據調度組件而苦惱，我們真心強烈建議使用海豚調度。

加入社區、進DS Group群，DS也會有每周的FAQ環節及時為你答疑解惑，貼心服務，你值得擁有。

強烈值得推薦Apache DolphinScheduler，調度選的好，下班回家早；調度選的對，半夜安心睡！希望大家都能從中受益，告別996。

最後，衷心祝願Apache DolphinScheduler生態圈越來越好！

用戶簡介

蜀海（北京）供應鏈管理有限責任公司

所屬行業：整體食材供應鏈

蜀海供應鏈成立於2014年6月，是集銷售、研發、採購、生產、品保、倉儲、運輸、信息、金融為一體的餐飲供應鏈服務企業，現為廣大餐飲連鎖企業及零售客戶提供整體食材供應鏈解決方案服務。

蜀海擁有遍佈全國的現代化冷鏈物流中心、食品工廠、蔬果加工中心、底料加工等基地。以安全透明的供應鏈體係為餐飲客戶提供品質服務，解決餐飲行業難標準化的痛點。在凈菜生產、菜品研發、餐飲標準工業化等項目領域做持續不斷的研究升級下，蜀海獲得了業內權威機構和廣大客戶的認可，已成為供應鏈領域的標桿企業。

本文由 白鯨開源 提供發佈支持！