數據倉庫任務調度系統平臺建設
面對業務應用的不斷加深，異構系統越來越多，響應頻率越來越快，管理水平要求越來越高。越來越大的壓力作用到我們的數據基礎平臺上。除了運行核心業務的平臺外，其它非核心業務應用系統在建設的時候，通常由多個項目單獨立項的方式分批分期建設。有采用各種計算機編程語言實現，有的采用各種數據庫腳本實現，還有采用各種系統批處理腳本來實現。面對各式各樣的作業，與之配套的批量作業調度方式也不盡相同。有的項目為了控制成本，直接通過系統的計劃任務或CronTab等方式實現定時啟動執行。有的項目則采用了第三方ETL工具自帶的調度功能來實現。從具體業務系統到作業系統，再到批量作業調度系統，數據平臺建設者們不可避免面臨著各種挑戰。然而，在大數據時代背景下，我們又希望通過技術手段迅速地去響應市場業務需求。因此，各種業務系統越建越多，技術要求越來越多元化，對管理運維提出了挑戰。響應需求越來越快，對數據平臺性能要求越來越高，並進一步對平臺穩定性提出了挑戰。同時，對原有系統的升級越來越頻繁，帶來了額外的升級維護成本，對系統的維護越來越困難。另外一方面，由於項目的獨立性，在項目建設的時候沒有考慮或很少考慮到對其它項目的影響。導致部分平臺，特別是批量調度平臺重復建設，浪費資源，而且每個作業的運行質量完全由ETL開發人員個人能力決定，具有極大的不可控性。
統一批量調度平臺的重要性
通過科學的項目管理機制固然可以在一定程度上降低項目自身業務系統和作業系統的風險。但由於項目建設的獨立性等因素，建設批量作業調度平臺的風險卻並沒有得到明顯改善。為什麽會出現這種情況，其實是與批量作業調度系統的本質有關系。批量作業調度系統不像其它系統，如作業系統一樣，其本身並不受制於具體業務運行系統。也就是說，它可以是一個與業務完全無關的、獨立的技術運行平臺。它應該滿足如下特性：
1、支持跨平臺調度批量作業：無論是Windows、linux、aix、hp-ux、saloris或者其它虛擬雲環境。都采取相同的方式來統一調度管理。
2、具有企業級特性：支持企業級的網絡技術環境，如多級代理，跨網段，跨域等復雜的分布式網絡環境。還需要支持HA高可靠性以及負載均衡。
3、統一的作業定義
4、完善的調度控制策略：除了支持一般的作業間的串並關系，依賴互斥外，還應支持時間計劃、容錯、循環、自定義條件等其它高級控制策略。
5、全方位監控運維管理：具備批量作業系統重要業務邏輯可視化展示功能。提供流程圖實時監控，多維度統計監控，實時消息事件監控預警。讓管理運維人員及時、清楚地了解到批量系統運行狀況。
6、作業調度分析能力：具備作業及作業流歷史運行日誌、異常日誌查看功能。並對作業為什麽不運行作出準確分析。同時還應具備歷史回放，運行預測等分析功能。
7、全面的人工幹預：能夠手動運行任意作業或作業流的任意分支。以及作業流斷點調試，啟用禁用作業，忽略、中止、重跑作業等。
8、多渠道應用能力
因此，批量調度系統不僅僅是一個統一的批量作業驅動中樞，它還是一個統一的批量作業應用管理平臺。統一的驅動中樞能充分屏蔽各個作業，各個批量系統間的技術差異，並能從全局上釋放更多的時間窗口，成倍提升批量系統的處理能力，保障各個批量系統的穩定性。統一的應用管理能降低系統升級以及整合的風險，提升技術團隊的業務分析能力，進一步提高實施效率，節約更多的人力成本。
統一批量調度平臺建設風險
統一批量調度平臺如此重要，但為什麽企業建設該平臺卻舉步維艱，面臨種種風險呢？
首先一直以來，批量系統從業者們對於作業調度的理解，仍然還存在於ETL軟件裏一個小功能的看法上，很少從全局性，管理性等角度去思考批量系統的重要性：“我寫一些sh腳本就可以把作業調起來，為什麽還要大費周折的采用專門工具，浪費成本不說，學習也費事”；“ETL軟件自帶了調度功能，用起來不是挺好的嘛？而且自己維護起來也不錯。我不覺得一定要采用專門的批量調度工具。”在整個批量系統項目生命周期中，大家通常最關心的是ETL作業的設計。但是ETL工程師是具有流動性的，這樣就決定了每個工程師只能管理自己的調度任務，一旦出現人員流動，新的ETL工程師將會付出極大成本對已有的作業進行維護，同時由於每個ETL工程師精力有限，靠人力進行作業管理的話，每個工程師管理的作業作業將會受到極大限制。
其次，目前市場上專業批量調度產品相對較少，可供選擇面較窄，缺乏足夠的產品橫向比較指標。因此一些大型企業，如中國X行則高價采購了國際更為知名的企業級作業調度工具Control-M。然而X行在實施Control-M的過程中卻發現該軟件十分復雜，要求使用者除了必須具備較高的素質外還要付出高昂的培訓費用，實際的使用效果也不太盡如人意。另外，國內一些所謂的批量調度軟件有很多是以項目的形態發展起來的，其本質上是由多個項目經驗堆積而成。 由於受制於項目自身特點和需求的局限性，使其很難朝著專業的產品方向發展。另外，國內還出現了號稱與領軍者Control-M可以PK的TASKCTL。雖然TASKCTL從產品形態上來看還算不錯，但是其初入市場不久，缺乏足夠的市場檢驗。目前國內最先進的調度系統莫過於淘寶的TBSchedule和當當網的elestic-job，TBSchedule功能強大，在大數據處理方面能夠很好的實現並行和優化策略，滿足了阿裏所有的任務，但是，TBSchedule最大的缺點就是該產品是定時調度系統，為了保證所有任務能在計劃時間內完成，阿裏是采用堆服務器的策略，所以TBSchedule並不適合國內絕大多數中小企業，沒有幾家企業可以像阿裏一樣不計成本，無限制堆加機器。elestic-job也是一個分布式的定時調度系統，同樣也不適合很多中小企業。
其三，有些項目組織者們雖然已經註意到統一調度平臺的重要性，但留給建設統一批量調度系統的資源並不多，缺乏驅動使然。建立統一批量調度平臺涉及到各個項目，各個部門的協調工作，總體上卻沒有一個“領導者”來牽頭建設。有的企業少則5,6個，多則幾十個業務應用的批量系統整合，如果沒有一個良好的溝通協調制度，就很難從全局上把控建設風險。據筆者所知，目前國內銀行業已經有多家企業開始著手全行級統一批量調度平臺的建設，但目前市場上還沒有一個完全成熟的方案可供參考。因此，由誰來牽頭，怎麽選型企業級調度技術產品則是擺在建設者們不得不面臨的全新問題。
其四，數據倉庫調度系統升級成本極高。之前公司使用的的某國外公司的任務調度系統，今年準備將系統升級，帶領團隊在耗費半年時間，終於實現支持定時調度和依賴調度的秒級任務調度系統，本以為大功告成，但是在老系統作業遷移方面遇到了更大的困難，老任務調度系統的作業作業類型多樣，相互之間依賴關系復雜，牽扯部門眾多，每個部門與部門之間的數據也有依賴關系。同時，由於測試環境有限，無法大規模測試。遷作業時即不允許作業失敗，也不允許老系統重跑該作業，同時該作業也要承接老系統作業的依賴關系，一時間項目處於崩潰的邊緣。在嘗試多種方案無法遷移後，最後決定項目重構，添加了很多與老系統交互的模塊，兩系統同時運行，最後雖然遷移成功，但是嚴重影響新系統的效率和穩定性，應該說，新系統並沒有達到預期的效果。
就到這裏，如果大家有更多關於數據倉庫任務調度系統建設的想法，歡迎郵件溝通[email protected]
數據倉庫任務調度系統平臺建設