Apache DolphinScheduler：深入瞭解大數據調度工具

一、海豚調度介紹 Apache DolphinScheduler 是一個分散式易擴展的可視化DAG工作流任務調度開源系統。適用於企業級場景，提供了一個可視化操作任務、工作流和全生命周期數據處理過程的解決方案。 Apache DolphinScheduler 旨在解決複雜的大數據任務依賴關係，併為應用 ...

一、海豚調度介紹

Apache DolphinScheduler 是一個分散式易擴展的可視化DAG工作流任務調度開源系統。適用於企業級場景，提供了一個可視化操作任務、工作流和全生命周期數據處理過程的解決方案。
Apache DolphinScheduler 旨在解決複雜的大數據任務依賴關係，併為應用程式提供數據和各種 OPS 編排中的關係。解決數據研發ETL依賴錯綜複雜，無法監控任務健康狀態的問題。DolphinScheduler 以 DAG（Directed Acyclic Graph，DAG）流式方式組裝任務，可以及時監控任務的執行狀態，支持重試、指定節點恢復失敗、暫停、恢復、終止任務等操作。

file

二、海豚調度特性

簡單易用：

可視化 DAG: 用戶友好的，通過拖拽定義工作流的，運行時控制工具
模塊化操作: 模塊化有助於輕鬆定製和維護。
模塊化操作: 模塊化有助於輕鬆定製和維護。

豐富的使用場景：

支持多種任務類型: 支持Shell、MR、Spark、SQL等10餘種任務類型，支持跨語言，易於擴展
豐富的工作流操作: 工作流程可以定時、暫停、恢復和停止，便於維護和控制全局和本地參數。

High Reliability：

高可靠性: 去中心化設計，確保穩定性。原生 HA 任務隊列支持，提供過載容錯能力。DolphinScheduler 能提供高度穩健的環境。

High Scalability：

高擴展性: 支持多租戶和線上資源管理。支持每天10萬個數據任務的穩定運行。

三、建議配置

操作系統版本要求
file
伺服器建議配置
file
網路要求

Apache DolphinScheduler正常運行提供如下的網路埠配置：

file

客戶端Web瀏覽器要求

Apache DolphinScheduler 推薦 Chrome 以及使用 Chromium 內核的較新版本瀏覽器訪問前端可視化操作界面

四、名詞解釋

DAG：全稱 Directed Acyclic Graph，簡稱 DAG。工作流中的 Task 任務以有向無環圖的形式組裝起來，從入度為零的節點進行拓撲遍歷，直到無後繼節點為止。舉例如下圖：

file

流程定義：通過拖拽任務節點並建立任務節點的關聯所形成的可視化DAG
流程實例：流程實例是流程定義的實例化，可以通過手動啟動或定時調度生成。每運行一次流程定義，產生一個流程實例
任務實例：任務實例是流程定義中任務節點的實例化，標識著某個具體的任務
任務類型：目前支持有 SHELL、SQL、SUB_PROCESS(子流程)、PROCEDURE、MR、SPARK、PYTHON、DEPENDENT(依賴)，同時計劃支持動態插件擴展，註意：其中 SUB_PROCESS類型的任務需要關聯另外一個流程定義，被關聯的流程定義是可以單獨啟動執行的
調度方式：系統支持基於 cron 表達式的定時調度和手動調度。命令類型支持：啟動工作流、從當前節點開始執行、恢復被容錯的工作流、恢復暫停流程、從失敗節點開始執行、補數、定時、重跑、暫停、停止、恢復等待線程。其中恢復被容錯的工作流和恢復等待線程兩種命令類型是由調度內部控制使用，外部無法調用
定時調度：系統採用 quartz 分散式調度器，並同時支持cron表達式可視化的生成
依賴：系統不單單支持 DAG 簡單的前驅和後繼節點之間的依賴，同時還提供任務依賴節點，支持流程間的自定義任務依賴
優先順序：支持流程實例和任務實例的優先順序，如果流程實例和任務實例的優先順序不設置，則預設是先進先出
郵件告警：支持 SQL任務查詢結果郵件發送，流程實例運行結果郵件告警及容錯告警通知
失敗策略：對於並行運行的任務，如果有任務失敗，提供兩種失敗策略處理方式，繼續是指不管並行運行任務的狀態，直到流程失敗結束。結束是指一旦發現失敗任務，則同時Kill掉正在運行的並行任務，流程失敗結束
補數：補歷史數據，支持區間並行和串列兩種補數方式，其日期選擇方式包括日期範圍和日期枚舉兩種

五、模塊介紹

dolphinscheduler-master master模塊，提供工作流管理和編排服務。
dolphinscheduler-worker worker模塊，提供任務執行管理服務。
dolphinscheduler-alert 告警模塊，提供 AlertServer 服務。
dolphinscheduler-api web應用模塊，提供 ApiServer 服務。
dolphinscheduler-common 通用的常量枚舉、工具類、數據結構或者基類
dolphinscheduler-dao 提供資料庫訪問等操作。
dolphinscheduler-remote 基於 netty 的客戶端、服務端
dolphinscheduler-service service模塊，包含Quartz、Zookeeper、日誌客戶端訪問服務，便於server模塊和api模塊調用
dolphinscheduler-ui 前端模塊

六、功能介紹

1.項目首頁

