深度解析 | 基于DAG的分布式任務排程平台：Maat

背景

什麼是Maat？

Maat是一個基于開源項目Airflow的流程排程系統，它支援使用者自定義地組裝流程節點，流程可以在使用者指定的時間觸發（支援crontab格式），或由使用者手動觸發。

Maat的所有節點分布式地運作在Hippo上，由Drogo排程。使用者可以建立自己的排程節點和執行節點，達到資源隔離的目的。

使用者可以通過配置的方式安裝自己執行節點的運作環境，也可以配置執行節點的副本數。

下圖展示了一個任務的一次排程流程：

為什麼要做Maat？

我們在項目的開發過程中，經常遇到一些流程化/定時排程的需求，如上線釋出流程、定時分析任務流程等。對于這些流程化的排程任務，我們嘗試過自己開發了一套流程排程系統，也嘗試過接入集團的工作流，但難免會遇到一些問題：

• 業務代碼和排程代碼耦合嚴重，修改流程基本需要入侵到代碼級别，業務代碼的釋出影響排程。

• 對于這些排程任務，沒有一個統一管控的系統，難以管理和追溯。

• 多分支的複雜流程不能很好支援，上下文傳遞場景不能很好支援。

• 缺少可視化的UI，使用者使用不友好。

技術選型

定時任務&流程任務的排程是一個通用的需求，集團内的産品如D2、工作流，開源的産品如Airflow、Quartz等。

D2

D2是基于ODPS生态的一套流程排程系統，承載集團基于ODPS資料産出的排程任務。支援使用者自定義編寫腳本，支援定時任務觸發和手動觸發（補運作的方式），适合基于資料狀态的任務流程排程（如根據資料的産出執行任務流），由D2團隊專門維護，有較好的UI。

但它有一些不足：

• D2的DAG排程是一張大圖，每天需要運作的每個節點及拓撲關系是根據前一天的全局的拓撲關系計算得出的，是以新建立/修改的任務理論上隻能第二天生效，如果想立即生效需要采用補運作的方式。業務上經常會有任務的變動（如任務配置或排程時間），或手動觸發一個排程的場景（如随時發生的上線流程、全量流程），使用D2對業務不是很靈活，也不符合D2的使用場景。

• 不支援流程上下文的傳遞，業務上對上下文的傳遞比較強烈，經常有上個節點産出某個值，下個節點需要使用。

• 缺乏對搜尋生态的支援。搜尋技術部整個底層架構有自己的一套生态，如排程（Hippo，Drago）、報警（Kmon）。使用D2，不能充分享受搜尋技術生态帶來的好處，對于之後的單元化部署也會帶來問題。

工作流

集團工作流是集團審批流程的一個通用排程引擎，很多産品的審批流程都是基于集團工作流的，同時它也可以作為一個簡易的任務排程流程使用，我們在Maat之前也使用集團工作流作為我們流程任務的排程引擎。它支援手動觸發，支援以HSF的方式調用外部系統，支援上下文傳遞。但它在配置上較為複雜，且支援外部系統的調用方式有限。

Quartz

Quartz是Java開源的任務排程架構。它支援分布式排程、支援任務持久化、支援定時任務，但不支援流程排程，且任務配置需要耦合在排程系統中，任務的熱加載需要做一些改造。

Airflow

開源項目Airflow是一套分布式的流程排程系統，它的優勢如下：

• 業務代碼和排程系統解耦，每個業務的流程代碼以獨立的Python腳本描述，裡面定義了流程化的節點來執行業務邏輯，支援任務的熱加載。

• 完全支援crontab定時任務格式，可以通過crontab格式指定任務何時進行。

• 支援複雜的分支條件，每個節點單獨設定觸發時機，如父節點全部成功時執行、任意父節點成功時執行。

• 有一套完整的UI，可視化展現所有任務的狀态及曆史資訊。

• 外部依賴較少，搭建容易，僅依賴DB和rabbitmq。

• 有同學問到Luigi與Airflow的對比，個人感覺都是基于pipline的一個任務排程系統，功能也大同小異，Airflow屬于後來居上，功能更強，找到一篇同類産品的對比。

經過一段時間的調研，我們選用Airflow作為我們的原型開發一套分布式任務排程系統，它功能全面，基本滿足業務需求，在功能上擴充相對友善，外部依賴較少，和搜尋生态對接相對容易。

原生Airflow的問題

Airflow可以解決流程排程中面臨的許多問題，但直接将原生的Airflow用于生産，仍面臨一些問題：

