前言：大數(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ù)庫(kù)操作算子可以包含數(shù)據(jù)庫(kù)驗(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ò)展

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

2.6 觸發(fā)機(jī)制

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

2.7 堵塞機(jī)制

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

2.8 圖形化進(jìn)展查看

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

2.9 報(bào)警

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

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

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

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

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

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

圖2 開放式SQL扇入扇出流程圖

• 主鍵：數(shù)據(jù)必須存在業(yè)務(wù)主鍵或者聯(lián)合主鍵，目的是為了保證數(shù)據(jù)在聚合或者更新的時(shí)候有依據(jù)。主鍵在Nosql的引擎中作為RowKey，在關(guān)系數(shù)據(jù)庫(kù)中作為主鍵，在ES中作為主鍵key。對(duì)于Kudu來講也是主鍵，針對(duì)數(shù)據(jù)的upsert就可以有依據(jù)的進(jìn)行更新或者插入。
• 數(shù)據(jù)列：數(shù)據(jù)列的變更會(huì)稍微復(fù)雜，如果在關(guān)系數(shù)據(jù)庫(kù)中會(huì)涉及到增加、變更列，但是在Hbase、ES中基本不需要主動(dòng)擴(kuò)展列，只需要對(duì)數(shù)據(jù)變更就可以了。
• 分區(qū)字段：對(duì)于事實(shí)表數(shù)據(jù)，在大數(shù)據(jù)量的情況下，為了檢索效率和數(shù)據(jù)存放最優(yōu)，一般會(huì)提供分區(qū)和桶的策略，針對(duì)Hive、Impala、GreenPlum的引擎會(huì)額外增加分區(qū)字段，分區(qū)可以是一級(jí)到多級(jí)，一般業(yè)務(wù)場(chǎng)景下第一分區(qū)為日期，根據(jù)實(shí)際業(yè)務(wù)需求可以變更更細(xì)粒度或者其他業(yè)務(wù)字段。在一般Mysql、Postgresql、Hbase這種引擎中不需要單獨(dú)增加分區(qū)字段。
• 數(shù)據(jù)更新范圍：大數(shù)據(jù)的數(shù)據(jù)交換，一般為了提高效率會(huì)進(jìn)行多批次的并發(fā)處理，這就需要在一批次的數(shù)據(jù)進(jìn)行分割，一般情況下會(huì)按照單一字段的進(jìn)行截取，字段的類型以時(shí)間戳(create_time、update_time)居多，也可以根據(jù)主鍵的key排序后分批次獲取，在源數(shù)據(jù)引擎允許的情況下，按照多批次的并發(fā)query可以做到很好的數(shù)據(jù)獲取，把串行的操作截?cái)喑啥喽蔚牟l(fā);這種在同一個(gè)任務(wù)多時(shí)間批次的情況下也很重要，每個(gè)批次會(huì)界定本批次設(shè)計(jì)數(shù)據(jù)更新的范圍。數(shù)據(jù)更新范圍使用前一般會(huì)獲取本次更新的數(shù)據(jù)量，可以根據(jù)原目標(biāo)引擎單個(gè)批次的最優(yōu)性能計(jì)算出offset。
• 多步驟過程：多步驟顧名思義就是數(shù)據(jù)的準(zhǔn)備不是一蹴而就的，例如在3個(gè)Mysql庫(kù)、Postgresql、Oracle中獲取員工信息，而員工編號(hào)是統(tǒng)一的，最終數(shù)據(jù)在DB2中匯聚在一起，最基礎(chǔ)的步驟是三份數(shù)據(jù)匯入到Oracle中，這就涉及到前面通過key做數(shù)據(jù)的Merge，這里會(huì)涉及到數(shù)據(jù)的插入和更新，但是如果有key存在并且不同數(shù)據(jù)源目標(biāo)數(shù)據(jù)列清楚的情況下，三份數(shù)據(jù)早到和晚到場(chǎng)景都沒有太大區(qū)別。第二步驟則根據(jù)匯總完的數(shù)據(jù)分析出一個(gè)過濾場(chǎng)景下的聚合信息，這步驟的場(chǎng)景作為計(jì)算數(shù)據(jù)源，再次進(jìn)行數(shù)據(jù)的扇出插入結(jié)果。第三步驟可以把第一步的臨時(shí)結(jié)果進(jìn)行刪除。所以在多步驟的場(chǎng)景下數(shù)據(jù)是分步驟完成了匯聚、聚合和刪除。
• 更新類型：百度外賣大數(shù)據(jù)實(shí)踐的開放式SQL場(chǎng)景有Insert(大批明細(xì)場(chǎng)景)、Update(數(shù)據(jù)后續(xù)更新)、Insert Once(聚合結(jié)果插入)、Insert Temp(臨時(shí)結(jié)果緩存)、Delete(善后處理場(chǎng)景)，在這些組合操作類型的場(chǎng)景下，需要在是線上增加一個(gè)執(zhí)行優(yōu)先級(jí)的信息，如果區(qū)分優(yōu)先級(jí)會(huì)按照從前到后的步驟執(zhí)行，如果沒有設(shè)定則可以并發(fā)操作。
• 黑盒暴露操作：黑盒操作是在通過開放式SQL的存取原則情況下，對(duì)無法按照約定規(guī)范操作的情況下實(shí)行的一種妥協(xié)方式，目的有兩個(gè)：一方面要把黑盒對(duì)數(shù)據(jù)依賴過程必須對(duì)外暴漏，這樣是為了后期梳理數(shù)據(jù)血緣關(guān)系提供素材;另一方面通過黑盒來滿足數(shù)據(jù)處理的靈活性，比如對(duì)json負(fù)責(zé)xpath的選擇，集中緩存優(yōu)化方案;黑盒雖然通過規(guī)范暴露了依賴源數(shù)據(jù)，但是也造成了對(duì)外不好解釋數(shù)據(jù)的處理過程，同時(shí)這種黑盒一般針對(duì)表或者多個(gè)字段，精細(xì)化程度不夠。

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