在項目管理頁面點擊項目名稱鏈接，進入項目首頁，如下圖所示，項目首頁包含該項目的任務狀態統計、流程狀態統計、工作流定義統計。這幾個指標的說明如下

任務狀態統計：在指定時間範圍內，統計任務實例中狀態為提交成功、正在運行、準備暫停、暫停、準備停止、停止、失敗、成功、需要容錯、kill、等待線程的個數
流程狀態統計：在指定時間範圍內，統計工作流實例中狀態為提交成功、正在運行、準備暫停、暫停、準備停止、停止、失敗、成功、需要容錯、kill、等待線程的個數
工作流定義統計：統計用戶創建的工作流定義及管理員授予該用戶的工作流定義

file

2.工作流定義

創建工作流定義

點擊項目管理->工作流->工作流定義，進入工作流定義頁面，點擊“創建工作流”按鈕，進入工作流DAG編輯頁面，如下圖所示：

file

工具欄中拖拽到畫板中，新增一個Shell任務,如下圖所示：

file

添加Shell任務的參數設置：

填寫“節點名稱”，“描述”，“腳本”欄位；
“運行標誌”勾選“正常”，若勾選“禁止執行”，運行工作流不會執行該任務；
選擇“任務優先順序”：當 worker 線程數不足時，級別高的任務在執行隊列中會優先執行，相同優先順序的任務按照先進先出的順序執行；
超時告警（非必選）：勾選超時告警、超時失敗，填寫“超時時長”，當任務執行時間超過超時時長，會發送告警郵件並且任務超時失敗；
資源（非必選）：資源文件是資源中心->文件管理頁面創建或上傳的文件，如文件名為 test.sh，腳本中調用資源命令為 sh test.sh。註意調用需要使用資源的全路徑；
自定義參數（非必填）；
點擊"確認添加"按鈕，保存任務設置。

配置任務之間的依賴關係：

點擊任務節點的右側加號連接任務；如下圖所示，任務 Node_B 和任務 Node_C 並行執行，當任務 Node_A 執行完，任務 Node_B、Node_C 會同時執行。

file

實時任務的依賴關係：

若DAG中包含了實時任務的組件，則實時任務的關聯關係顯示為虛線，在執行工作流實例的時候會跳過實時任務的執行

file

刪除依賴關係：點擊右上角"箭頭"圖標，選中連接線，點擊右上角"刪除"圖標，刪除任務間的依賴關係。

file

保存工作流定義：點擊”保存“按鈕，彈出"設置DAG圖名稱"彈框，如下圖所示，輸入工作流定義名稱，工作流定義描述，設置全局參數（選填，參考全局參數），點擊"添加"按鈕，工作流定義創建成功。

file

執行策略：

並行：如果對於同一個工作流定義，同時有多個工作流實例，則並行執行工作流實例。
串列等待：如果對於同一個工作流定義，同時有多個工作流實例，則並行執行工作流實例。
串列拋棄：如果對於同一個工作流定義，同時有多個工作流實例，則拋棄後生成的工作流實例並殺掉正在跑的實例。
串列優先：如果對於同一個工作流定義，同時有多個工作流實例，則按照優先順序串列執行工作流實例。

file

工作流定義操作功能

點擊項目管理->工作流->工作流定義，進入工作流定義頁面，如下圖所示:

file

工作流定義列表的操作功能如下：

編輯：只能編輯"下線"的工作流定義。工作流DAG編輯同創建工作流定義。
上線：工作流狀態為"下線"時，上線工作流，只有"上線"狀態的工作流能運行，但不能編輯。
下線：工作流狀態為"上線"時，下線工作流，下線狀態的工作流可以編輯，但不能運行。
運行：只有上線的工作流能運行。運行操作步驟見運行工作流
定時：只有上線的工作流能設置定時，系統自動定時調度工作流運行。創建定時後的狀態為"下線"，需在定時管理頁面上線定時才生效。定時操作步驟見工作流定時
定時管理：定時管理頁面可編輯、上線/下線、刪除定時。
刪除：刪除工作流定義。在同一個項目中，只能刪除自己創建的工作流定義，其他用戶的工作流定義不能進行刪除，如果需要刪除請聯繫創建用戶或者管理員。
下載：下載工作流定義到本地。
樹形圖：以樹形結構展示任務節點的類型及任務狀態，如下圖所示：

file

運****行工作流：

點擊項目管理->工作流->工作流定義，進入工作流定義頁面，如下圖所示，點擊"上線"按鈕，上線工作流。

file

點擊”運行“按鈕，彈出啟動參數設置彈框，如下圖所示，設置啟動參數，點擊彈框中的"運行"按鈕，工作流開始運行，工作流實例頁面生成一條工作流實例。

file

工作流運行參數說明：

