聯想基於Apache DolphinScheduler構建統一排程中心的應用實踐

繪製出的 DAG 儲存後會生成工作流定義，可以對工作流定義進行多種操作，如，定時或手動啟動，也可以檢視工作流定義的各版本資訊。

（3） 工作流例項

無論是手動觸發或者定時觸發工作流定義，都會生成工作流例項。一個 DAG 裡面有多個任務，因此，一個工作流例項會產生多個任務例項。

工作流例項也可以進行各種操作，比如，對正在執行例項進行暫停或 KILL 的操作，當工作流例項變成終態時，比如是失敗的狀態，也可以對工作流例項進行失敗重跑的操作。

（4）任務例項

在任務例項的層面，可以檢視任務的執行日誌，也可以對例項設定強制成功，這是一個人工干預的功能。

（5）任務狀態

任務有多種狀態。當 Master 生成任務例項的時候，任務預設為提交成功的狀態。當 Master 分發任務給 Worker，Worker 拿到後開始執行，會向 Master 彙報狀態。這個時候 Master 會把提交成功的任務狀態更改為執行中。當正在執行的工作流例項被暫停，任務就會顯示為暫停狀態。任務執行完成會顯示最終狀態，比如失敗、成功或 KILL。

當某個 Worker 節點掛掉時，任務需要容錯，這時需要容錯的狀態，由其他的 Worker 進行接管。當工作流例項被執行 KILL 操作，任務也會變成 KILL 狀態。

在 DolphinScheduler 3.0 的時候增加了在提交成功與執行中之間的一個狀態，分發狀態。

（6）2.x 新增主要 Feature

2.x 主要新增了五個特性：

• 任務結果引數傳遞；
• 工作流間的血緣關係，工作流之間的依賴關係可以透過依賴任務或者子流程表達；
• 增加資料同步主鍵 waterdrop、多分支等任務元件能力支援；
• 工作流定義和任務關係拆分，更易透過 openAPI 生成工作流；
• 將工作流定義和任務關係做了拆分，新增了工作流版本控制。

3. DolphinScheduler 架構設計

以下是 DolphinScheduler 整個架構的演變過程，以及它是如何支撐 10 萬級任務排程的。

（1）DolphinSchedule 1.2 架構

Apache DolphinScheduler 從一開始就採用了無中心化的設計，這樣可以保證排程叢集效能的線性增長。

1.2 架構是 Apache DolphinScheduler 最初的架構，其中有兩個重要的元件，即 MasterServer 和 WorkerServer。MasterServer 負責 DAG 任務的切分，將切分後的 DAG 任務生成工作流例項進行解析並提交。1.2 架構透過 zk 佇列儲存任務，Master 把任務儲存到 zk 佇列上，然後 Worker 再從 zk 佇列去取，這種方式消耗比較大，同時，Worker 與 DB 產生互動後會更改 Task 任務的狀態。因此，1.3 的架構對這兩點進行了改進。

（2）DolphinScheduler 1.3.x 架構

1.3.x 架構主要是對以上所說的兩點問題進行了改善。首先是在 Master 與 Worker 之間引入了 Netty 通訊，去除 zk 佇列，大大減少了 Worker 獲取任務執行的延遲。其次是在 Master 與 Worker 之間進行多種任務分發策略，Worker 只負責執行任務，職責變得更單一。Worker 把任務所執行的結果彙報給 Master，由 Master 統一對狀態進行管理。

（3）ApacheDolphinScheduler 2.x 架構

在 2.x 架構裡面主要是對 Master 進行了一些重構，並引入了 SPI 外掛化的設計，Master 可以與 API 直接進行通訊。

① 2.x 新增可擴充套件能力

2.x 新增的可擴充套件能力主要是基於 SPI 外掛化的設計。它不僅對任務進行了外掛化，也對告警外掛進行了 SPI 設計，包括註冊中心和資料來源，後期還會對資源的中心進行外掛化的設計。採用 SPI 可以使程式碼變得更加的簡潔，可增加排程系統的可擴充套件的能力，也便於二次任務的改造與開發，在多個的任務外掛裡面，各個任務外掛的 pom 依賴互不影響。

② 2.0 重構

• 去分散式鎖

2.0 重構大大提升了 2.0 的併發能力。雖然在 1.x 架構裡面是多個 Master 同時執行，但與 DB 進行互動的時候，會從資料庫裡取得 command，但需要採用分散式鎖。2.0 去除了這個分散式鎖，當 Master 動態上下線的時候，會根據自己的分片編號計算屬於自己的槽位，然後根據槽位查詢資料庫取到屬於自己的 command。

