大神讲解Azkaban VS 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 手动修复