失敗策略：當某一個任務節點執行失敗時，其他並行的任務節點需要執行的策略。”繼續“表示：某一任務失敗後，其他任務節點正常執行；”結束“表示：終止所有正在執行的任務，並終止整個流程。
通知策略：當流程結束，根據流程狀態發送流程執行信息通知郵件，包含任何狀態都不發，成功發，失敗發，成功或失敗都發。
流程優先順序：流程運行的優先順序，分五個等級：最高（HIGHEST），高(HIGH),中（MEDIUM）,低（LOW），最低（LOWEST）。當 master 線程數不足時，級別高的流程在執行隊列中會優先執行，相同優先順序的流程按照先進先出的順序執行。
Worker 分組：該流程只能在指定的 worker 機器組裡執行。預設是 Default，可以在任一 worker 上執行。
通知組：選擇通知策略||超時報警||發生容錯時，會發送流程信息或郵件到通知組裡的所有成員。
啟動參數: 在啟動新的流程實例時，設置或覆蓋全局參數的值。
補數：指運行指定日期範圍內的工作流定義，根據補數策略生成對應的工作流實例，補數策略包括串列補數、並行補數 2 種模式。
日期可以通過頁面選擇或者手動輸入，日期範圍是左關右關區間(startDate <= N <= endDate)
串列補數：指定時間範圍內，從開始日期至結束日期依次執行補數，依次生成多條流程實例；點擊運行工作流，選擇串列補數模式：例如從7月 9號到7月10號依次執行，依次在流程實例頁面生成兩條流程實例。

file

並行補數：指定時間範圍內，同時進行多天的補數，同時生成多條流程實例。手動輸入日期：手動輸入以逗號分割日期格式為 yyyy-MM-dd HH:mm:ss 的日期。點擊運行工作流，選擇並行補數模式：例如同時執行7月9號到7月10號的工作流定義，同時在流程實例頁面生成兩條流程實例(執行策略為串列時流程實例按照策略執行)。
並行度：是指在並行補數的模式下，最多並行執行的實例數。例如同時執行7月6號到7月10號的工作流定義，並行度為2，那麼流程實例為：
依賴模式：是否觸發下游依賴節點依賴到當前工作流的工作流實例的補數（要求當前補數的工作流實例的定時狀態為已上線，只會觸發下游直接依賴到當前工作流的補數）。

file

日期選擇：

通過頁面選擇日期：
手動輸入
補數與定時配置的關係：
未配置定時或已配置定時並定時狀態下線：根據所選的時間範圍結合定時預設配置(每天0點)進行補數，比如該工作流調度日期為7月7號到7月10號，流程實例為：
已配置定時並定時狀態上線：根據所選的時間範圍結合定時配置進行補數，比如該工作流調度日期為7月7號到7月10號，配置了定時（每日凌晨5點運行），流程實例為：

單獨運行任務
右鍵選中任務，點擊"啟動"按鈕(只有已上線的任務才能點擊運行)

file

彈出啟動參數設置彈框，參數說明同運行工作流

file
工作流定時

創建定時：點擊項目管理->工作流->工作流定義，進入工作流定義頁面，上線工作流，點擊"定時"按鈕,彈出定時參數設置彈框，如下圖所示：
選擇起止時間。在起止時間範圍內，定時運行工作流；不在起止時間範圍內，不再產生定時工作流實例。
添加一個每隔 5 分鐘執行一次的定時，如下圖所示：
失敗策略、通知策略、流程優先順序、Worker 分組、通知組、收件人、抄送人同工作流運行參數。
點擊"創建"按鈕，創建定時成功，此時定時狀態為"下線"，定時需上線才生效。
定時上線：點擊"定時管理"按鈕，進入定時管理頁面，點擊"上線"按鈕，定時狀態變為"上線"，如下圖所示，工作流定時生效。

file

導入工作流
點擊項目管理->工作流->工作流定義，進入工作流定義頁面，點擊"導入工作流"按鈕，導入本地工作流文件，工作流定義列表顯示導入的工作流，狀態為下線。

3.工作流實例

查看工作流實例

點擊項目管理->工作流->工作流實例，進入工作流實例頁面，如下圖所示：
點擊工作流名稱，進入DAG查看頁面，查看任務執行狀態，如下圖所示。

file

查看任務日誌

進入工作流實例頁面，點擊工作流名稱，進入DAG查看頁面，雙擊任務節點，如下圖所示：
點擊"查看日誌"，彈出日誌彈框，如下圖所示,任務實例頁面也可查看任務日誌。

查看任務歷史記錄

點擊項目管理->工作流->工作流實例，進入工作流實例頁面，點擊工作流名稱，進入工作流 DAG 頁面;
雙擊任務節點，如下圖所示，點擊"查看歷史"，跳轉到任務實例頁面，並展示該工作流實例運行的任務實例列表

file

查看運行參數

點擊項目管理->工作流->工作流實例，進入工作流實例頁面，點擊工作流名稱，進入工作流 DAG 頁面;
點擊左上角圖標，查看工作流實例的啟動參數；點擊圖標，查看工作流實例的全局參數和局部參數，如下圖所示：

工作流實例操作功能
點擊項目管理->工作流->工作流實例，進入工作流實例頁面，如下圖所示：
編輯：只能編輯成功/失敗/停止狀態的流程。點擊"編輯"按鈕或工作流實例名稱進入 DAG 編輯頁面，編輯後點擊"保存"按鈕，彈出保存 DAG 彈框，如下圖所示，修改流程定義信息，在彈框中勾選"是否更新工作流定義"，保存後則將實例修改的信息更新到工作流定義；若不勾選，則不更新工作流定義。

file

