| Airflow | Azkaban | Conductor | Oozie | AWS Step函数 | |
|---|---|---|---|---|---|
| 所有者 | Apache （以前是Airbnb） |
Netflix公司 | 阿帕奇 | 亚马逊 | |
| 社区 | 很活跃 | 有点活跃 | 活性 | 活性 | N / A |
| 历史 | 4年 | 7年 | 1.5年 | 8年 | 1.5年 |
| 主要目的 | 通用批处理 | Hadoop作业调度 | 微服务编排 | Hadoop作业调度 | 通用工作流 |
| 流程定义 | Python | 自定义DSL | JSON | XML | JSON |
| 支持单节点 | 是 | 是 | 是 | 是 | N / A |
| 快速演示设置 | 是 | 是 | 是 | 没有 | N / A |
| 支持HA | 是 | 是 | 是 | 是 | 是 |
| 单点故障 | 是 （单一调度程序） |
是 （单个Web和调度程序组合节点） |
没有 | 没有 | 没有 |
| HA额外要求 | Celery / Dask / Mesos + Load Balancer + DB | D B | 负载均衡器（Web节点）+ DB | 负载均衡器（Web节点）+ DB + Zookeeper | 本地人 |
| Cron Job | 是 | 是 | 没有 | 是 | 是 |
| 执行模型 | 推 | 推 | 轮询 | 轮询 | 未知 |
| Rest API触发器 | 是 | 是 | 是 | 是 | 是 |
| 参数化执行 | 是 | 是 | 是 | 是 | 是 |
| 由外部事件触发 | 是 | 没有 | 没有 | 是 | 是 |
| 本机等待任务支持 | 是 | 没有 | 是（需要外部信号） | 没有 | 是 |
| 回填支持 | 是 | 没有 | 没有 | 是 | 没有 |
| 本机Web身份验证 | LDAP /密码 | XML密码 | 没有 | 没有 | 没有 |
| 监控 | 是 | 有限 | 有限 | 是 | 有限 |
| 可扩展性 | 取决于执行程序设置 | 好 | 很好 | 很好 | 很好 |
声明
我不是任何这些引擎的专家，但已经使用了其中的一些（Airflow和Azkaban）并检查了代码，对于其他一些产品，我要么只阅读代码（Conductor）或文档（Oozie / AWS步骤函数），由于大多数是OSS项目，我当然可能错过了某些未记录的功能或社区贡献的插件。如果你发现任何错误，我很乐意更新。
底线：阅读本文时请自行判断。
Airflow
优点
与所有其他解决方案相比，Airflow是一种功能超强的引擎，你不仅可以使用插件来支持各种作业，包括数据处理作业：Hive，Pig（尽管你也可以通过shell命令提交它们），以及通过文件/ db entry / s3来触发的一般流程管理，或者等待来自Web端点的预期输出，但它也提供了一个很好的UI，允许你通过代码/图形检查DAG（工作流依赖性），并监视作业的实时执行。
目前充满活力的社区也可以高度定制Airflow。你可以使用本地执行程序通过单个节点运行所有作业，或通过Celery / Dask / Mesos编排将它们分发到一组工作节点。
缺点
气流本身仍然不是很成熟（实际上Oozie可能是这里唯一的“成熟”引擎），调度程序需要定期轮询调度计划并将作业发送给执行程序，这意味着它将不断地从“盒子”中甩出大量的日志。
由于它通过“滴答”定期轮询工作，你的工作不能保证“实时”安排，随着并发工作数量的增加，这会变得更糟。
同时，由于你有一个集中式调度程序，如果它出现故障或卡住，你的正在运行的作业将不会像执行程序的作业那样受到影响，但是不会安排新的作业了。当你使用HA设置运行时，这尤其令人困惑，其中你有多个Web节点，调度程序，代理（通常是Celery案例中的消息队列），多个执行程序。当调度程序因任何原因而卡住时，你在Web UI中看到的所有任务都在运行，但实际上它们实际上并没有向前运行，而执行程序却高兴地报告它们没问题。换句话说，默认监控仍然远非银弹。
从初看起来，Web UI非常好用，然而，它有时会让新用户感到困惑。我的DAG运行是什么意思，我的任务竟然没有状态？这些图表也不是搜索友好的，更不用说一些功能还远远没有详细记录（尽管文档看起来确实很好，我的意思是，与Oozie相比，后者似乎已经过时了）。
回填设计在某些情况下是好的，但在其他情况下非常容易出错。如果你的cron计划已禁用并且稍后重新启用，那么它会尝试追赶，如果你的工作不是幂等的，那么就会发生真实的无可挽回的事情。
Azkaban
优点
在所有引擎中，Azkaban可能是最容易开箱即用的。UI非常直观且易于使用。调度和REST API工作得很好。
有限的HA设置开箱即用。不需要负载均衡器，因为你只能有一个Web节点。你可以配置它如何选择执行程序节点然后才能将作业推送到它，它通常看起来非常好，只要有足够的容量来执行程序节点，就可以轻松运行数万个作业。
缺点
作为通用编排引擎，它没有非常丰富的功能，但可能不是最初设计的目的，它的优势在于对Hadoop / Pig / Hive的原生支持，尽管你也可以使用命令行实现这些功能，但它本身不能通过Airflow等外部资源触发工作，也不支持工作等待模式。虽然你可以通过java代码/脚本实现比较繁忙的工作，但这会导致资源利用率下降。
与其他文档和配置相比，文档和配置通常有点混乱。它可能不应该推荐为初学者使用，设计很好但是你最好有一个大型数据中心来运行执行程序，因为当执行程序耗尽资源而没有额外的监视功能时，调度会停止。与其他代码相比，整体代码质量有点朝向低端，所以它通常只有在资源不成问题时才能很好地扩展。
设置/设计不是云友好的。你几乎应该拥有稳定的裸机，而不是动态分配具有动态IP的虚拟实例。如果机器消失，调度会“向南飘移”。
监控部分通过JMX可接受（似乎没有记录）。但是，如果你的机器负载很重，它通常不会很好，因为端点可能会卡住。
Conductor
优点
将Conductor引入本次竞赛有点不公平，因为它的真正目的是微服务编排，无论这意味着什么，它的HA模型涉及一定数量的服务器，它们位于负载均衡器后面，将任务放入消息队列中，工作节点将轮询这个队列，这意味着你不太可能遇到停滞的调度。在API参数化执行的帮助下，如果你正确设置负载均衡器/服务发现层，它实际上非常擅长调度和扩展。
缺点
用户界面需要更多的提高，目前监控非常有限。虽然通用调度可能已经足够好了。
这是开箱即用的裸机。甚至没有运行shell脚本的本机支持，尽管通过python实现任务工作者很容易通过提供的示例完成工作。
Oozie
优点
Oozie通过db设置提供了一个看似可靠的HA模型（貌似b / c我没有看到它），它为Hadoop相关工作提供本机支持，因为它是为该生态系统构建的。
缺点
对于通用流程调度而言，不是一个非常好的候选者，因为XML定义对于定义轻量级作业非常冗长和繁琐。
它还需要相当多的外设设置。你需要一个zookeeper集群，一个db，一个负载均衡器，每个节点都需要运行像Tomcat这样的Web应用程序容器。初始设置也需要一些时间，这对初次使用的用户来说是不友好的。
Step函数
优点
亚马逊云的步骤函数是相当新（2016年12月推出），然而，未来似乎很有希望。凭借云平台和lambda函数的HA特性，它几乎感觉它可以轻松地无限扩展（与其他人相比）。
它还为通用工作流处理提供了一些有用的功能，如等待支持和基于输出的动态分支。
它也相当便宜：如果你没有运行成千上万的工作，这可能比运行你自己的集群更好。
缺点
只能由AWS用户使用。如果你还不是其中之一，那就木有办法了。
Lambda需要额外的工作来进行生产级迭代/部署。
没有用户界面（很好，但它实际上只是一个控制台）。因此，如果你需要任何级别的监控，你需要自己使用cloudwatch构建它。