導(dǎo)讀：大數(shù)據(jù)任務(wù)調(diào)度系統(tǒng)負(fù)責(zé)數(shù)據(jù)領(lǐng)域所有離線任務(wù)的編排調(diào)度，是數(shù)據(jù)中臺的重要組成部分。隨著任務(wù)量變大，調(diào)度系統(tǒng)面臨調(diào)度性能變差和穩(wěn)定性降低等挑戰(zhàn)。本次分享主要講述快手在每日數(shù)十萬任務(wù)的場景下，如何應(yīng)對這些挑戰(zhàn)，著重介紹在高性能和高可用等方面的建設(shè)經(jīng)驗。

本次分享包含四個部分：

• 背景介紹：包括任務(wù)調(diào)度系統(tǒng)的定位、挑戰(zhàn)與目標(biāo)、以及快手大數(shù)據(jù)任務(wù)調(diào)度系統(tǒng)的發(fā)展歷程；
• 快手大數(shù)據(jù)任務(wù)調(diào)度系統(tǒng)整體設(shè)計：包括調(diào)度模型和系統(tǒng)架構(gòu)；
• 任務(wù)調(diào)度系統(tǒng)的關(guān)鍵技術(shù)：將聚焦在低調(diào)度延遲、高可用和開放能力三部分；
• 任務(wù)調(diào)度系統(tǒng)的應(yīng)用、成果和未來規(guī)劃。

01

快手任務(wù)調(diào)度背景

對于調(diào)度系統(tǒng)，大家應(yīng)該都不陌生。我們在日常工作中，會碰到很多調(diào)度的場景，例如通過定時任務(wù)每天發(fā)送日報或者選擇合適的負(fù)載機器來執(zhí)行任務(wù)。根據(jù)側(cè)重點不同，調(diào)度系統(tǒng)可以分為資源調(diào)度系統(tǒng)和任務(wù)調(diào)度系統(tǒng)。

• 資源調(diào)度系統(tǒng)：主要關(guān)注底層物理資源的分配，往往管理著較大的物理集群，為使用者提供良好的資源抽象。常見的資源調(diào)度系統(tǒng)包括 Yarn、k8s、mesos 等。
• 任務(wù)調(diào)度系統(tǒng)：主要關(guān)注任務(wù)及時準(zhǔn)確地執(zhí)行，為使用者提供任務(wù)定時、工作流調(diào)度等能力。常見的任務(wù)調(diào)度系統(tǒng)包括 Airflow，DolphinScheduler，Azkaban 等。

資源調(diào)度系統(tǒng)和任務(wù)調(diào)度系統(tǒng)并不是對立的，而是協(xié)作關(guān)系。任務(wù)調(diào)度系統(tǒng)常常會依賴于資源調(diào)度系統(tǒng)來執(zhí)行任務(wù)。本文將聚焦在任務(wù)調(diào)度系統(tǒng)。

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

1. 經(jīng)過數(shù)據(jù)接入進入大數(shù)據(jù)系統(tǒng)；

2. 然后經(jīng)過精心建模，層層加工，生產(chǎn)出高價值的數(shù)據(jù)；

3. 最后經(jīng)過數(shù)據(jù)分發(fā)到合適的存儲引擎中，然后通過服務(wù)化提供給數(shù)據(jù)應(yīng)用，例如數(shù)據(jù)分析、在線服務(wù)、模型訓(xùn)練等。

在這整個過程中，會有很多任務(wù)負(fù)責(zé)數(shù)據(jù)的接入、加工和分發(fā)。這些任務(wù)交織依賴，形成了一個大的有向圖。數(shù)據(jù)生產(chǎn)的核心，就是需要對這個圖進行統(tǒng)一調(diào)度。為此，需要有一個統(tǒng)一的任務(wù)調(diào)度系統(tǒng)。任務(wù)調(diào)度系統(tǒng)是大數(shù)據(jù)生產(chǎn)的核心，它并不是孤立存在的，會依賴于底層的資源如大數(shù)據(jù)資源和容器資源，并為上層應(yīng)用如數(shù)據(jù)開發(fā)、ABTest 平臺、指標(biāo)生產(chǎn)、機器學(xué)習(xí)等提供服務(wù)。

