前言：大數(shù)據(jù)的分布式調(diào)度是在進(jìn)行數(shù)據(jù)ETL過程中起到了總體的承上啟下的角色，整個(gè)數(shù)據(jù)的生產(chǎn)、交付、消費(fèi)都會(huì)貫穿其中，本文從調(diào)度、分布式調(diào)度的特征展開，再對(duì)大數(shù)據(jù)調(diào)度個(gè)性化特征的一些闡述，由滿足大數(shù)據(jù)使用的架構(gòu)和業(yè)務(wù)場(chǎng)景的需求上娓娓道來，從實(shí)踐的角度分享如何打造一個(gè)高可用、高效率、靈活性的大數(shù)據(jù)調(diào)度平臺(tái)。

一、調(diào)度

從上個(gè)世紀(jì)50年代起，調(diào)度問題的研究就受到數(shù)學(xué)、運(yùn)籌學(xué)、工程技術(shù)學(xué)等領(lǐng)域科學(xué)的重視，人們主要從數(shù)學(xué)的角度來研究調(diào)度問題，調(diào)度問題也同樣被定義為”分配一組資源來執(zhí)行一組任務(wù)”，以獲得生產(chǎn)任務(wù)執(zhí)行時(shí)間或成本的最優(yōu)。調(diào)度在計(jì)算機(jī)任務(wù)的實(shí)現(xiàn)可以依賴操作系統(tǒng)的定時(shí)任務(wù)進(jìn)行觸發(fā)(例如Linux系統(tǒng)的Crontab)，主要針對(duì)單任務(wù)機(jī)制的觸發(fā)，調(diào)度最基本的需要能夠按時(shí)或者按照事件進(jìn)行觸發(fā)(At-least-once)，如果任務(wù)不符合預(yù)期，還需要在應(yīng)用端進(jìn)行重試，最大可能保證任務(wù)被按時(shí)執(zhí)行，并且成功執(zhí)行，同時(shí)不能多次執(zhí)行(Exactly once);但是在業(yè)務(wù)場(chǎng)景能保證可重復(fù)執(zhí)行、一致性操作情況下對(duì)于爭(zhēng)取能正常調(diào)度執(zhí)行多次執(zhí)行也是不可或缺的，比如給商戶進(jìn)行1min前的例行結(jié)算，如果結(jié)算是按照30min的時(shí)間窗口查找未結(jié)算的商戶，那么就會(huì)容忍30min延遲，并且多次被執(zhí)行也不會(huì)給商戶多結(jié)算，因?yàn)樵诮Y(jié)算付款和重置是否結(jié)算標(biāo)志位可以設(shè)計(jì)成原子性操作。所以在調(diào)度上能夠做到按時(shí)、正確的執(zhí)行，在業(yè)務(wù)方設(shè)計(jì)為了保證最終一致性也有一些架構(gòu)上的取舍。

如果應(yīng)用場(chǎng)景有上下游的協(xié)作，或者在任務(wù)執(zhí)行會(huì)存在不同的宿主機(jī)來完成，或者為了保證任務(wù)高可用場(chǎng)景，就需要引入分布式調(diào)度的架構(gòu)。

二、分布式調(diào)度

分布式調(diào)度是在單機(jī)的基礎(chǔ)上發(fā)展起來，在綜合考慮高可用、高效率、分布式協(xié)作的背景下逐步演進(jìn)的調(diào)度方式，從單點(diǎn)調(diào)度到分布式協(xié)作是一個(gè)質(zhì)變的過程，這個(gè)過程涉及到許多在單機(jī)并不存在的特征，下面針對(duì)重點(diǎn)展開聊下：

圖1 分布式調(diào)度組件化分解圖

2.1 調(diào)度器去中心化&高可用

2.2 宿主選擇

