大数据调度系统对比

0.前言

有了数据平台,有了数据仓库,那就需要一个系统来调度和管理数仓的任务,因此调度系统的地位可见之重要。没有工作流调度系统之前,公司里面的任务都是通过 crontab 来定义的,时间长了后会发现很多问题:

  • 大量的crontab任务需要管理;
  • 任务没有按时执行,各种原因失败,需要重试;
  • 多服务器环境下,crontab分散在很多集群上,日志查看不方便。

于是,出现了一些管理crontab任务的调度系统。而在大数据领域,关注的首要重点是在正确的时间点启动正确的作业,确保作业按照正确的依赖关系及时准确的执行。这个时候涌出了大量的调度工具。这也是本篇梳理的原因。

有个形象的说法:

调度选得好,下班回家早;

调度用得对,半夜安心睡。

一、Azkaban

1.1  Azkaban介绍

 Azkaban是由Linkedin开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运行一组工作和流程。Azkaban定义了一种KV文件格式来建立任务之间的依赖关系,并提供一个易于使用的web用户界面维护和跟踪你的工作流。

1.2 Azkaban的特点

  1. Web用户界面。

  2. 方便上传工作流。

  3. 方便设置任务之间的关系。

  4. 调度工作流。

  5. 认证/授权(权限的工作)。

  6. 随时操作(kill,重启)工作流。

  7. 模块化和可插拔的插件机制。

  8. 不同的项目可以归属于不同的空间,而且不同的空间又可以设置不同的权限 多个项目之间是不会产生任何的影响与干扰。

1.3 Azkaban优缺点

优点:简单,上手快

  • 在所有引擎中,Azkaban可能是最容易开箱即用的。UI非常直观且易于使用。调度和REST API工作得很好。

  • 有限的HA设置开箱即用。不需要负载均衡器,因为你只能有一个Web节点。你可以配置它如何选择执行程序节点然后才能将作业推送到它,它通常看起来非常好,只要有足够的容量来执行程序节点,就可以轻松运行数万个作业。

  • Azkaban有较完善的权限控制。

缺点

  • 出现失败的情况:Azkaban会丢失所有的工作流,因为Azkaban将正在执行的workflow状态保存在内存中。

  • 操作工作流:Azkaban使用Web操作,不支持RestApi,Java API操作

  • Azkaban可以直接操作shell语句。在安全性上可能Oozie会比较好。

二、Oozie

大数据调度系统对比_第1张图片

 2.1 Oozie介绍

 Oozie由Cloudera公司贡献给Apache的基于工作流引擎的开源框架,是用于Hadoop平台的开源的工作流调度引擎,是用来管理Hadoop作业,属于web应用程序,由Oozie client和Oozie Server两个组件构成,Oozie Server运行于Java Servlet容器(Tomcat)中的web程序。

2.2 Oozie特点

  1. 实际上Oozie不是仅用来配置多个MR工作流的,它可以是各种程序夹杂在一起的工作流,比如执行一个MR1后,接着执行一个java脚本,再执行一个shell脚本,接着是Hive脚本,然后又是Pig脚本,最后又执行了一个MR2,使用Oozie可以轻松完成这种多样的工作流。使用Oozie时,若前一个任务执行失败,后一个任务将不会被调度。

  2. Oozie的工作流必须是一个有向无环图,实际上Oozie就相当于Hadoop的一个客户端,当用户需要执行多个关联的MR任务时,只需要将MR执行顺序写入workflow.xml,然后使用Oozie提交本次任务,Oozie会托管此任务流。

  3. Oozie定义了控制流节点(Control Flow Nodes)和动作节点(Action Nodes),其中控制流节点定义了流程的开始和结束,以及控制流程的执行路径(Execution Path),如decision,fork,join等;而动作节点包括Haoop map-reduce hadoop文件系统,Pig,SSH,HTTP,eMail和Oozie子流程。

2.3 Oozie优缺点

优点

  • Oozie与Hadoop生态系统紧密结合,提供做种场景的抽象。

  • Oozie有更强大的社区支持,文档。

  • Job提交到hadoop集群,server本身并不启动任何job。

  • 通过control node/action node能够覆盖大多数的应用场景。

  • Coordinator支持时间、数据触发的启动模式。

  • 支持参数化和EL语言定义workflow,方便复用。

  • 结合HUE,能够方便的对workflow查看以及运维,能够完成workflow在前端页面的编辑、提交 能够完成workflow在前端页面的编辑、提交。

  • 支持action之间内存数据的交互。

  • 支持workflow从某一个节点重启。

