分享嘉賓：張蕤?快手

編輯整理：張德通 Treelab

出品平臺：DataFunTalk

導讀：大數據任務調度系統負責數據領域所有離線任務的編排調度，是數據中臺的重要組成部分。隨著任務量變大，調度系統面臨調度性能變差和穩定性降低等挑戰。本次分享主要講述快手在每日數十萬任務的場景下，如何應對這些挑戰，著重介紹在高性能和高可用等方面的建設經驗。

本文源自張蕤老師在『快手大數據｜數據中臺技術交流會』上的演講，相關視頻回放可用快手APP搜索“快手大數據”觀看。

本次分享包含四個部分：

背景介紹：包括任務調度系統的定位、挑戰與目標、以及快手大數據任務調度系統的發展歷程；

快手大數據任務調度系統整體設計：包括調度模型和系統架構；

任務調度系統的關鍵技術：將聚焦在低調度延遲、高可用和開放能力三部分；

任務調度系統的應用、成果和未來規劃。

01快手任務調度背景對于調度系統，大家應該都不陌生。我們在日常工作中，會碰到很多調度的場景，例如通過定時任務每天發送日報或者選擇合適的負載機器來執行任務。根據側重點不同，調度系統可以分為資源調度系統和任務調度系統。 資源調度系統：主要關注底層物理資源的分配，往往管理著較大的物理集群，為使用者提供良好的資源抽象。常見的資源調度系統包括 Yarn、k8s、mesos 等。 任務調度系統：主要關注任務及時準確地執行，為使用者提供任務定時、工作流調度等能力。常見的任務調度系統包括 Airflow，DolphinScheduler，Azkaban 等。 資源調度系統和任務調度系統并不是對立的，而是協作關系。任務調度系統常常會依賴于資源調度系統來執行任務。本文將聚焦在任務調度系統。

任務調度在各類場景中發揮著重要作用。大數據的原始數據一般是業務庫、服務端日志和客戶端日志，這些原始數據的價值密度是很低的。如果要提煉出高價值的信息，往往需要：

1. 經過數據接入進入大數據系統；

2. 然后經過精心建模，層層加工，生產出高價值的數據；

3. 最后經過數據分發到合適的存儲引擎中，然后通過服務化提供給數據應用，例如數據分析、在線服務、模型訓練等。

在這整個過程中，會有很多任務負責數據的接入、加工和分發。這些任務交織依賴，形成了一個大的有向圖。數據生產的核心，就是需要對這個圖進行統一調度。為此，需要有一個統一的任務調度系統。任務調度系統是大數據生產的核心，它并不是孤立存在的，會依賴于底層的資源如大數據資源和容器資源，并為上層應用如數據開發、ABTest 平臺、指標生產、機器學習等提供服務。

在快手，大數據任務調度系統挑戰主要包括三部分：

任務量大：有數十萬個任務，上百萬條依賴關系；這給任務調度系統的性能帶來了挑戰，大任務量會導致性能惡化。

任務交織依賴：任務之間相互依賴，組成一個大的有向圖。一個任務可能有上萬個上游，也可能有數萬個下游任務。這給任務調度系統的穩定性帶來了挑戰，一個任務的調度出錯有可能導致大面積故障。

場景多樣：調度場景多，執行方式多，任務類型多，給系統的功能帶來了挑戰，要求功能豐富且可擴展。

與這些挑戰對應，目標也包括三部分：

高性能：支持百萬級任務的調度，調度延遲控制在秒級或者毫秒級；

高可用：系統要準時調度，不重不錯，且具有高穩定性，避免造成鏈路數據質量或者數據時效故障；

功能強：具有豐富調度執行方式，具有強大的開放能力，打造豐富的生態體系，為上層應用提供便捷的服務。

縱觀快手大數據任務調度系統的發展歷程，可以分為四個階段。

1. 在 2016 年，整體規模較小，采用當時主流 Airflow 作為任務調度引擎。隨著時間的推移，快手的業務蓬勃發展，任務規模也急速增長，Airflow 性能和穩定性不再能滿足要求。

2. 在 2019 年，為了解決 Airflow 的問題，我們自研了任務調度系統 Kwaiflow，旨在支持百萬級別的任務規模。

3. 在 2020 年，我們升級 Kwaiflow 到 2.0 版本，支持例行、觸發式、補數據、阻斷多個場景，融合質量、安全等數據全生態。

4. 在 2021 下半年，我們開始打造新一代調度系統 Kwaiflow 3.0，以支持秒級調度，支持千萬級任務規模。