重跑：重新執行已經終止的流程。
恢復失敗：針對失敗的流程，可以執行恢復失敗操作，從失敗的節點開始執行。
停止：對正在運行的流程進行停止操作，後臺會先 kill worker 進程,再執行 kill -9 操作
暫停：對正在運行的流程進行暫停操作，系統狀態變為等待執行，會等待正在執行的任務結束，暫停下一個要執行的任務。
恢復暫停：對暫停的流程恢復，直接從暫停的節點開始運行
刪除：刪除工作流實例及工作流實例下的任務實例
甘特圖：Gantt 圖縱軸是某個工作流實例下的任務實例的拓撲排序，橫軸是任務實例的運行時間,如圖示：

file

4.任務實例

批量任務實例

點擊項目管理->工作流->任務實例，進入任務實例頁面，如下圖所示，點擊工作流實例名稱，可跳轉到工作流實例DAG圖查看任務狀態。

file

查看日誌：點擊操作列中的“查看日誌”按鈕，可以查看任務執行的日誌情況。

file

實時任務實例

切換到實時任務實例頁面，如下圖所示：

file

SavePoint：點擊操作列中的SavePoint按鈕，可以進行實時任務的SavePoint。
Stop：點擊操作列中的Stop按鈕，可以停止該實時任務。

5.任務定義

批量任務定****義

批量任務定義允許您在基於任務級別而不是在工作流中操作修改任務。再此之前，我們已經有了工作流級別的任務編輯器，你可以在工作流定義單擊特定的工作流，然後編輯任務的定義。當您想編輯特定的任務定義但不記得它屬於哪個工作流時，這是令人沮喪的。所以我們決定在任務菜單下添加任務定義視圖。

file

 在該視圖中，您可以通過單擊 操作 列中的相關按鈕來進行創建、查詢、更新、刪除任務定義。最令人興奮的是您可以通過通配符進行全部任務查詢，當您只 記得任務名稱但忘記它屬於哪個工作流時是非常有用的。也支持通過任務名稱結合使用 任務類型 或 工作流程名稱 進行查詢。

實時任務定義

實時任務定義在工作流定義中創建，在任務定義頁面可以進行修改和執行。

file
點擊實時任務執行，檢查執行參數後點擊確認，即可提交實時任務。

file

七、任務類型

1.SQL

SQL任務類型，用於連接資料庫並執行相應SQL。

創建數據源：

數據源中心支持MySQL、POSTGRESQL、HIVE/IMPALA、SPARK、CLICKHOUSE、ORACLE、SQLSERVER等數據源。
點擊"數據源中心->創建數據源"，根據需求創建不同類型的數據源
點擊"測試連接"，測試數據源是否可以連接成功（只有當數據源通過連接性測試後才能保存數據源）。

創建任務：

點擊項目管理-項目名稱-工作流定義，點擊"創建工作流"按鈕，進入DAG編輯頁面。
工具欄中拖動到畫板中，選擇需要連接的數據源，即可完成創建。

任務參數：

sql類型：支持查詢和非查詢兩種。
查詢：支持 DML select 類型的命令，是有結果集返回的，可以指定郵件通知為表格、附件或表格附件三種模板；
非查詢：支持 DDL全部命令和 DML update、delete、insert 三種類型的命令；
分段執行符號：提供在數據源不支持一次執行多段SQL語句時，拆分SQL語句的符號來進行多次調用數據源執行方法。例子：1.當數據源選擇Hive數據源時，不需要填寫此參數。因為Hive數據源本身支持一次執行多段SQL語句；2.當數據源選擇MySQL數據源時，並且要執行多段SQL語句時，需要填寫此參數為分號 ;。因為MySQL數據源不支持一次執行多段SQL語句；
sql參數：輸入參數格式為key1=value1;key2=value2…
sql語句：SQL語句
UDF函數：對於HIVE類型的數據源，可以引用資源中心中創建的UDF函數，其他類型的數據源暫不支持UDF函數。
自定義參數：SQL任務類型，而存儲過程是自定義參數順序，給方法設置值自定義參數類型和數據類型，同存儲過程任務類型一樣。區別在於SQL任務類型自定義參數會替換sql語句中${變數}。
前置sql:前置sql在sql語句之前執行。
後置sql:後置sql在sql語句之後執行。

任務樣例
Hive表創建示例
在hive中創建臨時表並寫入數據

該樣例向hive中創建臨時表tmp_hello_world並寫入一行數據。選擇SQL類型為非查詢，在創建臨時表之前需要確保該表不存在，所以我們使用自定義參數，在每次運行時獲取當天時間作為表名尾碼，這樣這個任務就可以每天運行。創建的表名格式為：tmp_hello_world_{yyyyMMdd}。

file
運行該任務成功之後在hive中查詢結果
登錄集群使用hive命令或使用beeline、JDBC等方式連接apache hive進行查詢，查詢SQL為select * from tmp_hello_world_{yyyyMMdd}，請將{yyyyMMdd}替換為運行當天的日期，查詢截圖如下：

file
使用前置sql和後置sql示例
在前置sql中執行建表操作，在sql語句中執行操作，在後置sql中執行清理操作
file

2.SPARK節點

Spark 任務類型用於執行 Spark 應用。對於 Spark 節點，worker 支持兩個不同類型的 spark 命令提交任務：

(1) spark submit 方式提交任務。

(2) spark sql 方式提交任務。

創建任務：

點擊項目管理 -> 項目名稱 -> 工作流定義，點擊”創建工作流”按鈕，進入 DAG 編輯頁面：
拖動工具欄的任務節點到畫板中。

