[[431516]]

本文轉載自微信公眾號「數(shù)倉與大數(shù)據(jù)」，作者otw30。轉載本文請聯(lián)系數(shù)倉與大數(shù)據(jù)公眾號。

0x00 前言

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

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

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

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

0x01 我接觸過的調度場景

場景一、數(shù)據(jù)開發(fā)

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

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

大數(shù)據(jù)時代的數(shù)據(jù)開發(fā)，即大數(shù)據(jù)開發(fā)，主要是使用大數(shù)據(jù)組件實現(xiàn)業(yè)務需求，可以是離線計算 Hive/Spark 等，也可以是 Spark Streaming/Flink/Kafka 等。

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

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

場景二、對賬系統(tǒng)

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

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

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

場景四、Yarn 任務調度

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

0x02 常見的調度實現(xiàn)方案

方案一、借助操作系統(tǒng)或數(shù)據(jù)庫

這種方式的優(yōu)勢在于不需要專門安裝配置、非常穩(wěn)定、使用方便。在一些規(guī)模較小的系統(tǒng)非常建議使用。

這是 linux 系統(tǒng)自帶的調度，最小調度頻率是分鐘級別，直接觸發(fā)執(zhí)行指定的 Shell，在腳本內實現(xiàn)任務依賴、記錄日志等操作。

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

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

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

方案二、自主開發(fā)

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

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

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

分布式定時任務調度系統(tǒng)技術選型

方案三、選用調度工具

借助操作系統(tǒng)或數(shù)據(jù)庫這種方式穩(wěn)定性最高，但只適合單一計算場景并且調度任務不是很多的場景。

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

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

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

下邊這篇是博哥總結的常見大數(shù)據(jù)調度系統(tǒng)的介紹，大家可以看一下：

大數(shù)據(jù)調度系統(tǒng)選得好,下班回家早;調度用得對,半夜安心睡

0x03 調度的功能需求介紹

基礎功能

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

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

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

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

擴展功能

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

如果還想更進一步，可以考慮實現(xiàn)如下功能：

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

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

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

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

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

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

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

個性化功能

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

0x04 調度的并發(fā)穩(wěn)定性要求

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

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

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

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

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