在過去的五六年，快手的任務數每年成倍數增長，從數千個增長到當前的數十萬個，接入的平臺數從 0 增長到數十個，用戶當前已覆蓋公司幾乎所有的業務方。

在初期，快手使用 Airflow 當作任務調度引擎，但后來又放棄了。我們為什么會做出這樣的選擇呢？這就需要分析 Airflow 的優點和痛點。Airflow 是以編程方式創建、調度和監控工作流的開源系統。Airflow 具有很多優點，包括：

能力豐富，具有豐富的任務類型，易用的流程控制；

UI 易用，較為方便地進行可視化運維；

組件少易部署，上手難度不大。

這些優點是我們選擇 Airflow 的原因。

但隨著任務規模增大，Airflow 的痛點也很明顯：

性能較差：我們發現，當 Airflow 單集群 Dag 數近 1 萬時，單任務調度延遲 P99 高達 5min，鏈路調度延遲高達數十分鐘，鏈路時效性難以保障。為了滿足業務增長，我們搭建了多個集群，運維成本倍增。

穩定性不足：當時 Airflow Scheduler 沒有 HA，任務執行時環境和資源不隔離，容易 OOM，導致調度故障比較多，年均故障數約 8 個。

集成度低：二次開發成本大，和周邊系統集成度低，開放能力差，難以快速構建生態。

由于這些痛點的存在，我們決定自研任務調度系統。

02快手任務調度整體設計

在 2019 年中旬，我們開始自研任務調度系統 Kwaiflow，并在下半年上線 1.0 版本。

Kwaiflow 是快手通用、高性能、易擴展的分布式工作流調度系統。其設計目標從兩方面考慮。

在功能型目標方面：

場景豐富：支持多場景調度，多種環境執行，支持多樣易擴展的任務類型

運維便捷：可以進行可視化、智能、便捷地運維

便于開放：具有強大的開放能力，易于系統集成，構建統一生態

在非功能型目標方面：

高容量：支持百萬級任務容量

高性能：秒級或者亞秒級調度延遲

高可用：可用性 99.99%，線上問題少，出現時能及時發現快速并處理

在定位上，Kwaiflow 基于大數據體系和其它基礎設施，提供調度、執行等核心能力，同時具有運維、監控報警、智能診斷、開放服務等重要能力，構建調度生態；面向數據處理、流程編排、算法調度和分布式計算等場景。

在調度模型上，Kwaiflow 采用了兩層實體的調度模型：

Task：執行模板，用于執行某一類型的代碼；Task 有很多類型，例如 HiveTask 用于執行 Hive SQL，BashTask 用于執行 Bash 腳本，HivePartitionSensorTask 用于探測 hive 表分區是否存在。

DAG：一系列 Task 的集合，具有調度定時等屬性。

在依賴關系方面，DAG 之間可以相互依賴，既可以同周期依賴，也可以跨周期依賴，還可以有依賴偏移。DAG 內的 Task 之間也可以依賴，由于他們調度屬性一致，所以都為同周期依賴。

一般來講，常見的調度模型除了雙層實體模型外，還有單層實體模型。單層實體模型沒有 DAG 的概念，只有 Task，Task 具有調度屬性，Task 之間相互依賴。兩種模型各有優劣。雙層模型更適合快手的情況，具有更強的表達力，使用場景更廣泛，當然也具有一定的復雜性。

在系統架構上：

API Server 提供各式各樣的接口，負責統一接入。

Scheduler 負責調度，不同的調度場景會有不同類型的調度器，包括例行、觸發式、補數據、阻斷調度器。在例行調度器中，任務實例生成后，會依次經過定時檢測、依賴檢測和資源檢測。如果都通過，會提交到 Queue Service 中。

Queue Service 為帶 ack 機制的消息隊列服務，會有不同的 channel，以便隔離任務。

Worker 負責任務的執行，從屬一個 worker 分組。不同分組的 Worker 消費 Queue Service 中不同 Channel 的任務，根據不同的任務類型進行執行。執行分為本地執行和容器化執行兩種方式，本地執行是指任務實例在 worker 內通過新建進程的方式執行；具有啟動快的特點；容器化執行是指在 k8s 遠程執行用戶代碼，具有資源隔離和環境隔離的特點。

除此之外，還有其它關鍵模塊，包括日志服務、報警服務、事件服務、實例血緣服務等。

03快手任務調度系統關鍵技術1. 關鍵技術：低調度延遲

