AWS Managed Airflow 与 AWS Lambda + Step Functions 与 AWS EKS 上的 Kubeflow

Question

这将是一个相当普遍的问题。我有一个我想实时执行的管道。管道可能会发生突然且不可预测的负载变化，因此可伸缩性（向上和向下）很重要。管道阶段可以打包为 docker 容器，尽管它们不一定以这种方式开始。

我看到了在 AWS 上构建上述管道的三种方法。 1) 我可以编写一个 Airflow DAG 并将 AWS 托管工作流用于 Apache 气流。 2) 我可以使用 AWS 步进函数编写 AWS lambda 管道。 3) 我可以在 AWS EKS 之上编写一个 Kubeflow 管道。

我想这三个选项在成本和可扩展性方面有不同的影响。例如。假设我没有达到 Lambda 的服务配额，在 AWS EKS 中扩展 Kubernetes 集群将比扩展 Lambda 函数慢很多。有人可以评论 AWS 托管 Airflow 的可扩展性吗？它的扩展速度是否比 EKS 快？它与 AWS Lambda 相比如何？

Answer 1

为什么不使用 Airflow 来编排整个管道？ Airflow 可以使用 StepFunctionStartExecutionOperator 或通过编写自定义 Python 函数对 PythonOperator 执行相同操作来调用 Step Function。

似乎此解决方案将是两全其美的解决方案：Airflow 中的真正数据编排、监控和警报（同时保持相当轻量级的 Airflow 实例，因为它是纯编排）以及 AWS Lambda 中的可扩展性和响应能力。

我过去曾在一个非常相似的用例中使用过这种方法，而且效果非常好。此外，如果您将来需要扩展此管道以与其他服务和系统集成，Airflow 可为您提供这种灵活性，因为它是一个编排器，并且与系统和提供商无关。