作者：梁福坤

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

調(diào)度

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

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

分布式調(diào)度

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

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

涉及到分布式調(diào)度的協(xié)作，就需要有調(diào)度中心節(jié)點，同時要保證高可用的目的就需要調(diào)度中心節(jié)點是多節(jié)點發(fā)布，主備的方式去單點依賴。

2.2 宿主選擇

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

被動選擇策略：宿主的被動選擇機制一般可以隨機或者按照順序選擇策略，也可以按照當(dāng)前宿主機進行的任務(wù)執(zhí)行數(shù)量的方式進行常規(guī)的調(diào)度分配。當(dāng)然，也可以進行高級的操作，參照宿主機的處理能力（吞吐量和響應(yīng)時間）、資源使用情況（CPU、Memory、Disk I/O、Net I/O等）進行反饋機制的動態(tài)分配。后者需要有集中節(jié)點存儲當(dāng)前宿主機的處理能力、資源情況，便于在決策選擇中提供參照。

主動選擇策略：宿主的主動選擇具備更加豐富的選舉策略，任務(wù)在下達到具體算子時，會比較明確的定義出當(dāng)前任務(wù)需要由多少個宿主參與執(zhí)行，通過zookeeper的分布式鎖來實現(xiàn)鎖的搶占機制，搶占成功則執(zhí)行，否則放棄。這種選舉策略讓宿主機得到了更多的參與，降低了對調(diào)度器的依賴。這種主動選擇的方式，避免被動選擇因不具備執(zhí)行條件被選中，在執(zhí)行的能力在時間上的損耗。

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

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

2.4 執(zhí)行算子抽象

以往單機任務(wù)的調(diào)度可以比較靈活的執(zhí)行多樣的任務(wù)，可以是腳本、Webservice調(diào)用、HDFS Client命令行等，但是對于分布式協(xié)作需要接收外部命令運行，這就需要算子通過標(biāo)準(zhǔn)的數(shù)據(jù)通訊協(xié)議對外提供調(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ù)庫驗證信息、具體執(zhí)行的SQL等。執(zhí)行算子抽象后，滿足規(guī)范和靈活性，靈活是一個雙刃劍，可以最大限度的滿足用戶需求，但也會導(dǎo)致大數(shù)據(jù)層面無法很細粒度的去感知數(shù)據(jù)的表、字段數(shù)據(jù)的完成情況，對數(shù)據(jù)生產(chǎn)無法更加精細粒度的產(chǎn)出交付。

2.5 彈性擴展

任務(wù)具體執(zhí)行的宿主機需要在調(diào)度層面滿足彈性的擴展，擴展最主要的需要是滿足高可用和任務(wù)隨著水平擴展進行分攤壓力。在集群目標(biāo)宿主機選擇時，一般目標(biāo)集合可以指定具體IP-List，也可以是一個BNS(百度機器的NameServer服務(wù))。IP-List方式設(shè)置比較簡單直觀，但是存在每次調(diào)整依賴變更調(diào)度系統(tǒng)服務(wù)，變更之后還需要進行刷新宿主機的情況。而通過BNS服務(wù)比較簡單，同時和線上服務(wù)發(fā)布部署進行結(jié)合，不存在延遲部署和刷新，推薦通過BNS的方式介入。

2.6 觸發(fā)機制

常規(guī)觸發(fā)是按照執(zhí)行間隔或者具體時間的Crontab語法，開始時間，截止時間參數(shù)完成，但是在分布式調(diào)度任務(wù)中，最重要的就是完成協(xié)作，所以如果要進階的話，就是依賴觸發(fā)的機制。這種就很好的形成了上下游依賴觸發(fā)，是分布式協(xié)作的關(guān)鍵步驟。從最初的任務(wù)節(jié)點按照常規(guī)觸發(fā)，下游節(jié)點形成依賴鏈條，這里如果在高級進階的話，就是依賴的某個/某些頻次觸發(fā)，比如每小時的12分鐘開始被執(zhí)行，下游可以選擇具體的2:12 ，4:12進行觸發(fā)，而非每個整點12分都被調(diào)用。這三種方式目前在外賣的大數(shù)據(jù)平臺都有不同場景訴求，架構(gòu)設(shè)計在3個需求上都有靈活的交付。

2.7 堵塞機制