調度延遲是指理論起調時刻到實際開始運行用戶代碼的時間差。調度延遲是衡量任務調度系統性能的重要指標之一，該指標越小越好。

任務實例從生成，到開始運行用戶代碼，需要經過等待時間就緒、等待依賴就緒、等待資源就緒和準備運行環境四個階段。要有較小的調度延遲，就需要減少各個階段的系統時間損耗。調度延遲的主要因素與處理方案有：

定時器。定時器在探測時間就緒環節起作用，一個精準的、支持百萬級別高吞吐的定時器，對低調度延遲至關重要。優秀的定時器，時間損耗可以控制在毫秒內。

數據庫訪問。任務實例狀態發生變更后，需要對狀態進行持久化。通過索引、讀寫分離、分庫分表等方式，可以將單次數據庫訪問耗時控制在 1 ~ 3ms，總體耗時控制在 10ms 左右 。

狀態轉變。任務實例自生成到運行結束，會經歷多次狀態轉變。狀態轉變高效與否是調度延遲的重要因素。一般來說有兩種辦法：輪詢與事件觸發。我們采用的是事件觸發方式，第一時間感知狀態轉變。通過事件觸發，時間損耗可以控制在毫秒內。

運行環境準備。這個環節主要工作包括加載鏡像、初始化運行環境等。我們主要采用了預加載和鏡像預熱技術。不同的運行環境，時間損耗不一樣，會在亞秒到分鐘不等。

這四個因素中，后兩者相對較復雜，接下來著重介紹狀態轉變和運行環境準備這兩部分。

首先看狀態轉變這個因素。任務從發布，到調度執行完成，會經歷數次或者十數次狀態變化。如何進行快速高效地狀態轉變是一個重要的問題。Kwaiflow 的解決辦法是采用 Akka actor。充分利用了 akka actor 高性能特點。

具體來講：

1. Kwaiflow 的任務從 API Server 發布后，經過 Entry Actor 加載到 DagLoader Actors 中等待時間就緒；

2.?在時間就緒后，由 Instance Generator Actors 生成任務實例，然后進入 Dependency Detector Actor 探測上游依賴就緒情況；

3. 在依賴就緒后，進入 Resource Detector Actor 探測資源就緒情況；

4. 在資源就緒后，任務實例通過 Queue Service 下發到 worker 中。

5. 任務實例在 worker 被接收后，將會由 Processor Actor 執行，執行前后會依次經歷代碼渲染、Prehook、代碼執行、Posthook 四個步驟。

6. 如果執行成功，則流程終止；如果執行失敗，Posthook 會將信息通過 Processor Actor、ResultHandlerActor 傳遞給 scheduler 的 RetryerActor 進行重試操作。

整個流程具有三個特點：

全流程事件觸發：無輪詢，任務發布、調度、執行、重試，均為事件觸發。

高吞吐：采用異步并發的方式，能快速調起大量任務實例

簡單易用：無需使用底層 API 進行鎖和線程管理，專注業務實現。

采用 actor，狀態轉變導致的時間損耗控制在毫秒級別。

接下來我們看運行環境準備這個因素。這和執行場景有關。為了滿足不同的執行場景，Kwaiflow 提供了兩種執行方式：容器化執行和本地執行。

容器化執行：任務實例每次執行前，在 k8s 按需申請容器資源，在容器中執行任務實例，執行完后，及時釋放容器資源。優點是實現了執行時的資源隔離和環境隔離；缺點是每次都需要申請和初始化容器資源，啟動耗時長。容器化執行適合對資源、環境敏感的任務，例如 Bash 任務。為了減少容器化執行的啟動耗時，我們將鏡像分為自定義鏡像和通用鏡像，對通用鏡像進行預熱，提前分發到機器中，減少鏡像下載耗時。通過鏡像預熱，可以將啟動耗時從分鐘級降低到秒級。

本地執行：任務實例在 worker 機中，通過新建進程的方式執行。同一個 worker 機中的所有任務實例共享計算資源和執行環境。優點是啟動耗時短，overhead 小；缺點是資源和環境不隔離，一個任務實例執行異常有可能導致整個 worker 機 crash。本地執行適合對資源、環境不敏感的任務，例如 Hive 和 Sensor 任務。本地執行的啟動耗時一般在亞秒級。

2. 關鍵技術：高可用

高可用對調度系統來說非常重要。為了保障 Kwaiflow 的高可用，我們主要從兩方面進行考慮：系統設計和故障發現處理。在系統設計上，Kwaiflow 可以做到高可靠執行，即任務實例在復雜環境中 Exactly Once 執行，做到不漏，且盡量不重。

