作者簡介：wade，嘰里呱啦攻城獅一枚，曾就職於蘇寧，同花順等，9個月大粿粿的爸爸。 |
前言
“工欲善其事，必先利其器” |
在 2019 年進行數倉建設時，選擇一款易用、方便、高效的調度系統被擺在非常突出的位置，感謝前同事馬振洋同學和楊孟霏同學的付出，最終有緣選擇了 DolphinScheduler的前身 EasyScheduler (后面使用 ES 代替)，版本為 1.1，差不多成了第一批在生產上使用海豚調度產品的吃瓜群眾，同時我們也在密切關注社區的變化，並成功在 2020 年 8月份升級至現在的 DolphinScheduler 1.3.2 版本(再次感謝楊孟霏同學，你是最棒的)，在穩定性和功能豐富性上有了大幅度提升。
寫在開頭，先說下成績，每天運行的工作流實例 1500+，任務實例達到了 6000+，今天就是以用戶視角，從管理，開發，運維三個角度談一下一年多使用 DS ( DolphinScheduler 的縮寫，后面使用這個來代替)的感受，為社區其他同事提供一個避坑參考，也希望把用戶的真實感受反饋給社區，和社區共同進步 up！！！！！
一、管理篇
DS 作為數倉處理工作實際上的運維管理者，對 DS 的管理能力非常看重，如何管理好 DS 上的眾多玩家和成千上萬的任務，保證系統穩定健康，一直是我們孜孜不倦的追求，首先我們帶着問題出發，DS 能夠回答的問題又有哪些？
模塊 |
核心訴求 |
權限 |
￮ 生產上數據源、資源文件、項目的權限管控問題 ￮ Worker分組權限 ￮ 報警分組權限 ￮ 工作流權限 |
賬號 |
￮ 工作流負責人如何指定 ￮ 離職人員賬號如何處理 ￮ 運維賬號如何分配 |
系統 |
￮ 系統穩定性如何保障 ￮ 元數據丟失如何快速恢復 |
1.1 權限
￮ 數據源
數據源中心進行數據源配置，支持主流關系型數據庫數據源或者開源大數據框架，個人建議線上環境部署使用公共賬號，配置示例如下：
這樣有幾個好處：
1. 大量減少數據源個數，方便后續進行IP或者連接賬號的統一管理，方便賦權，進行權限控制
2. 當有人離職時，即使賬號被刪除，不會對已有工作流運行產生影響（離職賬號被刪除還會引發別的問題，后面講）
3. 數據源被授權之后，右側出現的編輯和刪除動作及其危險，應該屬於管理員操作，普通開發不應該具有編輯或者刪除的權限，目前 DS 這一塊沒有做的很完美，有條件的話可以進行二次開發，讓前端直接禁用
￮ 資源文件
有些腳本運行需要在資源中心配置資源文件，比如 datax 同步需要的 json 文件，目前在 DS 上面同樣也有廣泛的用途，這個功能可以擺脫服務器的限制，做到配置全 web 操作，上一張已經配置好的圖片，具體怎么使用，官方說明里面有，不再贅述。
目前遇到的幾個影響體驗的點
1.默認上傳路徑為 hdfs 路徑，datax 調用的是本地路徑，因此需要把文件從 hdfs 下載到本地，發現重新上傳之后，執行下載不起作用，沒有覆蓋原來的文件，建議寫腳本進行判斷
2.資源授權被文件擠占，導致無法多選，一次性不能賦權太多，建議前端對這一塊進行修改
￮ 項目
在 ES 時代，由於沒有跨項目依賴功能，所有項目只能混在一起，搜索任務只能依靠工作流名稱，得益於 DS 提供的跨項目依賴功能，果斷進行項目的拆分，合理進行布局
合理創建項目應該遵循以下幾個原則：
1. 按照團隊角色進行分類(BI 團隊、AI 團隊、數倉團隊)
2. 按照數倉應用進行分類
3. 按照數倉層次進行分類
4. 業務開發項目和非業務項目進行拆分
5. 不同的調度周期也可以作為考慮因素
強烈建議大家禁用頁面上的刪除按鈕，是個非常危險的存在，工作流不可以賦權，項目一旦被賦權之后，可以看到下面所有的工作流
線上環境權限建議配置如下：
模塊 |
管理員 |
開發人員/運維人員 |
賬號 |
增刪改查 |
可以改密碼 |
數據源 |
增刪改查 |
可查 |
資源 |
增刪改查 |
可查 |
項目 |
增刪改查 |
可查 |
工作流 |
增刪改查 |
可查 |
監控中心 |
可見 |
可見 |
安全中心 |
可見 |
不可見 |
1.2 賬號
目前不建議大家直接刪除已離職賬號，直接刪除會導致兩個問題的發生
1. 由該賬號創建的數據源會失效，工作流無法運行，使用公共數據源可以規避這個問題
2. 由該賬號創建的定時會失效，界面無法查到，因為對應的用戶 ID 找不到了
【解決方案】：暫時可以更改離職人員密碼，賬號不可登錄即可
￮ 負責人
目前調度系統界面上顯示的為修改人，當對工作流進行編輯/保存之后，修改人立刻發生變化為最后一次修改工作流的人，通過查看調度系統后台數據庫，發現還有一個創建人ID，界面上未顯示，這兩類角色均無法表示此工作流的實際負責人
【創建人】：一般為初始負責人，但是由於工作流會發生移交或者離職，導致工作流負責人發生變化
【修改人】：修改人只是臨時修改，有可能是組內其他同事修改，或者管理員在線上修改，也無法表示工作流的實際負責人
【負責人】：數倉項目實際開發中某個業務模塊的負責人，對該工作流負責
【解決方案】：目前建議進行二次開發，批量在界面進行授權，以方便后續的問題排查
1.3 系統
建議 DBA 定期進行備份，同時數據定期備份至數倉進行二次保證，一旦工作流被意外刪除，可以做到快速恢復，不會影響生產
總結：1.權限控制粒度比較粗，一旦授權即擁有所有權限(增刪改查)、生產的危險性比較高，無法控制到工作流層級。 2.主要升級：支持了跨項目間依賴 DS 目前的權限體系個人覺得還處於從 0 到 1 的過程中，權限授權太大，甚至可以刪除項目，這是極其危險的動作，缺少任務負責人、操作記錄審計等一系列系統保護的功能。
|
編輯注：后續社區希望實現“用戶-角色-權限”+ 審計的方式來實現權限管控，對此有興趣貢獻的伙伴歡迎來聯系我微信: taskflow
二、開發篇
上一篇管理篇講的更多的是開發的外圍准備工作，現在就深入開發本身來理解一下 DS 的設計原則和最佳實踐，根據官方的設定，整體按照 “項目 --> 工作流 --> 節點任務” 三個層次去進行開發，可以做到各種技術棧開發的節點混排，當節點任務特別多的時候，建議引入 SUB_PROCESS 子工作流進行封裝和屏蔽。
2.1 整體概述
數據開發整體在畫布進行操作，組織成一個 DAG 圖進行運行，官方提供的可以配置的節點還是比較多的，具體操作可以參考官方使用文檔，這里主要對於其中主要的組件作一個補充說明。
2.2 重點組件
目前在嘰里呱啦主要使用了【shell】、【sub_process】、【sql節點】、【depend節點】進行離線數倉的開發。大致位置如下圖：
￮ shell
配置方式 1 如圖：
說明: Worker 分組為 Spark 並不是真正的 Spark 任務，只是命名而已，需要將 sh 腳本線下放到 Spark Worker 分組的這台機器上，讓調度系統可以識別，腳本輸入框調用路徑與 sh 腳本實際存放路徑一致即可。
配置方式 2 如圖：
這種方式相對於 1 來說區別在於：
1. 上傳 sh 腳本可以在調度系統完成，通過資源文件直接上傳，不需要線下通過 jumpserver(跳板機) 上傳到服務器
2. 直接顯示代碼，可以更清晰的定位問題，不需要再下載服務器上的代碼來看
主要問題：
1. shell 節點無法看到代碼，雖然可以暴露代碼，如果代碼太長，或者依賴的資源文件比較多的情況，配置和運維的難度系數還是比較高
2. shell 節點實踐過程中，會出現 shell 節點日志報了失敗，調度任務處於成功的情況，猜測 DS 雖然可以吊起 shell 腳本，但是對於 shell 腳本的控制力沒有那么強，沒有進行深度的集成
3. shell 腳本一旦運行，調度系統無法對 shell 腳本進行停止等操作，需要額外人工運維
4. shell 腳本的運行日志五花八門，沒有統一格式，需要具體問題具體分析
5. 資源文件中 datax 的 json 中的用戶名/密碼是明文顯示，存在安全風險，可以對datax 進行二次開發
總結：shell 節點可以運行包括jar包、py腳本、sh腳本，因此具備非常強的兼容性和靈活性，可以作為最后的備選方案，但是同時也有很多的缺陷需要注意，如果可以使用DS原生的節點任務，還是建議使用特定的節點任務 |
￮ SUB_PROCESS
這個節點的出現，一開始我不是很理解，一個代碼可以在多個地方執行的場景，運行多次是對資源的極大浪費，可以一次調用然后依賴執行就行了，但是其實這個節點第二個作用在於可以在任務節點和工作流之間，再架設一層實現對多任務節點的分類，在大型應用場景中(比如會員畫像，復雜報表統計)，可以使用該組件對代碼進行封裝，整體布局變得更加清晰，下面我們就以生產為例來說一下：
假如我們要加工的指標有 20+，DS 無法支持多段 sql 的執行，更是加劇了這種多節點的情況，這是一個績效統計的代碼，節點多達 28 個，后續迭代維護可能導致節點任務進一步增加，示意圖如下：
使用了 SUB_PROCESS 節點之后，通過分類歸納，對於這種多節點任務進行可重構, DS 的強大之處在於可以不同節點進行混排，完全取決於開發人員，使的外層節點任務可以降到 10 個以下，很方便去定位問題(沒有放績效、給的是標簽工作流，理解原理即可)
子節點任務的配置需要先設定一個工作流，定時不需要設置，在主工作流中進行引用即可
總結：這個節點對於復雜工作流的重構提供了一種思路，建議大家可以去嘗試下，單個工作流的節點任務連接線最好不要有交叉，節點數量控制在 20 個以內為宜。 |
￮ SQL節點
sql 節點可以說是數倉使用最多的節點了，SQL 語法取決於你的數據源是什么類型的數據庫，這里主要講解數倉使用最多的 Hive，相比於 shell 腳本，配置起來更加簡單，提交一段查詢就可以，直接貼一段生產代碼
【 sql 參數】：hive調參命令 set 被省略了
【 UDF 函數】：這個可以不用管，一般 udf 不需要臨時添加，試過用資源文件配置，sentry 機制不允許，一般會注冊成永久 udf，直接在sql語句里面使用即可
【自定義參數】：按照圖示配置即可
【前置 sql/后置sql 】: 執行簡單 drop 語句，不建議在這里去寫業務代碼，主要功能在於保障數倉的任務執行是可以重跑的。
【彩蛋】
這個地方的 SQL 語句除了可以進行數據 ETL，還可以配合郵件系統將 SQL 執行結果直接發送到郵件，可以實現部分數據提取、監控的功能，但是屬於輕量級，不建議大規模使用，郵件系統容易崩潰，配置如下。
PS 踩坑教訓：
1. 變量名、參數變量設置 [yyyyMMdd] 之間不要存在空格，否則空指針警告
2. 代碼里面的變量引用必須要有變量命名，即使注釋了也不行，否則空指針警告
3. SQL 不要以 “;” 結尾，目前不支持
4. 代碼中不要出現 “?” ，? 屬於保留字，會導致代碼無法執行
5. 正則表達式慎重，可能會出現意想不到的后果
￮ depend 節點
設計初衷主要是為了應對跨工作流依賴的情況，整個數據加工管道是由多個工作流組合，對於跨工作流要有好的機制來實現這個依賴，整個依賴關系圖大致如下：
需要在 B，C，D，F，G 里面配置相應的依賴節點
比如 B 配置依賴 A 和 E 節點，定期掃描，依賴屬於強依賴，需要等到 A 和 E 同時執行完成，且在 B 掃描的時候都完成，當 B 的 depend 節點運行時，A 和 E 如果已經已經啟動，depend 節點會一直處於運行中狀態，直到檢測上游任務是一個失敗or成功的狀態。
遇到的主要問題如下：
1. 從 B 的視角我知道依賴的是誰，但是從 E 的視角來看，我並不知道 B，C，F 依賴了我，一旦工作流數據有問題，無法判斷 E 執行了之后，還需要執行 B，C，E
2. 這種掃描方式屬於被動掃描，E 執行之后是沒辦法主動觸發起 B，C，E，在工作流失敗，需要主動拉起后續任務的時候會極其困難
【解決方案】：
1. 可以根據數據庫的 json 依賴配置信息自行加工一個依賴列表，尋找到需要拉起的 B，C，E
2. 上游任務執行失敗之后，后續任務掃描肯定會失敗，因此只要把失敗的任務逐層手動拉起即可
￮ 補充說明
由於某些功能比較新穎、Hive 的特性不支持、節點操作起來繁瑣等原因，暫時沒有進行使用，被放棄的組件如下：
節點 |
現狀 |
未使用原因 |
PROCEDURE |
未使用 |
hive目前還不支持 store procedure，遇到 hivesql 無法解決的問題，建議直接寫腳本處理 |
MR |
未使用 |
代碼量大，維護成本高，HiveSQL 無法處理的情況，寫 UDF 進行擴展 |
SPARK/Flink/Py |
未使用 |
未使用 spark，hive on spark只需要設置參數即可，flink 使用 shell 節點代替了 |
Http/sqoop/datax |
未使用 |
沒有調通，datax直接使用shell腳本進行調度 |
Conditions |
未使用 |
沒有找到業務場景 |
總結：上面總結了四種主要的節點任務配置范例和遇到的挑戰，給了一些解決方案，社區也在加緊這一方面的開發，期待中 功能極其豐富，基本可以囊括數據開發的各個方面，且對於 RDBMS 和大數據組件也有很好的支持， 在一些細節處理上還不夠完美，缺少列表依賴功能，級聯重跑功能 |
編輯注: 列表依賴功能，級聯重跑其實社區也有規划
三、運維篇
三分開發，七分運維，運維的難度系數可以說遠勝開發，有沒有被莫名其妙的問題搞得暈頭轉向，作業失敗排查靠什么？靠經驗，經驗有時候並不可靠，靠日志？日志打得不完善，無從查起。。。一旦我們上線一個新的工作流，隨之而來的運維工作會立刻提上日程，今天就一起看下 DS 這一塊是如何實現的？
3.1 流程把控
在 ES 時代，假如在測試環境配置了一個工作流，要想發布到線上，同樣的流程需要在線上再操作一遍，這個過程不但無聊而且很容易出現人為錯誤，浪費時間，感謝社區，急開發之所急，上線了導入導出工作流這個功能，之前一直沒有體驗這個功能，直到最近在做流程管控，對這個功能重新重視起來，並進行了實戰，現在匯報一下我的實戰結果。
首先看一下新老流程對比
（補充說明：dev:開發環境, fat:測試環境）
server |
大數據 |
說明 |
dev |
dev/fat
|
￮ server 后端的 dev 環境和 fat 對應大數據測試環境，集群規模：5台 ￮ 測試環境的 dev 和 fat 的區別就是 ODS 層的數據源更換 |
fat |
||
pre/rc |
rc/prd |
￮ server 的 rc 環境和 prd 環境對應大數據的生產環境，集群規模：70 台左右 ￮ 使用生產數據進行驗證 |
prd |
老流程采取在線上集群開辟一個邏輯 test 庫的形式進行開發，這種方式在上線到正式庫的時候，需要手動修改代碼，導致上線時間被無限拉長，甚至需要一天的時間來專門發布調試，切換成新的流程之后，大大縮短了上線發布的時間，基本可以控制在 20 分鍾以內，具體操作也比較簡單，導入導出工作流即可，保證線上和線下數據源名稱是一致即可。
目前遇到的主要問題點
1. 從測試環境導出的 json 文件，導入生產后，“描述”會丟失
2. 如果已經有該工作流，新導入的是一個新的工作流，不是覆蓋，需要先修改原來的工作流，然后
再去調整工作流依賴，如果依賴特別多的話，可以直接增量改線上的工作流
3. SUB PROCESS 子流程組件導入會多出一些異常的工作流，需要進行清除
4. 工作流歸屬隊列 default 會變成 flink，這個問題要 check下，不是所有的都這樣(default 和 flink 自己創建的)
5. 同步任務導出到生產上之后，依賴的資源文件無法修改
6. jar 包任務和 flink 實時任務目前不包括
總結：遇到很多細節問題，可能是這個功能大家用的還不夠多，導致沒有進行大的改善，但是這個功能還是非常強大的，可以大大縮短開發上線時間，如果生成全局代碼，使用 Git 管理也是個不錯的選擇 |
3.2 實例監控
問題 1：工作流實例在夜間運行，失敗了怎么才能快速發現？
答案：DS 目前沒有接通企業微信或者釘釘等，可以安排每天安排一個專人值班，擴展整體調度監控郵件，擴展電話告警功能，失敗立即給值班人員電話，可以做到快速修復
編輯注: 已經接通了企業微信，釘釘也有 PR 的
問題 2: 運維時如何快速找到失敗的工作流？
可以根據時間和狀態進行失敗、等待等任務篩選，也可以通過名稱進行模糊搜索
工作流實例是除了工作流定義之外，被打開最多的頁面，執行用戶和 host 的篩選框基本上不會被使用，狀態目前只能支持單選，還不支持多選，在多狀態選擇時有一些問題，支持模糊搜索，還不支持精確搜索，需要社區可以盡快完善這個功能
問題 3: 如何快速查看節點日志？
這個可以從兩個路徑進入節點日志
1. 點擊進入工作流，雙擊節點任務
節點配置右上角有查看日志，彈出節點執行日志
2. 或者復制節點任務，至任務實例查詢，最右側的查看日志
sql 節點任務的日志之前是直接替換？為真正的日期，現在改成顯示變量名，反而有點不適應，沒有顯示 yarn 執行詳細情況，有時候排查問題會比較麻煩
問題 4: 系統運行資源情況，調度各時段執行情況如何有效監控？
目前 DS 提供了首頁整體流程和任務、以及按照人員維度統計的柱狀圖，還有監控中心模塊，形成了一個初步的監控手段
解決方案：針對整體流程和任務運行情況的統計，進行二次開發，進行郵件發送
人員維度統計工作流數量意義有限，更多的還是希望可以看到每個時間段的資源消耗情況和任務執行進度情況的進度條，方便去合理安排工作流定時和優化長耗時任務，監控中心可以用來輔助排查像資源緊張導致的任務長時間提交不上去的情況。
總結：目前由於對於調度任務整體運行情況依然缺乏把控，社區版本可以做到對於job層級的監測，需要進行一些擴展工作 DS 提供了像首頁概覽、監控中心等模塊，但整體監控的粒度還是較粗，希望看到任務執行時 yarn 資源消耗情況，MR 執行詳情，更方便的定位問題。 |
四、最后
使用 DS 一年多以來，最大的感受是，社區願意傾聽廣大用戶的心聲，不斷完善和發展，任何一款產品都不是天生強大，需要所有人的共同努力，不斷的給到正反饋，才能形成合力，開源的意義就是讓大家都參與進來，貢獻自己的力量!
最后也要給社區以誠摯的敬意，希望在未來的道路上變得更好，給大家提供更優質的作品。
編輯注: 嘰里呱啦是國內最早一批使用 DolphinScheduler(2019 年開源不久就開始使用了) 的公司，wade 同學的文章非常具有實踐意義，寫的也非常用心，全文 7000+ 字的實踐一氣呵成，有實踐趟坑也有解決方案(這里豎起大拇指)。Dolphin 今年剛成為 Apache 頂級項目，要走的路還挺長，那在這里我們也真誠呼喚更多熱愛開源的伙伴加入到開源共建隊伍中來，一起讓本土開源做的更好，讓更多人用上易用的、易維護的、穩定的大數據智能調度，誠如小海豚的 Slogan:
歡迎參與開源共建
近 2 年國內開源的迅猛崛起，參與貢獻過開源項目已成為很多公司招聘的加分和優先項，參與開源的過程可以使自己的各方面能力得到快速成長，畢竟社區高手眾多。DolphinScheduler 社區發展十分蓬勃，為了做更好用、易用的智能調度，真誠歡迎熱愛開源的伙伴加入到開源社區中來，為中國開源崛起獻上一份自己的力量，讓本土開源走向全球
參與 DolphinScheduler 社區有非常多的參與貢獻的方式，包括：
貢獻第一個PR(文檔、代碼) 我們也希望是簡單的，第一個PR用於熟悉提交的流程和社區協作以及感受社區的友好度。
社區匯總了以下適合新手的問題列表：https://github.com/apache/dolphinscheduler/issues/4124
如何參與貢獻鏈接：https://dolphinscheduler.apache.org/zh-cn/community/development/contribute.html
來吧，DolphinScheduler開源社區需要您的參與，為中國開源崛起添磚加瓦吧，滴水匯聚亦可成江河。
參與開源可以近距離與各路高手切磋，如果您想參與貢獻，可以添加社區小助手
微信(easyworkflow) 手把手教會您( 貢獻者不分水平高低，有問必答，關鍵是有一顆願意貢獻的心 )。添加小助手微信時請說明想參與貢獻哈，邀請加入貢獻者種子孵化群！
來吧，開源重在參與，我們非常期待您的參與。
作者簡介：wade，嘰里呱啦攻城獅一枚，曾就職於蘇寧，同花順等，9個月大粿粿的爸爸，歡迎數據開發、數據平台研發的同學聯系我微信：viking107270626，歡迎大家多多交流。 |
戳原文，立刻奔向
DolphinScheduler 的 github 倉庫一起玩耍，來個 star 先收藏也是好的~