正规的扬中网站建设杭州关键词优化外包
目录
为什么需要工作流调度系统
什么是azkaban
azkaban适用场景
azkaban特点
常见的工作流调度系统
azkaban和Ooize特性对比
azkaban的架构
azkaban调度的任务有可能有那些类型
总结
为什么需要工作流调度系统
一个完整的大数据分析系统，必然由很多任务单元 (如数据收集、数据清洗、数据存储、数据分析等) 组成，所有的任务单元及其之间的依赖关系组成了复杂的工作流。复杂的工作流管理涉及到很多问题：
如何定时调度某个任务？
如何在某个任务执行完成后再去执行另一个任务？
如何在任务失败时候发出预警？
…
面对这些问题，工作流调度系统应运而生。Azkaban 就是其中之一。
什么是azkaban
Azkaban是由Linkedin公司推出的一个批量工作流任务调度器，主要用于在一个工作流内以一个特定的顺序运行一组工作和流程，它的配置是通过简单的key:value对的方式，通过配置中的dependencies 来设置依赖关系。Azkaban使用job配置文件建立任务之间的依赖关系，并提供一个易于使用的web用户界面维护和跟踪你的工作流。
azkaban适用场景
根据以上业务场景： （2）任务依赖（1）任务的结果，（3）任务依赖（2）任务的结果，（4）任务依赖（3）任务的结果，（5）任务依赖（4）任务的结果。一般的做法是，先执行完（1）再执行（2），再一次执行（3）（4）（5）。这样的话，整个的执行过程都需要人工参加，并且得盯着各任务的进度。但是我们的很多任务都是在深更半夜执行的，通过写脚本设置crontab执行。其实，整个过程类似于一个有向无环图（DAG）。每个子任务相当于大任务中的一个节点，也就是，我们需要的就是一个工作流的调度器，而Azkaban就是能解决上述问题的一个调度器。
azkaban特点
- 兼容任何版本的Hadoop
- 易于使用的Web用户界面
- 简单的工作流的上传
- 方便设置任务之间的关系
- 调度工作流
- 模块化和可插拔的插件机制
- 认证/授权（权限的工作）
- 能够杀死并重新启动工作流
- 有关失败和成功的电子邮件提醒
- SLA 警报和自动查杀失败任务
- 重试失败的任务
- Azkaban 的设计理念是在保证功能实现的基础上兼顾易用性，其页面风格清晰明朗，下面是其 WEB UI 界面
常见的工作流调度系统
1）简单的任务调度：直接使用crontab实现;
2）复杂的任务调度：开发调度平台或使用现成的开源调度系统，比如Ooize、Azkaban等
azkaban和Ooize特性对比
| 特性 | Hamake | Oozie |
|---|---|---|
| 工作流描述语言 | XML | XML (xPDL based) |
| 依赖机制 | data-driven | explicit |
| 是否要web容器 | NO | YES |
| 进度跟踪 | console/log messages | web page |
| Hadoop job调度支持 | no | YES |
| 运行模式 | command line utility | daemon |
| Pig支持 | yes | yes |
| 事件通知 | no | no |
| 需要安装 | no | yes |
| 支持的hadoop版本 | 0.18+ | 0.20+ |
| 重试支持 | no | workflownode evel |
| 运行任意命令 | yes | yes |
| Amazon EMR支持 | yes | no |
azkaban的架构
azkabanWebServer
azkabanWebServer是整个Azkaban工作流系统的主要管理者，它负责用户登录认证、project管理、定时执行工作流、跟踪工作流执行进度等一系列任务。
azkabanExecutorServer
负责具体的工作流的提交、执行，它们通过MySQL数据库来协调任务的执行。
关系型数据库（MySQL）
存储大部分执行流状态，azkabanWebServer和azkabanExecutorServer都需要访问数据库。
azkaban调度的任务有可能有那些类型
- shell脚本
- java程序
- MR程序
- spark程序
- hive的sql
- python脚本
- sqoop任务
总结
如果工作流不是特别复杂，推荐使用轻量级的 Azkaban，主要有以下原因：
安装方面：Azkaban 3.0 之前都是提供安装包的，直接解压部署即可。Azkaban 3.0 之后的版本需要编译，这个编译是基于 gradle 的，自动化程度比较高；
页面设计：所有任务的依赖关系、执行结果、执行日志都可以从界面上直观查看到；
配置方面：Azkaban Flow 1.0 基于 Properties 文件来定义工作流，这个时候的限制可能会多一点。但是在 Flow 2.0 就支持了 YARM。YARM 语法更加灵活简单，著名的微服务框架 Spring Boot 就采用的 YAML 代替了繁重的 XML。