對于高可靠執行，常見的故障場景包括組件故障或者組件失聯。例如 scheduler crash、容器化任務與 worker 失聯等。

為了達到高可靠，我們主要從三方面考慮：

Failover 機制方面：通過自動故障轉移和魯棒通信協議，來實現組件的自動容錯。例如 Kwaiflow ?采用主備 Master，多 worker 的設計來避免單點問題；各個組件之間采用魯棒通信協議來避免失聯問題。協議包括 scheduler Executor 通信協議、Executor Runner 通信協議、External Job 通信協議。右圖展示了 Executor Runner 通信協議的主要流程，協議規定了任務提交、正常執行、異常執行、通信失聯的處理辦法，不依賴外部系統的狀態。

避免遺漏執行方面：通過消息 ack 機制，保障消息不丟失；同時通過定期兜底巡檢，保障任務實例不遺漏。

避免重復執行方面：通過狀態機轉移圖，避免不合理狀態轉變；同時通過重試前清理前一個實例，避免重復執行。

高可用方面，還有一個重要的系統設計是分級保障。快手在進行大型活動例如春節、奧運時，整體數據量大幅度增長，局部數據呈數倍增長。但計算資源是有限的，計算資源的增長往往不能匹配數據量的增長，不能讓所有的任務和往常一樣按時產出。這時候我們就需要進行分級保障。

所謂分級保障，就是在資源有限的情況下，讓高優任務得到特權，優先得到執行，優先獲得充足的優質資源，保障產出時間；而低優任務則會被延遲調度執行，分配更少的資源。

在快手，整個離線體系，包括 Kwaiflow、Hive、Yarn、HDFS 等，都具有分級保障的能力。這里介紹 Kwaiflow 的分級保障能力，包括三方面：

Kwaiflow 調度器具有分級調度的能力。Kwaiflow 調度器能感知到資源調度系統的狀態，在資源不足時，Kwaiflow 任務會在調度器排隊，高優任務排在前面，低優任務排在后面；當資源得到釋放時，高優任務優先被調度。

Kwaiflow 的執行器按照不同優先級進行分組。包括三組：P0 執行器組、P1 執行器組以及 P2 P3 執行器組。P0 執行器用于執行最高優先級的 P0 任務，具有充足的 worker，P0 任務實例基本不會在執行器層被限制。對于 P2 P3 分組，在調度高峰期，任務實例很多時，可能存在排隊執行的情況。

Kwaiflow 具有較強的人工管控能力，可以人為地允許或者阻斷某些任務的調度。典型使用場景是在大型活動期間，可以根據預案，對低優先級的任務人為進行延遲調度，保障資源分配給高優任務。

前面主要從系統設計方面介紹了線上故障的自動規避。Kwaiflow 高可用的第二個方面是故障的發現和處理。如果故障發現不及時、處理不迅速，會出現大規模的調度錯誤或者調度延遲故障。在快手調度系統發展的過程中，我們碰到過這樣的大故障，為了避免再次發生，我們建立了完備的監控預案體系。

在監控方面，我們分成使用層、服務層、依賴層三個層次，并劃分監控優先級，采用不同的響應方式。

在故障預案方面，我們有兩類預案：系統故障處理預案用于處理調度系統自身問題；數據異常處理預案用于處理鏈路數據不正確的問題。我們沉淀了多場景的阻斷恢復和補數據工具，能夠在數分鐘內啟動數據恢復。

在演練方面，我們定期對預案進行演練，保證預案的可用性，操作的熟練性。

3. 關鍵技術：開放能力

開放是數據中臺的核心競爭力。只有足夠開放，才能給予使用者自由的發揮空間，滿足更多使用場景；只有足夠開放，才能構建數據生態，提供更豐富的能力。Kwaiflow 提供了多種開放能力：

Kwaiflow 具有開放的 API，支持多語言 SDK，提供了標準化的接入流程、使用手冊和接入 demo。

Kwaiflow 提供了標準的事件。包括任務操作事件、任務實例狀態變更事件、任務實例診斷事件等。根據這些事件，可以完整復現出任務和任務實例的全生命周期。

Kwaiflow 提供了插件化任務類型。開發者可以定義和開發自定義的任務類型，并進行靈活測試、灰度上線和管理。

Kwaiflow 提供了 Hook，可以在用戶代碼運行前后執行。包括執行前的 Prehook 和執行后的 Posthook。常見場景包括用于代碼渲染、前置檢查的 Prehook，以及用于執行后數據質量檢測的 Posthook。

