數倉系統

在之前的文章，我們規劃了數倉架構，制定了數倉規範，然後在架構和規範的指導下設計了儲存模型、構建了 ETL 系統。

數倉模型解決了資料儲存問題，ETL 解決了資料同步整合計算問題，而排程解決的是自動化問題。

我們透過配置排程去週期性定時觸發執行各種任務或流程(同步、整合、計算、校驗、測試等)並監控他們的執行情況，及時、保質、自動化的滿足各種資料使用需求。

最後排程還有一個附加的用途，對於新接手的維護專案，我們想要快速瞭解其資料流轉，線上執行的排程任務就是最好的切入點了。

方案一、藉助作業系統或資料庫

這種方式的優勢在於不需要專門安裝配置、非常穩定、使用方便。在一些規模較小的系統非常建議使用。

方案二、自主開發

排程這個事情使用場景特別廣泛，但是每個場景或者每家公司使用的功能有多又少，比如有的只需要能穩定的定時排程即可，有的還需要實現跨伺服器排程、監控告警、流程依賴控制、視覺化配置等等。

可能是感覺市面上可選的工具都不足以滿足個性化的需求，不少公司會選擇自主研發，利用多執行緒和定時器，或者基於一些底層開源工具進行深度封裝。我們之前做對賬系統就是 java 封裝的 quartz。

這裡有篇介紹底層排程工具的文章。需要自主研發的朋友，可以看看 "JavaBoy" 怎麼說：

分散式定時任務排程系統技術選型

方案三、選用排程工具

藉助作業系統或資料庫這種方式穩定性最高，但只適合單一計算場景並且排程任務不是很多的場景。

• 如果所有計算都在同一資料庫內就可以使用資料庫本身的排程。
• 如果所有計算呼叫都能夠集中到同一臺伺服器內完成，我們就可以用作業系統自帶的排程。

自主研發的方式適用於個性化程度很高、排程效能併發要求不太高、或者功能相對少且自身有研發能力的場景。

雖然排程本身不是一個特別難實現的事情，很多公司可能都有過這種經歷。但是想把它做到極致，具備穩定、易用、功能完備、高效能、高併發、高適應性等各方面都不錯的程度，還是很難的。能用和好用/通用之間要走的路還有很多。海豚排程這兩年能夠迅速得到市場認可，但可能大家不知道的是，易觀將其開源之前內部研發迭代了至少五年了，照樣其開源後仍有一部分人覺得不好用呢。

下邊這篇是博哥總結的常見大資料排程系統的介紹，大家可以看一下：

基礎功能：

引數傳遞：複雜的 ETL 任務，可能會有一級任務、二級任務、三級任務等等，必須設定一些引數來支援過期重跑、補數等場景。而且最好設定成外部的引數可以覆蓋內部的(這跟程式開發的邏輯正好相反)，防止開發/測試人員設定的子任務引數上線時候忘記刪除造成不必要的問題。

跨伺服器呼叫：很多 ETL 工具也都具備定時排程和引數傳遞的功能，但跨伺服器呼叫就是排程工具所特有的了。擁有跨伺服器呼叫能力後，可以真正的將整個資料流轉串聯起來，比如我們的資料整合同步任務、數倉內的主體 ETL 任務、對外推送任務，三者經常是分開部署的。

任務編排：正常的任務編排應該在 ETL 系統裡完成，但涉及到跨叢集任務依賴的場景，就必須使用排程工具了。

推薦閱讀：