基于DolphinScheduler的使用淺談數倉分層及模型設計

前言：本文旨在簡單介紹DS的概述和架構上的設計，對其安裝等不做展開介紹，之前了解了一下，很多小伙伴也在使用該產品，我呢，也是到現在公司后才開始接觸并使用，對其 “開發” 的還不夠深，這里根據官方檔案和專案中的實踐和大家簡單分享，歡迎大家批評指正，敬禮！

一、簡介

DS是分布式易擴展的可視化作業流任務調度平臺，

Apache DolphinScheduler是一個分布式去中心化，易擴展的可視化DAG作業流任務調度平臺，致力于解決資料處理流程中錯綜復雜的依賴關系，使調度系統在資料處理流程中開箱即用，

二、架構圖

三、架構設計

1、名詞解釋

1.1、DAG：

? 相信大家對這個次并不陌生，在spark和flink中都有這個定義，在DS中，作業流中的Task任務以有向無環圖的形式組裝起來，從入度為零的節點進行拓撲遍歷，直到無后繼節點為止，舉例如下圖：

1.2、任務型別：

? 目前支持有SHELL、SQL、SUB_PROCESS(子流程)、PROCEDURE、MR、SPARK、PYTHON、DEPENDENT(依賴)，同時計劃支持動態插件擴展，注意：其中子 SUB_PROCESS 也是一個單獨的流程定義，是可以單獨啟動執行的，舉例如下圖：
注：左側邊欄看大的都是可調度執行的組件，暢用無限~

1.3、調度方式：

? 系統支持基于 cron 運算式的定時調度和手動調度，

? 命令型別支持：啟動作業流、從當前節點開始執行、恢復被容錯的作業流、恢復暫停流程、從失敗節點開始執行、補數、定時、重跑、暫停、停止、恢復等待執行緒，其中 恢復被容錯的作業流 和 恢復等待執行緒 兩種命令型別是由調度內部控制使用，外部無法呼叫，舉例如下圖：

1.4、依賴：

? 系統不單單支持 DAG 簡單的前驅和后繼節點之間的依賴，同時還提供任務依賴節點，支持流程間的自定義任務依賴，說到依賴想重點和兄弟們討論下這個問題，但是文字表達起來比較費勁，希望各位兄弟可以留言，咱們針對具體問題一起聊聊，

1.5、補數：

? 補歷史資料，支持區間并行和串行兩種補數方式

1.6、郵件告警：

? 支持 SQL任務 查詢結果郵件發送，流程實體運行結果郵件告警及容錯告警通知

下圖：是單獨執行任務時進行的相關配置，我個人感覺補數功能是比較牛X的，用好系統時間的變數，造作起來吧（我也是這兩天遇到了這樣的需求，才 “開發出了這個功能”），歡迎兄弟們一起討論，

2、系統架構

2.1、系統架構圖

2.2、架構組成、簡介

• MasterServer

  MasterServer采用分布式無中心設計理念，MasterServer主要負責 DAG 任務切分、任務提交監控，并同時監聽其它MasterServer和WorkerServer的健康狀態， MasterServer服務啟動時向Zookeeper注冊臨時節點，通過監聽Zookeeper臨時節點變化來進行容錯處理， MasterServer基于netty提供監聽服務，

• WorkerServer

  WorkerServer也采用分布式無中心設計理念，WorkerServer主要負責任務的執行和提供日志服務， WorkerServer服務啟動時向Zookeeper注冊臨時節點，并維持心跳， WorkerServer基于netty提供監聽服務，

• ZooKeeper

  ZooKeeper服務，系統中的MasterServer和WorkerServer節點都通過ZooKeeper來進行集群管理和容錯，另外系統還基于ZooKeeper進行事件監聽和分布式鎖，

• Task Queue

  提供任務佇列的操作，目前佇列也是基于Zookeeper來實作，由于佇列中存的資訊較少，不必擔心佇列里資料過多的情況，