任務參數：

預設參數說明請參考DolphinScheduler任務參數附錄。
程式類型：支持 Java、Scala、Python 和 SQL 四種語言。
Spark 版本：支持 Spark1 和 Spark2。
主函數的 Class：Spark 程式的入口 Main class 的全路徑。
主程式包：執行 Spark 程式的 jar 包（通過資源中心上傳）。
SQL腳本：Spark sql 運行的 .sql 文件中的 SQL 語句。
部署方式：(1) spark submit 支持 yarn-clusetr、yarn-client 和 local 三種模式。(2) spark sql 支持 yarn-client 和 local 兩種模式。
任務名稱（可選）：Spark 程式的名稱。
Driver 核心數：用於設置 Driver 內核數，可根據實際生產環境設置對應的核心數。
Driver 記憶體數：用於設置 Driver 記憶體數，可根據實際生產環境設置對應的記憶體數。
Executor 數量：用於設置 Executor 的數量，可根據實際生產環境設置對應的記憶體數。
Executor 記憶體數：用於設置 Executor 記憶體數，可根據實際生產環境設置對應的記憶體數。
主程式參數：設置 Spark 程式的輸入參數，支持自定義參數變數的替換。
選項參數：支持 --jar、–files、–archives、–conf 格式。
資源：如果其他參數中引用了資源文件，需要在資源中選擇指定。
自定義參數：是 Spark 局部的用戶自定義參數，會替換腳本中以 ${變數} 的內容。

任務樣例

spark submit
執行 WordCount 程式
本案例為大數據生態中常見的入門案例，常應用於 MapReduce、Flink、Spark 等計算框架。主要為統計輸入的文本中，相同的單詞的數量有多少。

在 DolphinScheduler 中配置 Spark 環境
若生產環境中要是使用到 Spark 任務類型，則需要先配置好所需的環境。配置文件如下：bin/env/dolphinscheduler_env.sh。

file
上傳主程式包
在使用 Spark 任務節點時，需要利用資源中心上傳執行程式的 jar 包。
當配置完成資源中心之後，直接使用拖拽的方式，即可上傳所需目標文件。

file
配置 Spark 節點
根據上述參數說明，配置所需的內容即可。
file
spark sql
執行 DDL 和 DML 語句
本案例為創建一個視圖表 terms 並寫入三行數據和一個格式為 parquet 的表 wc 並判斷該表是否存在。程式類型為 SQL。將視圖表 terms 的數據插入到格式為 parquet 的表 wc。

file
註意：

JAVA 和 Scala 只用於標識，使用 Spark 任務時沒有區別。如果應用程式是由 Python 開發的，那麼可以忽略表單中的參數Main Class。參數SQL腳本僅適用於 SQL 類型，在 JAVA、Scala 和 Python 中可以忽略。

SQL 目前不支持 cluster 模式。

3.Apache Zeppelin

Zeppelin任務類型，用於創建並執行Zeppelin類型任務。worker 執行該任務的時候，會通過Zeppelin Cient API觸發Zeppelin Notebook Paragraph。

創建任務

點擊項目管理-項目名稱-工作流定義，點擊"創建工作流"按鈕，進入DAG編輯頁面。
工具欄中拖動到畫板中，即可完成創建。

任務參數

file
生產（克隆）模式

填上Zeppelin Production Note Directory參數以啟動生產模式。
在生產模式下，目標note會被克隆到您所填的Zeppelin Production Note Directory目錄下。Zeppelin任務插件將會執行克隆出來的note併在執行成功後自動清除它。因為在此模式下，如果您不小心修改了正在被Dolphin Scheduler調度的note，也不會影響到生產任務的執行，從而提高了穩定性。
如果您選擇不填Zeppelin Production Note Directory這個參數，Zeppelin任務插件將會執行您的原始note。'Zeppelin Production Note Directory’參數在格式上應該以斜杠開頭和結尾，例如 /production_note_directory/。

任務樣例
Zeppelin Paragraph 任務樣例
這個示例展示瞭如何創建Zeppelin Paragraph任務節點：
file

file

八、集群部署

集群部署目的是在多台機器部署 DolphinScheduler 服務，用於運行大量任務情況。

集群部署(Cluster)使用的腳本和配置文件與偽集群部署中的配置一樣，所以所需要的步驟也與偽集群部署大致一樣。區別就是偽集群部署針對的是一臺機器，而集群部署(Cluster)需要針對多台機器，且兩者“修改相關配置”步驟區別較大

1.前置準備工作

JDK：下載JDK (1.8+)，安裝並配置 JAVA_HOME 環境變數，並將其下的 bin 目錄追加到 PATH 環境變數中。如果你的環境中已存在，可以跳過這步。
二進位包：在下載頁面下載 DolphinScheduler 二進位包
資料庫：PostgreSQL (8.2.15+) 或者 MySQL (5.7+)，兩者任選其一即可，如 MySQL 則需要 JDBC Driver 8.0.16
註冊中心：ZooKeeper (3.4.6+)，下載地址
進程樹分析
macOS安裝pstree
Fedora/Red/Hat/CentOS/Ubuntu/Debian安裝psmisc

