| 占用独立服务器，独立部署，独立运维 |
集成在 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 手动修复 |