• 原生Airflow雖然支援分布式，但由于依賴本地狀态，不能直接部署在drogo上。

• 缺乏合适的監控手段，需要結合kmon完善監控和報警設施。

• 缺乏使用者友好的編輯手段，使用者需要了解Airflow的原理和細節。

• 大量任務運作時，排程的性能急劇下降。

• 分布式模式下，原生Airflow存在一些bug。

Maat架構

Maat架構：

業務層

任何流程式排程及定時觸發的需求均可以通過Maat建立應用，Maat提供了可視化編輯頁面及豐富的api，使用者可以友善地建立編輯流程模闆，設定複雜的分支邏輯，Maat會在排程時按照運作時的狀态決定流程的流轉路徑。

目前接入Maat的應用場景包括Tisplus、Hawkeye、Kmon、容量平台、離線元件平台、Opensearch

管控層

由于原生Airflow的管控比較簡單，是基于描述任務流程dag的Python腳本排程，使用者要進行任務的建立、更新、運作需要深入學習Airflow原理才能上手，并且之後維護隻能基于檔案操作，非常不便。是以Maat在外層封裝一層管控系統Maat Console，降低運維及使用者學習的成本。

下圖是Maat管控系統Aflow的操作界面：

模闆管理

在任務流程排程的場景中，常見的情況是：不同任務執行的流程基本一緻，隻有個别參數不同。是以Maat提出了基于模闆管理的任務流程，使用者在模闆管理中定義一個流程的運作模闆，對于其中未确定的部分用變量表示。當生成具體任務時，由具體變量和模闆渲染出具體的任務。當模闆修改時，可以将模闆生效到所有依賴該模闆的任務。

模闆管理預設了幾種任務節點，使用者可以自由選擇不同的任務節點組裝模闆流程。

應用管理

管理所有具體的流程排程任務，包括任務使用的模闆、變量的值、報警資訊、任務觸發crontab等，使用者在通過模闆建立應用後，後續可以通過應用管理繼續維護任務的運作。

隊列管理

由于Maat上運作的任務所屬應用各不相同，不同應用運作環境也不相同，另外不同應用也希望達到叢集隔離的目的。為了實作這個功能Maat提供了隊列的管理，指定隊列的任務節點會被排程到相應隊列的機器上，相應隊列的機器也隻會運作指定隊列的任務節點。

另外，隊列上也可以指定并發數，表示目前隊列上最多同時有多少個任務運作，確定機器上同時運作的任務不會太多導緻負載過高，超出并發的任務會被挂起直到資源釋放。

核心子產品

Maat核心子產品完成了任務排程的整個流程。核心子產品的每個節點都獨立運作在機器上，啟動上互相不依賴，通過DB儲存資料狀态，通過MQ或FaaS完成消息的分發。

Web Api Service

Web Api Service提供了豐富的與外部互動的Api，包括任務增删改、曆史任務狀态、任務狀态修改、任務的觸發、任務的重試等接口。

另外原生Airflow提供的web展示功能也是由該角色完成。

Scheduler

scheduler是Maat關鍵角色，它決定了任務何時被排程運作，也決定一次任務運作中，哪些節點可以被執行。被判定執行的節點會被scheduler通過MQ或FaaS發送給worker執行。

随着任務的增多，單一的scheduler負載過高導緻排程周期增長，為了減輕scheduler的壓力，Maat将scheduler按照業務拆分。不同業務的任務有獨立的scheduler負責排程，發送任務到指定的Worker上。

Scheduler性能優化

原生Airflow的排程邏輯吞吐量較低，當任務量增多時，排程周期會很長，一些任務多的Scheduler延遲到達1分鐘左右。我們參考社群最新的實作，對原生排程邏輯進行優化，将原先阻塞的排程方式拆分為多個程序池，全異步地完成可執行任務的生産->送出->輪詢操作。經過壓測原先排程周期為30s-40s的場景降低為5s左右。

Worker

worker為具體執行任務的角色，worker會接受scheduler發出的任務，在worker上執行節點中描述的具體任務。worker多副本部署，任務會在任意一個對等的worker上機器，當worker資源不足時，可以動态擴容。

由于不同隊列任務所需的基礎環境不同，如Python、Java、Hadoop、zk等，不同隊列的worker角色啟動參數有配置上的差異，不同隊列的worker啟動時會按照配置中描述的資源完成部署安裝。

worker上任務完成後會回寫db，scheduler察覺到目前任務狀态變化後會繼續任務的排程。

Distributers