• Alert

  提供告警相關介面，介面主要包括告警兩種型別的告警資料的存盤、查詢和通知功能，其中通知功能又有郵件通知

• API

  API介面層，主要負責處理前端UI層的請求，該服務統一提供RESTful api向外部提供請求服務， 介面包括作業流的創建、定義、查詢、修改、發布、下線、手工啟動、停止、暫停、恢復、從該節點開始執行等等

• UI

  系統的前端頁面，提供系統的各種可視化操作界面

2.3、架構設計思想

一、去中心化vs中心化

中心化思想：

? 中心化的設計理念比較簡單，分布式集群中的節點按照角色分工，大體上分為兩種角色：

• Master的角色主要負責任務分發并監督Slave的健康狀態，可以動態的將任務均衡到Slave上，以致Slave節點不至于“忙死”或”閑死”的狀態，
• Worker的角色主要負責任務的執行作業并維護和Master的心跳，以便Master可以分配任務給Slave，

? 中心化思想設計存在的問題：

• 一旦Master出現了問題，則群龍無首，整個集群就會崩潰，為了解決這個問題，大多數Master/Slave架構模式都采用了主備Master的設計方案，可以是熱備或者冷備，也可以是自動切換或手動切換，而且越來越多的新系統都開始具備自動選舉切換Master的能力,以提升系統的可用性，
• 另外一個問題是如果Scheduler在Master上，雖然可以支持一個DAG中不同的任務運行在不同的機器上，但是會產生Master的過負載，如果Scheduler在Slave上，則一個DAG中所有的任務都只能在某一臺機器上進行作業提交，則并行任務比較多的時候，Slave的壓力可能會比較大，

去中心化思想：

• 在去中心化設計里，通常沒有Master/Slave的概念，所有的角色都是一樣的，地位是平等的，全球互聯網就是一個典型的去中心化的分布式系統，聯網的任意節點設備down機，都只會影響很小范圍的功能，
• 去中心化設計的核心設計在于整個分布式系統中不存在一個區別于其他節點的”管理者”，因此不存在單點故障問題，但由于不存在” 管理者”節點所以每個節點都需要跟其他節點通信才得到必須要的機器資訊，而分布式系統通信的不可靠性，則大大增加了上述功能的實作難度，
• 實際上，真正去中心化的分布式系統并不多見，反而動態中心化分布式系統正在不斷涌出，在這種架構下，集群中的管理者是被動態選擇出來的，而不是預置的，并且集群在發生故障的時候，集群的節點會自發的舉行"會議"來選舉新的"管理者"去主持作業，最典型的案例就是ZooKeeper及Go語言實作的Etcd，
• DolphinScheduler的去中心化是Master/Worker注冊到Zookeeper中，實作Master集群和Worker集群無中心，并使用Zookeeper分布式鎖來選舉其中的一臺Master或Worker為“管理者”來執行任務，

四、實踐

注：這部分的話，我截圖給大家展示一下吧，然后配一些文字說明，有感興趣的小伙伴可以討論哈，

先來介紹下我們這邊大致的設計思路：

? 按照數倉分層的思想，我們構建出了四個主要的專案，當然還會有一些其他的專案，包括臨時需求、多場景取數等等吧，下面來重點看下這四個專案中內容：

1、dw_ods層

? 看到這個名字，不用說，相信大家也知道是在做什么事了，對嘍，就是你們想的那樣，我來說下我們這邊ODS層的設計吧（可能很亂，見笑了各位大佬）

對了，就是有這么多的ODS庫，是不是很酸爽？基于工具的不能全域查找的特性，在不了解表的情況下，再加上運氣背的話，可能要翻遍整個ODS的庫才能知道你想看的表在哪個庫下（哭瞎）~~

