![]() |
1
PeiXyJ 64 天前 ![]() 直接用 XXL-job 做定时任务管理不行么? 为什么还要引入 Docker ?
|
2
David1119 64 天前 ![]() airflow 挺好的,就是不太轻量,感觉有些占资源。还有个 perfect 可以看看,没具体用过,可以都搭一下对比对比。https://github.com/PrefectHQ/prefect
|
3
ddkk1112 64 天前 ![]() airflow 挺好的,但是稍微有点重
重要一点,airflow 用 postgres 做管理数据库,mysql 会不定时崩溃 |
![]() |
4
lvhuiyang OP @PeiXyJ 感谢回复,引入 Docker 是为了方便运行不同语言环境的项目,这些项目本身是 Docker 部署的,有对应的 image 管理,所以相对比较方便。
|
8
Or13rs 64 天前 ![]() 我们生产上用了五年了,目前规模到大概是每天一万多个任务,我觉得 airflow 作为比较早的方案,随着规模的扩大,会越来越难维护,很重。
现在遇到的困境大概就是日志和告警, 日志方面,可能因为我们是早期版本,airflow 的日志会占用大量 inode , 然后是告警,因为 airflow 的核心设计,导致状态转移会因为一些重启、重试、失败难以监控,直接导致通过获取日志监控失败,通过扫 airflow 的 instance 表状态转移也不容易监控,除非提高扫描频率,但是会增加数据库压力,可能 binlog 才是唯一的出了(摊手) 最后看你们使用的重不重, 如果不重,独立一个 celery 服务会是一个很好的方案, 如果要管理方便 perfect 和 dagster 会很好, 另外还有些更轻量级的新奇方案 https://github.com/faust-streaming/mode |
![]() |
9
lvhuiyang OP @Or13rs 感谢回复,很宝贵的经验。 我目前管理的项目规模还不大,觉得上面提到的 Airflow 的问题也还可以接受,总之很感谢分享这些经验,我再调研一下
|
10
kratosmy 63 天前 via iPhone ![]() @Or13rs 我们会在 openshift 上用 airflow 的 kubenetesexecutor 跑各个 batch job ,会有什么坑吗
|
11
Philippa 63 天前 ![]() Airflow 毛病实在太多了,6 年前一个项目用了,除了重量级,一些 bugs 连 Airbnb 自身都无法解决。
Python 代码无法序列化,需要提前打包成 image 进行运行。现在很多已经可以直接序列化代码发送到各个机器运行,比如 Ray ,这种实验性有需要高性能的代码就非常贴切。 状态管理以来本身的 databases ,但这个表设计和 API 又是它们自己定的,无法优化用起来也要迁就。 反应很慢,而且界面也不友好,它的关系依然需要手动定义,所以没有降低复杂度,只是有一个可视化。 如果是单纯的 Python ,我优先考虑 Ray 。Ray 和 Airflow 一样,都有 kubernetes 的 operators ,容器方面交给 k8s 就可以了。 如果是多种语言只是需要一个外层的调度框架,我会优先考虑 Go 生态的。甚至其实自己写也没差,因为可以自己 100% 控制。 |