分布式調(diào)度在任務(wù)執(zhí)行階段，可以在目標(biāo)宿主中進(jìn)行全部執(zhí)行、N選M(N>=M>=1)的選擇，宿主機(jī)具備相同類型任務(wù)互備的機(jī)制，在MPP(Massively Parallel Processor)架構(gòu)中尤為常見，把大任務(wù)分而治之快速完成。也存在場(chǎng)景(比如外賣給商戶結(jié)算)為了一致性和準(zhǔn)確性只能由一臺(tái)主機(jī)進(jìn)行執(zhí)行，并且需要成功執(zhí)行

被動(dòng)選擇策略：宿主的被動(dòng)選擇機(jī)制一般可以隨機(jī)或者按照順序選擇策略，也可以按照當(dāng)前宿主機(jī)進(jìn)行的任務(wù)執(zhí)行數(shù)量的方式進(jìn)行常規(guī)的調(diào)度分配。當(dāng)然，也可以進(jìn)行高級(jí)的操作，參照宿主機(jī)的處理能力(吞吐量和響應(yīng)時(shí)間)、資源使用情況(CPU、Memory、Disk I/O、Net I/O等)進(jìn)行反饋機(jī)制的動(dòng)態(tài)分配。后者需要有集中節(jié)點(diǎn)存儲(chǔ)當(dāng)前宿主機(jī)的處理能力、資源情況，便于在決策選擇中提供參照。 主動(dòng)選擇策略：宿主的主動(dòng)選擇具備更加豐富的選舉策略，任務(wù)在下達(dá)到具體算子時(shí)，會(huì)比較明確的定義出當(dāng)前任務(wù)需要由多少個(gè)宿主參與執(zhí)行，通過zookeeper的分布式鎖來實(shí)現(xiàn)鎖的搶占機(jī)制，搶占成功則執(zhí)行，否則放棄。這種選舉策略讓宿主機(jī)得到了更多的參與，降低了對(duì)調(diào)度器的依賴。這種主動(dòng)選擇的方式，避免被動(dòng)選擇因不具備執(zhí)行條件被選中，在執(zhí)行的能力在時(shí)間上的損耗。

2.3 任務(wù)故障轉(zhuǎn)移

調(diào)度任務(wù)的從任務(wù)級(jí)別job到transformer、operator，整個(gè)鏈條都存在具體局部失敗的情況，調(diào)度器需要在原目標(biāo)宿主機(jī)重試和失敗后轉(zhuǎn)移到其他備宿主機(jī)的功能，最大力度的保證任務(wù)被成功執(zhí)行。

2.4 執(zhí)行算子抽象

以往單機(jī)任務(wù)的調(diào)度可以比較靈活的執(zhí)行多樣的任務(wù)，可以是腳本、Webservice調(diào)用、HDFS Client命令行等，但是對(duì)于分布式協(xié)作需要接收外部命令運(yùn)行，這就需要算子通過標(biāo)準(zhǔn)的數(shù)據(jù)通訊協(xié)議對(duì)外提供調(diào)用服務(wù)，常規(guī)的WebService、RPC(thrift/protocol buffer)等協(xié)議在跨語言通訊上具有較為廣泛的應(yīng)用。所以具體執(zhí)行單元可以是具體任務(wù)的抽象，例如提供了Rest API方式，調(diào)用的URL和參數(shù)都是執(zhí)行方填入，最大程度上支撐了靈活性;數(shù)據(jù)庫操作算子可以包含數(shù)據(jù)庫驗(yàn)證信息、具體執(zhí)行的SQL等。執(zhí)行算子抽象后，滿足規(guī)范和靈活性，靈活是一個(gè)雙刃劍，可以最大限度的滿足用戶需求，但也會(huì)導(dǎo)致大數(shù)據(jù)層面無法很細(xì)粒度的去感知數(shù)據(jù)的表、字段數(shù)據(jù)的完成情況，對(duì)數(shù)據(jù)生產(chǎn)無法更加精細(xì)粒度的產(chǎn)出交付。

2.5 彈性擴(kuò)展