在快手，大數(shù)據(jù)任務(wù)調(diào)度系統(tǒng)挑戰(zhàn)主要包括三部分：

• 任務(wù)量大：有數(shù)十萬個任務(wù)，上百萬條依賴關(guān)系；這給任務(wù)調(diào)度系統(tǒng)的性能帶來了挑戰(zhàn)，大任務(wù)量會導(dǎo)致性能惡化。
• 任務(wù)交織依賴：任務(wù)之間相互依賴，組成一個大的有向圖。一個任務(wù)可能有上萬個上游，也可能有數(shù)萬個下游任務(wù)。這給任務(wù)調(diào)度系統(tǒng)的穩(wěn)定性帶來了挑戰(zhàn)，一個任務(wù)的調(diào)度出錯有可能導(dǎo)致大面積故障。
• 場景多樣：調(diào)度場景多，執(zhí)行方式多，任務(wù)類型多，給系統(tǒng)的功能帶來了挑戰(zhàn)，要求功能豐富且可擴展。

與這些挑戰(zhàn)對應(yīng)，目標(biāo)也包括三部分：

• 高性能：支持百萬級任務(wù)的調(diào)度，調(diào)度延遲控制在秒級或者毫秒級；
• 高可用：系統(tǒng)要準(zhǔn)時調(diào)度，不重不錯，且具有高穩(wěn)定性，避免造成鏈路數(shù)據(jù)質(zhì)量或者數(shù)據(jù)時效故障；
• 功能強：具有豐富的調(diào)度執(zhí)行方式，具有強大的開放能力，打造豐富的生態(tài)體系，為上層應(yīng)用提供便捷的服務(wù)。

縱觀快手大數(shù)據(jù)任務(wù)調(diào)度系統(tǒng)的發(fā)展歷程，可以分為四個階段。

1. 在 2016 年，整體規(guī)模較小，采用當(dāng)時主流 Airflow 作為任務(wù)調(diào)度引擎。隨著時間的推移，快手的業(yè)務(wù)蓬勃發(fā)展，任務(wù)規(guī)模也急速增長，Airflow 性能和穩(wěn)定性不再能滿足要求。

2. 在 2019 年，為了解決 Airflow 的問題，我們自研了任務(wù)調(diào)度系統(tǒng) Kwaiflow，旨在支持百萬級別的任務(wù)規(guī)模。

3. 在 2020 年，我們升級 Kwaiflow 到 2.0 版本，支持例行、觸發(fā)式、補數(shù)據(jù)、阻斷多個場景，融合質(zhì)量、安全等數(shù)據(jù)全生態(tài)。

4. 在 2021 下半年，我們開始打造新一代調(diào)度系統(tǒng) Kwaiflow 3.0，以支持秒級調(diào)度，支持千萬級任務(wù)規(guī)模。

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

在初期，快手使用 Airflow 當(dāng)作任務(wù)調(diào)度引擎，但后來又放棄了。我們?yōu)槭裁磿龀鲞@樣的選擇呢？這就需要分析 Airflow 的優(yōu)點和痛點。Airflow 是以編程方式創(chuàng)建、調(diào)度和監(jiān)控工作流的開源系統(tǒng)。Airflow 具有很多優(yōu)點，包括：

• 能力豐富，具有豐富的任務(wù)類型，易用的流程控制；
• UI 易用，較為方便地進行可視化運維；
• 組件少易部署，上手難度不大。

這些優(yōu)點是我們選擇 Airflow 的原因。

但隨著任務(wù)規(guī)模增大，Airflow 的痛點也很明顯：

• 性能較差：我們發(fā)現(xiàn)，當(dāng) Airflow 單集群 Dag 數(shù)近 1 萬時，單任務(wù)調(diào)度延遲 P99 高達 5min，鏈路調(diào)度延遲高達數(shù)十分鐘，鏈路時效性難以保障。為了滿足業(yè)務(wù)增長，我們搭建了多個集群，運維成本倍增。
• 穩(wěn)定性不足：當(dāng)時 Airflow Scheduler 沒有 HA，任務(wù)執(zhí)行時環(huán)境和資源不隔離，容易 OOM，導(dǎo)致調(diào)度故障比較多，年均故障數(shù)約 8 個。
• 集成度低：二次開發(fā)成本大，和周邊系統(tǒng)集成度低，開放能力差，難以快速構(gòu)建生態(tài)。

