關(guān)鍵詞：大數(shù)據(jù)；DAG有向無環(huán)圖；調(diào)度平臺

中圖法分類號：TP301 文獻標識碼：A

1引言

大型商業(yè)運營階段生產(chǎn)的數(shù)據(jù)類型大多是傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)。這些數(shù)據(jù)基本屬于隱私性和安全性等級十分高的貿(mào)易、商業(yè)、物流，以及保險、股票等傳統(tǒng)支撐行業(yè)數(shù)據(jù)。而互聯(lián)網(wǎng)時代出現(xiàn)的數(shù)據(jù)類型大多屬于非結(jié)構(gòu)化的社交網(wǎng)絡數(shù)據(jù)、電子商務交易數(shù)據(jù)、圖片定位數(shù)據(jù)，以及商業(yè)智能報表、衛(wèi)星遙感數(shù)據(jù)、監(jiān)控錄像等非結(jié)構(gòu)化和二維碼像素數(shù)據(jù)。因此，研究大數(shù)據(jù)任務流調(diào)度平臺，對于企業(yè)內(nèi)部自建大數(shù)據(jù)量的實時／離線同步、處理、清洗、治理、流程化、持久化等任務流程，具有重要的成本與運營意義。

2研究現(xiàn)狀

此前，傳統(tǒng)技術(shù)任務調(diào)度系統(tǒng)大多是侵入式調(diào)度，即需要依賴框架，若將框架拿掉或者換一個框架，則需要重新進行修改，同時部分調(diào)度系統(tǒng)雖然為非侵入式，但其機制的設計不足以承擔大數(shù)據(jù)時代數(shù)據(jù)的變化速度，不適應企業(yè)高速發(fā)展所需要的彈性、可定制性、獨立性?，F(xiàn)有的系統(tǒng)和技術(shù)已經(jīng)無法解決當前大數(shù)據(jù)背景下企業(yè)數(shù)據(jù)量暴增的問題。

3大數(shù)據(jù)DAG任務流調(diào)度平臺架構(gòu)設計

本文詳細闡述了大數(shù)據(jù)DAG任務流調(diào)度平臺方案，即大數(shù)據(jù)DAG任務流調(diào)度平臺技術(shù)研究與應用。整體架構(gòu)設計如圖1所示。

該框架在設計上充分考慮了大數(shù)據(jù)場景，利用去中心化的架構(gòu)，構(gòu)建整個調(diào)度集群，基于DAG有向無環(huán)圖，構(gòu)建整個任務流程體系，核心是使企業(yè)實時／離線大數(shù)據(jù)處理流程更加簡易化，各組件模塊相互協(xié)作共同為此服務。其中用到的關(guān)鍵技術(shù)點將展開一一討論。

3.1協(xié)議設計

首先，需要進行通信協(xié)議設計，傳統(tǒng)的http協(xié)議不滿足需求，我們需要高效、穩(wěn)定的通信協(xié)議，以解決通信中丟包、粘包、斷線重連、消息重發(fā)等問題。其次，進行具體的通信協(xié)議設計，協(xié)議頭為15個字節(jié)。

該協(xié)議保障了傳輸?shù)姆€(wěn)定性和可擴展性，Proto flag保障協(xié)議不被篡改，Real body size和Body size保證拆包、粘包、壓縮、加密的處理，Encrypt Flag可支持自定義協(xié)議加密算法等。

3.2任務引擎設計

首先需要說明任務引擎在整個架構(gòu)里面的必要性和重要性，任務引擎為一個單位，可由不同程序不同模塊組成，甚至不同開發(fā)語言組成，這種架構(gòu)所設計的任務引擎具備很強的擴展性和隔離性，如何建立它們之間的關(guān)系，是一個難題。其次探討任務引擎通信的設計，即如何做到不同結(jié)構(gòu)任務引擎之間的關(guān)聯(lián)。

每個任務引擎都有對外握手機制（輸入和輸出），要實現(xiàn)這一特性，必須定義任務引擎標準，每個任務引擎必須具備引擎名稱、輸入標準、輸出標準等標準信息，才能建立握手機制。之后，引擎之間就具備了信息交換、信息解析的能力，以使用Java語言編寫的sql引擎為例講解標準的定義，sql引擎應具備接收數(shù)據(jù)源并且執(zhí)行動作的能力。

3.3任務引擎熱加載機制

