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 Lambdas 相比如何？

Answer 1

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

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

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