註意: DolphinScheduler 本身不依賴 Hadoop、Hive、Spark，但如果你運行的任務需要依賴他們，就需要有對應的環境支持

2.準備 DolphinScheduler 啟動環境

配置用戶免密及許可權
創建部署用戶，並且一定要配置 sudo 免密。以創建 dolphinscheduler 用戶為例

# 創建用戶需使用 root 登錄

配置機器SSH免密登陸
由於安裝的時候需要向不同機器發送資源，所以要求各台機器間能實現SSH免密登陸。配置免密登陸的步驟如下

su dolphinscheduler

註意: 配置完成後，可以通過運行命令 ssh localhost 判斷是否成功，如果不需要輸入密碼就能ssh登陸則證明成功

啟動zookeeper
進入 zookeeper 的安裝目錄，將 zoo_sample.cfg 配置文件複製到 conf/zoo.cfg，並將 conf/zoo.cfg 中 dataDir 中的值改成 dataDir=./tmp/zookeeper

# 啟動 zookeeper

3.修改相關配置

完成基礎環境的準備後，需要根據你的機器環境修改配置文件。配置文件可以在目錄 bin/env 中找到，他們分別是並命名為 install_env.sh 和 dolphinscheduler_env.sh。

修改 install_env.sh 文件
文件 install_env.sh 描述了哪些機器將被安裝 DolphinScheduler 以及每台機器對應安裝哪些服務。您可以在路徑 bin/env/install_env.sh 中找到此文件，可通過以下方式更改env變數,export <ENV_NAME>=，配置詳情如下。

# ---------------------------------------------------------

修改 dolphinscheduler_env.sh 文件
文件 ./bin/env/dolphinscheduler_env.sh 描述了下列配置：

DolphinScheduler 的資料庫配置，詳細配置方法見初始化資料庫
一些任務類型外部依賴路徑或庫文件，如 JAVA_HOME 和 SPARK_HOME都是在這裡定義的
註冊中心zookeeper
服務端相關配置，比如緩存，時區設置等

如果您不使用某些任務類型，您可以忽略任務外部依賴項，但您必鬚根據您的環境更改 JAVA_HOME、註冊中心和資料庫相關配置。

# JAVA_HOME, will use it to start DolphinScheduler server

這個是與偽集群部署差異較大的一步，因為部署腳本會通過 scp 的方式將安裝需要的資源傳輸到各個機器上，所以這一步我們僅需要修改運行install.sh腳本的所在機器的配置即可。配置文件在路徑在bin/env/install_env.sh下，此處我們僅需修改INSTALL MACHINE，DolphinScheduler ENV、Database、Registry Server與偽集群部署保持一致，下麵對必須修改參數進行說明

# ---------------------------------------------------------

4.初始化資料庫

啟動 DolphinScheduler
使用上面創建的部署用戶運行以下命令完成部署，部署後的運行日誌將存放在 logs 文件夾內

bash ./bin/install.sh

5.登陸DolphinScheduler

啟停服務

# 一鍵停止集群所有服務

註意1:: 每個服務在路徑 /conf/dolphinscheduler\_env.sh 中都有 dolphinscheduler\_env.sh 文件，這是可以為微服務需求提供便利。意味著您可以基於不同的環境變數來啟動各個服務，只需要在對應服務中配置 /conf/dolphinscheduler\_env.sh 然後通過 /bin/start.sh 命令啟動即可。但是如果您使用命令 /bin/dolphinscheduler-daemon.sh start 啟動伺服器，它將會用文件 bin/env/dolphinscheduler\_env.sh 覆蓋 /conf/dolphinscheduler_env.sh 然後啟動服務，目的是為了減少用戶修改配置的成本.

註意2:：服務用途請具體參見《系統架構設計》小節。Python gateway service 預設與 api-server 一起啟動，如果您不想啟動 Python gateway service 請通過更改 api-server 配置文件 api-server/conf/application.yaml 中的 python-gateway.enabled : false 來禁用它。

九、架構設計

file

1.DolphinScheduler 元數據文檔

一個租戶下可以有多個用戶；
一個用戶可以有多個項目
一個項目可以有多個工作流定義，每個工作流定義只屬於一個項目；
一個租戶可以被多個工作流定義使用，每個工作流定義必須且只能選擇一個租戶；
一個工作流定義可以有一個或多個定時的配置；
一個工作流定義對應多個任務定義
一個工作流定義可以有多個工作流實例，一個工作流實例對應一個或多個任務實例

2.架構設計

架構說明

MasterServer

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

該服務內主要包含:

DistributedQuartz分散式調度組件，主要負責定時任務的啟停操作，當quartz調起任務後，Master內部會有線程池具體負責處理任務的後續操作；
MasterSchedulerService是一個掃描線程，定時掃描資料庫中的t\_ds\_command表，根據不同的命令類型進行不同的業務操作；
WorkflowExecuteRunnable主要是負責DAG任務切分、任務提交監控、各種不同事件類型的邏輯處理；
TaskExecuteRunnable主要負責任務的處理和持久化，並生成任務事件提交到工作流的事件隊列；
EventExecuteService主要負責工作流實例的事件隊列的輪詢；
StateWheelExecuteThread主要負責工作流和任務超時、任務重試、任務依賴的輪詢，並生成對應的工作流或任務事件提交到工作流的事件隊列；
FailoverExecuteThread主要負責Master容錯和Worker容錯的相關邏輯；