對于相同任務(wù)的不同時間的運行實例，會存在前面的實例還沒有正常結(jié)束的情況，這種在高頻次調(diào)用，第三方依賴故障延遲等情況下會出現(xiàn)，如果繼續(xù)調(diào)用會造成調(diào)用鏈條惡化，所以防止這種情況，堵塞機制會提供三種模式：常規(guī)例行（默認模式）、丟棄后續(xù)、丟棄前例。后面2種方案都需要提供容錯重放機制，這個場景比較類似1.1章節(jié)提到的結(jié)算案例。

2.8 圖形化進展查看

調(diào)度可以根據(jù)調(diào)用鏈條和不同事件頻次的實例，通過樹狀圖形化的方式查看執(zhí)行的進度情況，例如可以查看job中transformer、算子的運行機器狀況、狀態(tài)和具體的實時執(zhí)行日志。圖形化是根據(jù)調(diào)用的觸發(fā)機制分析出來的一個鏈條，是在煩冗復(fù)雜的調(diào)用關(guān)系中找到清晰脈絡(luò)的數(shù)據(jù)直觀表達的方式，是調(diào)度中常規(guī)的展示方式。在進階中可以查看相應(yīng)的參數(shù)傳遞，并發(fā)算子的執(zhí)行進度條，預(yù)估完成周期等。

2.9 報警

通過郵件或者短信的方式對不符合預(yù)期返回標(biāo)識的進行中止，同時通過郵件或者短信等方式對預(yù)先設(shè)置的用戶或者用戶組發(fā)出警告。報警觸發(fā)的機制可以在宿主機單臺時候觸發(fā)，也可以在一定占比的宿主機在一定的時間窗口超過了閾值，觸發(fā)報警。同時也要支持報警的屏蔽，用在進行運維或者升級部署、運維接管的情況。

上面是很多常規(guī)調(diào)度擁有的一些特征，這些是在分布式場景下的延伸需求，從單點簡單的邏輯到多節(jié)點的協(xié)作統(tǒng)籌在工程層面無疑增加了額外輔助，這些都是在業(yè)務(wù)演進中逐步完善起來，而高可用、高效率是在分布式環(huán)境下做出的改變。

大數(shù)據(jù)分布式調(diào)度

大數(shù)據(jù)分布式調(diào)度，在上面通用調(diào)度的基礎(chǔ)上又進行了具體跟數(shù)據(jù)特征相匹配的改良。主要是從數(shù)據(jù)的流程層面進行梳理，用來解釋數(shù)據(jù)的上下游、血緣關(guān)系的問題，具體又有哪些特征是針對大數(shù)據(jù)的呢？

3.1 數(shù)據(jù)扇入扇出

大數(shù)據(jù)的存儲和檢索方案很多，因大數(shù)據(jù)特征之一就是多樣性，為了滿足多樣的業(yè)務(wù)場景會有不同的引擎或者存儲選擇，在多樣化解決方案的同時，造成了數(shù)據(jù)之間進行交換變得復(fù)雜，引擎之間的數(shù)據(jù)存取規(guī)則都有個性化的支持，比如Hbase的數(shù)據(jù)到Mysql和ElasticSearch（以下簡稱ES），涉及到Hbase的讀取和后續(xù)后面兩者的數(shù)據(jù)存入，這種對于Hbase就是一對二的數(shù)據(jù)扇出，但是在數(shù)據(jù)在Hbase中通過Get或者Scan方式獲取后，要插入數(shù)據(jù)需要了解后面2者的存儲結(jié)構(gòu)，甚至是索引結(jié)構(gòu)。所以類似這種跨引擎（或者跨版本，不同API）的方式，為了保持通用，需要進行需求的抽象，在外賣平臺針對數(shù)據(jù)的交換定義了一套開放式SQL，這個框架對數(shù)據(jù)引擎的存和取分別作了抽象，在不同的目標(biāo)引擎中有具體的實現(xiàn)，所以就有一些約定的規(guī)范。


主鍵：數(shù)據(jù)必須存在業(yè)務(wù)主鍵或者聯(lián)合主鍵，目的是為了保證數(shù)據(jù)在聚合或者更新的時候有依據(jù)。主鍵在Nosql的引擎中作為RowKey，在關(guān)系數(shù)據(jù)庫中作為主鍵，在ES中作為主鍵key。對于Kudu來講也是主鍵，針對數(shù)據(jù)的upsert就可以有依據(jù)的進行更新或者插入。

數(shù)據(jù)列：數(shù)據(jù)列的變更會稍微復(fù)雜，如果在關(guān)系數(shù)據(jù)庫中會涉及到增加、變更列，但是在Hbase、ES中基本不需要主動擴展列，只需要對數(shù)據(jù)變更就可以了。

