首页 > 其他 > 详细

大数据基础之调度框架

时间:2018-12-12 18:19:46      阅读:187      评论:0      收藏:0      [点我收藏+]

常见调度框架实现方式

开源

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

 

大数据基础之调度框架

原文:https://www.cnblogs.com/barneywill/p/10109820.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!