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

常見調度框架實現方式

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

azkaban實現詳見：https://www.cnblogs.com/barneywill/p/9895130.html

oozie實現詳見：https://www.cnblogs.com/barneywill/p/9895091.html

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，將中國工人的工作內容和時間告訴日本工人，同時不斷將日本工人工作的進展同步給中國工人，所有的變化對領導層都是透明的；