分區(qū)字段：對于事實表數(shù)據(jù)，在大數(shù)據(jù)量的情況下，為了檢索效率和數(shù)據(jù)存放最優(yōu)，一般會提供分區(qū)和桶的策略，針對Hive、Impala、GreenPlum的引擎會額外增加分區(qū)字段，分區(qū)可以是一級到多級，一般業(yè)務(wù)場景下第一分區(qū)為日期，根據(jù)實際業(yè)務(wù)需求可以變更更細粒度或者其他業(yè)務(wù)字段。在一般Mysql、Postgresql、Hbase這種引擎中不需要單獨增加分區(qū)字段。

數(shù)據(jù)更新范圍：大數(shù)據(jù)的數(shù)據(jù)交換，一般為了提高效率會進行多批次的并發(fā)處理，這就需要在一批次的數(shù)據(jù)進行分割，一般情況下會按照單一字段的進行截取，字段的類型以時間戳（create_time、update_time）居多，也可以根據(jù)主鍵的key排序后分批次獲取，在源數(shù)據(jù)引擎允許的情況下，按照多批次的并發(fā)query可以做到很好的數(shù)據(jù)獲取，把串行的操作截斷成多段的并發(fā)；這種在同一個任務(wù)多時間批次的情況下也很重要，每個批次會界定本批次設(shè)計數(shù)據(jù)更新的范圍。數(shù)據(jù)更新范圍使用前一般會獲取本次更新的數(shù)據(jù)量，可以根據(jù)原目標(biāo)引擎單個批次的最優(yōu)性能計算出offset。

多步驟過程：多步驟顧名思義就是數(shù)據(jù)的準(zhǔn)備不是一蹴而就的，例如在3個Mysql庫、Postgresql、Oracle中獲取員工信息，而員工編號是統(tǒng)一的，最終數(shù)據(jù)在DB2中匯聚在一起，最基礎(chǔ)的步驟是三份數(shù)據(jù)匯入到Oracle中，這就涉及到前面通過key做數(shù)據(jù)的Merge，這里會涉及到數(shù)據(jù)的插入和更新，但是如果有key存在并且不同數(shù)據(jù)源目標(biāo)數(shù)據(jù)列清楚的情況下，三份數(shù)據(jù)早到和晚到場景都沒有太大區(qū)別。第二步驟則根據(jù)匯總完的數(shù)據(jù)分析出一個過濾場景下的聚合信息，這步驟的場景作為計算數(shù)據(jù)源，再次進行數(shù)據(jù)的扇出插入結(jié)果。第三步驟可以把第一步的臨時結(jié)果進行刪除。所以在多步驟的場景下數(shù)據(jù)是分步驟完成了匯聚、聚合和刪除。

更新類型：百度外賣大數(shù)據(jù)實踐的開放式SQL場景有Insert（大批明細場景）、Update（數(shù)據(jù)后續(xù)更新）、Insert Once（聚合結(jié)果插入）、Insert Temp（臨時結(jié)果緩存）、Delete（善后處理場景），在這些組合操作類型的場景下，需要在是線上增加一個執(zhí)行優(yōu)先級的信息，如果區(qū)分優(yōu)先級會按照從前到后的步驟執(zhí)行，如果沒有設(shè)定則可以并發(fā)操作。

黑盒暴露操作：黑盒操作是在通過開放式SQL的存取原則情況下，對無法按照約定規(guī)范操作的情況下實行的一種妥協(xié)方式，目的有兩個：一方面要把黑盒對數(shù)據(jù)依賴過程必須對外暴漏，這樣是為了后期梳理數(shù)據(jù)血緣關(guān)系提供素材；另一方面通過黑盒來滿足數(shù)據(jù)處理的靈活性，比如對json負責(zé)xpath的選擇，集中緩存優(yōu)化方案；黑盒雖然通過規(guī)范暴露了依賴源數(shù)據(jù)，但是也造成了對外不好解釋數(shù)據(jù)的處理過程，同時這種黑盒一般針對表或者多個字段，精細化程度不夠。