由于這些痛點的存在，我們決定自研任務(wù)調(diào)度系統(tǒng)。

02

快手任務(wù)調(diào)度整體設(shè)計

在 2019 年中旬，我們開始自研任務(wù)調(diào)度系統(tǒng) Kwaiflow，并在下半年上線 1.0 版本。

Kwaiflow 是快手通用、高性能、易擴展的分布式工作流調(diào)度系統(tǒng)。其設(shè)計目標(biāo)從兩方面考慮。

在功能型目標(biāo)方面：

• 場景豐富：支持多場景調(diào)度，多種環(huán)境執(zhí)行，支持多樣易擴展的任務(wù)類型
• 運維便捷：可以進行可視化、智能、便捷地運維
• 便于開放：具有強大的開放能力，易于系統(tǒng)集成，構(gòu)建統(tǒng)一生態(tài)

在非功能型目標(biāo)方面：

• 高容量：支持百萬級任務(wù)容量
• 高性能：秒級或者亞秒級調(diào)度延遲
• 高可用：可用性 99.99%，線上問題少，出現(xiàn)時能及時發(fā)現(xiàn)快速并處理

在定位上，Kwaiflow 基于大數(shù)據(jù)體系和其它基礎(chǔ)設(shè)施，提供調(diào)度、執(zhí)行等核心能力，同時具有運維、監(jiān)控報警、智能診斷、開放服務(wù)等重要能力，構(gòu)建調(diào)度生態(tài)；面向數(shù)據(jù)處理、流程編排、算法調(diào)度和分布式計算等場景。

在調(diào)度模型上，Kwaiflow 采用了兩層實體的調(diào)度模型：

• Task：執(zhí)行模板，用于執(zhí)行某一類型的代碼；Task 有很多類型，例如 HiveTask 用于執(zhí)行 Hive SQL，BashTask 用于執(zhí)行 Bash 腳本，HivePartitionSensorTask 用于探測 hive 表分區(qū)是否存在。
• DAG：一系列 Task 的集合，具有調(diào)度定時等屬性。

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

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

在系統(tǒng)架構(gòu)上：

• API Server 提供各式各樣的接口，負(fù)責(zé)統(tǒng)一接入。
• Scheduler 負(fù)責(zé)調(diào)度，不同的調(diào)度場景會有不同類型的調(diào)度器，包括例行、觸發(fā)式、補數(shù)據(jù)、阻斷調(diào)度器。在例行調(diào)度器中，任務(wù)實例生成后，會依次經(jīng)過定時檢測、依賴檢測和資源檢測。如果都通過，會提交到 Queue Service 中。
• Queue Service 為帶 ack 機制的消息隊列服務(wù)，會有不同的 channel，以便隔離任務(wù)。
• Worker 負(fù)責(zé)任務(wù)的執(zhí)行，從屬一個 worker 分組。不同分組的 Worker 消費 Queue Service 中不同 Channel 的任務(wù)，根據(jù)不同的任務(wù)類型進行執(zhí)行。執(zhí)行分為本地執(zhí)行和容器化執(zhí)行兩種方式，本地執(zhí)行是指任務(wù)實例在 worker 內(nèi)通過新建進程的方式執(zhí)行；具有啟動快的特點；容器化執(zhí)行是指在 k8s 遠(yuǎn)程執(zhí)行用戶代碼，具有資源隔離和環(huán)境隔離的特點。

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

03

快手任務(wù)調(diào)度系統(tǒng)關(guān)鍵技術(shù)

1. 關(guān)鍵技術(shù)：低調(diào)度延遲

調(diào)度延遲是指理論起調(diào)時刻到實際開始運行用戶代碼的時間差。調(diào)度延遲是衡量任務(wù)調(diào)度系統(tǒng)性能的重要指標(biāo)之一，該指標(biāo)越小越好。