用戶可以進行一個任務引擎（新引擎或迭代引擎）的上傳，當上傳到worker時，worker會將用戶上傳的任務引擎做一致性校驗（ md5/hash）.如發(fā)現(xiàn)此次上傳的引擎較舊引擎無變化，就不進行處理，如有變化，則worker會將舊引擎（oldEngine）標記為刪除狀態(tài)，將指針指向新引擎（newEngine），確保下一次任務使用新引擎，正在執(zhí)行的舊引擎會在它所有任務完成之后，從標記刪除變?yōu)槲锢韯h除。

3.4 DAG結(jié)構(gòu)

調(diào)度系統(tǒng)需要使用DAG（有向無環(huán)圖）結(jié)構(gòu)，一般情況下，任務都是孤立的，任務之間也無關(guān)聯(lián)性可言，這樣的任務調(diào)度系統(tǒng)使用場景有限，因此無法實現(xiàn)任務順序性、任務關(guān)聯(lián)性、任務流程控制等，如何建立任務之間的關(guān)系，是一個難題。基于DAG結(jié)構(gòu)設計的任務流程，可以實現(xiàn)整個任務流程體系。

如圖2所示，總共有9個任務，每個任務都有關(guān)聯(lián)性和順序性，保證整個流程任務執(zhí)行的正確性是關(guān)鍵。

通過圖2可以看到，需要1個節(jié)點（ node）代表任務本身，每個節(jié)點存在多條邊（edge），每條邊存在前后2個節(jié)點（beforeNode，afterNode）。

整體執(zhí)行順序如圖3所示。

3.5資源介質(zhì)機制

任務引擎除了需要具備握手機制，還要保障其獨立性和可擴展性。例如，某個引擎需要以文件內(nèi)容為輸入進行解析，這時引擎如果要獲取這個文件，難度較大、效率較低，因為不知道這個文件來源于哪里，此時需要有“人”幫任務引擎準備好它所需要的“物資”，針對這種情況，我們提出資源介質(zhì)的概念。

用戶通過介質(zhì)人口進行資源上傳，用戶不用關(guān)心當前上傳的資源是什么類型的介質(zhì)，統(tǒng)一上傳到調(diào)度平臺，由調(diào)度平臺的資源介質(zhì)中心進行管理分類等操作，當任務引擎需要資源時，通過資源介質(zhì)出口到各個任務引擎，并自動幫任務引擎準備好這些資源。同樣，任務引擎也不關(guān)心當前的資源介質(zhì)，直接使用即可。

3.6調(diào)度算法

本文實現(xiàn)的調(diào)度算法基于動態(tài)負載均衡算法的變種，并基于幾個指標來做決定，即內(nèi)存、cpu、任務數(shù)、線程數(shù)、系統(tǒng)負載、cpu負載，判斷當前是否可以進行調(diào)度，最終實現(xiàn)的計算式為：

其中，各字段的含義為ree為最終確定是否空閑可調(diào)度標志free Thread為當前系統(tǒng)空閑線程，cpu為cpu使用率，threshold為可配置閾值，mem為系統(tǒng)內(nèi)存占用，cpuLoad為系統(tǒng)cpu負載程度，systemLoad為系統(tǒng)整體負載程度。

當freeThread大于1，cpu小于threshold，mem小于threshold，cpuLoad小于threshold，systemLoad小于threshold時，ree即為true，空閑狀態(tài)，可接受任務調(diào)度。

其中，cpu負載獲取算法為：

主要通過統(tǒng)計cpu rq上task處于runnable的平均時間。同時，根據(jù)不同周期，統(tǒng)計出不同的k線。其中，oldLoad為舊負載，newLoad為負載

系統(tǒng)負載獲取算法為（1分鐘）：

其中，old為舊負載，EXPi為l/exp（5 sec/1 min）固定點，F(xiàn)IXEDi為1《11固定點，new為新計算的負載。

至于5分鐘和15分鐘的計算，將式（4）中的EXP₁換成EXP₅/EXP₁₅即可。

3.7回調(diào)機制

調(diào)度系統(tǒng)回調(diào)機制十分重要。一般情況下，任務執(zhí)行完成后，需要通知任務發(fā)起者，告訴它任務成功還是失敗，面對這種情況，侵入式調(diào)度可以很好實現(xiàn)這一特性，調(diào)用當前空間用戶定義的回調(diào)函數(shù)即可，但介于侵入式擴展性問題，我們需要設計一個新的調(diào)度回調(diào)機制。