WorkerServer：
WorkerServer也採用分散式無中心設計理念，WorkerServer主要負責任務的執行和提供日誌服務。WorkerServer服務啟動時向Zookeeper註冊臨時節點，並維持心跳。WorkerServer基於netty提供監聽服務。

該服務包含：

WorkerManagerThread主要負責任務隊列的提交，不斷從任務隊列中領取任務，提交到線程池處理；
TaskExecuteThread主要負責任務執行的流程，根據不同的任務類型進行任務的實際處理；
RetryReportTaskStatusThread主要負責定時輪詢向Master彙報任務的狀態，直到Master回覆狀態的ack，避免任務狀態丟失；

ZooKeeper：

ZooKeeper服務，系統中的MasterServer和WorkerServer節點都通過ZooKeeper來進行集群管理和容錯。另外系統還基於ZooKeeper進行事件監聽和分散式鎖。我們也曾經基於Redis實現過隊列，不過我們希望DolphinScheduler依賴到的組件儘量地少，所以最後還是去掉了Redis實現。

AlertServer：

提供告警服務，通過告警插件的方式實現豐富的告警手段。

ApiServer：

API介面層，主要負責處理前端UI層的請求。該服務統一提供RESTful api向外部提供請求服務。

UI：

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

3.架構設計思想

去中心化vs中心化

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

file

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

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

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

去中心化：
file

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

4.容錯設計

容錯分為服務宕機容錯和任務重試，服務宕機容錯又分為Master容錯和Worker容錯兩種情況

宕機容錯
服務容錯設計依賴於ZooKeeper的Watcher機制，實現原理如圖：
file
其中Master監控其他Master和Worker的目錄，如果監聽到remove事件，則會根據具體的業務邏輯進行流程實例容錯或者任務實例容錯。

Master容錯流程：

容錯範圍：從host的維度來看，Master的容錯範圍包括：自身host+註冊中心上不存在的節點host，容錯的整個過程會加鎖；

容錯內容：Master的容錯內容包括：容錯工作流實例和任務實例，在容錯前會比較實例的開始時間和服務節點的啟動時間，在服務啟動時間之後的則跳過容錯；

容錯後處理：ZooKeeper Master容錯完成之後則重新由DolphinScheduler中Scheduler線程調度，遍歷 DAG 找到”正在運行”和“提交成功”的任務，對”正在運行”的任務監控其任務實例的狀態，對”提交成功”的任務需要判斷Task Queue中是否已經存在，如果存在則同樣監控任務實例的狀態，如果不存在則重新提交任務實例。

Worker容錯流程：
容錯範圍：從工作流實例的維度看，每個Master只負責容錯自己的工作流實例；只有在handleDeadServer時會加鎖；
容錯內容：當發送Worker節點的remove事件時，Master只容錯任務實例，在容錯前會比較實例的開始時間和服務節點的啟動時間，在服務啟動時間之後的則跳過容錯；
容錯後處理：Master Scheduler線程一旦發現任務實例為” 需要容錯”狀態，則接管任務併進行重新提交。
註意：由於” 網路抖動”可能會使得節點短時間內失去和ZooKeeper的心跳，從而發生節點的remove事件。對於這種情況，我們使用最簡單的方式，那就是節點一旦和ZooKeeper發生超時連接，則直接將Master或Worker服務停掉。

5.任務失敗重試

這裡首先要區分任務失敗重試、流程失敗恢復、流程失敗重跑的概念：

任務失敗重試是任務級別的，是調度系統自動進行的，比如一個Shell任務設置重試次數為3次，那麼在Shell任務運行失敗後會自己再最多嘗試運行3次
流程失敗恢復是流程級別的，是手動進行的，恢復是從只能從失敗的節點開始執行或從當前節點開始執行
流程失敗重跑也是流程級別的，是手動進行的，重跑是從開始節點進行

接下來說正題，我們將工作流中的任務節點分了兩種類型。

一種是業務節點，這種節點都對應一個實際的腳本或者處理語句，比如Shell節點、SQL節點、Spark節點等。
還有一種是邏輯節點，這種節點不做實際的腳本或語句處理，只是整個流程流轉的邏輯處理，比如依賴節點、子流程節點等。

業務節點都可以配置失敗重試的次數，當該任務節點失敗，會自動重試，直到成功或者超過配置的重試次數。邏輯節點不支持失敗重試。

如果工作流中有任務失敗達到最大重試次數，工作流就會失敗停止，失敗的工作流可以手動進行重跑操作或者流程恢復操作。

6.任務優先順序設計

在早期調度設計中，如果沒有優先順序設計，採用公平調度設計的話，會遇到先行提交的任務可能會和後繼提交的任務同時完成的情況，而不能做到設置流程或者任務的優先順序，因此我們對此進行了重新設計，目前我們設計如下：

按照不同流程實例優先順序優先於同一個流程實例優先順序優先於同一流程內任務優先順序優先於同一流程內任務提交順序依次從高到低進行任務處理。
具體實現是根據任務實例的json解析優先順序，然後把流程實例優先順序_流程實例id_任務優先順序_任務id信息保存在ZooKeeper任務隊列中，當從任務隊列獲取的時候，通過字元串比較即可得出最需要優先執行的任務
其中流程定義的優先順序是考慮到有些流程需要先於其他流程進行處理，這個可以在流程啟動或者定時啟動時配置，共有5級，依次為HIGHEST、HIGH、MEDIUM、LOW、LOWEST。如下圖