這么設計也是歷史遺留問題了，很難再改變了，這就是所謂的按照業務系統的劃分，在ODS落地時，也做了分庫，并且基本是和ODS保持高度一致的，
其實從另外一面看待，這么設計也沒什么問題，
也有了解過其他小伙伴們在ODS層的設計，其中有一種是將所有的ODS層表落到一個庫下，但是在命名的時候，會按照業務系統進行劃分，我個人覺得這兩種設計各有利弊吧，不能絕對的說誰好誰壞~
另外還有一點，就是ODS層表的設計，目前我們是采用磁區表進行存盤的，并定期對歷史磁區進行洗掉，以保證存盤空間和執行效率，當然也有把ODS層直接進行truncate再進行全量寫的~看自己公司的設計理念和習慣了，

來給大家展示下，在DS中的設計：

這兩張圖非常清晰的展示了我們在ODS層的設計，懂得一眼就明白了，不明白的咱可以留言交流，

2、dw_dwd層

說下DWD的設計，在數倉中將業務流轉換為資料流，根據業務程序劃分出主題，采用維度建模的方式，將資料進行匯總，采用一些七七八八的手段，盡可能的提高dwd層表的復用性，

? 在DS中，根據主題表創建不同的作業流：

? 弊端：等主題慢慢膨脹起來，管理起來比較費勁

? 好處：各自為戰，清晰明了

來看上面圖二：

? 這是我們眾多DWD表中的一張，在DS中，設定任務調度時，強依賴了DS中的依賴組件，并將DWD表中涉及到的ODS表增加至依賴中，這樣做的好處，是比較精準的把控了每一張DWD表的動向，

3、dw_dws層

DWS層的設計也是比較明確的，基于DWD的層表，在同粒度的情況下，對資料進行匯總，然后形成主題寬表，
我們在設計這層的時候，嚴格按照數倉設計的規范：DWS層的表只能使用DWD的表進行關聯匯總，堅決不允許出現跨層使用的情況，
如果在生產程序中，發現現有模型不能很好的支持業務的輸出，會定期對模型進行小范圍的重構（增減欄位等），以保證模型的復用能力和“活力”，
在DS中，我們也是按照主題寬表進行分作業流設計的，如下圖：

如上圖二：在DWS中，我們也是按照依賴對作業流進行了設計，DIM層、DWD層都是在執行完畢的情況下，才能繼續往下走，
PS：做任務依賴這點DS還是很香的，當然很多同學想用弱依賴來更加完美的配置作業流，但是目前DS貌似不支持，期待新功能早日上線吧，

4、DM層

設計完DWS層算是完成一大半作業了，DM層（或者叫ADS層）基本就是根據實際的報表需求，對資料進行匯總，最終由DM層將資料推到OLAP（目前我們使用的Doris，感興趣的小伙伴可以一起交流下，哇咔咔~）供業務或者分析師使用，

5、DIM層

對了，差點忘了說，還有比較重要的一層：DIM層，即維度層，
在數倉建設的程序中，嚴格遵守一致性維度的原則，維度層的表是可以進行跨層使用的，下面展示下我們數倉分層的架構簡圖：

五、結束語

本文介紹了DS的架構原理和我實際作業中的使用情況，在我們整個數倉專案中，DS起到了至關重要的作用，使得開發效率明顯提升，調度任務管理起來也更加清晰，
說一說我在使用程序中的心得吧，我個人個感覺，對調度的設計也是需要畫個架構圖提前規劃的，不然隨著需求的增加，專案越來越多，作業流越來越多，管理就變得困難了，提前做好規范，各位開發的小伙伴嚴格按照規范做事，即使會出圈也不會跑太偏，
本文篇幅有限，有些問題介紹也不是很深入，相信所有使用DS的小伙伴會充分挖掘它的功能，使開發變得更加容易，實際使用的功能還有很多，就不一一介紹了，有興趣的小伙伴可以一起交流，
好了，此致吧，敬禮了~~睡覺了，晚安！！！