開放式SQL是大數(shù)據(jù)在做數(shù)據(jù)ETL的一個規(guī)范標(biāo)準(zhǔn)，目的在數(shù)據(jù)的交換和流動是通過配置的范式來完成，并非是通過硬編碼或者單純組件化的方式。編碼更多的是要提供豐富的解析函數(shù)，更優(yōu)秀的中間大結(jié)果集的Cache和復(fù)用。開放式SQL提供了數(shù)據(jù)從哪里來，到哪里去的哲學(xué)問題，同時也可以進行對外闡述對數(shù)據(jù)做何種操作，這是在為后期數(shù)據(jù)血緣關(guān)系提供最基礎(chǔ)的指導(dǎo)，在發(fā)展過程中，百度外賣大數(shù)據(jù)平臺也經(jīng)歷了如下的不同階段。


3.2 協(xié)作參數(shù)一致性

調(diào)度策略除了有之前提到的上下游關(guān)系外，在大數(shù)據(jù)場景下還需保證數(shù)據(jù)處理的統(tǒng)籌協(xié)作，更為重要的是精細參數(shù)的上傳下達。上下游使用系統(tǒng)默認的參數(shù)Key定義，也可以自定義Key的參數(shù)；系統(tǒng)參數(shù)比如說起止時間戳、機器IP、執(zhí)行任務(wù)實例等。對于全局系統(tǒng)默認的Key，由調(diào)度系統(tǒng)進行賦值。

參數(shù)的作用域有本地化和全局2種方式，本地化可以設(shè)定參數(shù)的Key：Value，相同Key的全局不會被覆蓋，本地的優(yōu)先級高于全局；而全局的變量是由上游產(chǎn)生并且進行流轉(zhuǎn)；調(diào)度本身規(guī)定了不同算子在參數(shù)接收方面的追加、解析、編碼規(guī)范，比如在Shell命令和WebService中追加參數(shù)有較大區(qū)別。

參數(shù)除了作用域還有是否被傳遞的屬性，上游的參數(shù)可以有針對性的對下游輸出，同樣，如果算子接收到上游參數(shù)可以選擇修改值，但是這種傳遞是不被修改。

3.3 數(shù)據(jù)質(zhì)量實時Check

數(shù)據(jù)生產(chǎn)在交付之前一般會對數(shù)據(jù)進行校驗，由于大數(shù)據(jù)生產(chǎn)的過程比較冗長，如果在后期輸出數(shù)據(jù)再進行質(zhì)量校驗，往往發(fā)現(xiàn)問題比較滯后。所以在數(shù)據(jù)的階段性交付過程就可以對數(shù)據(jù)進行核驗，可以比較早的對數(shù)據(jù)的問題進行干預(yù)，保證數(shù)據(jù)交付的可靠及時性。

Check算子：針對數(shù)據(jù)的校驗特點，設(shè)計了專門算子提供質(zhì)量保證。數(shù)據(jù)核驗的方式一般有2種：跟自身歷史比較、跟其他數(shù)據(jù)源進行比較。前者只需要對目標(biāo)數(shù)據(jù)源進行選擇相應(yīng)的SQL或者標(biāo)準(zhǔn)API來獲取當(dāng)前生產(chǎn)窗口的數(shù)據(jù)，然后才去同比、環(huán)比、滑動窗口的均值、左右邊界等方式，時間粒度可以靈活到天、小時、分鐘。如果跟其他數(shù)據(jù)源進行比較則需要對源和目標(biāo)分別進行描述，可以進行嚴格相等、區(qū)間、浮動率等方式比較，應(yīng)用的場景以數(shù)據(jù)交換較多。除了數(shù)據(jù)比較之外，還提供關(guān)鍵性字段類型、精度、寬度的比較，以及對空置率、重復(fù)率、區(qū)分度的統(tǒng)計報表產(chǎn)出，比較直觀的查看數(shù)據(jù)的稀疏和分布。

整體和抽樣：針對于其他數(shù)據(jù)源進行比較的方式，常規(guī)的是通過宏觀的字段抽樣的Count方式條數(shù)比較，也可以通過對數(shù)據(jù)類型的Sum、Avg的比較，這里需要注意不同引擎的存儲精度略有區(qū)別，盡量選擇整形字段；除此之外也會增加對明細數(shù)據(jù)抽樣的全列的字段比較，這種比較容易發(fā)現(xiàn)字段值的缺失，類型變更等問題。

這里需要說明的是，如果沒有配置Check算子，則認為數(shù)據(jù)生產(chǎn)完就可以進行交付；如果數(shù)據(jù)的樹狀結(jié)構(gòu)中有Check算子，則認為在下一個Check算子之間的所有數(shù)據(jù)生產(chǎn)節(jié)點都默認數(shù)據(jù)可以交付。這樣默認操作是因為數(shù)據(jù)的校驗不一定要面面俱到，否則也會帶來時間上的損耗，一般情況下我們認為只需要在關(guān)鍵性節(jié)點進行核驗就可以了。校驗失敗通過告警的方式中止數(shù)據(jù)ETL過程，后續(xù)可以重試或者人工方式介入處理。