任務分發層負責将scheduler需要排程的任務發送到指定的Worker上。目前Maat同時使用原生Celery+Rabbitmq的方式和搜尋生态FaaS的方式實作任務分發。

Celery + RabbitMQ

原生Airflow使用Celery + RabbitMQ完成消息從Scheduler到Worker的分發。

Scheduler将需要運作的任務發送到MQ中，發送到MQ中包含任務對應的隊列資訊。Worker從MQ擷取消息時，僅擷取相應隊列任務，拉取到對應Worker上執行。MQ在Maat中以rabbitmq實作，MQ和其他角色一樣，也是獨立部署的。

Celery + Rabbitmq的模型對消息隊列中的任務進行持久化，所有的任務狀态也進行持久化，記憶體Queue的性能滿足大部分場景的需求。但由于Maat基于二層排程Drogo部署，任何部署節點都要求無狀态的，而消息隊列MQ因為儲存消息狀态顯然不滿足這個要求，是以我們選擇使用搜尋生态的FaaS架構作為Celery + RabbitMQ的替代方案。

FaaS

FaaS：FaaS（Function as a Service）是基于搜尋生态實作的ServerLess架構，Maat将其作為執行器。Maat的所有任務都抽象成function，任務執行時則調用相應的function，完成後傳回任務狀态。目前已完成與FaaS的初步對接，期望未來能基于FaaS做更多優化。如：多樣化的任務執行方式，可以将輕量級的任務函數化，将重量級的任務服務化；任務資源動态調整，甚至某些任務可以執行時配置設定資源，完成後即釋放。

對于Maat來講，FaaS支援任務從生産者到消費者的分發，内置消息Queue，提供任務狀态接口，同時FaaS自身保證消息不對丢失，後續還具備根據消費者負載自動擴縮容的功能。

基礎元件

• DB：使用集團IDB，負責Maat資訊的持久化，包括任務資訊、任務運作曆史、任務運作狀态、節點運作曆史、節點運作狀态等。

• OSS：由于上drogo導緻機器遷移的風險，所有日志不能存放在本地，是以所有節點運作日志存放在oss上，需要檢視日志上從oss上擷取。

• Kmon：完成監控叢集運作狀态及任務失敗的報警功能。

• Drogo：完成Maat所有節點的docker容器化部署。

Maat平台的優勢

可視化編輯及通用的節點類型

Maat提供了一個管控平台Aflow，使用者可以友善地編輯流程節點，管理所有的模闆和任務，詳細見上文的[管控層]。

除此之外，Maat還提供了豐富的通用節點類型。原生Airflow支援許多不同種類的節點類型，這些節點可以執行不同類型的任務。在與使用者的接觸中，Maat針對使用者的使用習慣與需求，對一些節點進行封裝，同時開發了幾種新的節點類型，可以滿足大部分使用者的需求。

• Bash節點：直接在worker上執行簡單的bash操作，由于bash通常需要依賴其他資源，實際使用較少，參照“帶資源的Bash節點”；

• Http節點：該節點支援http調用，排程時發送http請求觸發其他系統，同時該節點提供一個輪詢的http接口，觸發成功後輪詢其他系統是否成功，成功時才繼續運作；

• 帶資源的Bash節點：與普通Bash節點不同的是，該節點附帶一些資源（如jar包、bash腳本、Python腳本等），節點運作時會先将資源下載下傳到本地，然後執行bash腳本；

• 分支節點：該節點根據之前節點的運作結果或初始傳入的參數決定分之後的節點走哪個分支。

Drogo化部署

Maat服務有多種角色，每種角色都需要不同的運作環境，為了維護這些運作環境，對運維同學來說絕對是個噩夢，這種情況下上hippo成為Maat運維最好的選擇。drogo作為基于二層排程服務的管控平台，為Maat各個節點部署在hippo上成為可能。具體來說，Drogo化的優勢如下：

• 低成本增加新節點。上Drogo前，有新增節點的需求時，每次都需要準備運作資源，重新寫部署腳本，而每個節點的腳本都要運維同學自己維護。上Drogo後，所有這些部署資訊儲存在Drogo平台上，有新的的節點也隻需要将之前類似的部署資訊複制，稍加修改即可。

• 擴容簡單。上Drogo前，某類任務水位太高，為這類任務擴容，每次都需要準備機器、準備環境、調試運作參數，可能需要半天到一天的時間。上Drogo後，調整副本數，Drogo會自動擴容。

