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。


更多精彩内容