缺点

  • 对于通用流程调度而言,不是一个非常好的候选者,因为XML定义对于定义轻量级作业非常冗长和繁琐。

  • 它还需要相当多的外设设置。你需要一个zookeeper集群,一个db,一个负载均衡器,每个节点都需要运行像Tomcat这样的Web应用程序容器。初始设置也需要一些时间,这对初次使用的用户来说是不友好的。

三、XXL-JOB

大数据调度系统对比_第2张图片

 3.1 XXL-JOB介绍

 XXL-JOB是一个分布式任务调度平台,其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线,开箱即用。

官网首页:https://www.xuxueli.com

3.2 XXL-JOB特点

  1. 简单:支持通过Web页面对任务进行CRUD操作,操作简单,一分钟上手。

  2. 动态:支持动态修改任务状态、启动/停止任务,以及终止运行中任务,即时生效。

  3. 调度中心HA(中心式):调度采用中心式设计,“调度中心”自研调度组件并支持集群部署,可保证调度中心HA。

  4. 执行器HA(分布式):任务分布式执行,任务”执行器”支持集群部署,可保证任务执行HA。

  5. 注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时,也支持手动录入执行器地址。

  6. 弹性扩容缩容:一旦有新执行器机器上线或者下线,下次调度时将会重新分配任务。

  7. 触发策略:提供丰富的任务触发策略,包括:Cron触发、固定间隔触发、固定延时触发、API(事件)触发、人工触发、父子任务触发。

  8. 调度过期策略:调度中心错过调度时间的补偿处理策略,包括:忽略、立即补偿触发一次等。

  9. 阻塞处理策略:调度过于密集执行器来不及处理时的处理策略,策略包括:单机串行(默认)、丢弃后续调度、覆盖之前调度。

  10. 任务超时控制:支持自定义任务超时时间,任务运行超时将会主动中断任务。

  11. 任务失败重试:支持自定义任务失败重试次数,当任务失败时将会按照预设的失败重试次数主动进行重试;其中分片任务支持分片粒度的失败重试。

  12. 任务失败告警;默认提供邮件方式失败告警,同时预留扩展接口,可方便的扩展短信、钉钉等告警方式。

  13. 路由策略:执行器集群部署时提供丰富的路由策略,包括:第一个、最后一个、轮询、随机、一致性HASH、最不经常使用. 最近最久未使用、故障转移、忙碌转移等。;

  14. 分片广播任务:执行器集群部署时,任务路由策略选择”分片广播”情况下,一次任务调度将会广播触发集群中所有执行器执行一次任务,可根据分片参数开发分片任务。

  15. 动态分片:分片广播任务以执行器为维度进行分片,支持动态扩容执行器集群从而动态增加分片数量,协同进行业务处理;在进行大数据量业务操作时可显著提升任务处理能力和速度。

  16. 故障转移:任务路由策略选择”故障转移”情况下,如果执行器集群中某一台机器故障,将会自动Failover切换到一台正常的执行器发送调度请求。

  17. 任务进度监控:支持实时监控任务进度。

  18. Rolling实时日志:支持在线查看调度结果,并且支持以Rolling方式实时查看执行器输出的完整的执行日志。

  19. GLUE:提供Web IDE,支持在线开发任务逻辑代码,动态发布,实时编译生效,省略部署上线的过程。支持30个版本的历史版本回溯。

  20. 脚本任务:支持以GLUE模式开发和运行脚本任务,包括Shell、Python、NodeJS、PHP、PowerShell等类型脚本。

  21. 命令行任务:原生提供通用命令行任务Handler(Bean任务,”CommandJobHandler”);业务方只需要提供命令行即可。

  22. 任务依赖:支持配置子任务依赖,当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔。

  23. 一致性:“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行。

  24. 自定义任务参数:支持在线配置调度任务入参,即时生效。

  25. 调度线程池:调度系统多线程触发调度运行,确保调度精确执行,不被堵塞。

  26. 数据加密:调度中心和执行器之间的通讯进行数据加密,提升调度信息安全性。

  27. 邮件报警:任务失败时支持邮件报警,支持配置多邮件地址群发报警邮件。

  28. 推送maven中央仓库: 将会把最新稳定版推送到maven中央仓库, 方便用户接入和使用。

  29. 运行报表:支持实时查看运行数据,如任务数量、调度次数、执行器数量等;以及调度报表,如调度日期分布图,调度成功分布图等。

  30. 全异步:任务调度流程全异步化设计实现,如异步调度、异步运行、异步回调等,有效对密集调度进行流量削峰,理论上支持任意时长任务的运行。

  31. 跨语言:调度中心与执行器提供语言无关的 RESTful API 服务,第三方任意语言可据此对接调度中心或者实现执行器。除此之外,还提供了 “多任务模式”和“httpJobHandler”等其他跨语言方案。;

  32. 国际化:调度中心支持国际化设置,提供中文、英文两种可选语言,默认为中文。

  33. 容器化:提供官方docker镜像,并实时更新推送dockerhub,进一步实现产品开箱即用。

  34. 线程池隔离:调度线程池进行隔离拆分,慢任务自动降级进入”Slow”线程池,避免耗尽调度线程,提高系统稳定性。

  35. 用户管理:支持在线管理系统用户,存在管理员、普通用户两种角色。

  36. 权限控制:执行器维度进行权限控制,管理员拥有全量权限,普通用户需要分配执行器权限后才允许相关操作。