任務(wù)實例從生成，到開始運行用戶代碼，需要經(jīng)過等待時間就緒、等待依賴就緒、等待資源就緒和準(zhǔn)備運行環(huán)境四個階段。要有較小的調(diào)度延遲，就需要減少各個階段的系統(tǒng)時間損耗。調(diào)度延遲的主要因素與處理方案有：

• 定時器。定時器在探測時間就緒環(huán)節(jié)起作用，一個精準(zhǔn)的、支持百萬級別高吞吐的定時器，對低調(diào)度延遲至關(guān)重要。優(yōu)秀的定時器，時間損耗可以控制在毫秒內(nèi)。
• 數(shù)據(jù)庫訪問。任務(wù)實例狀態(tài)發(fā)生變更后，需要對狀態(tài)進行持久化。通過索引、讀寫分離、分庫分表等方式，可以將單次數(shù)據(jù)庫訪問耗時控制在 1 ~ 3ms，總體耗時控制在 10ms 左右 。
• 狀態(tài)轉(zhuǎn)變。任務(wù)實例自生成到運行結(jié)束，會經(jīng)歷多次狀態(tài)轉(zhuǎn)變。狀態(tài)轉(zhuǎn)變高效與否是調(diào)度延遲的重要因素。一般來說有兩種辦法：輪詢與事件觸發(fā)。我們采用的是事件觸發(fā)方式，第一時間感知狀態(tài)轉(zhuǎn)變。通過事件觸發(fā)，時間損耗可以控制在毫秒內(nèi)。
• 運行環(huán)境準(zhǔn)備。這個環(huán)節(jié)主要工作包括加載鏡像、初始化運行環(huán)境等。我們主要采用了預(yù)加載和鏡像預(yù)熱技術(shù)。不同的運行環(huán)境，時間損耗不一樣，會在亞秒到分鐘不等。

這四個因素中，后兩者相對較復(fù)雜，接下來著重介紹狀態(tài)轉(zhuǎn)變和運行環(huán)境準(zhǔn)備這兩部分。

首先看狀態(tài)轉(zhuǎn)變這個因素。任務(wù)從發(fā)布，到調(diào)度執(zhí)行完成，會經(jīng)歷數(shù)次或者十?dāng)?shù)次狀態(tài)變化。如何進行快速高效地狀態(tài)轉(zhuǎn)變是一個重要的問題。Kwaiflow 的解決辦法是采用 Akka actor。充分利用了 akka actor 高性能特點。

具體來講：

1. Kwaiflow 的任務(wù)從 API Server 發(fā)布后，經(jīng)過 Entry Actor 加載到 DagLoader Actors 中等待時間就緒；

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

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

4. 在資源就緒后，任務(wù)實例通過 Queue Service 下發(fā)到 worker 中。

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

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

整個流程具有三個特點：

• 全流程事件觸發(fā)：無輪詢，任務(wù)發(fā)布、調(diào)度、執(zhí)行、重試，均為事件觸發(fā)。
• 高吞吐：采用異步并發(fā)的方式，能快速調(diào)起大量任務(wù)實例
• 簡單易用：無需使用底層 API 進行鎖和線程管理，專注業(yè)務(wù)實現(xiàn)。

采用 actor，狀態(tài)轉(zhuǎn)變導(dǎo)致的時間損耗控制在毫秒級別。

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

• 容器化執(zhí)行：任務(wù)實例每次執(zhí)行前，在 k8s 按需申請容器資源，在容器中執(zhí)行任務(wù)實例，執(zhí)行完后，及時釋放容器資源。優(yōu)點是實現(xiàn)了執(zhí)行時的資源隔離和環(huán)境隔離；缺點是每次都需要申請和初始化容器資源，啟動耗時長。容器化執(zhí)行適合對資源、環(huán)境敏感的任務(wù)，例如 Bash 任務(wù)。為了減少容器化執(zhí)行的啟動耗時，我們將鏡像分為自定義鏡像和通用鏡像，對通用鏡像進行預(yù)熱，提前分發(fā)到機器中，減少鏡像下載耗時。通過鏡像預(yù)熱，可以將啟動耗時從分鐘級降低到秒級。
• 本地執(zhí)行：任務(wù)實例在 worker 機中，通過新建進程的方式執(zhí)行。同一個 worker 機中的所有任務(wù)實例共享計算資源和執(zhí)行環(huán)境。優(yōu)點是啟動耗時短，overhead 小；缺點是資源和環(huán)境不隔離，一個任務(wù)實例執(zhí)行異常有可能導(dǎo)致整個 worker 機 crash。本地執(zhí)行適合對資源、環(huán)境不敏感的任務(wù)，例如 Hive 和 Sensor 任務(wù)。本地執(zhí)行的啟動耗時一般在亞秒級。

