沐鸣娱乐


        Python开源任务调度管理项目的分析和对比(python 任务 调度 管理)

        任务背景:

         

        上个月领导给我一个模型工程化专项工作,大体内容就是 ,把模型团队交付的项目代码 ,部署到应用环境中,跑出来的结果供系统使用。这也是我最近一直在忙着做的一个事情,天天加班到8、9点 。

         

        不过,这并不是一个从0到1的工作,之前最开始是采用的Django框架搭建起一个服务 ,使用apscheduler 做任务管理,但是没有可视化的监控和预警 。

         

        任务需求 :

         

        在实际生产中,因为业务系统是一个基本投资收益分析的系统,对于基金来说 ,多数的数据分析都是基于季报来的,所以模型运行在一定程度上运行频率并不高。

         

        模型的运行任务大体的分为三块,

         

        1. 数据准备 ,检查数据是否已经下发,模型运行的前置要求
        2. 模型运行,检查模型是否运行完成,中间是否有报错
        3. 模型结果,检查目标结果表是否有模型跑出来的结果

        这三步是具有依赖关系,后者的运行依赖前者运行完成。

         

        理想目标:

         

        在Java中有很多开源的任务管理项目,比如说国产的xxl-job。

         

        地址:https://www.xuxueli.com/xxl-job/ 但是呢,模型相关的内容基本都是Python交付的,偶然还有matlab ,所以期望能找到一个开源的Python任务管理调度项目

         

        开源寻找:

         

        1.Airflow

         

        地址:https://github.com/apache/airflow

         

        Airflow 是一个使用 Python 语言编写的 data pipeline 调度和监控工作流的平台。Airflow 是通过 DAG(Directed acyclic graph 有向无环图)来管理任务流程的任务调度工具, 不需要知道业务数据的具体内容,设置任务的依赖关系即可实现任务调度。

         

        这个平台拥有和 Hive、Presto 、MySQL、HDFS 、Postgres 等数据源之间交互的能力 ,并且提供了钩子(hook)使其拥有很好的扩展性。除了一个命令行界面,该工具还提供了一个基于 Web 的用户界面可以可视化管道的依赖关系、监控进度、触发任务等。

        Python开源任务调度管理项目的分析和对比(python 任务 调度 管理)

        airflow架构图

        Python开源任务调度管理项目的分析和对比(python 任务 调度 管理)

        airflow可视化管理页面

         

        总结 :

         

        这么看Airflow是一个很好的解决方案,但是呢,有一个比较尴尬的问题是,Airflow的运行是依赖Linux系统的,可是由于历史原因公司现在的生产上模型是运行在window server环境中,一个巨大的尴尬写在脸上,这么好用的工具因为客观限制无法使用。

         

        2.Django Celery Flower

         

        地址: https://github.com/celery/celery/

         

        Celery 是一个简单 、灵活且可靠的分布式系统,用于处理大量消息,同时为操作提供维护此类系统所需的工具。它是一个专注于实时处理的任务队列,同时也支持任务调度。

         

        Celery本身不含消息服务,它使用第三方消息服务来传递任务 ,目前 ,Celery支持的消息服务有RabbitMQ、Redis甚至是数据库,当然Redis应该是最佳选择。

         

        不像是Airflow,Celery本身也没有可视化页面管理,不过有相配套的可视化管理工具——Flower,地址:https://github.com/mher/flower

         

        Flower 是一个基于 Web 的工具,用于监控和管理 Celery 集群。

         

        Flower 具有以下重要的特性:

         

        • 任务进度和历史
        • 能够显示任务详细信息(参数、开始时间、运行时间等)
        • 图表和统计

        Python开源任务调度管理项目的分析和对比(python 任务 调度 管理)

        Flower 管理页面

         

        总结 :

         

        Celery是一个很好的任务调度框架,正如它说的那样,支持大量消息,可以支持到百万级别的量级。但是它用起来的还需要配置消息队列 ,redis或者mq ,使用起来配置比较多,而且需要三方插件的支持。也是解决目前问题的一种方式 ,不过有种高射炮打蚊子的感觉,后面维护也很费劲。

         

        3.Django Apscheduler

         

        地址:https://github.com/jcass77/django-apscheduler

         

        Apscheduler是Python的第三方库 ,提供了基于日期 、固定时间间隔以及crontab 类型的任务,可以在主程序的运行过程中快速增加新作业或删除旧作业 ,如果把作业存储在数据库中,那么作业的状态会被保存,当调度器重启时,不必重新添加作业,作业会恢复原状态继续执行。

         

        Apscheduler可以当作一个跨平台的调度工具来使用 ,可以作为 linux 系统crontab 工具或 windows 计划任务程序的替换。

         

        相应的在Django中有集成包——django-apscheduler ,它是一个 Django 应用程序,它为 APScheduler 添加了一个轻量级的包装器。它允许使用 Django 的 ORM 在数据库中存储持久作业。

         

        总结:

         

        这是目前正在使用的方式,目前历史上使用的是Django的1.x版本,而且并没有做可视化的管理,Django本身自带了一个admin管理页面 ,这个页面并不能满足所有的需求。

         

        4.JobCenter(Flask Apscheduler)

         

        地址:https://github.com/guomaoqiu/JobCenter

         

        Jobcenter的slogan是Apscheduler的最佳实践,看名字是国人开发的。

        Python开源任务调度管理项目的分析和对比(python 任务 调度 管理)

        Jobcenter的slogan

         

        特点:

         

        • 可视化界面操作
        • 定时任务统一管理
        • 完全完全的Crontab
        • 支持秒级任务
        • 作业任务可搜索、暂停、编辑、删除
        • 作业任务持久化存储、各种不同类型作业动态添加

        Python开源任务调度管理项目的分析和对比(python 任务 调度 管理)

        Jobcenter任务列表

        Python开源任务调度管理项目的分析和对比(python 任务 调度 管理)

        某个Job的日志

         

        Jobcenter是基于Flask和Apscheduler开发的,本质上也是对Apscheduler的封装和使用,不过作者做了一个不错的前端。但列表中编辑功能不可用,也没有在列表操作中接入任务日志查看的功能。

         

        总结:

         

        有句话说,踏破铁鞋无觅处,得来全不费功夫。从目前来看 ,JobCenter的功能仿佛可以实现我的需求 ,本身模型的任务量级也不大 ,在百八十个左右。

         

        倾向选择:

         

        【重点】如果环境是Linux的话,或者可以更改/新建Linux的环境,那么一定要选择的Airflow,这是最佳实践。框架提供的功能和管理都很完善。

         

        如果只能在window机器,在考虑其他的 。

         

        3、4的区别在于web管理的实现框架上,一个是Django ,一个是Flask,两个框架的特点都非常的鲜明。

         

        从目前的工作做下来 ,我个人倾向选择3或者4 。

         

        对于当前的实际情况来说,选择3的优点,是可以基于历史项目升级,部分的功能可以复用(之前是基于Api管理),缺点是需要自主开发可视化的管理 。

         

        选择4的优点,前端功能大部分已经实现了。缺点是还需要根据实际情况做功能改造 ,作者分享的源码中部分功能没有实现 ,看提交,最近的更新是14个月前,看样子维护的不勤快 。

         

        好了,具体怎么选择还得领导决定,或者你有什么更好的开源项目欢迎分享给我。

         

        我是马拉松程序员,可不止代码。

        相关新闻

        联系我们
        联系我们
        分享本页
        返回顶部

          XML地图