大資料開發架構——調度系統的分類決議

一、什么是調度系統

調度系統，更確切地說，作業調度系統（Job Scheduler）或者說作業流調度系統（workflow Scheduler）是任何一個稍微有點規模，不是簡單玩玩的大資料開發平臺都必不可少的重要組成部分，除了Crontab，Quartz這類偏單機的定時調度程式／庫，開源的分布式作業調度系統也有很多，比較知名的比如：oozie，azkaban，chronos，zeus等等，此外，還有包括阿里的TBSchedule，SchedulerX和騰訊的Lhotse，

二、為什么需要調度系統

我們都知道大資料的計算、分析和處理，一般由多個任務單元組成（Hive、Sparksql、Spark、Shell等），每個任務單元完成特定的資料處理邏輯，

多個任務單元之間往往有著強依賴關系，上游任務執行并成功，下游任務才可以執行，比如上游任務結束后拿到 A 結果，下游任務需結合 A 結果才能產出 B 結果，因此下游任務的開始一定是在上游任務成功運行拿到結果之后才可以開始，

而為了保證資料處理結果的準確性，就必須要求這些任務按照上下游依賴關系有序、高效的執行，一個較為基礎的處理方式是：預估出每個任務處理所需時間，根據先后順序，計算出每個任務的執行的起止時間，通過定時跑任務的方式，讓整個系統保持穩定的運行，

一個完整的資料分析任務最少執行一次，在資料量較少，依賴關系較為簡單的低頻資料處理程序中，這種調度方式完全可以滿足需求，然而在企業級場景中，更多的是需要每天執行，如果任務數量較多，在任務啟動的時間計算上就將耗費大量時間，另外如果出現上游任務執行時長超出原定預計時間或者運行例外的問題，上述的處理方式將完全無法應對，也會對人力物力造成重復損耗，因此，對于企業資料開發程序來說，一個完整且高效的作業流調度系統將起到至關重要的作用，

三、調度系統的兩大種類

調度系統分為作業調度系統和資源調度系統兩大類，但很多時候大家往往把這兩類的概念混為一談，

1、資源調度系統

資源調度系統的關注的重點是底層物理資源的分配管理，目標是最大化地利用集群機器的CPU、磁盤、網路等硬體資源，所調配和處理的往往是與業務邏輯沒有直接關聯的諸如通用程式行程這類的物件，

2、作業調度系統

作業調度系統關注的重點是在正確的時間點啟動正確的作業，確保作業按照正常的依賴關系及時準確地執行，資源的利用率通常不是第一關注要點，業務流程的正確性才是最重要的，作業調度系統有時也會考慮負載均衡問題，但保證負載均衡更多的是為了系統自身的健壯性，而資源的合理利用作為一個可以優化的點，往往依托底層的資源調度系統來實作，

那么，為什么市面上會存在這么多的作業調度系統專案，作業調度系統為什么沒有像HDFS、Hive、 HBase 之類的組件那樣形成一個相對 標準化的解決方案呢？歸根結底，還是由作業調度系統的業務復雜性決定的，

一個成熟易用、便于管理和維護的作業調度系統，需要和大量的周邊組件對接，不僅包括各種存盤計算框架，還可能要處理或使用到血緣管理、權限控制、負載流控、監控報警、質量分析等各種服務或事務，這些事務環節，每家公司都有自己的解決方案，所以作業調度系統所處的整體外部環境千差萬別，而且，各公司各種業務流程的定制化需求又進一步加大了環境的差異性，所以，調度系統很難做到既能靈活通用地適配廣大用戶的各種需求，又不太晦澀難用，

市面上現有的各種開源作業調度系統，不是在某些環節、功能上是缺失的，使用和運維的代價很高，需要大量二次開發；就是只針對特定的業務場景，形態簡單，缺乏靈活性；要不就是在一些功能環節上是封閉自成體系的，很難和外部系統進行對接，

那么，理想中的完備作業調度系統，到底都要處理哪些事務呢？要做好這些事務都有哪些困難要克服，有哪些方案可以選擇，市面上的開源調度系統專案又是如何應對這些問題的，下面就讓我和大家一起來探討一 下，

四、作業調度系統的兩大種類

根據實際的功能定位，市面上的作業調度系統主要分為以下兩大類：定時分片類作業調度系統和DAG作業流類作業調度系統，這兩類系統的架構和功能實作通常存在很大的差異，

1、定時分片類作業調度系統

定時分片類系統的方向，重點定位于任務的分片執行場景，這類系統的代表包括TBSchedule、SchedulerX、 Elastic-job、 Saturn，

這種功能定位的作業調度系統，其最早的需求來源和出發點往往是做一個分布式Crontab和Quartz，

一開始各個業務方自成一體，自己搞自己的單機定時任務，隨著越來越多，分散管理的代價越來越高，再加上有些業務隨著資料量的增加，各種定時任務為了提高運行效率，也需要以分布式的方式在多臺機器上并發執行，這時候，分布式分片調度系統也就應運而生了，

