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 可以為您提供這種靈活性，因為它是一個編排器，並且與系統和提供商無關。