圖3 分布式調(diào)度的演進(jìn)過程

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

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

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

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

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

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

• Check算子：針對(duì)數(shù)據(jù)的校驗(yàn)特點(diǎn)，設(shè)計(jì)了專門算子提供質(zhì)量保證。數(shù)據(jù)核驗(yàn)的方式一般有2種：跟自身歷史比較、跟其他數(shù)據(jù)源進(jìn)行比較。前者只需要對(duì)目標(biāo)數(shù)據(jù)源進(jìn)行選擇相應(yīng)的SQL或者標(biāo)準(zhǔn)API來獲取當(dāng)前生產(chǎn)窗口的數(shù)據(jù)，然后才去同比、環(huán)比、滑動(dòng)窗口的均值、左右邊界等方式，時(shí)間粒度可以靈活到天、小時(shí)、分鐘。如果跟其他數(shù)據(jù)源進(jìn)行比較則需要對(duì)源和目標(biāo)分別進(jìn)行描述，可以進(jìn)行嚴(yán)格相等、區(qū)間、浮動(dòng)率等方式比較，應(yīng)用的場(chǎng)景以數(shù)據(jù)交換較多。除了數(shù)據(jù)比較之外，還提供關(guān)鍵性字段類型、精度、寬度的比較，以及對(duì)空置率、重復(fù)率、區(qū)分度的統(tǒng)計(jì)報(bào)表產(chǎn)出，比較直觀的查看數(shù)據(jù)的稀疏和分布。
• 整體和抽樣：針對(duì)于其他數(shù)據(jù)源進(jìn)行比較的方式，常規(guī)的是通過宏觀的字段抽樣的Count方式條數(shù)比較，也可以通過對(duì)數(shù)據(jù)類型的Sum、Avg的比較，這里需要注意不同引擎的存儲(chǔ)精度略有區(qū)別，盡量選擇整形字段;除此之外也會(huì)增加對(duì)明細(xì)數(shù)據(jù)抽樣的全列的字段比較，這種比較容易發(fā)現(xiàn)字段值的缺失，類型變更等問題。

