前言： 大數據領域對多種任務都有調度需求，以離線數倉的任務應用最多，許多團隊在調研開源產品後，選擇Apache DolphinScheduler（以下簡稱DS）作為調度場景的技術選型。得益於DS優秀的特性，在對數倉任務做運維和管理的時候，往往比較隨意，或將所有任務節點寫到一個工作流里，或將每個邏輯節 ...
前言： 大數據領域對多種任務都有調度需求，以離線數倉的任務應用最多，許多團隊在調研開源產品後，選擇Apache DolphinScheduler（以下簡稱DS）作為調度場景的技術選型。得益於DS優秀的特性，在對數倉任務做運維和管理的時候，往往比較隨意，或將所有任務節點寫到一個工作流里，或將每個邏輯節點單獨定義一個工作流， 缺少與數倉建模對應的任務管理規範；
這造成了數據管理困難和異常容錯繁瑣等痛點，本文基於數倉建模標準的方法論，構建一套用於DS管理數倉任務的規範，避免以上痛點。
海豚調度數倉任務現狀分析
本文緣起社區負責人的痛點定位；在使用DS做數倉任務管理時，數據建模分層落地到調度上缺少規範，社區用戶用起來比較亂，基於這個原因，寫了這篇文章。
在使用調度能力的時候，一些常見的場景如下：
一個任務流構建數倉所有的邏輯節點
Apache DolphinScheduler里有任務血緣的概念，這個概念和數據血緣有許多類似的地方；在構建調度任務的時候，用戶容易將任務血緣和數據血緣混淆，希望在構建數倉生命周期的時候，通過任務血緣呈現出數據血緣的關係，這導致丟失了數據建模規範的分層管理。
類似例子如下：
單個工作流：
包含所有計算邏輯：
優點：這樣做的好處是可以在一個工作流里直觀的復現數據建模；
缺點：對於數據管理困難，只能人為的觀察定位數據情況；
任務運行異常後，容錯困難，要排查所有邏輯節點，並將計算邏輯回滾，這是特別繁瑣的過程；
每個邏輯節點構建一個任務流
除了將整個數倉的邏輯包裝到一個工作流，還有另外一種方式：將每個邏輯節點包裝成一個工作流；這種能很好的將計算邏輯解耦，任務運行異常的時候邏輯回歸也清晰簡單；但是依舊沒有做到合理的數倉建模分層管理，且操作繁瑣，面對超大量任務時，創建工作流將成為一種負擔。
類似例子如下：
優點：優秀的異常容錯，任務出現異常計算的時候，前後任務邏輯就能異常回滾重跑；
缺點：任務流創建繁瑣，且沒有做好數倉規範的數據分層管理。
數倉任務管理調度****需求分析
從數倉的視角，任務調度核心需求是：任務類型、依賴關係、定時調度、任務優先順序，以及數倉分層管理，層級依賴（調度系統的視角，還有高可用、告警、資源管理、用戶安全、易用性、可擴展等能力）。
任務類型、依賴關係、定時調度、任務優先順序是系統提供的能力，數倉分層管理和層級依賴是調度能力之上的任務管理規範。這裡參考數據建模規範構建與之對應的任務管理規範。
數據建模架構如下：
數據建模到數倉開發過程中需要關註4點：
-
邏輯開發：數據需求的實現；
-
數據管理：各層級數據劃分；
-
開發依賴：數據層級依賴實現；
-
異常容錯：異常任務定位和數據複原重跑。
構建在調度系統之上的數倉任務編排規範，需要滿足以上要求。
數倉開發任務管理規範
為了和數據建模規範保持一致，我們按照數據建模的分層理論，設計調度任務的編排規範。
從頂層設計上將工作流定義為3類：
-
數倉分層工作流：ODS、DIM、DW、ADS每層一個工作流；DW層可以根據業務需求，細分出三個DWD、DWM、DWS等好實現業務需求的單獨任務流管理；
-
數倉任務Master管理工作流：將數倉分層，按照開發依賴串聯到一個工作流中統一管理；
-
異常容錯工作流：數倉運行過程中，中途出錯或者結果異常，需要數據環境複原，就可以將中間表清理邏輯包裝在異常容錯工作流，做統一數據清理，然後再從頭跑數倉任務。
數倉開發工作流規範如下：
數倉每層工作流只關註每層的邏輯；以ODS層為例，該層提供多個數據應用方數據支持，所以在這個任務工作流里，構建這一層的所有邏輯節點：
運行任務管理Master工作流，節點佈局規範如下：
異常容錯工作流：
這一個工作流，主要是為了在任務運行異常時，刪除中間表計算的新增結果；
依據數據模型的表設計，想將DS的任務血緣當簡單數據血緣使用需求的，可以在這一個工作流里將節點關聯，數據清理和任務血緣不衝突，還可以順便檢測數據清理情況。
結語
除此之外，數倉還有一些局部概念需要在任務編排上做規範，比如需要將DS項目和數倉映射，一個DS項目管理一個數倉；需要將數據集市和工作流映射，ADS層有多種數據應用場景就拆分成多個工作流等；本文的規範是以數倉標準數據模型構建的，如果有特殊需求，可以在這個任務管理規範基礎上做相應調整。
如果這份博客對大家有幫助，希望各位給i7楊一個免費的點贊