2. 關(guān)鍵技術(shù)：高可用

高可用對調(diào)度系統(tǒng)來說非常重要。為了保障 Kwaiflow 的高可用，我們主要從兩方面進行考慮：系統(tǒng)設(shè)計和故障發(fā)現(xiàn)處理。在系統(tǒng)設(shè)計上，Kwaiflow 可以做到高可靠執(zhí)行，即任務(wù)實例在復(fù)雜環(huán)境中 Exactly Once 執(zhí)行，做到不漏，且盡量不重。

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

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

• Failover 機制方面：通過自動故障轉(zhuǎn)移和魯棒通信協(xié)議，來實現(xiàn)組件的自動容錯。例如 Kwaiflow 采用主備 Master，多 worker 的設(shè)計來避免單點問題；各個組件之間采用魯棒通信協(xié)議來避免失聯(lián)問題。協(xié)議包括 scheduler Executor 通信協(xié)議、Executor Runner 通信協(xié)議、External Job 通信協(xié)議。右圖展示了 Executor Runner 通信協(xié)議的主要流程，協(xié)議規(guī)定了任務(wù)提交、正常執(zhí)行、異常執(zhí)行、通信失聯(lián)的處理辦法，不依賴外部系統(tǒng)的狀態(tài)。
• 避免遺漏執(zhí)行方面：通過消息 ack 機制，保障消息不丟失；同時通過定期兜底巡檢，保障任務(wù)實例不遺漏。
• 避免重復(fù)執(zhí)行方面：通過狀態(tài)機轉(zhuǎn)移圖，避免不合理狀態(tài)轉(zhuǎn)變；同時通過重試前清理前一個實例，避免重復(fù)執(zhí)行。

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

所謂分級保障，就是在資源有限的情況下，讓高優(yōu)任務(wù)得到特權(quán)，優(yōu)先得到執(zhí)行，優(yōu)先獲得充足的優(yōu)質(zhì)資源，保障產(chǎn)出時間；而低優(yōu)任務(wù)則會被延遲調(diào)度執(zhí)行，分配更少的資源。

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

• Kwaiflow 調(diào)度器具有分級調(diào)度的能力。Kwaiflow 調(diào)度器能感知到資源調(diào)度系統(tǒng)的狀態(tài)，在資源不足時，Kwaiflow 任務(wù)會在調(diào)度器排隊，高優(yōu)任務(wù)排在前面，低優(yōu)任務(wù)排在后面；當(dāng)資源得到釋放時，高優(yōu)任務(wù)優(yōu)先被調(diào)度。
• Kwaiflow 的執(zhí)行器按照不同優(yōu)先級進行分組。包括三組：P0 執(zhí)行器組、P1 執(zhí)行器組以及 P2 P3 執(zhí)行器組。P0 執(zhí)行器用于執(zhí)行最高優(yōu)先級的 P0 任務(wù)，具有充足的 worker，P0 任務(wù)實例基本不會在執(zhí)行器層被限制。對于 P2 P3 分組，在調(diào)度高峰期，任務(wù)實例很多時，可能存在排隊執(zhí)行的情況。
• Kwaiflow 具有較強的人工管控能力，可以人為地允許或者阻斷某些任務(wù)的調(diào)度。典型使用場景是在大型活動期間，可以根據(jù)預(yù)案，對低優(yōu)先級的任務(wù)人為進行延遲調(diào)度，保障資源分配給高優(yōu)任務(wù)。

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