file

任務的優先順序也分為5級，依次為HIGHEST、HIGH、MEDIUM、LOW、LOWEST。如下圖

file

7.Logback和netty實現日誌訪問

由於Web(UI)和Worker不一定在同一臺機器上，所以查看日誌不能像查詢本地文件那樣。有兩種方案：
將日誌放到ES搜索引擎上
通過netty通信獲取遠程日誌信息
介於考慮到儘可能的DolphinScheduler的輕量級性，所以選擇了gRPC實現遠程訪問日誌信息。

file

詳情可參考Master和Worker的logback配置，如下示例：

<conversionRule conversionWord="messsage" converterClass="org.apache.dolphinscheduler.service.log.SensitiveDataConverter"/>

8.配置文件詳解

dolphinscheduler-daemon.sh \[啟動/關閉DolphinScheduler服務腳本\]

dolphinscheduler-daemon.sh腳本負責DolphinScheduler的啟動&關閉. start-all.sh/stop-all.sh最終也是通過dolphinscheduler-daemon.sh對集群進行啟動/關閉操作. 目前DolphinScheduler只是做了一個基本的設置,JVM參數請根據各自資源的實際情況自行設置。

預設簡化參數如下:

export DOLPHINSCHEDULER_OPTS="

9.負載均衡

負載均衡即通過路由演算法（通常是集群環境），合理的分攤伺服器壓力，達到伺服器性能的最大優化。

DolphinScheduler-Worker 負載均衡演算法

DolphinScheduler-Master 分配任務至 worker,預設提供了三種演算法:

加權隨機（random）
平滑輪詢（roundrobin）
線性負載（lowerweight）
預設配置為線性加權負載。

由於路由是在客戶端做的，即 master 服務，因此你可以更改 master.properties 中的 master.host.selector 來配置你所想要的演算法。

eg：master.host.selector=random（不區分大小寫）

Worker 負載均衡配置

配置文件 worker.properties

權重
上述所有的負載演算法都是基於權重來進行加權分配的，權重影響分流結果。你可以在修改 worker.weight 的值來給不同的機器設置不同的權重。

預熱
考慮到 JIT 優化，我們會讓 worker 在啟動後低功率的運行一段時間，使其逐漸達到最佳狀態，這段過程我們稱之為預熱。感興趣的同學可以去閱讀 JIT 相關的文章。

因此 worker 在啟動後，他的權重會隨著時間逐漸達到最大（預設十分鐘）。

負載均衡演算法細述

隨機（加權）

該演算法比較簡單，即在符合的 worker 中隨機選取一臺（權重會影響他的比重）。

平滑輪詢（加權）

加權輪詢演算法一個明顯的缺陷。即在某些特殊的權重下，加權輪詢調度會生成不均勻的實例序列，這種不平滑的負載可能會使某些實例出現瞬時高負載的現象，導致系統存在宕機的風險。為瞭解決這個調度缺陷，我們提供了平滑加權輪詢演算法。

每台 worker 都有兩個權重，即 weight（預熱完成後保持不變），current\_weight（動態變化），每次路由。都會遍歷所有的 worker，使其 current\_weight+weight，同時累加所有 worker 的 weight，計為 total\_weight，然後挑選 current\_weight 最大的作為本次執行任務的 worker，與此同時，將這台 worker 的 current\_weight-total\_weight。

線性加權(預設演算法)

該演算法每隔一段時間會向註冊中心上報自己的負載信息。我們主要根據兩個信息來進行判斷
load 平均值（預設是 CPU 核數 *2）
可用物理記憶體（預設是 0.3，單位是 G）

如果兩者任何一個低於配置項，那麼這台 worker 將不參與負載。（即不分配流量）

你可以在 worker.properties 修改下麵的屬性來自定義配置：

worker.max.cpuload.avg=-1 (worker最大cpuload均值，只有高於系統cpuload均值時，worker服務才能被派發任務. 預設值為-1: cpu cores * 2)
worker.reserved.memory=0.3 (worker預留記憶體，只有低於系統可用記憶體時，worker服務才能被派發任務，單位為G)

10.緩存

緩存目的

由於在master-server調度過程中，會產生大量的資料庫讀取操作，如tenant，user，processDefinition等，一方面對DB產生很大的讀壓力，另一方面則會使整個核心調度流程變得緩慢；

考慮到這部分業務數據是讀多寫少的場景，故引入了緩存模塊，以減少DB讀壓力，加快核心調度流程；

緩存設置

spring:

緩存模塊採用spring-cache機制，可直接在spring配置文件中配置是否開啟緩存（預設none關閉）, 緩存類型；

目前採用caffeine進行緩存管理，可自由設置緩存相關配置，如緩存大小、過期時間等；

緩存讀取
緩存採用spring-cache的註解，配置在相關的mapper層，可參考如：TenantMapper.

緩存更新

業務數據的更新來自於api-server, 而緩存端在master-server, 故需要對api-server的數據更新做監聽(aspect切麵攔截@CacheEvict)，當需要進行緩存驅逐時會通知master-server，master-server接收到cacheEvictCommand後進行緩存驅逐；