前言：大數據的分布式調度是在進行數據ETL過程中起到了總體的承上啟下的角色，整個數據的生產、交付、消費都會貫穿其中，本文從調度、分布式調度的特征展開，再對大數據調度個性化特征的一些闡述，由滿足大數據使用的架構和業務場景的需求上娓娓道來，從實踐的角度分享如何打造一個高可用、高效率、靈活性的大數據調度平臺。

一、調度

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

如果應用場景有上下游的協作，或者在任務執行會存在不同的宿主機來完成，或者為了保證任務高可用場景，就需要引入分布式調度的架構。

二、分布式調度

分布式調度是在單機的基礎上發展起來，在綜合考慮高可用、高效率、分布式協作的背景下逐步演進的調度方式，從單點調度到分布式協作是一個質變的過程，這個過程涉及到許多在單機并不存在的特征，下面針對重點展開聊下：

圖1 分布式調度組件化分解圖

2.1 調度器去中心化&高可用

2.2 宿主選擇

分布式調度在任務執行階段，可以在目標宿主中進行全部執行、N選M(N>=M>=1)的選擇，宿主機具備相同類型任務互備的機制，在MPP(Massively Parallel Processor)架構中尤為常見，把大任務分而治之快速完成。也存在場景(比如外賣給商戶結算)為了一致性和準確性只能由一臺主機進行執行，并且需要成功執行

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

2.3 任務故障轉移

調度任務的從任務級別job到transformer、operator，整個鏈條都存在具體局部失敗的情況，調度器需要在原目標宿主機重試和失敗后轉移到其他備宿主機的功能，最大力度的保證任務被成功執行。

2.4 執行算子抽象

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

2.5 彈性擴展