Azkaban与阿里云EMR-数据开发对比结果

背景

目前我司大数据部门使用的 ETL 调度工具是 Apache Azkaban，因为该服务会占用独立的机器，因此考虑迁移到阿里云的 EMR 上，因此在整体迁移之前，我们先做了一下作业配置和工作流调度方面的测试，看看目前 EMR 上的功能能否满足现有的ETL 调度需求。经过几天的文件迁移和工作流调度测试，对两个工具的对比情况进行了整理。

Azkaban与阿里云EMR-数据开发对比结果

Azkaban	阿里云EMR-数据开发
占用独立服务器，独立部署，独立运维	集成在 EMR 中，不需要部署，不需要特运维
代码文件打包成 zip，手动上传	代码文件手动上传到 OSS
一个项目下可以都多个工作流，但是必须在一个 zip 包中，上传后自动解析 flow。flow 之间无法直接依赖。	一个项目可以多个工作流，工作流之间可以互相依赖。
每个 flow 下的 job，支持 hive、shell、spark 等	每个 flow 下的 job，支持 hive、shell、spark 等
sql 文件、作业之间的依赖关系都在 zip 包中，azkaban 自动解析	需要为每个sql 创建一个job 作业，类型是 shell，引用 oss 上的 shell 命令和 sql 脚本：azkaban 上有接近 80 个作业，在 EMR 上就需要创建 80 多个 job 作业； 每个作业都要写 shell 命令； 并为每个作业指定执行队列bi和执行用户 hadoop
一个工作流需要维护一个.flow结尾的配置文件，flow 下的作业的依赖关系都维护在这个文件中，可以通过依赖图看到 job 间的依赖关系。	基于 EMR 上创建好的作业，可以在工作流界面通过拖拽的方式创建工作流；此次测试，按照业务 IM、CDR、DM、SMS、Tickets、UserCenter 等业务分别创建的工作流，因此没有一个全局的依赖关系图
flow 之间无法直接依赖	flow 间可以配置依赖关系
一个flow 有一个可视化的依赖关系图	一个 flow 有可视化图，有依赖关系的 flow 没有可视化依赖图
一个 flow 下的依赖越来越多时，可视化的依赖图会越来越庞大	一个flow 下的依赖越来越多时，可以拆分成小的 flow，flow 之间形成依赖，但是没有可视化的依赖图
正常的调度执行	正常的调度执行
flow调度执行失败后，作业恢复：执行单个作业；快速选择某个作业的父节点执行；快速选择某个作业的子节点执行；快速选择某个作业的全部依赖作业并执行	flow调度执行失败后，作业恢复：一个 flow 失败，可以整个 flow 重新执行，或者每个作业手动去执行；flow 间的依赖导致的失败，需要一个个flow 手动修复

总结

相比 Azkaban，EMR 数据开发下的工作流调度功能太弱，完全不能满足当前的调度需求，因此原计划的从 Azkaban迁移至 EMR 的计划作废，继续使用 Azkaban。