四、Airflow

大数据调度系统对比_第3张图片

 4.1 Airflow介绍

Airflow 是一个使用 Python 语言编写的 Data Pipeline 调度和监控工作流的平台。

Airflow 是通过 DAG(Directed acyclic graph 有向无环图)来管理任务流程的任务调度工具,不需要知道业务数据的具体内容,设置任务的依赖关系即可实现任务调度。

这个平台拥有和 Hive、Presto、MySQL、HDFS、Postgres 等数据源之间交互的能力,并且提供了钩子(hook)使其拥有很好地扩展性。除了使用命令行,该工具还提供了一个 WebUI 可以可视化的查看依赖关系、监控进度、触发任务等。

4.2 Airflow特点

  • 分布式任务调度:允许一个工作流的task在多台worker上同时执行。

  • 可构建任务依赖:以有向无环图的方式构建任务依赖关系。

  • task原子性:工作流上每个task都是原子可重试的,一个工作流某个环节的task失败可自动或手动进行重试,不必从头开始任务。

4.3 优缺点

优点

  • 提供了一个很好的UI,允许你通过代码/图形检查DAG(工作流依赖性),并监视作业的实时执行。

  • 高度定制Airflow。

缺点

  • 部署几台集群扩容相对复杂及麻烦。

  • Airflow的调度依赖于crontab命令,调度程序需要定期轮询调度计划并将作业发送给执行程序。

  • 定期轮询工作,你的工作不能保证准时安排。

  • 当任务数量多的时候,容易造成卡死。

五、DolphinScheduler

 5.1 DolphinScheduler介绍

Apache DolphinScheduler(Incubator,原Easy Scheduler)是一个分布式数据工作流任务调度系统,主要解决数据研发ETL错综复杂的依赖关系,而不能直观监控任务健康状态等问题。Easy Scheduler以DAG流式的方式将Task组装起来,可实时监控任务的运行状态,同时支持重试、从指定节点恢复失败、暂停及Kill任务等操作。

作为强大的带有有向无环图(DAG)可视化界面的分布式大数据工作流调度平台,DolphinScheduler解决了复杂的任务依赖关系和简化了数据任务编排的工作。它以开箱即用的、易于扩展的方式将众多大数据生态组件连接到可处理 100,000 级别的数据任务调度系统中来。

5.2 设计特点