• 在監(jiān)控方面，我們分成使用層、服務(wù)層、依賴層三個層次，并劃分監(jiān)控優(yōu)先級，采用不同的響應(yīng)方式。
• 在故障預(yù)案方面，我們有兩類預(yù)案：系統(tǒng)故障處理預(yù)案用于處理調(diào)度系統(tǒng)自身問題；數(shù)據(jù)異常處理預(yù)案用于處理鏈路數(shù)據(jù)不正確的問題。我們沉淀了多場景的阻斷恢復(fù)和補數(shù)據(jù)工具，能夠在數(shù)分鐘內(nèi)啟動數(shù)據(jù)恢復(fù)。
• 在演練方面，我們定期對預(yù)案進行演練，保證預(yù)案的可用性，操作的熟練性。

3. 關(guān)鍵技術(shù)：開放能力

開放是數(shù)據(jù)中臺的核心競爭力。只有足夠開放，才能給予使用者自由的發(fā)揮空間，滿足更多使用場景；只有足夠開放，才能構(gòu)建數(shù)據(jù)生態(tài)，提供更豐富的能力。Kwaiflow 提供了多種開放能力：

• Kwaiflow 具有開放的 API，支持多語言 SDK，提供了標(biāo)準(zhǔn)化的接入流程、使用手冊和接入 demo。
• Kwaiflow 提供了標(biāo)準(zhǔn)的事件。包括任務(wù)操作事件、任務(wù)實例狀態(tài)變更事件、任務(wù)實例診斷事件等。根據(jù)這些事件，可以完整復(fù)現(xiàn)出任務(wù)和任務(wù)實例的全生命周期。
• Kwaiflow 提供了插件化任務(wù)類型。開發(fā)者可以定義和開發(fā)自定義的任務(wù)類型，并進行靈活測試、灰度上線和管理。
• Kwaiflow 提供了 Hook，可以在用戶代碼運行前后執(zhí)行。包括執(zhí)行前的 Prehook 和執(zhí)行后的 Posthook。常見場景包括用于代碼渲染、前置檢查的 Prehook，以及用于執(zhí)行后數(shù)據(jù)質(zhì)量檢測的 Posthook。

04

快手任務(wù)調(diào)度系統(tǒng)的應(yīng)用與成果

如果把任務(wù)調(diào)度系統(tǒng)比作大樓的骨架，那么基于任務(wù)調(diào)度系統(tǒng)的應(yīng)用就是裝修完善、適于人工作生活的大廈。通過應(yīng)用，能更好地體現(xiàn)任務(wù)調(diào)度系統(tǒng)的價值。在快手，集成開發(fā)平臺是任務(wù)調(diào)度系統(tǒng)的一個典型應(yīng)用。

集成開發(fā)平臺是快手的一站式離線數(shù)據(jù)開發(fā)平臺。它使用 kwaiflow 作為統(tǒng)一的編排與調(diào)度系統(tǒng)，構(gòu)建了各類的數(shù)據(jù)開發(fā)運維等服務(wù)，提供了數(shù)據(jù)查詢、同步、開發(fā)、服務(wù)化、運維、管理等能力。

該平臺具有三個特點：

• 一站式：平臺涵蓋離線數(shù)據(jù)開發(fā)的各環(huán)節(jié)，包括數(shù)據(jù)接入、數(shù)據(jù)加工、數(shù)據(jù)分發(fā)和數(shù)據(jù)服務(wù)化。用戶可以方便地進行數(shù)據(jù)源管理，創(chuàng)建數(shù)據(jù)接入任務(wù)將各種數(shù)據(jù)源導(dǎo)入到大數(shù)據(jù)系統(tǒng)中；用戶可以通過智能 IDE 編寫、測試和發(fā)布 ETL 任務(wù)，對數(shù)據(jù)進行加工處理，產(chǎn)生高價值的數(shù)據(jù)；用戶還可以創(chuàng)建數(shù)據(jù)分發(fā)任務(wù)，將高價值數(shù)據(jù)分發(fā)到其它存儲引擎中，例如關(guān)系型數(shù)據(jù)庫、非關(guān)系型數(shù)據(jù)庫、緩存系統(tǒng)、OLAP 引擎等。用戶也可以直接通過配置的方式創(chuàng)建服務(wù)化 API，為線上系統(tǒng)提供服務(wù)。
• 通用：集成開發(fā)平臺能統(tǒng)一運維 Kwaiflow 所有任務(wù)，包括任務(wù)運維、實例運維、鏈路運維等方式，適合數(shù)據(jù)開發(fā)、定時調(diào)度、觸發(fā)式調(diào)度等場景。
• 智能：在開發(fā)環(huán)節(jié)，通過智能 IDE，能及時發(fā)現(xiàn)代碼問題；在運維環(huán)節(jié)，通過智能監(jiān)控、智能診斷，能及時發(fā)現(xiàn)任務(wù)和鏈路問題，并輔助定位問題原因。

