【原創】大數據基礎之調度框架

常見調度框架實現方式

開源	Oozie	成熟穩定可靠，可直接用於生產環境
	Azkaban	單點、簡單粗暴，有兩套獨立的調度實現，必須二次開發纔可用
	Airflow		代碼以及流程配置都是python
本身封裝	基於quartz單機	使用zk來作分佈式控制	經常使用quartz+zk作調度系統
		使用db心跳來作分佈式控制	好比阿里Zeus（3年前再也不開源，還須要作一些二次開發才能用）
	基於quartz分佈式	quartz自己使用db鎖來作分佈式控制

Ps：

• Quartz有兩種部署方式：單機以及分佈式（如今還支持新的TerracottaJobStore），單機因爲使用的RAMJobStore，重啓以後沒辦法自動恢復以前中斷的任務，因此基於單機的封裝主要是兩個點，一個是scheduler分佈式控制，一個是scheduler重啓後的任務自動恢復，這兩點在分佈式中已經實現，因此基於單機的封裝看起來沒有必要；
• azkaban和zeus都是本身提供執行節點（azkaban中是executor server，zeus是worker）來執行任務，而且都是經過啓動本地進程執行任務，這樣會有兩個問題：
  • 調度節點scheduler須要維護可用執行節點executor列表（zeus使用長鏈接，作的更好一些），而且在執行節點executor異常時恢復任務，而且很容易因爲狀態同步不及時形成一些問題，這是一個比較龐大的開銷，oozie徹底不須要這些；
  • 啓動本地進程執行任務，雖然能夠靈活控制任務進程的資源，可是有任務同時重複執行的風險，除非任務自己經過zk來保證不一樣時重複執行；

• zeus相比azkaban，有一點作的很差，是all-in-one，即主從部署在一塊兒，有兩個問題，一個是資源浪費，一個是主從相互影響；

 

	Oozie	Azkaban	Zeus
版本	4.3（5.0Beta）	3.45
高可用性	支持（zk）	不支持（存在單點）	支持（db心跳）
高穩定性	是	未知	未知
功能	豐富	簡單	簡單
界面	Ext2	最好	Gwt
是否須要二次開發	否	是	是
是否須要人工干預	否	是	否
重啓服務器流程自動恢復	是	否	是
是否有任務重複運行風險	否	是	是
代碼質量	高	通常	通常
代碼更新	正常	過於頻繁	中止開源，無人維護
主從分離（任務分配與執行分離）	是	是	否
最小佔用資源	2個server Yarn	1個web server 2個executor server	2個server

 

調度相關術語

任務	Task/Job	一個具體的操做
工做流	Workflow	由多個任務組成
調度	Coordinator	按照條件觸發工做流，好比定時
定義	Definition	描述要作的事情，好比任務定義、工做流定義、調度定義
實例	Instance	定義的一次具體執行，包括執行時間、狀態等

 

調度框架通用抽象

1 任務、工做流、調度

 

 

2 定義、實例

 

3 抽象

l  模型Model分爲三種：任務Task/Job、工做流Workflow、調度Coordinator，一個或多個任務組合成一個工做流，工做流能夠手工觸發，也能夠配置調度來觸發，常見的調度好比定時；

l  定義Definition的每一次執行都是一個實例Instance，實例記錄開始、結束時間、狀態、日誌等；

 

全部的調度框架的抽象是相同或者近似的，因此理論上能夠將調度框架A的任務、工做流、調度定義 翻譯Translate 爲調度框架B的任務、工做流、調度定義，實現調度框架的切換；

 

一個形象的類比是，調度框架A是中國工人，調度框架B是日本工人，中國工人生病了，如今須要增長一個翻譯人員C，將中國工人的工做內容和時間告訴日本工人，同時不斷將日本工人工做的進展同步給中國工人，全部的變化對領導層都是透明的；