[[431516]]

本文轉載自微信公眾號「數倉與大數據」，作者otw30。轉載本文請聯系數倉與大數據公眾號。

0x00 前言

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

數倉模型解決了數據存儲問題，ETL 解決了數據同步集成計算問題，而調度解決的是自動化問題。

我們通過配置調度去周期性定時觸發執行各種任務或流程(同步、集成、計算、校驗、測試等)并監控他們的運行情況，及時、保質、自動化的滿足各種數據使用需求。

最后調度還有一個附加的用途，對于新接手的維護項目，我們想要快速了解其數據流轉，線上運行的調度任務就是最好的切入點了。

0x01 我接觸過的調度場景

場景一、數據開發

這是一個非常熱門的招聘崗位。

在之前主要是指數據庫開發，大概的工作內容是基于關系型數據庫(Oracle、DB2、SQL Server 等)通過寫 SQL/存儲過程等來實現業務需求。

大數據時代的數據開發，即大數據開發，主要是使用大數據組件實現業務需求，可以是離線計算 Hive/Spark 等，也可以是 Spark Streaming/Flink/Kafka 等。

在數據倉庫場景，有叫數倉開發/ETL 開發，當然也有很多直接叫數據開發的。大數據時代很少有叫 ETL 開發了，直接就是數據倉庫工程師/大數據開發工程師。

好了，不管叫法怎么變，我們都可以稱自己為數據工程師，我們的工作職責就是使用各種技術去實現業務需求，業務需求多了又都需要周期性的跑數據，這時候就需要配置調度了。

場景二、對賬系統

做為一個企業，跟客戶/供應商之間肯定有不少業務往來，而且很多都是通過各自的信息化系統實現的。比如通過支付寶購買電影票，每月固定日期支付寶跟影院都要進行對賬。我們可以創建各種各樣的對賬任務，然后配置調度去周期性的拉取雙方的購票數據進行比對。

場景三、DMP 人群包自動化生成

這個是我之前做過的一個系統，業務人員通過頁面框選人群，系統后臺自動化離線計算，人群包生成后返回通知。為防止同一時間點啟動過多的計算任務，所有任務統一提交到調度中心，調度中心會根據計算資源負載來決定是執行任務還是等待。對于周期性的人群包生成需求，我們還可以配置定時任務。

場景四、Yarn 任務調度

在大數據集群，Yarn 是一個通用資源管理系統，可為上層應用提供統一的資源管理和調度。當計算任務到來時候，如果空閑資源足夠則立即執行，否則就阻塞等待。

0x02 常見的調度實現方案

方案一、借助操作系統或數據庫

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

這是 linux 系統自帶的調度，最小調度頻率是分鐘級別，直接觸發執行指定的 Shell，在腳本內實現任務依賴、記錄日志等操作。

這是 windows 系統自帶的調度，最小調度頻率也是分鐘級別，直接觸發執行指定的 bat 腳本，在腳本內實現任務依賴、記錄日志等操作，同時該操作 windows 會提供一套可視化頁面來配置查看運行調度任務以及調用日志。

上邊截圖是 Oracle 數據庫自帶的調度。Oracle 數據庫調度分兩個版本，在 Oracle 10g 之前功能還很簡單，只能調用自己的存儲過程。10g 以后還可以調度 shell/bat 腳本，并且配置更方便了。

配置好的調度，其調用日志以及調度計劃，會在一張 Oracle 元數據表中記錄起來。事實上，Oracle 服務自身也有一個自帶的調度程序用來維護數據庫自身。

方案二、自主開發

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

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

這里有篇介紹底層調度工具的文章。需要自主研發的朋友，可以看看 "JavaBoy" 怎么說：

分布式定時任務調度系統技術選型

方案三、選用調度工具

借助操作系統或數據庫這種方式穩定性最高，但只適合單一計算場景并且調度任務不是很多的場景。

• 如果所有計算都在同一數據庫內就可以使用數據庫本身的調度。
• 如果所有計算調用都能夠集中到同一臺服務器內完成，我們就可以用操作系統自帶的調度。

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

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

下邊這篇是博哥總結的常見大數據調度系統的介紹，大家可以看一下：

大數據調度系統選得好,下班回家早;調度用得對,半夜安心睡

0x03 調度的功能需求介紹

基礎功能

定時調用：根據每個任務配置的執行時間點啟動任務，可以是一次性的也可以是周期性的。

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

跨服務器調用：很多 ETL 工具也都具備定時調度和參數傳遞的功能，但跨服務器調用就是調度工具所特有的了。擁有跨服務器調用能力后，可以真正的將整個數據流轉串聯起來，比如我們的數據集成同步任務、數倉內的主體 ETL 任務、對外推送任務，三者經常是分開部署的。

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

擴展功能

滿足了以上四點基礎功能后，基本就能滿足日常的調度需求了。

如果還想更進一步，可以考慮實現如下功能：

可視化配置：所有調度功能配置都通過系統頁面添加和展示。

權限管理：每個人都分配獨立賬號，任務創建時候可以分配只讀或可執行權限給指定的角色。

自動錯誤重試：這里的重試，是針對某些網絡、服務宕機或者計算資源不足等問題造成的錯誤，可以通過自動重試處理。

任務執行情況日志記錄：每一步任務都會記錄運行日志，比如開始時間、結束時間以及ETL程序打印的日志，方便事后檢查。

告警通知：任務失敗后，根據告警規則觸發告警。任務完成后不管成功還是失敗都可以將執行情況告訴指定的人。通知的作用有 2 點：第一，確保任務真的執行了;第二，可以在通知消息體內發送必要的業務數據如運營日報。

任務暫停：該功能我看海豚調度也有實現，可能是在任務開發/測試時候能用到吧。

并行補數：這在計算資源充足的情況下還是很好用的，但要切記：對于前后日期間有依賴的任務不能使用此功能，比如影片的累計票房計算。

個性化功能

比如我們之前的調度工具，即做了調度的事情，也做了 ETL 的事情。因為我們還實現了這幾個功能：數據源連接、SQL 編輯器、字段映射等等。

0x04 調度的并發穩定性要求

對于少量的任務，只需要滿足功能性需求，然后簡單易用即可，但當任務數量多到一定程度，就不得不考慮高并發和穩定性這些需求了。

調度系統不同于計算引擎，不需要考慮算力問題，只需要按時啟動任務，并監控任務的執行情況即可，但當瞬時在線任務過多時候，在線任務的維護以及后續新啟動任務的處理，是設計的重點，我們需要優化程序盡可能的提高瞬時在線任務的個數，同時當后續有新啟動任務的時候考慮放入等待隊列中，以此保證調度的穩定性。

穩定性的另一處保障機制，就是 master 和 worker 的 HA 設計了，當調度節點真的掛掉的時候可以啟動新的節點來自動恢復任務。

最后，如果想進一步了解調度系統的設計，包括架構和功能實現的話，可以關注下 DolpinScheduler ，網上資料很多，熟悉 Java 的朋友也可以下載源碼看看，相比于 Flink/Spark 等大數據組件，海豚調度的代碼還是相對簡單些的。

對 DolpinScheduler 感興趣的，可以點擊閱讀原文直達中文社區，文檔寫的還是很全面的。