3.4 數(shù)據(jù)血緣關(guān)系

人生哲學(xué)解釋：血緣關(guān)系分析是大數(shù)據(jù)調(diào)度與其他調(diào)度之間的區(qū)分度較大特征之一，主要解決大數(shù)據(jù)的“人生哲學(xué)問題”：我是誰，從哪里來，到哪里去。而這一切的基礎(chǔ)是開放式SQL對數(shù)據(jù)存取的規(guī)范，之后依賴對開放式SQL的解析來完成血緣關(guān)系分析，主要包含數(shù)據(jù)的上游依賴關(guān)系和下游的被依賴關(guān)系，這2個是通常被涉及到的，除此之外還包含第三個特征：計算邏輯或者口徑對外的輸出，鑒于大數(shù)據(jù)在進行計算和挖掘之后數(shù)據(jù)會被推送到不同的業(yè)務(wù)場景使用，會造成相同口徑指標(biāo)不同的計算結(jié)果，當(dāng)被提及計算邏輯時，研發(fā)同學(xué)也無所適從，經(jīng)常需要追根溯源對代碼和過程進行回訪，進而導(dǎo)致無益消耗的增加。

所以計算邏輯輸出也是常規(guī)和減少人力梳理成本的重要特點。

開放式SQL可以對外解釋，數(shù)據(jù)從哪里來，到哪里去的邏輯問題，也會涉及到具體SQL或者API層面的計算口徑，但是這里需要提到之前的【黑盒暴露】和研發(fā)專注開發(fā)ETL的豐富function，黑盒是無法解釋計算邏輯的，但是function卻可以給出入?yún)ⅰ⒊鰠⒌恼f明，讓特征三的提供成本最低。

血緣關(guān)系分析的手法一方面依賴SQL屬主引擎的語法解析，例如Mysql可以使用Alibaba druid、JSqlparser，GreenPlum、Postgresql可以借助JSqlparser，Impala則需要通過impala-frontend進行語法分析，分析的結(jié)果在外賣大數(shù)據(jù)平臺需要精確到單個字段依賴上游的哪些庫表、字段；越是精細越是精細在進行大數(shù)據(jù)回溯的時候就越有針對性，同時也越有利于效率的提高。

在進行大數(shù)據(jù)回溯的時候越有針對性和利于效率的提高。

針對非SQL方式，例如Hbase、ElasticSearch數(shù)據(jù)源的依賴，也會同樣被映射成不同的文檔/表，具體的列簇中的列，source中的key。

總之，數(shù)據(jù)可解釋是血緣關(guān)系存在的價值，血緣關(guān)系同樣和開放式SQL都在ETL的演進中具有里程碑的意義。

3.5 基于表的Transformer演進

在大數(shù)據(jù)調(diào)度中，對用戶最直觀的展示是某個表是否可以被交付，或者更為精確查看表中的字段哪些具備了可以被交付？這樣做是為了讓下游數(shù)據(jù)更好的有選擇性的、細粒度的依賴觸發(fā)動作。所以在大數(shù)據(jù)調(diào)度中會區(qū)分出三類角色，從粗粒度到細粒度分別是：Job、Transformer、operator。


下面解釋下三者的分工和協(xié)作：

任務(wù)（Job）：Job的主要作用是進行數(shù)據(jù)相關(guān)性的統(tǒng)籌，簡單來講是針對表之間、多種數(shù)據(jù)源之間進行協(xié)作的一個統(tǒng)籌，是一個最大粒度的過程，具體調(diào)度的實例化過程都是以Job作為入口，其他2個角色都不具備實例化的能力。這里會區(qū)分出同樣有數(shù)據(jù)之間依賴，但是并不一定在一個執(zhí)行頻次上的任務(wù)，可以采取配置不同的job依賴關(guān)系。

轉(zhuǎn)換（Transformer）：一個轉(zhuǎn)換就代表一個表，單獨把表拿出來，是因為在大數(shù)據(jù)的交付過程，表是一個完整的符號，不如庫的粒度大，也不像字段太精細無法對外完整表述。