• Master 中執行緒池

在 1.x 的版本里面，執行緒池的使用數量相對較多一點，在 2.0 重構主要是對 Master 中執行緒池進行了一些最佳化，引入了事件驅動的機制：

第一，MasterSchedulerService 執行緒去掉了分散式鎖，從 DB 中取到 command 生成工作流例項進行拆分、提交任務。

第二，在 WorkflowExecuteThread 執行緒裡會維護一個事件的佇列，然後去不斷地處理變化，當有 Worker 發來的任務狀態變化或 Master 發來流程例項狀態的變化，WorkflowExecuteThread 執行緒就會進行相應處理。當 API 的介面上觸發瞭如 KILL 或暫停操作這樣的事件，會透過事件的機制，由 Master 統一去進行處理。

4. 社群發展

如圖是 DolphinScheduler 的社群發展指標。可以看到 DolphinScheduler 從進入孵化器，到從孵化器畢業，再到現在，社群發展的各項指標都是呈指數級的增長，是一個具備很強生命力的 Community。其中，社群的使用者數、開發者的數量、貢獻者的數量，以及 Committer PMC 都有幾何倍的增長，並且還在持續不斷地上升。這些都說明了 DolphinScheduler 是一個健康的可持續發展的社群。

基於以上原因，最終聯想選擇了 Apache DolphinScheduler，目前已接入了多個業務 Domain 到生產環境。

03

在聯想的落地實踐

在聯想內部，各個業務裡面有不同的需求，比如，不同的任務型別，以及任務間需要依賴、引數傳遞等。所以，在接入 DolphinScheduler 後進行一些功能的改造。

1. HTTP 任務引數傳遞

在一些非大資料的場景裡面更多是 HTTP 任務，並且任務的請求引數之間存在依賴的關係，所以就提出了 HTTP 引數傳遞的功能。當時在社群 2.x 的版本里面只有 SQL 任務和 Shell 任務是支援引數傳遞，而 HTTP 任務不支援。

因此，對排程進行了一些改造，在 HTTP 的任務節點裡面的自定義的引數增加了 OUT 引數，也就是使任務的執行結果可以作為變數輸出，並增加欄位的解析。這樣，就可以在 API 介面返回的結果取某個欄位定義為輸出變數，下一個 HTTP 任務就可以把其作為請求引數使用。

2. Java 任務外掛開發

第二個改造是 Java 任務外掛的開發。在之前的一些業務部門有一些 XXL-Job 的任務，需要對這些任務進行遷移。這些作業主要是透過 Spring Bean 裡面的方法實現定時。對於 DolphinScheduler 而言，如果進行改造需要增加執行器的概念，由執行器和 Worker 進行通訊，增加執行器與 Worker 之間的任務狀態的彙報，最後再由 Worker 把最終的狀態彙報給 Master。

這個實現的原理是透過提供 SDK 開發執行器，提供一個註解給業務人員新增到自己編寫的排程任務裡，當程式啟動的時候會掃描註解下面所有的方法，並在執行過程中將所執行的狀態彙報給 Worker，由 Worker 彙報給 Master 進行統一管理。因此需要去抽象出一些必要的任務引數，並將其作為 Java 任務外掛，從而實現在 DAG 上支援 Java 任務。

如圖，是 Java 任務外掛的實現，在 DAG 上去拖拽 Java Method 任務時填上引數即可實現 Worker 對執行器的呼叫。

3. 專案全域性引數

在 DolphinScheduler 裡有很多引數的概念，方便對任務進行各種操作，比如，任務的自定義的引數、流程的全域性的引數、啟動的引數、還有一些內建的引數。在操作 HTTP 任務時，在 Header 裡有 token 欄位，並在多個工作流定義裡面都使用同樣的欄位，因此，就有了專案全域性引數這樣的需求。

當一個普通任務執行時，任務內的引數根據引數替換優先順序規則依次覆蓋，引數優先順序從高到低為：

任務自定義引數 > 流程定義全域性引數 > 專案全域性引數

當手動啟動流程定義時，可以指定啟動引數，這時候引數替換的優先順序會發生變化，啟動引數覆蓋流程定義的全域性引數，優先順序變為：

