使用 Airflow 管理容器化运行的定时任务有没有什么坑？

直接用 XXL-job 做定时任务管理不行么? 为什么还要引入 Docker ？

airflow 挺好的，就是不太轻量，感觉有些占资源。还有个 perfect 可以看看，没具体用过，可以都搭一下对比对比。https://github.com/PrefectHQ/prefect

airflow 挺好的，但是稍微有点重
重要一点，airflow 用 postgres 做管理数据库，mysql 会不定时崩溃

@PeiXyJ 感谢回复，引入 Docker 是为了方便运行不同语言环境的项目，这些项目本身是 Docker 部署的，有对应的 image 管理，所以相对比较方便。

@David1119 感谢回复，之前用过 airflow 所以会优先考虑 airflow 了，倒是可以对比一下 perfect

@ddkk1112 确实，之前老是碰到一个死锁问题，然后导致 scheduler 挂掉

@ddkk1112 @quanqqqq 感谢回复，嗯预期是使用 postgres 作为数据库的

我们生产上用了五年了，目前规模到大概是每天一万多个任务，我觉得 airflow 作为比较早的方案，随着规模的扩大，会越来越难维护，很重。
现在遇到的困境大概就是日志和告警，
日志方面，可能因为我们是早期版本，airflow 的日志会占用大量 inode ，
然后是告警，因为 airflow 的核心设计，导致状态转移会因为一些重启、重试、失败难以监控，直接导致通过获取日志监控失败，通过扫 airflow 的 instance 表状态转移也不容易监控，除非提高扫描频率，但是会增加数据库压力，可能 binlog 才是唯一的出了（摊手）
最后看你们使用的重不重，
如果不重，独立一个 celery 服务会是一个很好的方案，
如果要管理方便 perfect 和 dagster 会很好，
另外还有些更轻量级的新奇方案 https://github.com/faust-streaming/mode

@Or13rs 感谢回复，很宝贵的经验。 我目前管理的项目规模还不大，觉得上面提到的 Airflow 的问题也还可以接受，总之很感谢分享这些经验，我再调研一下

@Or13rs 我们会在 openshift 上用 airflow 的 kubenetesexecutor 跑各个 batch job ，会有什么坑吗

Airflow 毛病实在太多了，6 年前一个项目用了，除了重量级，一些 bugs 连 Airbnb 自身都无法解决。
Python 代码无法序列化，需要提前打包成 image 进行运行。现在很多已经可以直接序列化代码发送到各个机器运行，比如 Ray ，这种实验性有需要高性能的代码就非常贴切。
状态管理以来本身的 databases ，但这个表设计和 API 又是它们自己定的，无法优化用起来也要迁就。
反应很慢，而且界面也不友好，它的关系依然需要手动定义，所以没有降低复杂度，只是有一个可视化。

如果是单纯的 Python ，我优先考虑 Ray 。Ray 和 Airflow 一样，都有 kubernetes 的 operators ，容器方面交给 k8s 就可以了。
如果是多种语言只是需要一个外层的调度框架，我会优先考虑 Go 生态的。甚至其实自己写也没差，因为可以自己 100% 控制。

@Philippa 感谢回复，很好的建议，我再调研一下。

@kratosmy 我们都没有敢上 K8S 的执行器，怕坑填不上，只是用调度向 K8S 提交计算任务，包括 hive ，spark ，flink 这些类型任务，目前遇到的坑是，K8S 执行任务的可观测性很差，经常出现任务提交和任务执行日志翻半天， 任务一旦故障，告警信息定位和告警触发都是问题

@Or13rs 好吧，但现在都准备跑在 openshift 上了，只能看后面并行的时候能不能解决这些问题