一个分布式易扩展的可视化DAG工作流任务调度系统。致力于解决数据处理流程中错综复杂的依赖关系,使调度系统在数据处理流程中开箱即用 其主要目标如下:(https://github.com/apache/dolphinscheduler)

  • 以DAG图的方式将Task按照任务的依赖关系关联起来,可实时可视化监控任务的运行状态。。

  • 支持丰富的任务类型:Shell、MR、Spark、SQL(mysql、postgresql、hive、sparksql),Python,Sub_Process、Procedure等。

  • 支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复,同时支持失败重试/告警、从指定节点恢复失败、Kill任务等操作。

  • 支持工作流优先级、任务优先级及任务的故障转移及任务超时告警/失败

  • 支持工作流全局参数及节点自定义参数设置。

  • 支持资源文件的在线上传/下载,管理等,支持在线文件创建、编辑。

  • 支持任务日志在线查看及滚动、在线下载日志等。

  • 实现集群HA,通过Zookeeper实现Master集群和Worker集群去中心化。

  • 支持对Master/Worker cpu load,memory,cpu在线查看。

  • 支持工作流运行历史树形/甘特图展示、支持任务状态统计、流程状态统计。

  • 支持补数。

  • 支持多租户。

  • 支持国际化。

以上特点简单总结:

  • 高可靠性:去中心化的多Master和多Worker, 自身支持HA功能, 采用任务队列来避免过载,不会造成机器卡死。

  • 简单易用 DAG监控界面,所有流程定义都是可视化,通过拖拽任务定制DAG,通过API方式与第三方系统对接, 一键部署。

  • 丰富的使用场景 支持暂停恢复操作. 支持多租户,更好的应对大数据的使用场景. 支持更多的任务类型,如 spark, hive, mr, python, sub_process, shell。

  • 高扩展性 支持自定义任务类型,调度器使用分布式调度,调度能力随集群线性增长,Master和Worker支持动态上下线。

六、总结

功能 XXL-job DolphinScheduler Azkaban Airflow Oozie
定位 一个轻量级分布式的任务调度框架 解决数据处理流程中错综复杂的依赖关系 为了解决Hadoop的任务依赖关系问题 通用的批量数据处理 管理Hdoop作业(job)的工作流程调度管理系统
任务类型支持 Java 支持传统的shell任务,同时支持大数据平台任务调度:MR、Spark、SQL(mysql、postgresql、hive/sparksql)、python、procedure、sub_process CommandHadoopShellJavaHadoopJavaPigHive等,支持插件式扩展 Python、Bash、HTTP、Mysql等,支持Operator的自定义扩展 统一调度hadoop系统中常见的mr任务启动、Java MR、Streaming MR、Pig、Hive、Sqoop、Spark、Shell等
可视化流程定义 无,可配置任务级联触发 是所有流定时操作都是可视化的,通过拖拽来绘制DAG,配置数据源及资源,同时对于第三方系统,提供api方式的操作。 否,通过自定义DSL绘制DAG并打包上传 否,通过python代码来绘制DAG,使用不便 否,配置相关的调度任务复杂,依赖关系、时间触发、事件触发使用xml语言进行表达
任务监控支持 任务状态、任务类型、重试次数、任务运行机器、可视化变量等关键信息一目了然 只能看到任务状态 不能直观区分任务类型 任务状态、任务类型、任务运行机器、创建时间、启动时间、完成时间等。
自定义任务类型支持 是需要java先开发具体执行器
暂停/恢复/补数 支持暂停、恢复操作 支持暂停、恢复 补数操作 否,只能先将工作流杀死在重新运行 否,只能先将工作流杀死在重新运行 支持启动/停止/暂停/恢复/重新运行:Oozie支持Web,RestApi,Java API操作
高可用支持 支持HA调度中心HA和执行器HA 支持HA去中心化的多Master和多Worker 通过DB支持HA但Web Server存在单点故障风险 通过DB支持HA但Scheduler存在单点故障风险 通过DB支持HA
多租户支持 支持dolphinscheduler上的用户可以通过租户和hadoop用户实现多对一或一对一的映射关系,这对大数据作业的调度是非常重要。
过载处理能力 任务队列机制,轮询 任务队列机制,单个机器上可调度的任务数量可以灵活配置,当任务过多时会缓存在任务队列中,不会操作机器卡死 任务太多时会卡死服务器 任务太多时会卡死服务器 调度任务时可能出现死锁
集群扩展支持 是,新注册执行器即可 是,调度器使用分布式调度,整体的调度能力会随集群的规模线性正常,Master和Worker支持动态上下线 是-只Executor水平扩展 是-只Executor水平扩展

参考资料:公众号(大数据左右手)-大数据调度系统选得好,下班回家早;调度用得对,半夜安心睡

你可能感兴趣的:(调度管理,#,对比&选型,调度系统,Azkaban)