8

我们在 k8s 中有很多长时间运行的内存/cpu 密集型作业，这些作业在谷歌云平台上的 kubernetes 上使用 celery 运行。但是，我们在扩展/重试/监控/警报/交付保证方面存在很大问题。我们想从 celery 转移到一些更高级的框架。

有一个比较：https ://github.com/argoproj/argo/issues/849但这还不够。

空气流动：

  • 在社区有更好的支持 ~400 vs ~12 个标签，13k 星 vs ~3.5k 星
  • python 定义流的方式感觉比只使用 yamls 更好
  • 作为产品支持 GCP：Cloud Composer
  • 更好的仪表板
  • 一些不错的运营商，例如电子邮件运营商

阿尔戈项目：

  • 对 Kubernetes 的本机支持（我认为这在某种程度上更好）
  • 支持未来可能有用的 CI/CD/事件
  • （可能）更好地支持将结果从一项工作传递到另一项工作（在 Airflow xcom 机制中）

我们的 DAG 并没有那么复杂。我们应该选择哪些框架？

4

1 回答 1

8

惯用的 Airflow 并不是真正设计用于自行执行长时间运行的作业。相反，Airflow 旨在充当促进者在另一个服务中启动计算作业（这由 Operators 完成），同时监控给定计算作业的状态（这由 Sensors 完成）。

给定您的示例，Airflow 中所需的任何计算任务都将由正在使用的给定服务的适当 Operator 启动（Airflow 具有用于简化此操作的 GCP 挂钩），并且适当的 Sensor 将确定任务何时完成并且不再阻塞下游任务依赖在那个操作上。

虽然对 Argoproj 的细节并不十分熟悉，但它似乎不像 Airflow 这样的“调度系统”，而更像是一个用于编排和实际执行大部分计算的系统。

于 2019-07-16T14:46:32.043 回答