一個Batch作業調度系統構思

最近在構思一個作業調度系統(Job scheduling system), 其實作業調度系統也不是什么新東西, 很多大學的超級計算中心和氣象中心都有這種系統, 最典型的開源軟件架構是Torque加Maui, 這兩個軟件都是由Cluster Resources Inc維護的開源軟件, 在維基百科上列出了一堆軟件(http://en.wikipedia.org/wiki/Category:Job_scheduling).

我所考慮的是作業調度系統, 不是面向科學計算, 而是針對金融行業日結月結作業或者DW/BI系統的refresh, 這類作業調度系統和氣象中心的作業調度系統有很大的不同. 具體不同之處, 我就不列了. 這類調度系統的特點是, 作業數量很多, 主要是來回導數據和運行stored procedure. 在我看來, 這些操作, 由大到小可以分為3個層次, Cycle->Batch->Job. 先給出我自己對這3個概念的定義.

Cycle: 一個完整的刷新過程, 比如EOD(日結) refresh, 就可以算作一個cycle

Batch: 每次單獨被調起的刷新過程段, 就是一個batch. 一個Cycle可以包含多個batch, 比如CRM batch和ERP batch.

Job: 一個不能再分解的作業, 比如一個ETL Job.

構思中的系統為Batch級的調度系統, 它將不涉及Cycle級別的管理, 因為, 在我看來Cycle級的管理, 多是來維護Batch之間的依賴關系, 通常一個企業的Batch不會很多, 所以維護起來并不復雜, 可以寫一個簡單的shell, 或者用一些可視化的control flow工具完成, 比如微軟SSIS的 control flow, IBM DataStage(以下有時會簡稱為ds) 的Job Sequence, 或者CA的Autosys來管理. 而Batch內部的調度要比這個復雜得多了去, 需要一個專門的系統來管理.

這個Batch級的調度系統, 具有如下特性:

1. 提供水平擴展能力(即可以動態增加或減少工作節點Node)

2. 提供Load Balance特性(*考慮到LB算法的復雜性, 可先采用一個高效但不準確的算法)

3. 如果某個節點出現故障, 作業將自動轉移到其他節點上運行.

4. 提供出錯重試機制(能做到一定程度的High Availability)

5. 超時告警機制

6. Job調度設置的版本管理功能(這個我認為很重要, 如果Job調度調整錯了, 作為應急, 可以很容易恢復到以前的版本. )

想法由來:

金融行業日結月結的數據量很大, 花費時間一般都很長. 而在DW/BI系統中, 留給DW/BI的刷新窗口往往也不會很大, 同時業務對于DW/BI系統的實時性要求也越來越高了, 除了傳統的EOD batch, 有的還需要mini batch和micro batch. 這時候一個高效可靠的調度就顯得尤為重要了. 另外,在一些大公司中, 往往會使用多種數據庫(SQL Server, Oracle, MySQL), 多種ETL工具(比如SQL Server SSIS,Datastage). 這些都給batch調度帶來了不大不小的困難.

觸發這個構思的最直接的原因, 公司采用了國內一個系統服務商開發的調度系統, 這個系統不太穩定, 而且使用超復雜. 下面是我公司的情況, 故事挺長的, 建議讀者略過.

講個故事

###############
公司以前的DW/BI系統調度是通過Shell腳本來實現的
(簡單講, 就是用Shell來調用datastage的dsjob命令
或者sqlplus), 隨著job越來越多, batch的時間越來
越長, 都快要突破留給DW/BI的時間窗口了.  縮短
batch一個很簡單的方法是,再增加一臺datastage服務
器, 這樣2臺Datastage并行運行, 應該會快一些, 
同時一臺datastage server宕掉后, 如果能將所有
ds job切換到另一臺, 也算做到了高可用性(HA), 
這些shell開發的調度程序難以支持這種需求. 為
此, 公司引進了一國內系統服務商自己研發的產品, 
這里就不點名了, 如果有興趣的話, google 
搜 " 企業ETL服務管理平臺軟件 ", 該產品號稱支持:
* 動態負載均衡(Load Balance)
* 擁有橫向擴展能力(High Scalability)
* 可以進行集群管理
經過一段時間的使用, 發現這個軟件真不咋樣, 
1. 用戶體驗不友好, 不是一般的不友好.
2. 系統穩定性不行, 有幾次無法被自動調起 
  (這有點諷刺意味, 宣稱提供HA特性的系統,
  本身卻不夠穩定)
3. 該軟件是通過不斷掃描(或監聽)外部狀態,
   來啟動batch. 而沒有任何機制, 來實現
   batch暫停, batch終止. 
4. 該軟件的維護起來真困難, 需要多一套配置
  (曰為base配置), 
5. 該軟件權限管理比較別扭, 這將直接影響到
  調度作業修改的流程控制 
另外, 更深一些, 它是假集群, 在某些情形下, 
  會造成很嚴重的后果, 簡單列幾條:
1. 比如在生產環境中, 可以部署2個該軟件服務
   端, 同時只有一個服務端是主服務端(master),
   另一個是standby, 這些服務端通過tcp通訊
   來完成心跳測試的. 很明顯, 這種架構, 
   存在假死現象.  即master端和standby端之間, 
   如果出現網絡異常情況, 這個standby服務端就
   會切換成主服務端, 這時候, 整個環境會有2個
   主服務端, 不敢想象這種情況下調度會是什么
   樣子, 估計調度會亂作一團的. (建議該廠家
   研究一下真正cluster軟件是如果測心跳的, 
   比如SQL Server Cluster或Oracle RAC, 
   其實安裝一下這些系統, 就能猜出一二)
2. 再比如, 開始時由服務端A作為主服務端, 調起
   了Job_1, 未等Job_1結束, 服務端A宕掉, 服務
   端B被切換成主服務端, 這時, Job_1就是一個
   孤兒job, 該Job有可能正常運行結束, 也有可
   能運行失敗. 一旦出現了孤兒job, 該軟件采用
   的是簡單重調方式, 它會再次調起Job_1. 如果
   Job_1是不可重調的, 這可能會引起嚴重的問題. 
3. 另外, 這種宣稱的集群, 其實不應該算作集群. 
    我認為一個集群, 應該是作為一個整體向用戶
    提供計算能力, 從用戶角度看, 集群就像是一個
    單一的計算機. 而該軟件在生產環境中, 可以部
    署多個服務端, 卻又不能提供一個統一的訪問
    渠道來和這幾個服務端通訊.
###############

Job調度模型

本調度框架構思來自于高速公路收費口排隊. 姑且叫做Batch調度之高速公路收費口調度模型. 在講述模型之前, 先做一些假設:
假設1: 有2條京滬高速公路, 不是2車道, 是復線, 比如路R1和路R2, 分別有3個收費口和4個收費口, 也就是說這兩條路的處理能力不一樣. (構建一個多節點的情形, R1節點同時能處理3個Job, 而R2同時能處理4個Job)

假設2: 通向R1收費口的路(gateway), 寬為5米, R1的所有收費口都共用這5米的入口; 通向R2收費口的路寬為6米, (每個節點的處理能力不同)

假設3: 有些收費口只允許小汽車通過, 有的允許大客車和大貨車通過, 有的不限制汽車的類型. (比如SSIS Job只能在windows節點上運行, 而不能再linux上運行)

情景模擬一下, 如果你是一個司機的話, 你是如何選擇收費口呢? 你需要看看你開的是什么車, 哪些收費口允許你的車通過; 如果R1和R2上還有其他車在交費,它們將占用一定的路寬, 你需要再看看你的車寬度, 看看能不能轉鉆過去到達收費口. 如果你沒有喝醉酒, 你應該會選擇一個合適的收費口.

現在春節剛過, 相信不少朋友又一次領略了鐵老大的威武. 在我記憶中, 最氣憤的一次購票經歷是, 有一次在北京轉車, 火車站廣場露天排隊, 好幾個長龍, 我就跟在一個隊伍的后邊排著, 大概排了兩三個小時, 好不容易快到窗口了, 隊伍前面一陣騷亂, 原來這個窗口賣票員要吃午飯, 窗口就這樣關啦. 我和我后面的很多人算是白排了.

構思中的調度系統, 并沒有窗口排隊概念, 而是采用即時任務分派策略(Just-in-time dispatch), 這樣做將比窗口排隊方式好很多. 如果你采用排隊方式, 當某個節點宕掉, 你需要考慮排這個節點上的任務該如何分配到其他節點上, 要做到公平, 算法恐怕會有點復雜.

軟件結構

程序:

1. Batch級的命令行程序(執行啟動/暫停/繼續/終止操作,以及查詢batch的所處狀態)

2. 靜態模型的版本控制工具

常駐進程:

1. Job分派進程

2. 一個類似cron的進程, 不斷掃描event是否可以觸發

3. 測超時的進程

外部需擴展

1. 超時算法由外部程序擴展, 推薦的算法是runtime>max(timeout_threshold,average_time*ratio)

2. 每次Batch啟動時候, 可以一個XML字符串的形式給batch附加一些全局信息, 比如交易日期等等

3. 每個job, 在執行前調命令和執行命令以及執行后調命令, 都給命令附加額外的參數, 這些參數包括, job的所有靜態和動態信息, 以及batch的信息.

操作說明

常見的batch驅動機制包括: 被動被call起來, 定時被call起來, 還有一種情形是, 滿足某個條件后, Batch應該被call起來, (比如, 當FTP文件下載完畢). 目前本調度程序不僅支持第一種情形, 對于后面2種情形, 可以通過定時事件(cron_event)來完成. 定時啟動, 就不說了, 對于對于FTP下載完成等啟動, 也可用cron來擴展, cron任務來監控某個文件是否下載完成(如果它的md5值和源頭那邊一致, 就認為文件傳輸完畢), 待下載完成后, 調用batch.

batch級的操作

1. 啟動一個batch(指定batch級別的Indicator)

2. 暫停一個batch

3. 繼續運行一個batch

4. 強制結束一個batch

5. 強制重新開始一個的batch(或者不提供強制重啟, 提供另一個reset命令, 強制重啟=reset+啟動)

6. 查詢一個Batch的運行狀態

如何一個啟動Batch:

batch_manage run Batch_ID='Batch_ERP' Cycle_No='Cycle_20101215' Frequency='D' BatchIndictor='''<batchIndicator transactionDate='20101215' something='hello' />'''

數據模型

在開始介紹數據模型之前, 先看看一個Job會有什么樣的屬性, 這樣有利于我們更好地管理Job.

首先Job會有一個Batch屬性, 這樣當我們啟動一個batch時候, 就知道我們該call哪些job.

其次, Job運行會有頻率屬性的, 比如job A在天結/周結/月結都需要運行, 而job B只在月結是運行, 顯然一個job可能有一個或多個頻率值.

為了很好的組織Job, 我們引入了Job_Group概念, 作為Job的類型歸類, 比如我們可以有一個Datastage group, 作為所有datastage etl job的歸類, SSIS group 作為所有ssis job的歸類.

數據模型包括4個部分, 分別為Batch定義模型部分, 運行時模型, 運行時歸檔模型, Batch定義歸檔模型.

Batch定義模型是整個系統的基礎, 它定義了Batch級以及Job級別的靜態模型; 運行時模式, 顧名思義, 保存著batch運行時的動態信息, batch結束后, 所有的動態信息被轉存到運行時歸檔模型中. Batch定義歸檔模型, 是考慮到我們需要對Batch調度調整進行版本管理引入的, 也就是保存著Batch定義模型的revise數據.

我手頭上PowerDesigner/ERWin, 甚至連Visio都沒有, 只好用Excel來做建模工作, 所以表的relationship沒有辦法直觀地表達出來, 需要看字段外鍵. 這里只貼出Batch定義模型和運行時模型, 其他2個部分其實僅僅是這2個部分的簡單擴展.

Batch定義模型部分

Node_Static(節點表)

Frequency_Static(頻率表)

Job_Group_Static(job組別)

Batch_Static(Batch主表)

Job_Static (任務主表), 這是一個寬表, 字段很多.

Job_Timeout_Def_Static

Job_Depend_Static,

這個表有一個四態控制字段Control_Flag, Control_Flag=Successful 表示, 前一個job必須運行成功, 才能運行后續job, Control_Flag=Failed, 表示前一個job必須失敗, 才能運行后續job, Control_Flag=Completed, 表示只要前一個job運行結束(不管是成功還是失敗), 后續job都可以運行, Control_Flag=Disable, 表示不考慮這個依賴.