任務(wù)調(diào)度系統(tǒng)要得到廣泛使用，不僅要有強大的自身能力，更要有豐富的生態(tài)體系。在快手，Kwaiflow 和大數(shù)據(jù)的其它系統(tǒng)深度集成，接入了 Kwaiflow，便可以便捷地使用其它大數(shù)據(jù)系統(tǒng)的能力?？梢哉f，自身能力和生態(tài)體系對 Kwaiflow 來說同等重要。

首先，就自身而言，Kwaiflow 具有強大的調(diào)度執(zhí)行能力。包括多場景調(diào)度能力、多樣化的執(zhí)行能力、易用的運維能力和高可用的特性。

其次，Kwaiflow 具有資源管控能力。接入 Kwaiflow，便可以方便地使用大數(shù)據(jù)資源和容器資源。

最后，Kwaiflow 無縫集成了其它中臺能力。包括數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全體系、完整準(zhǔn)確的任務(wù)實例血緣、鏈路元數(shù)據(jù)、鏈路保障體系。

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

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

• 在規(guī)模上，Kwaiflow 初版設(shè)計容量為百萬級別任務(wù)，當(dāng)前已有數(shù)十萬的任務(wù)數(shù)，和 Airflow 單集群不超過 1 萬相比，提升了數(shù)十倍。
• 在性能上，Kwaiflow 調(diào)度高峰期的調(diào)度延遲 P99 小于 5 秒，和 Airflow 5 分鐘相比，有數(shù)量級的提升；Kwaiflow 起調(diào)速率十?dāng)?shù)萬每分鐘，和 Airflow 數(shù)千每分鐘對比，提升了數(shù)十倍；Kwaiflow 運行的并發(fā)實例數(shù)十?dāng)?shù)萬萬，和 Airflow 小于1萬相比，提升了十?dāng)?shù)倍。
• 在穩(wěn)定性上，Kwaiflow 可用性為 99.99%， Airflow 則為 99.5%；Kwaiflow 年故障數(shù)約 1 個，而 Airflow 年均為 8 個。

在功能方面，Kwaiflow：

• 具有強大的調(diào)度能力，支持多調(diào)度場景、支持各種復(fù)雜依賴流程編排。
• 具有靈活的執(zhí)行方式，豐富易擴展的任務(wù)類型。
• 具有便捷的運維中心，任務(wù)、實例、鏈路可視化運維，智能化運維。
• 具有多種資源管控能力，支持多租戶，可方便使用和管理大數(shù)據(jù)與容器資源。
• 全面集成數(shù)據(jù)中臺能力，包括數(shù)據(jù)質(zhì)量與安全體系、血緣、元數(shù)據(jù)、鏈路保障體系。

在使用情況方面，Kwaiflow：

• 面向全公司，接入了數(shù)據(jù)、算法領(lǐng)域數(shù)十個平臺，包括指標(biāo)模型管理平臺、AB 測試平臺、用戶畫像、機器學(xué)習(xí)平臺等。
• 面向主站、電商、商業(yè)化、海外、游戲等幾乎公司所有業(yè)務(wù)方。

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

• 更通用化：更好地支持觸發(fā)式調(diào)度，更復(fù)雜的在線流程編排，探索分布式計算。
• 更高性能：更好地支持秒級調(diào)度，支持千萬級規(guī)模任務(wù)實例，支持大規(guī)模觸發(fā)式調(diào)度。
• 更豐富的功能：更豐富的容器資源管理能力，完善的自動化測試系統(tǒng)和大規(guī)模模擬演練系統(tǒng)，更加快速的部署能力。

今天的分享就到這里，謝謝大家。