我认为这是不可能的。即使您设法将所有必需的依赖项和Airflow本身作为Lambda部署,该服务也有一些 无法改变的硬限制 这将阻止Airflow作为服务运行。例如,Lambda函数的最长运行时间为15分钟,Airflow调度程序必须连续运行。
使用AWS服务,您可以获得与Airflow大致相同的功能: 胶 用于编写ETL工作,以及 StepFunctions 管理他们。
这可能不是一个好主意,但仅在概念证明中,它可能是可行的。
标准的Airflow部署有一个或多个运行的Web服务器。使用我的几个1000个DAG文件,Web服务器的启动时间差不多是20分钟,尽管这已经在我使用的1.10.2和1.8和1.10中得到了改进。
它还有一个调度程序,基本上一直在运行。
最后,如果你有celery执行器,你希望工作节点运行拾取任务。 OTOH如果您有kubernetes执行程序,则调度程序会为排队的工作创建工作区(我认为)。这些也应该始终在运行。
现在,在AWS中,您可以使用所有Airflow的依赖项,配置文件以及可能的填充程序脚本来从S3获取最新的DAG文件。调度程序有一个循环限制参数,所以你可以将它设置为一个循环(或者只有很少的DAG文件,为什么不是50个循环,通常每个文件只有1个)而不是无限循环。然后你可以使用一些外部触发器来定期运行它。假设您知道您只在10分钟内安排DAG,并且您的任务通常需要大约7-9分钟,然后每10分钟触发一次以运行该调度程序,它可能正常工作。将Celery与SQS结合使用,您可以在队列中出现任何内容时将工作任务作为AWS lambda启动。或者使用Kubernetes,您可以保留EKS群集并让调度程序推进工作。
然后棘手的部分最终成为Web服务器。虽然您可以使用EC2或ECS或EKS泊坞窗图像并且只在您需要时启动和停止它,但它确实使用了相当多的资源来构建DAG包;像调度程序;但它只在这样做之后才开始提供请求,所以它根本不适合在AWS Lambda中运行。我的意思是,如果你完全重建了UI,那么大部分都是S3中的静态文件,只有一些请求会触发lambda从DB获取数据,是的,这样就可以了。但是你要运行一个定制的Airflow。
在这一点上,您想知道,如果我在AWS Lambda中有很多需要开发来支持这一点,那么使用RDS和Lambda开发我需要的整个DAG流程但是没有Airflow需要做多少工作?