這類系統的實際應用場景，往往和日常維護作業或需要定時執行的業務邏輯有一定的關聯，比如需要定時批量清理一批機器的磁盤空間， 需要定時生成一批商品清單，需要定時批量對一批資料建索引， 需要定時對一批用戶發送推評通知等，

這類系統的核心目標基本是以下兩點：

（1）對作業分片邏輯的支持：將一個大的任務拆成多個小任務，分配到不同的服務器上執行，難點在于要做到不漏、不重，保證負載均衡，節點崩潰時自動進行任務遷移等，

（2）高可用的精確定時觸發要求：因為往往涉及實際業務流程的及時性和準確性，所以通常需要保證任務觸發的強實時和可靠性，

所以，負載均衡、彈性擴容、狀態同步和失效轉移通常是這類調度系統在架構設計時重點考慮的特性，

從接入方案和流程上來說，因為要支持分片邏輯和失效轉移等，這類調度系統對所調度的任務通常都是有侵入性要求的，

常見的做法是用戶作業需要依賴相關分片調度系統的客戶端庫函式，擴展一個作業調度類作為作業觸發的入口類，一般還需要接收和處理分片資訊用于對資料進行正確的分片處理，通常還需要實作一些介面用于滿足服務端的管理需求，比如注冊節點、注冊作業、啟動任務、停止任務、匯報狀態等，有些系統還要求作業執行節點常駐守護行程，用于協調本地作業的管理和通信，

2、DAG作業流類調度系統

DAG作業流類調度系統的關注重點：定位于任務的調度依賴關系的正確處理，分片執行的邏輯通常不是系統關注的核心，或者不是系統核心流程的關鍵組成部分，如果某些任務真的關注分片邏輯，往往交給后端集群（比如MR任務自帶分片能力）或具體型別的任務執行后端去實作，

這類系統的代表包括oozie、azkaban、chronos、zeus、 Lhotse, 還有各種大大小小的公有云服務提供的可視化作業流定義系統，

DAG作業流類調度系統所服務的往往是作業繁多、作業之間的流程依賴比較復雜的場景，比如大資料開發平臺的離線數倉報表業務，從資料采集、清洗，到各個層級的報表的匯總運算，再到最后教據匯出到外部業務系統，一個完整的業務流程可能涉及成百上千個相互交叉，依賴關聯的作業，

所以DAG工作流類調度系統關注的重點通常包括以下幾點：

（1）足夠豐富和靈活的依賴觸發機制：比如時間觸發任務、依賴觸發任文混合觸發任務

而依賴觸發任務自身可能還要考慮多親依賴、長短周期依賴(如小時村任務依賴天任務，或者反過來)、依賴范圍判定(比如所依賴任務最后一次成功就可以觸發下游，還是過去一個星期的所有任務都成功才可以觸發下游)、自身歷史任務依賴、串并行觸發機制等，

（2）作業的計劃、變更和執行流水的管理和同步

定時分片類調度系統中固然也要考慮這個需求，但通常相對簡單，而在DAG作業流類調度系統中，因為任務觸發機制的靈活性和作業依賴關系的復雜性，這個需求就尤為重要，需要提供的功能更加復雜，具體的問題解決起來也困難很多，

（3）任務的優先級管理、業務隔離、權限管理

在定時分片類調度系統中，具體執行端的業務在很多情況下本來就是隔離的，注冊了特定業務的節點才會去執行特定的任務，而且業務鏈路一般都比較短，再加上強實時性要求，所以對優先級的管理通常要求也不高，基本靠資源隔離來實作資源的可用，一般不存在競爭資源的問題，權限管理也是一樣的，

而在DAG作業流類調度系統中，往往一大批作業共享資源執行，所以優先級、負載隔離和權限管控的問題也就突顯出來了，

（4）各種特殊流程的處理，比如暫停任務、重刷歷史資料、人工標注失敗或成功、臨時任務和周期任務的協同

這類需求本質上也是業務流程的復雜性帶來的，比如業務邏輯變更、腳本寫錯、上游資料有問題、下游系統掛掉等，而業務之間的網狀關聯性，導致處理問題時需要考慮的因素很多，也就要求處理的手段應足夠靈活強大，

（5）完備的監控報警通知機制

最簡單的有任務失敗報警、超時報警，復雜一點的有流量負載監控、業務進度監控和預測， 如果做得再完善一點，還可以包括業務健康度監控分析、性能優化建議和問題診斷專家系統等，

需要注意的是，這兩類系統的定位目標并不是絕對沖突矛盾的，只不過要同時圓滿地支持這兩類系統的需求，從實作的角度來說是很困難的，因為側重點不同，在架構上多少會對某些方面做些取舍，當前的系統都沒有做到完美的兩者兼顧，但并不代表這兩類系統的實作就一定是不可調和的，好比離線批處理計算框架和流式實時計算框架，長期以來它們各行其道，但是隨著理論和實踐的深入，也開始有依托一種框架統一處理兩類計算業務的可能性出現，

參考自：劉旭暉《大資料平臺架構基礎指南》