• 有效防止機器遷移帶來的服務中斷。上Drogo前，機器出現問題後，隻能另找機器擴容，對于某些隻能單點運作的節點，隻能燒香祈禱機器不挂了。上Drogo後，機器遷移後，會Drogo會自動配置設定一台機器将服務拉起，對于可中斷的服務，單節點部署也不用擔心機器挂了導緻服務消失了。

下圖展示了目前Drogo上部署的Maat各個角色：

由于原生Airflow的一些節點是有狀态的，需要依賴本地一些檔案，機器遷移會導緻這些節點的狀态丢失，我們對Maat做了一些修改，保證機器遷移不會丢失運作狀态：

• 之前的排程依賴本地Python dag檔案，機器遷移導緻本地檔案丢失。我們做了修改，所有dag儲存在db，依賴db中儲存的資訊排程，保證機器遷移後，dag資訊也不會丢失。

• 由于基于本地檔案，web service和scheduler讀寫的都是同一份dag檔案，導緻原生Airflow的scheduler和web service角色必須綁定運作。以db中資訊排程後，web service和scheduler可以單獨部署。

• 由于原來日志檔案儲存在本地，機器遷移會導緻日志檔案丢失。我們改造後，将日志檔案儲存在oss遠端，每次讀取日志從遠端讀取。

分叢集管理

由于不同任務隔離的需求，Maat基于Airflow原生的隊列管理擴充不同任務的叢集管理功能，不同類型的任務可以建立自己的scheduler和worker，建立應用時可以使用指定的scheduler排程或運作在指定worker上（如果不指定由預設scheduler和worker排程）。

叢集的配置參數包括以下資訊：

• worker部署配置：該worker依賴的資源，drogo啟動時會将任務運作需要的資源部署到worker機器上，機器遷移時也會使用這份部署配置重新配置設定資源。

• worker個數：控制worker角色的個數。

• 叢集并發數：控制叢集中正在運作的并發數，防止任務運作過多導緻下遊系統壓力過大。

• scheduler：目前每個叢集隻有一個scheduler，後續會改造成支援多個scheduler排程節點。

監控&報警

平台監控報警

為了掌握平台的運作狀況，Maat在各個節點的關鍵步驟向kmon彙報metric資訊，metric異常狀态下會發送報警給開發同學。也可以根據這些metric資訊判斷目前叢集的負載狀況，對任務負載較高的節點進行優化。

任務報警

對于具體任務，Maat支援在每個任務節點運作異常的情況下發送報警，如節點運作異常、任務未按時運作、任務運作逾時等。使用者可以在管控平台設定報警條件及報警接收人。

平台現狀

Maat是一個通用基于Dag的任務排程系統，服務于集團内部和雲上的許多場景：

• 搜尋中台Tisplus：排程Tisplus的上線流程及其他需要定時觸發的任務；

• Hawkeye：定時排程Hawkeye的分析任務；

• 搜尋監控平台Kmon：支援kmon的監控托管服務及報警處理流程；

• 搜尋容量預估平台Torch：支援容量預估流程的管控；

• 搜尋離線平台Bahamut：支援離線元件平台釋出流程、全量流程；

• Opensearch：一些算法場景的離線任務；

• Tpp：推薦場景的流程排程任務。

Maat線上叢集任務執行現狀（2018.8.13資料）：

• 日均排程任務：3000+個

• 日均運作任務：24K+次

随着更多應用場景的接入，平台能力将會接受進一步的考驗。

未來展望

随着業務的接入和資料規模的增大，Maat平台也需要進一步提升使用者體驗，提升平台穩定性。

• 與Aflow進一步結合，在管控平台上一站式完成叢集的建立、配置、部署。

• 提供更加豐富的報警選項，進一步加強錯誤的回報機制。

• 随着任務數量的增多，一些排程上的缺陷逐漸展現出來，對于這些缺陷做進一步優化。

• 和FaaS深度合作，為各類任務建立單獨的FaaS服務，降低資源使用率。

加入我們

搜尋中台從0到1建設已經走過了3年，但它離我們心目中讓天下沒有難用的搜尋的遠大願景還離的非常遠，在這個前行的道路上一定會充滿挑戰，無論是業務視角的SaaS化能力、搜尋算法産品化、雲端devops&aiops，還是業務建站等都将遇到世界級的難題等着我們去挑戰。是以，無論是web開發，引擎開發還是算法同學。

原文釋出時間為：2018-08-16

本文作者：斯蘭

本文來自雲栖社群合作夥伴“

阿裡技術

”，了解相關資訊可以關注“

”。