任務背景：

上個月領導給我一個模型工程化專項工作，大體內容就是，把模型團隊交付的項目代碼，部署到應用環(huán)境中，跑出來的結果供系統(tǒng)使用。這也是我最近一直在忙著做的一個事情，天天加班到8、9點。

不過，這并不是一個從0到1的工作，之前最開始是采用的Django框架搭建起一個服務，使用apscheduler 做任務管理，但是沒有可視化的監(jiān)控和預警。

任務需求：

在實際生產中，因為業(yè)務系統(tǒng)是一個基本投資收益分析的系統(tǒng)，對于基金來說，多數(shù)的數(shù)據分析都是基于季報來的，所以模型運行在一定程度上運行頻率并不高。

模型的運行任務大體的分為三塊，

1. 數(shù)據準備，檢查數(shù)據是否已經下發(fā)，模型運行的前置要求
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 調度和監(jiān)控工作流的平臺。Airflow 是通過 DAG（Directed acyclic graph 有向無環(huán)圖）來管理任務流程的任務調度工具， 不需要知道業(yè)務數(shù)據的具體內容，設置任務的依賴關系即可實現(xiàn)任務調度。

這個平臺擁有和 Hive、Presto、MySQL、HDFS、Postgres 等數(shù)據源之間交互的能力，并且提供了鉤子（hook）使其擁有很好的擴展性。除了一個命令行界面，該工具還提供了一個基于 Web 的用戶界面可以可視化管道的依賴關系、監(jiān)控進度、觸發(fā)任務等。

airflow架構圖

airflow可視化管理頁面

總結：

這么看Airflow是一個很好的解決方案，但是呢，有一個比較尷尬的問題是，Airflow的運行是依賴Linux系統(tǒng)的，可是由于歷史原因公司現(xiàn)在的生產上模型是運行在window server環(huán)境中，一個巨大的尷尬寫在臉上，這么好用的工具因為客觀限制無法使用。

2.Django Celery Flower

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

Celery 是一個簡單、靈活且可靠的分布式系統(tǒng)，用于處理大量消息，同時為操作提供維護此類系統(tǒng)所需的工具。它是一個專注于實時處理的任務隊列，同時也支持任務調度。

Celery本身不含消息服務，它使用第三方消息服務來傳遞任務，目前，Celery支持的消息服務有RabbitMQ、Redis甚至是數(shù)據庫，當然Redis應該是最佳選擇。

不像是Airflow，Celery本身也沒有可視化頁面管理，不過有相配套的可視化管理工具——Flower，地址：https://github.com/mher/flower

Flower 是一個基于 Web 的工具，用于監(jiān)控和管理 Celery 集群。

Flower 具有以下重要的特性：

• 任務進度和歷史
• 能夠顯示任務詳細信息（參數(shù)、開始時間、運行時間等）
• 圖表和統(tǒng)計

Flower 管理頁面

總結：

Celery是一個很好的任務調度框架，正如它說的那樣，支持大量消息，可以支持到百萬級別的量級。但是它用起來的還需要配置消息隊列，redis或者mq，使用起來配置比較多，而且需要三方插件的支持。也是解決目前問題的一種方式，不過有種高射炮打蚊子的感覺，后面維護也很費勁。

3.Django Apscheduler

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

Apscheduler是Python的第三方庫，提供了基于日期、固定時間間隔以及crontab 類型的任務，可以在主程序的運行過程中快速增加新作業(yè)或刪除舊作業(yè)，如果把作業(yè)存儲在數(shù)據庫中，那么作業(yè)的狀態(tài)會被保存，當調度器重啟時，不必重新添加作業(yè)，作業(yè)會恢復原狀態(tài)繼續(xù)執(zhí)行。

Apscheduler可以當作一個跨平臺的調度工具來使用，可以作為 linux 系統(tǒng)crontab 工具或 windows 計劃任務程序的替換。

相應的在Django中有集成包——django-apscheduler，它是一個 Django 應用程序，它為 APScheduler 添加了一個輕量級的包裝器。它允許使用 Django 的 ORM 在數(shù)據庫中存儲持久作業(yè)。

總結：

這是目前正在使用的方式，目前歷史上使用的是Django的1.x版本，而且并沒有做可視化的管理，Django本身自帶了一個admin管理頁面，這個頁面并不能滿足所有的需求。

4.JobCenter（Flask Apscheduler）

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

Jobcenter的slogan是Apscheduler的最佳實踐，看名字是國人開發(fā)的。

Jobcenter的slogan

特點：

• 可視化界面操作
• 定時任務統(tǒng)一管理
• 完全完全的Crontab
• 支持秒級任務
• 作業(yè)任務可搜索、暫停、編輯、刪除
• 作業(yè)任務持久化存儲、各種不同類型作業(yè)動態(tài)添加

Jobcenter任務列表

某個Job的日志

Jobcenter是基于Flask和Apscheduler開發(fā)的，本質上也是對Apscheduler的封裝和使用，不過作者做了一個不錯的前端。但列表中編輯功能不可用，也沒有在列表操作中接入任務日志查看的功能。

總結：

有句話說，踏破鐵鞋無覓處，得來全不費功夫。從目前來看，JobCenter的功能仿佛可以實現(xiàn)我的需求，本身模型的任務量級也不大，在百八十個左右。

傾向選擇：

【重點】如果環(huán)境是Linux的話，或者可以更改/新建Linux的環(huán)境，那么一定要選擇的Airflow，這是最佳實踐?？蚣芴峁┑墓δ芎凸芾矶己芡晟?。

如果只能在window機器，在考慮其他的。

3、4的區(qū)別在于web管理的實現(xiàn)框架上，一個是Django，一個是Flask，兩個框架的特點都非常的鮮明。

從目前的工作做下來，我個人傾向選擇3或者4。

對于當前的實際情況來說，選擇3的優(yōu)點，是可以基于歷史項目升級，部分的功能可以復用（之前是基于Api管理），缺點是需要自主開發(fā)可視化的管理。

選擇4的優(yōu)點，前端功能大部分已經實現(xiàn)了。缺點是還需要根據實際情況做功能改造，作者分享的源碼中部分功能沒有實現(xiàn)，看提交，最近的更新是14個月前，看樣子維護的不勤快。

好了，具體怎么選擇還得領導決定，或者你有什么更好的開源項目歡迎分享給我。

我是馬拉松程序員，可不止代碼。