任務自定義引數 > 流程定義啟動引數 > 流程定義全域性引數 > 專案全域性引數

4. 內部認證接入

對於內部認證接入，接入了兩種內部的認證方式。

04

3.x 新特性 & Roadmap

1. 3.x 新特性

DolphinScheduler 在 3.x 版本里增加了很多的新特性，以下主要對四個特性作介紹。

（1）UI 重構

在 3.x 版本中，DolphinScheduler 對整個 UI 進行了重構，使 UI 的響應速度都有了提升。

（2）資料質量校驗

資料質量校驗是在做資料處理中常用的功能。在 3.0 版本中，DolphinScheduler 內嵌了 10 個資料質量規則，都可以透過拖拉拽的方式內嵌到 DAG 裡對單表或多表進行校驗，保證資料處理過程中的正確性和準確性。

（3）任務組

當排程裡的任務達到了幾萬級十萬級的時候，就會出現大量併發，大量的任務在競爭資源。雖然 Dolphin 在一開始也對任務優先順序進行了設計，Worker 裡也有各自的執行緒池，但任務執行時還是可以同時搶佔資源。

因此在 3.0 版本里新增了任務組功能來控制任務例項的併發，針對每個業務設定任務組細分各自的佇列，將資源競爭下沉到各個任務組裡。

在建立任務組的時候可以根據業務區分給任務組命名，同時可以設定任務組的資源數量。建立任務時可以設定任務歸屬的任務組，當任務啟動時，Master 向 Worker 分發任務先判斷當前任務所在的任務組的資源數量是否已經被佔滿，如果沒有則順利地傳送，否則就處於等待狀態。

（4）支援多種工作流執行的策略

在 DolphinScheduler 之前的版本中，都預設工作流的執行策略為並行執行。當有多個定時任務或者手動提交多個任務執行時，任務之間是處於並行狀態。在 3.x 的版本里面增加了多種工作流執行的策略的支援，可以選擇任務是並行執行或序列等待、序列拋棄、序列優先等。下面是序列等待狀態的示例：

如圖，這幾個例項同屬於一個工作流定義，如果是在之前版本中，例項是並行執行的，但在 3.x 版本里，可以選擇設定序列等待，此時就只有一個工作流例項是正在執行的，其他的例項為序列等待的狀態。當正在執行的例項執行完後，例項狀態就變成序列恢復狀態，然後繼續執行。

2. 未來規劃

最後是關於聯想內部以及 Dolphinscheduler 社群未來的一些規劃。

在聯想內部主要是做了四個方向的規劃：

（1）根據內部的需求增加個性化功能。比如，對線上狀態的工作流定義加入定時的預覽，目前 Dolphinscheduler 只可以對下線狀態的工作流定義和在編輯中的工作流定義進行預覽，之後會對這裡進行調整。

（2）API 整合。聯想各個的業務團隊裡有著各自的 UI 介面使用，但都需要用到排程的一些特性和功能，比如任務編排、檢視任務狀態、執行或者定時工作流定義等，這都需要 API 的整合。

（3）SDK 整合。目前 Dolphin 裡面可以透過 Python 程式碼快速地生成 DAG，但在 Java SDK 裡面需要進行改造。

（4）資料質量。Dolphinscheduler 3.0 版本目前已經支援資料質量校驗規則的功能。

對於社群，個人的思考是未來的 Roadmap 更多集中在任務的觸發，任務的排程，任務的執行方面上：

（1）定時觸發外掛化。Dolphin 目前是使用分散式的 Quartz，這裡也可以考慮做外掛化，比如說透過時間輪的設計，或者使用者自定義一個觸發邏輯。

（2）去 zk 實現高可用。目前 DolphinScheduler 服務註冊上也實現了 SPI 實現，可以使用 zk 或者 Etcd，任務佇列也已經不存在 zk 裡面了，不過如果使用 zk 作為註冊中心，在部署的時候也要部署 zk。如何在去掉 zk 的情況下也能保證註冊的一致性，是未來需要考慮的一個方向。

（3）DataOps。排程中心在整個 DataOps 裡面承擔了一個強有力的底座功能。如何使排程中心更好地去支援 DataOps 的生態？

（4）通用性功能、效能。Dolphinscheduler 本身是一個排程，迴歸排程的一些核心的功能，會在效能上持續的最佳化，不斷地降低延時。

（5）雲原生。雲原生時代，排程也會在這個方向持續的增加支援能力。