算子（operator）：算子是調(diào)度的最細粒度，不可分割。算子的分類根據(jù)應(yīng)用會擴展很多，有控制類型算子，例如啟停算子、分發(fā)算子、Check算子等。也會有針對數(shù)據(jù)操作進行封裝的功能性算子，比如獲取hdfs數(shù)據(jù)推送到mysql，F(xiàn)tp到對象存儲等；針對大數(shù)據(jù)調(diào)度的功能性算子是針對單個字段或者幾個字段的產(chǎn)生，這個完全依賴于數(shù)據(jù)產(chǎn)生的難易程度和組合回溯的相關(guān)性，最終由開放式SQL進行配置，例如其中的一行則認為是對一個算子的功能進行的描述，select字段中的數(shù)據(jù)獲取可以是多個，同樣對應(yīng)的insert中也可以是多個；大數(shù)據(jù)調(diào)度在完成開發(fā)之后，后期的更多運維精力就在算子的豐富。算子的實現(xiàn)會考慮到前面提到的靈活和通用的選擇。

3.6 基于字段精細化回溯

字段級別的回溯，主要依賴2+1的方式完成，前面的2是指血緣關(guān)系+可更新目標(biāo)引擎；通過開放式SQL可以梳理出數(shù)據(jù)的血緣關(guān)系，便于分析出整個鏈條中可以上下游依賴的點和并發(fā)的點。另外的1是指在調(diào)度的圖形化界面中，可以針對一個具體實例化的Job選擇需要回溯的transformer或者某些算子。

同樣，根據(jù)上圖4中的流程，我們走一個具體的實例。圖中標(biāo)識的黑色0/6代表的是開放式SQL中黑盒的部分，這部分對數(shù)據(jù)來說無法解釋的生產(chǎn)過程；三個標(biāo)識圖形2代表的是Check算子，其他圓角方形顏色相同代表有上下游血緣關(guān)系依賴，例如7會依賴上游的1。下面我們了解下幾個場景的回溯：

回溯1：在這種情況下算子1/2/3/4/6會被進行回溯，而算子0和5則不會被執(zhí)行到，同樣因為1后面有緊鄰的check算子2，則1執(zhí)行完，算子7不會馬上被并發(fā)執(zhí)行，因為有一個黑色的算子6。但是在算子2執(zhí)行成功之后，如果能暴露出算子6的依賴和產(chǎn)出關(guān)系，算子7就可以被執(zhí)行，不需要等待算子3/4/6的執(zhí)行完成。所以節(jié)約了一定的時間。其他場景也是類似

回溯Transformer2，這種場景算子7和算子9會同時觸發(fā)執(zhí)行，同樣，如果算子9在完成的情況下，下游transformer3中的11不會被執(zhí)行，因為是非首節(jié)點，但是在算子7執(zhí)行完成之后，算子13和算子10都會被同時調(diào)起。

可更新目標(biāo)引擎是指非SQL On Hadoop的文件解決方案，類似GreenPlum、Hbase、ES都是可以被實時更新。這里不詳細展開。

3.7 信號燈

信號燈在大數(shù)據(jù)分布式調(diào)度中作為一個消息中間件，主要作用是生產(chǎn)者（Producer）在數(shù)據(jù)生產(chǎn)結(jié)束、數(shù)據(jù)質(zhì)量核驗通過等過程對外釋放信號，這里面包含具體的庫表、字段和本批次的數(shù)據(jù)范圍等信息，消費者（Consumer）可以根據(jù)需要監(jiān)聽不同的表主題，來完成后續(xù)的操作。通過信號燈的方式，可以很好的對數(shù)據(jù)下游依賴解耦合，同時信號燈也可以被應(yīng)用在數(shù)據(jù)集市中庫表、字段的數(shù)據(jù)完成情況標(biāo)識，可以讓用戶進行查看，免去了數(shù)據(jù)是否可用，是否交付的交互。

總結(jié)

大數(shù)據(jù)分布式調(diào)度的應(yīng)用場景和ETL的定義過程、數(shù)據(jù)引擎和業(yè)務(wù)場景的需求有著至關(guān)重要的關(guān)聯(lián)，分布式調(diào)度的過程是通過場景化驅(qū)動逐步完善的過程，百度外賣大數(shù)據(jù)的調(diào)度V2.0是滿足了通用的調(diào)度之后，發(fā)現(xiàn)存在的數(shù)據(jù)解釋和細粒度更新延遲等問題之后，開啟了逐步迭代完善過程，后期也期待我們的系統(tǒng)開源的一天。