04快手任務調度系統的應用與成果

如果把任務調度系統比作大樓的骨架，那么基于任務調度系統的應用就是裝修完善、適于人工作生活的大廈。通過應用，能更好地體現任務調度系統的價值。在快手，集成開發平臺是任務調度系統的一個典型應用。

集成開發平臺是快手的一站式離線數據開發平臺。它使用 kwaiflow 作為統一的編排與調度系統，構建了各類的數據開發運維等服務，提供了數據查詢、同步、開發、服務化、運維、管理等能力。

該平臺具有三個特點：

一站式：平臺涵蓋離線數據開發的各環節，包括數據接入、數據加工、數據分發和數據服務化。用戶可以方便地進行數據源管理，創建數據接入任務將各種數據源導入到大數據系統中；用戶可以通過智能 IDE 編寫、測試和發布 ETL 任務，對數據進行加工處理，產生高價值的數據；用戶還可以創建數據分發任務，將高價值數據分發到其它存儲引擎中，例如關系型數據庫、非關系型數據庫、緩存系統、OLAP 引擎等。用戶也可以直接通過配置的方式創建服務化 API，為線上系統提供服務。

通用：集成開發平臺能統一運維 Kwaiflow 所有任務，包括任務運維、實例運維、鏈路運維等方式，適合數據開發、定時調度、觸發式調度等場景。

智能：在開發環節，通過智能 IDE，能及時發現代碼問題；在運維環節，通過智能監控、智能診斷，能及時發現任務和鏈路問題，并輔助定位問題原因。

任務調度系統要得到廣泛使用，不僅要有強大的自身能力，更要有豐富的生態體系。在快手，Kwaiflow 和大數據的其它系統深度集成，接入了 Kwaiflow，便可以便捷地使用其它大數據系統的能力。可以說，自身能力和生態體系對 Kwaiflow 來說同等重要。 首先，就自身而言，Kwaiflow 具有強大的調度執行能力。包括多場景調度能力、多樣化的執行能力、易用的運維能力和高可用的特性。 其次，Kwaiflow 具有資源管控能力。接入 Kwaiflow，便可以方便地使用大數據資源和容器資源。 最后，Kwaiflow 無縫集成了其它中臺能力。包括數據質量、數據安全體系、完整準確的任務實例血緣、鏈路元數據、鏈路保障體系。

將從性能、功能和使用情況三個方面介紹 Kwaiflow 的成果。

在性能方面，和 Airflow 相比，有極大的提升：

在規模上，Kwaiflow 初版設計容量為百萬級別任務，當前已有數十萬的任務數，和 Airflow 單集群不超過 1 萬相比，提升了數十倍。

在性能上，Kwaiflow 調度高峰期的調度延遲 P99 小于 5 秒，和 Airflow 5 分鐘相比，有數量級的提升；Kwaiflow 起調速率十數萬每分鐘，和 Airflow 數千每分鐘對比，提升了數十倍；Kwaiflow 運行的并發實例數十數萬萬，和 Airflow 小于1萬相比，提升了十數倍。

在穩定性上，Kwaiflow 可用性為 99.99%， Airflow 則為 99.5%；Kwaiflow 年故障數約 1 個，而 Airflow 年均為 8 個。

在功能方面，Kwaiflow：

具有強大的調度能力，支持多調度場景、支持各種復雜依賴流程編排。

具有靈活的執行方式，豐富易擴展的任務類型。

具有便捷的運維中心，任務、實例、鏈路可視化運維，智能化運維。

具有多種資源管控能力，支持多租戶，可方便使用和管理大數據與容器資源。

全面集成數據中臺能力，包括數據質量與安全體系、血緣、元數據、鏈路保障體系。

在使用情況方面，Kwaiflow：

面向全公司，接入了數據、算法領域數十個平臺，包括指標模型管理平臺、AB 測試平臺、用戶畫像、機器學習平臺等。

面向主站、電商、商業化、海外、游戲等幾乎公司所有業務方。

在未來，Kwaiflow 主要朝著三個方向發展：

更通用化：更好地支持觸發式調度，更復雜的在線流程編排，探索分布式計算。

更高性能：更好地支持秒級調度，支持千萬級規模任務實例，支持大規模觸發式調度。

更豐富的功能：更豐富的容器資源管理能力，完善的自動化測試系統和大規模模擬演練系統，更加快速的部署能力。