這里需要說明的是，如果沒有配置Check算子，則認(rèn)為數(shù)據(jù)生產(chǎn)完就可以進(jìn)行交付;如果數(shù)據(jù)的樹狀結(jié)構(gòu)中有Check算子，則認(rèn)為在下一個(gè)Check算子之間的所有數(shù)據(jù)生產(chǎn)節(jié)點(diǎn)都默認(rèn)數(shù)據(jù)可以交付。這樣默認(rèn)操作是因?yàn)閿?shù)據(jù)的校驗(yàn)不一定要面面俱到，否則也會(huì)帶來時(shí)間上的損耗，一般情況下我們認(rèn)為只需要在關(guān)鍵性節(jié)點(diǎn)進(jìn)行核驗(yàn)就可以了。校驗(yàn)失敗通過告警的方式中止數(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對(duì)數(shù)據(jù)存取的規(guī)范，之后依賴對(duì)開放式SQL的解析來完成血緣關(guān)系分析，主要包含數(shù)據(jù)的上游依賴關(guān)系和下游的被依賴關(guān)系，這2個(gè)是通常被涉及到的，除此之外還包含第三個(gè)特征：計(jì)算邏輯或者口徑對(duì)外的輸出，鑒于大數(shù)據(jù)在進(jìn)行計(jì)算和挖掘之后數(shù)據(jù)會(huì)被推送到不同的業(yè)務(wù)場(chǎng)景使用，會(huì)造成相同口徑指標(biāo)不同的計(jì)算結(jié)果，當(dāng)被提及計(jì)算邏輯時(shí)，研發(fā)同學(xué)也無所適從，經(jīng)常需要追根溯源對(duì)代碼和過程進(jìn)行回訪，進(jìn)而導(dǎo)致無益消耗的增加。

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

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

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

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

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

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

3.5 基于表的Transformer演進(jìn)

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

圖4 三者協(xié)作示例

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

• 任務(wù)(Job)：Job的主要作用是進(jìn)行數(shù)據(jù)相關(guān)性的統(tǒng)籌，簡(jiǎn)單來講是針對(duì)表之間、多種數(shù)據(jù)源之間進(jìn)行協(xié)作的一個(gè)統(tǒng)籌，是一個(gè)最大粒度的過程，具體調(diào)度的實(shí)例化過程都是以Job作為入口，其他2個(gè)角色都不具備實(shí)例化的能力。這里會(huì)區(qū)分出同樣有數(shù)據(jù)之間依賴，但是并不一定在一個(gè)執(zhí)行頻次上的任務(wù)，可以采取配置不同的job依賴關(guān)系。
• 轉(zhuǎn)換(Transformer)：一個(gè)轉(zhuǎn)換就代表一個(gè)表，單獨(dú)把表拿出來，是因?yàn)樵诖髷?shù)據(jù)的交付過程，表是一個(gè)完整的符號(hào)，不如庫(kù)的粒度大，也不像字段太精細(xì)無法對(duì)外完整表述。
• 算子(operator)：算子是調(diào)度的最細(xì)粒度，不可分割。算子的分類根據(jù)應(yīng)用會(huì)擴(kuò)展很多，有控制類型算子，例如啟停算子、分發(fā)算子、Check算子等。也會(huì)有針對(duì)數(shù)據(jù)操作進(jìn)行封裝的功能性算子，比如獲取hdfs數(shù)據(jù)推送到mysql，F(xiàn)tp到對(duì)象存儲(chǔ)等;針對(duì)大數(shù)據(jù)調(diào)度的功能性算子是針對(duì)單個(gè)字段或者幾個(gè)字段的產(chǎn)生，這個(gè)完全依賴于數(shù)據(jù)產(chǎn)生的難易程度和組合回溯的相關(guān)性，最終由開放式SQL進(jìn)行配置，例如其中的一行則認(rèn)為是對(duì)一個(gè)算子的功能進(jìn)行的描述，select字段中的數(shù)據(jù)獲取可以是多個(gè)，同樣對(duì)應(yīng)的insert中也可以是多個(gè);大數(shù)據(jù)調(diào)度在完成開發(fā)之后，后期的更多運(yùn)維精力就在算子的豐富。算子的實(shí)現(xiàn)會(huì)考慮到前面提到的靈活和通用的選擇。

3.6 基于字段精細(xì)化回溯

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

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

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

2)回溯Transformer2，這種場(chǎng)景算子7和算子9會(huì)同時(shí)觸發(fā)執(zhí)行，同樣，如果算子9在完成的情況下，下游transformer3中的11不會(huì)被執(zhí)行，因?yàn)槭欠鞘坠?jié)點(diǎn)，但是在算子7執(zhí)行完成之后，算子13和算子10都會(huì)被同時(shí)調(diào)起。

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

3.7 信號(hào)燈

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

總結(jié)

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