我們將解決以下問題：各個業(yè)務系統(tǒng)回調(diào)方式不一致，回調(diào)失敗的處理，回調(diào)性能。

為了讓回調(diào)機制不受限于某種類型，與業(yè)務系統(tǒng)剝離，我們設計了1個統(tǒng)一注冊回調(diào)接口，回調(diào)方式以插件形式注冊，支持更多回調(diào)方式進行擴展，讓用戶無需關(guān)注回調(diào)實現(xiàn)，只需要提交任務時進行注冊回調(diào)邏輯，設計如下：用戶先自定義回調(diào)邏輯處理，然后提交任務，等待調(diào)度平臺任務執(zhí)行成功或失敗，任務執(zhí)行結(jié)束后會通過回調(diào)機制進行回調(diào)，回調(diào)失敗會進行重試，整個回調(diào)過程為異步操作，保證不阻塞業(yè)務，重試會有次數(shù)限制，當達到對應次數(shù)后，會等待一段時間進行重試。

3.8信號機制

任務引擎會定義1個信號處理函數(shù)（標準），該處理函數(shù)處理當前任務引擎需要釋放的資源，然后一般就做結(jié)束進程exit處理，當用戶觸發(fā)停止任務.worker會發(fā)送1個中斷信號，系統(tǒng)空間會因當前進程信號中斷而調(diào)用系統(tǒng)內(nèi)核函數(shù)do_signal（）、handle_signal（）（linux），轉(zhuǎn)向任務引擎空間的信號處理函數(shù)（windows為SetConsoleCtrlHandler）.此時任務引擎進行善后工作，信號處理函數(shù)結(jié)束后調(diào)用sigreturn（）進行系統(tǒng)空間內(nèi)核善后工作，再返回任務引擎空間繼續(xù)執(zhí)行中斷前邏輯。

4效果評價

按照上文所述的大數(shù)據(jù)DAG任務流調(diào)度平臺方案，我們進行了編碼實現(xiàn)，主要分為用戶端流程任務配置、大數(shù)據(jù)端dag流程任務調(diào)度、任務進度、任務日志追溯等功能，這里采用的是B/S前后端分離，去中心化架構(gòu)模式，通過集群負載均衡的方式，支持超大數(shù)據(jù)的任務調(diào)度，并支持任務引擎動態(tài)擴展，處理大數(shù)據(jù)處理過程中非常復雜的任務依賴關(guān)系，致力于實現(xiàn)在離線、實時超大量任務流程中的高性能調(diào)度和穩(wěn)定性。另外，我們還實現(xiàn)了告警和消息通知機制，能在任務異常時，及時告知、處理，以挽回損失。

依托大數(shù)據(jù)DAG流程調(diào)度運行過程的示例，流程配置采用非常簡單的拖拽配置方式，任務執(zhí)行過程能按照順序執(zhí)行，并且整個執(zhí)行過程日志均有記錄，每個任務引擎也有自己的輸入／輸出標準，同時能拿到前置任務的輸出。整個平臺對使用人員而言非常人性化，只需在界面進行配置，任務將會以預期的結(jié)果運行。

綜合來看，本文研究的大數(shù)據(jù)DAG任務流調(diào)度平臺憑借其全方位、高擴展、高性能的架構(gòu)設計，足以勝任企業(yè)內(nèi)部自建大數(shù)據(jù)量的實時／離線同步、處理等任務流程，大大提高了整體數(shù)據(jù)處理、任務調(diào)度能力。

5結(jié)束語

本文設計并實現(xiàn)了一套大數(shù)據(jù)DAG任務流調(diào)度平臺，并通過各個環(huán)節(jié)的設計，將高性能和高擴展發(fā)揮極致，隨著互聯(lián)網(wǎng)的發(fā)展，有效解決了企業(yè)在現(xiàn)代數(shù)字化建設中，將新舊數(shù)據(jù)（通常為超大數(shù)據(jù)）處理整合并持續(xù)性擴充的難題，通過多維度構(gòu)建起全方位的調(diào)度平臺，提高企業(yè)經(jīng)營效率，節(jié)約大量人力，減少了企業(yè)在數(shù)據(jù)暴漲時代維護數(shù)據(jù)的投入。

作者簡介：

許佳裕（1993—），大專，助理工程師，研究方向：大數(shù)據(jù)任務調(diào)度、數(shù)據(jù)清洗、框架設計建設、Lmux內(nèi)核。