【原创】大数据基础之调度框架

常见调度框架实现方式

开源	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，将中国工人的工作内容和时间告诉日本工人，同时不断将日本工人工作的进展同步给中国工人，所有的变化对领导层都是透明的；