一、背景

阿里云日志服務(wù)作為云原生可觀測(cè)與分析平臺(tái)。提供了一站式的數(shù)據(jù)采集、加工、查詢分析、可視化、告警、消費(fèi)與投遞等功能。全面提升用戶的研發(fā)、運(yùn)維、運(yùn)營(yíng)、安全場(chǎng)景的數(shù)字化能力。

日志服務(wù)平臺(tái)作為可觀測(cè)性平臺(tái)提供了數(shù)據(jù)導(dǎo)入、數(shù)據(jù)加工、聚集加工、告警、智能巡檢、導(dǎo)出等功能，這些功能在日志服務(wù)被稱為任務(wù)，并且具有大規(guī)模的應(yīng)用，接下來主要介紹下這些任務(wù)的調(diào)度框架的設(shè)計(jì)與實(shí)踐。

本次介紹主要分為四個(gè)部分：

• 任務(wù)調(diào)度背景
• 可觀測(cè)性平臺(tái)的億級(jí)任務(wù)調(diào)度框架設(shè)計(jì)
• 任務(wù)調(diào)度框架在日志服務(wù)的大規(guī)模應(yīng)用
• 展望

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

通用調(diào)度

調(diào)度在計(jì)算機(jī)里面是一個(gè)非常常見的技術(shù)，從單機(jī)到分布式再到大數(shù)據(jù)系統(tǒng)，調(diào)度的身影無處不在。這里嘗試總結(jié)出調(diào)度的一些共同特征。

• 操作系統(tǒng)：從單機(jī)操作系統(tǒng)Linux來看，內(nèi)核通過時(shí)間片的方式來控制進(jìn)程在處理器上的執(zhí)行時(shí)間，進(jìn)程的優(yōu)先級(jí)與時(shí)間片掛鉤，簡(jiǎn)單來說，進(jìn)程的在單CPU或者某個(gè)CPU的執(zhí)行由調(diào)度器來掌握；K8s被稱為分布式時(shí)代的操作系統(tǒng)，在Pod創(chuàng)建后，K8s的控制面調(diào)度器通過對(duì)節(jié)點(diǎn)進(jìn)行打分排序，最終選出適合的Node來運(yùn)行Pod。
• 大數(shù)據(jù)分析系統(tǒng)：從最早的MapReduce使用公平調(diào)度器支持作業(yè)的優(yōu)先級(jí)和搶占，到SQL計(jì)算引擎Presto通過Coordinator的調(diào)度器將執(zhí)行計(jì)劃中的任務(wù)分配到適合的worker上來執(zhí)行，Spark通過DAGScheduler拆分成Stage，TaskScheduler將Stage對(duì)應(yīng)的TaskSet最終調(diào)度到適合的Worker上來執(zhí)行。
• 任務(wù)調(diào)度框架：在數(shù)據(jù)處理中常見的ETL處理任務(wù)、定時(shí)任務(wù)，這些任務(wù)具有多模的特點(diǎn)：定時(shí)執(zhí)行、持續(xù)運(yùn)行、一次性執(zhí)行等。在任務(wù)執(zhí)行過程中需要考慮任務(wù)的編排和狀態(tài)一致性問題。

這里簡(jiǎn)單的對(duì)調(diào)度做一個(gè)抽象，如上圖所示，調(diào)度負(fù)責(zé)將不同的Task分配到不同的Resource上執(zhí)行，Task可以是進(jìn)程、Pod、子任務(wù)；Resource為具體執(zhí)行Task任務(wù)的資源，可以是處理器、線程池、節(jié)點(diǎn)、機(jī)器。通過這個(gè)抽象，可以看出調(diào)度在系統(tǒng)中的位置。

調(diào)度的覆蓋面很廣，本文主要集中在任務(wù)調(diào)度框架的設(shè)計(jì)與實(shí)踐，這里先通過一些例子來看下任務(wù)調(diào)度的一些特點(diǎn)，以下主要講任務(wù)分為定時(shí)類的任務(wù)和依賴類的任務(wù)兩種來展開。

任務(wù)調(diào)度

定時(shí)類任務(wù)

定時(shí)執(zhí)行可以理解為每個(gè)任務(wù)之間有時(shí)間先后順序，并且要在特定的時(shí)間點(diǎn)執(zhí)行，比如每隔1小時(shí)對(duì)日志進(jìn)行監(jiān)控，00點(diǎn)的監(jiān)控任務(wù)需要首先執(zhí)行，01點(diǎn)的監(jiān)控任務(wù)需要在01點(diǎn)準(zhǔn)時(shí)執(zhí)行；同樣，類似的定時(shí)場(chǎng)景，還有儀表盤訂閱、定時(shí)計(jì)算等。

?依賴類任務(wù)

除了定時(shí)執(zhí)行，還有另外一種編排形式，比如順序依賴，各個(gè)任務(wù)之間有先后執(zhí)行的依賴，也叫Pipeline方式，還有一種比較常見的編排形式，拓?fù)湟蕾?，也稱為DAG，比如Task2/Task3需要等到Task1執(zhí)行完成才可以執(zhí)行，Task5需要等到Task3/Task4執(zhí)行完才可以執(zhí)行。

?任務(wù)調(diào)度特點(diǎn)

任務(wù)調(diào)度在執(zhí)行的過程中需要盡可能均衡的將任務(wù)分派到合適的機(jī)器或者執(zhí)行器上去執(zhí)行，比如要根據(jù)執(zhí)行器的當(dāng)前負(fù)載情況，要根據(jù)任務(wù)自身的特征進(jìn)行分派執(zhí)行；在執(zhí)行器執(zhí)行的過程中也可能會(huì)崩潰，退出，這時(shí)候需要將任務(wù)遷移到其他的執(zhí)行器中。整個(gè)調(diào)度過程需要考慮到調(diào)度策略、FailOver、任務(wù)遷移等。接下來來看下任務(wù)調(diào)度的一個(gè)簡(jiǎn)單應(yīng)用。

任務(wù)調(diào)度應(yīng)用：一條日志的歷險(xiǎn)

上圖中原始日志為一條Nginx訪問日志，其中包括IP、時(shí)間、Method、URL、UserAgent等信息，這樣一些原始日志并不利于我們進(jìn)行分析，比如我們想統(tǒng)計(jì)訪問最高的Top 10 URL，通過命令處理是這樣的：

cat nginx_access.log |awk '{print $7}'| sort|uniq -c| sort -rn| head -10 | more

拋開命令的復(fù)雜性和原始日志的數(shù)據(jù)量不談，即使需求稍微變化，命令就需要大量的改動(dòng)，非常不利于維護(hù)，對(duì)日志進(jìn)行分析的正確方式必然是使用分布式日志平臺(tái)進(jìn)行日志分析，原始日志蘊(yùn)含著大量“信息”，但是這些信息的提取是需要一系列的流程。

首先是數(shù)據(jù)采集、需要通過Agent對(duì)分布在各個(gè)機(jī)器上的數(shù)據(jù)進(jìn)行集中采集到日志平臺(tái)，日志采集上來后需要進(jìn)行清洗，比如對(duì)于Nginx訪問日志使用正則提取，將時(shí)間、Method、URL等重要信息提取出來作為字段進(jìn)行存儲(chǔ)并進(jìn)行索引構(gòu)建，通過索引，我們可以使用類SQL的分析語(yǔ)法對(duì)日志進(jìn)行分析、例如查看訪問的Top 10 URL，用SQL來表達(dá)就會(huì)非常簡(jiǎn)潔清晰：

select url, count(1) as cnt from log group by url order by cnt desc limit 10

業(yè)務(wù)系統(tǒng)只要在服務(wù)，日志就會(huì)不斷產(chǎn)生，可以通過對(duì)流式的日志進(jìn)行巡檢，來達(dá)到系統(tǒng)異常的檢測(cè)目的，當(dāng)異常發(fā)生時(shí)，我們可以通過告警通知到系統(tǒng)運(yùn)維人員。

?通用流程提取

從這樣一個(gè)日志分析系統(tǒng)可以提取出一些通用的流程，這些通用的流程可以概括為數(shù)據(jù)攝入、數(shù)據(jù)處理、數(shù)據(jù)監(jiān)測(cè)、數(shù)據(jù)導(dǎo)出。

除了日志，系統(tǒng)還有Trace數(shù)據(jù)、Metric數(shù)據(jù)，它們是可觀測(cè)性系統(tǒng)的三大支柱。這個(gè)流程也適用于可觀測(cè)性服務(wù)平臺(tái)，接下來來看下一個(gè)典型的可觀測(cè)服務(wù)平臺(tái)的流程構(gòu)成。

?典型可觀測(cè)服務(wù)平臺(tái)數(shù)據(jù)流程

• 數(shù)據(jù)攝入：在可觀測(cè)服務(wù)平臺(tái)首先需要擴(kuò)展數(shù)據(jù)來源，數(shù)據(jù)源可能包括各類日志、消息隊(duì)列Kafka、存儲(chǔ)OSS、云監(jiān)控?cái)?shù)據(jù)等，也可以包括各類數(shù)據(jù)庫(kù)數(shù)據(jù)，通過豐富數(shù)據(jù)源的攝入，可以對(duì)系統(tǒng)有全方位的觀測(cè)。
• 數(shù)據(jù)處理：在數(shù)據(jù)攝入到平臺(tái)后，需要對(duì)數(shù)據(jù)進(jìn)行清洗、加工，這個(gè)過程我們把他統(tǒng)稱數(shù)據(jù)處理，數(shù)據(jù)加工可以理解為數(shù)據(jù)的各種變換和富華等，聚集加工支持對(duì)數(shù)據(jù)進(jìn)行定時(shí)rolling up操作，比如每天計(jì)算過去一天匯總數(shù)據(jù)，提供信息密度更高的數(shù)據(jù)。
• 數(shù)據(jù)監(jiān)測(cè)：可觀測(cè)性數(shù)據(jù)本身反應(yīng)了系統(tǒng)的運(yùn)行狀態(tài)，系統(tǒng)通過對(duì)每個(gè)組件暴露特定的指標(biāo)來暴露組件的健康程度，可以通過智能巡檢算法對(duì)異常的指標(biāo)進(jìn)行監(jiān)控，比如QPS或者Latency的陡增或陡降，當(dāng)出現(xiàn)異常時(shí)可以通過告警通知給相關(guān)運(yùn)維人員，在指標(biāo)的基礎(chǔ)上可以做出各種運(yùn)維或者運(yùn)營(yíng)的大盤，在每天定時(shí)發(fā)送大盤到群里也是一種場(chǎng)景的需求。
• 數(shù)據(jù)導(dǎo)出：可觀測(cè)性數(shù)據(jù)的價(jià)值往往隨著時(shí)間產(chǎn)生衰減，那么對(duì)于長(zhǎng)時(shí)間的日志類數(shù)據(jù)出于留檔的目的可以進(jìn)行導(dǎo)出到其他平臺(tái)。

從以上四個(gè)過程我們可以抽象出各類任務(wù)，分別負(fù)責(zé)攝入、處理、檢測(cè)等，比如數(shù)據(jù)加工是一種常駐任務(wù)，需要持續(xù)對(duì)數(shù)據(jù)流進(jìn)行處理，儀表盤訂閱是一種定時(shí)任務(wù)，需要定時(shí)發(fā)出儀表盤到郵件或者工作群中。接下來將要介紹對(duì)各類任務(wù)的調(diào)度框架。

可觀測(cè)性平臺(tái)的億級(jí)任務(wù)調(diào)度框架設(shè)計(jì)可觀測(cè)平臺(tái)任務(wù)特點(diǎn)

根據(jù)上面對(duì)可觀測(cè)平臺(tái)任務(wù)的介紹，可以總結(jié)一個(gè)典型的可觀測(cè)平臺(tái)的任務(wù)的特點(diǎn)：

• 業(yè)務(wù)復(fù)雜，任務(wù)類型多：數(shù)據(jù)攝入，僅數(shù)據(jù)攝入單個(gè)流程涉及數(shù)據(jù)源可能有幾十上百個(gè)之多。
• 用戶量大，任務(wù)數(shù)數(shù)量多：由于是云上業(yè)務(wù)，每個(gè)客戶都有大量的任務(wù)創(chuàng)建需求。
• SLA要求高：服務(wù)可用性要求高，后臺(tái)服務(wù)是升級(jí)、遷移不能影響用戶已有任務(wù)的運(yùn)行。
• 多租戶：云上業(yè)務(wù)客戶相互直接不能有影響。?

可觀測(cè)平臺(tái)任務(wù)調(diào)度設(shè)計(jì)目標(biāo)

根據(jù)平臺(tái)任務(wù)的特點(diǎn)，對(duì)于其調(diào)度框架，我們需要達(dá)到上圖中的目標(biāo)

• 支持異構(gòu)任務(wù)：告警、儀表盤訂閱、數(shù)據(jù)加工、聚集加工每種任務(wù)的特點(diǎn)不一樣，比如告警是定時(shí)類任務(wù)、數(shù)據(jù)加工是常駐類任務(wù)，儀表盤訂閱預(yù)覽是一次性任務(wù)。
• 海量任務(wù)調(diào)度：對(duì)于單個(gè)告警任務(wù)，假如每分鐘執(zhí)行一次，一天就會(huì)有1440次調(diào)度，這個(gè)數(shù)量乘以用戶數(shù)再乘以任務(wù)數(shù)，將是海量的任務(wù)調(diào)度；我們需要達(dá)到的目標(biāo)是任務(wù)數(shù)的增加不會(huì)對(duì)打爆機(jī)器的性能，特別是要做到水平擴(kuò)縮容，任務(wù)數(shù)或者調(diào)度次數(shù)增加只需要線性增加機(jī)器即可。
• 高可用：作為云上業(yè)務(wù)，需要達(dá)到后臺(tái)服務(wù)升級(jí)或者重啟、甚至宕機(jī)對(duì)用戶任務(wù)運(yùn)行無影響的目的，在用戶層面和后臺(tái)服務(wù)層面都需要具有任務(wù)運(yùn)行的監(jiān)控能力。
• 簡(jiǎn)單高效的運(yùn)維：對(duì)于后臺(tái)服務(wù)需要提供可視化的運(yùn)維大盤，可以直觀的展示服務(wù)的問題；同時(shí)也要對(duì)服務(wù)進(jìn)行告警配置，在服務(wù)升級(jí)、發(fā)布過程中可以盡量無人值守。
• 多租戶：云上環(huán)境是天然有多租戶場(chǎng)景，各個(gè)租戶之間資源要做到嚴(yán)格隔離，相互之間不能有資源依賴、性能依賴。
• 可擴(kuò)展性：面對(duì)客戶的新增需求，未來需要支持更多的任務(wù)類型，比如已經(jīng)有了MySQL、SqlServer的導(dǎo)入任務(wù)，在未來需要更多其他的數(shù)據(jù)庫(kù)導(dǎo)入，這種情況下，我們需要做到不修改任務(wù)調(diào)度框架，只需要修改插件即可完成。
• API化：除了以上的需求，我們還需要做到任務(wù)的API化管控，對(duì)于云上用戶，很多海外客戶是使用API、Terraform來對(duì)云上資源做管控，所以要做到任務(wù)管理的API化。?

可觀測(cè)平臺(tái)任務(wù)調(diào)度框架總體概覽

基于上述的調(diào)度設(shè)計(jì)目標(biāo)，我們?cè)O(shè)計(jì)了可觀測(cè)性任務(wù)調(diào)度框架，如上圖所示，下面從下到上來介紹。

• 存儲(chǔ)層：主要包括任務(wù)的元數(shù)據(jù)存儲(chǔ)和任務(wù)運(yùn)行時(shí)的狀態(tài)和快照存儲(chǔ)。任務(wù)的元數(shù)據(jù)主要包括任務(wù)類型，任務(wù)配置、任務(wù)調(diào)度信息，都存儲(chǔ)在了關(guān)系型數(shù)據(jù)庫(kù)；任務(wù)的運(yùn)行狀態(tài)、快照存儲(chǔ)在了分布式文件系統(tǒng)中。
• 服務(wù)層：提供了任務(wù)調(diào)度的核心功能，主要包括任務(wù)調(diào)度和任務(wù)執(zhí)行兩部分，分別對(duì)應(yīng)前面講的任務(wù)編排和任務(wù)執(zhí)行模塊。任務(wù)調(diào)度主要針對(duì)三種任務(wù)類型進(jìn)行調(diào)度，包括常駐任務(wù)、定時(shí)任務(wù)、按需任務(wù)。任務(wù)執(zhí)行支持多種執(zhí)行引擎，包括presto、restful接口、K8s引擎和內(nèi)部自研的ETL 2.0系統(tǒng)。
• 業(yè)務(wù)層：業(yè)務(wù)層包括用戶直接在控制臺(tái)可以使用到的功能，包括告警監(jiān)控、數(shù)據(jù)加工、重建索引、儀表盤訂閱、聚集加工、各類數(shù)據(jù)源導(dǎo)入、智能巡檢任務(wù)、和日志投遞等。
• 接入層：接入層使用Nginx和CGI對(duì)外提供服務(wù)，具有高可用，地域化部署等特性。
• API/SDK/Terraform/控制臺(tái)：在用戶側(cè)，可以使用控制臺(tái)對(duì)各類任務(wù)進(jìn)行管理，對(duì)于不同的任務(wù)提供了定制化的界面和監(jiān)控，同時(shí)也可以使用API、SDK、Terraform對(duì)任務(wù)進(jìn)行增刪改查。
• 任務(wù)可視化：在控制臺(tái)我們提供了任務(wù)執(zhí)行的可視化和任務(wù)監(jiān)控的可視化，通過控制臺(tái)用戶可以看出看到任務(wù)的執(zhí)行狀態(tài)、執(zhí)行歷史等，還可以開啟內(nèi)置告警對(duì)任務(wù)進(jìn)行監(jiān)控。

任務(wù)調(diào)度框架設(shè)計(jì)要點(diǎn)

接下來從幾方面對(duì)任務(wù)調(diào)度框的設(shè)計(jì)要點(diǎn)進(jìn)行介紹，主要包括以下幾方面來介紹：

• 異構(gòu)任務(wù)模型抽象
• 調(diào)度服務(wù)框架
• 大規(guī)模任務(wù)支持
• 服務(wù)高可用設(shè)計(jì)
• 穩(wěn)定性建設(shè)

任務(wù)模型抽象

接下來看下任務(wù)模型的抽象：

• 對(duì)于告警監(jiān)控、儀表盤訂閱、聚集加工等需要定時(shí)執(zhí)行的任務(wù)，抽象為定時(shí)任務(wù)，支持定時(shí)和Cron表達(dá)式設(shè)置。
• 對(duì)于數(shù)據(jù)加工、索引重建、數(shù)據(jù)導(dǎo)入等需要持續(xù)運(yùn)行的任務(wù)，抽象為常駐任務(wù)，這類任務(wù)往往只需要運(yùn)行一次，可以有也可以沒有結(jié)束狀態(tài)。
• 對(duì)于數(shù)據(jù)加工的預(yù)覽、儀表盤訂閱的預(yù)覽等功能，是在用戶點(diǎn)擊時(shí)才會(huì)需要?jiǎng)?chuàng)建一個(gè)任務(wù)來執(zhí)行，執(zhí)行完成即可退出，不需要保存任務(wù)狀態(tài)，這類任務(wù)抽象為DryRun類型，或者按需任務(wù)。

調(diào)度服務(wù)框架

服務(wù)基礎(chǔ)框架使用了Master-Worker架構(gòu)，Master負(fù)責(zé)任務(wù)的分派和Worker的管控，Master將數(shù)據(jù)抽象為若干Partitions，然后將這些Partitions分派給不同的Worker，實(shí)現(xiàn)了對(duì)任務(wù)的分而治之，在Worker執(zhí)行的過程中Master還也可以根據(jù)Worker的負(fù)載進(jìn)行Partitions的動(dòng)態(tài)遷移，同時(shí)在Worker重啟升級(jí)過程中，Master也會(huì)對(duì)Partition進(jìn)行移出和移入；

任務(wù)的調(diào)度主要在Worker層來實(shí)現(xiàn)，每個(gè)Worker負(fù)責(zé)拉取對(duì)應(yīng)Partitions的任務(wù)，然后通過JobLoader對(duì)任務(wù)進(jìn)行加載，注意：這里只會(huì)加載當(dāng)前Worker對(duì)應(yīng)Partitions的任務(wù)列表，然后Scheduler對(duì)任務(wù)進(jìn)行調(diào)度的編排，這里會(huì)涉及常駐任務(wù)、定時(shí)任務(wù)、按需任務(wù)的調(diào)度，Scheduler將編排好的任務(wù)發(fā)送到JobExecutor進(jìn)行執(zhí)行，JobExecutor在執(zhí)行的過程中需要實(shí)時(shí)對(duì)任務(wù)的狀態(tài)進(jìn)行持久化保存到RedoLog中,在下次Worker升級(jí)重新啟動(dòng)的過程中，需要從RedoLog中加載任務(wù)的狀態(tài)，從而保證任務(wù)狀態(tài)的準(zhǔn)確性。

?大規(guī)模任務(wù)支持

通過任務(wù)服務(wù)框架的介紹，我們知道Partitions是Master與Worker溝通的橋梁，也是對(duì)大規(guī)模任務(wù)進(jìn)行分而治之的介質(zhì)。如上圖所示，假設(shè)有N個(gè)任務(wù)，按照一定的哈希算法將N個(gè)任務(wù)映射到對(duì)應(yīng)的Partition，因?yàn)閃orker關(guān)聯(lián)特定的Partition，這樣Worker就可以跟任務(wù)關(guān)聯(lián)起來，比如任務(wù)j1、j2對(duì)應(yīng)的partition是p1，而p1對(duì)應(yīng)的Worker是worker1，這樣j1、j2就可以在worker1上執(zhí)行。需要說明的如下：

• Worker與Partition的對(duì)應(yīng)關(guān)系并非一成不變，是一個(gè)動(dòng)態(tài)的映射，在Worker重啟或者負(fù)載較高時(shí)，其對(duì)應(yīng)的Partition會(huì)遷移到其他的Worker上，所以Worker需要實(shí)現(xiàn)Partition的移入和移出操作。
• 任務(wù)數(shù)量增加的時(shí)候，因?yàn)橛蠵artition這個(gè)中間層，只需要增加Worker的數(shù)量就可以滿足任務(wù)增長(zhǎng)時(shí)的需求，達(dá)到水平擴(kuò)展的目的。增加新Worker后，可以分擔(dān)更多的Partition
  

服務(wù)高可用設(shè)計(jì)

服務(wù)的高可用主要是服務(wù)的可用性時(shí)間，作為后臺(tái)服務(wù)肯定有重啟、升級(jí)的需求，高可用場(chǎng)景主要涉及到Partition遷移的處理，在Worker重啟、Worker負(fù)載較高時(shí)、Worker異常時(shí)，都會(huì)有Partition遷移的需求，在Partition遷移的過程中，任務(wù)也需要進(jìn)行遷移，任務(wù)的遷移就涉及到狀態(tài)的保留，類似CPU上進(jìn)程的航線文切換。

對(duì)于任務(wù)的切換，我們使用了RedoLog的方式來保存任務(wù)的狀態(tài)，一個(gè)任務(wù)可以被分為多個(gè)階段，對(duì)應(yīng)任務(wù)執(zhí)行的狀態(tài)機(jī)，在每個(gè)階段執(zhí)行時(shí)都對(duì)其進(jìn)行內(nèi)存Checkpoint的更新和RedoLog的更新，RedoLog是持久化到之前提到的分布式文件系統(tǒng)中，使用高性能的Append的方式進(jìn)行順序?qū)懭?，在Partition遷移到新的Worker后，新的Worker在對(duì)RedoLog進(jìn)行加載，就可以完成任務(wù)狀態(tài)的恢復(fù)。

這里涉及一個(gè)優(yōu)化，RedoLog如果一直使用Append的方式進(jìn)行寫入，勢(shì)必會(huì)造成RedoLog越來越膨脹，也會(huì)造成Worker加載Partition時(shí)速度變慢，對(duì)于這種情況，我們使用了Snapshot的方式，將過去一段時(shí)間的RedoLog進(jìn)行合并，這樣只需要在加載Partition時(shí)，加載Snapshot和Snaphost之后的RedoLog就可以減少文件讀取的次數(shù)和開銷，提高加載速度。

穩(wěn)定性建設(shè)

穩(wěn)定性建設(shè)主要涉及以下幾方面內(nèi)容：

• 發(fā)布流程：
• 從編譯到發(fā)布全Web端白屏化操作，模板化發(fā)布，每個(gè)版本都可跟蹤、回退。
• 支持集群粒度、任務(wù)類型粒度的灰度控制，在發(fā)布時(shí)可以進(jìn)行小范圍驗(yàn)證，然后全量發(fā)布。
• 運(yùn)維流程：
• 提供內(nèi)部運(yùn)維API、Web端操作，對(duì)于異常Job進(jìn)行修復(fù)、處理。減少人工介入運(yùn)維。
• On-Call：
• 在服務(wù)內(nèi)部，我們開發(fā)了內(nèi)部巡檢功能，查找異常任務(wù)，例如某些任務(wù)啟動(dòng)時(shí)間過長(zhǎng)、停止時(shí)間過長(zhǎng)都會(huì)打印異常日志，可以對(duì)異常日志進(jìn)行跟蹤和監(jiān)控。
• 通過異常日志，使用日志服務(wù)告警進(jìn)行監(jiān)控，出現(xiàn)問題可以及時(shí)通知運(yùn)維人員。
• 任務(wù)監(jiān)控：
• 用戶側(cè)：在控制臺(tái)我們針對(duì)各類任務(wù)提供了監(jiān)控儀表盤和內(nèi)置告警配置。
• 服務(wù)側(cè)：在后臺(tái)，可以看到集群粒度任務(wù)的運(yùn)行狀態(tài)，便于后臺(tái)運(yùn)維人員進(jìn)行服務(wù)的監(jiān)控。
• 同時(shí)，對(duì)于任務(wù)的執(zhí)行狀態(tài)和歷史都會(huì)存入特定的日志庫(kù)中，以便出現(xiàn)問題時(shí)進(jìn)行追溯和診斷。

下面是一些服務(wù)側(cè)的部分大盤示例，展示的是告警的一些執(zhí)行狀態(tài)。

下面是用戶側(cè)的任務(wù)監(jiān)控狀態(tài)和告警的展示。

大規(guī)模應(yīng)用

在日志服務(wù)，任務(wù)的調(diào)度已經(jīng)有了大規(guī)模的應(yīng)用，下面是某地域單集群的任務(wù)的運(yùn)行狀態(tài)，因?yàn)楦婢嵌〞r(shí)執(zhí)行且使用場(chǎng)景廣泛，其單日調(diào)度次數(shù)達(dá)到了千萬級(jí)別，聚集加工在Rolling up場(chǎng)景中有很高場(chǎng)景的應(yīng)用，也達(dá)到了百萬級(jí)別；對(duì)于數(shù)據(jù)加工任務(wù)因?yàn)槭浅ｑv任務(wù)，調(diào)度頻率低于類似告警類的定時(shí)任務(wù)。

接下來以一個(gè)聚集加工為例來看下任務(wù)的調(diào)度場(chǎng)景。

典型任務(wù)：聚集加工

聚集加工是通過定時(shí)對(duì)一段時(shí)間的數(shù)據(jù)進(jìn)行聚集查詢，然后將結(jié)果存入到另一個(gè)庫(kù)中，從而將高信息密度的信息進(jìn)行提取，相對(duì)于原始數(shù)據(jù)具有降維、低存儲(chǔ)、高信息密度的特點(diǎn)。適合于定時(shí)分析、全局聚合的場(chǎng)景。

這里是一個(gè)聚集加工的執(zhí)行狀態(tài)示例，可以看到每個(gè)時(shí)間區(qū)間的執(zhí)行情況，包括處理行數(shù)、處理數(shù)據(jù)量、處理結(jié)果情況，對(duì)于執(zhí)行失敗的任務(wù)，還可以進(jìn)行手動(dòng)重試。

對(duì)于聚集加工并非定時(shí)執(zhí)行這么簡(jiǎn)單的邏輯，在過程中需要處理超時(shí)、失敗、延遲等場(chǎng)景，接下來對(duì)每種場(chǎng)景進(jìn)行一個(gè)簡(jiǎn)單介紹。

?調(diào)度場(chǎng)景一：實(shí)例延遲執(zhí)行

無論實(shí)例是否延遲執(zhí)行，實(shí)例的調(diào)度時(shí)間都是根據(jù)調(diào)度規(guī)則預(yù)先生成的。雖然前面的實(shí)例發(fā)生延遲時(shí)，可能導(dǎo)致后面的實(shí)例也延遲執(zhí)行，但通過追趕執(zhí)行進(jìn)度，可逐漸減少延遲，直到恢復(fù)準(zhǔn)時(shí)運(yùn)行。 

調(diào)度場(chǎng)景二：從某個(gè)歷史時(shí)間點(diǎn)開始執(zhí)行聚集加工作業(yè)

在當(dāng)前時(shí)間點(diǎn)創(chuàng)建聚集加工作業(yè)后，按照調(diào)度規(guī)則對(duì)歷史數(shù)據(jù)進(jìn)行處理，從調(diào)度的開始時(shí)間創(chuàng)建補(bǔ)運(yùn)行的實(shí)例，補(bǔ)運(yùn)行的實(shí)例依次執(zhí)行直到追上數(shù)據(jù)處理進(jìn)度后，再按照預(yù)定計(jì)劃執(zhí)行新實(shí)例。 

調(diào)度場(chǎng)景三：固定時(shí)間內(nèi)執(zhí)行聚集加工作業(yè)

如果需要對(duì)指定時(shí)間段的日志做調(diào)度，則可設(shè)置調(diào)度的時(shí)間范圍。如果設(shè)置了調(diào)度的結(jié)束時(shí)間，則最后一個(gè)實(shí)例（調(diào)度時(shí)間小于調(diào)度結(jié)束時(shí)間）執(zhí)行完成后，不再產(chǎn)生新的實(shí)例。

調(diào)度場(chǎng)景四：修改調(diào)度配置對(duì)生成實(shí)例的影響

修改調(diào)度配置后，下一個(gè)實(shí)例按照新配置生成。一般建議同步修改SQL時(shí)間窗口、調(diào)度頻率等配置，使得實(shí)例之間的SQL時(shí)間范圍可以連續(xù)。 

調(diào)度場(chǎng)景五：重試失敗的實(shí)例

• 自動(dòng)重試
• 如果實(shí)例執(zhí)行失?。ɡ鐧?quán)限不足、源庫(kù)不存在、目標(biāo)庫(kù)不存在、SQL語(yǔ)法不合法），系統(tǒng)支持自動(dòng)重試
• 手動(dòng)重試
• 當(dāng)重試次數(shù)超過您配置的最大重試次數(shù)或重試時(shí)間超過您配置的最大運(yùn)行時(shí)間時(shí)，重試結(jié)束，該實(shí)例狀態(tài)被置為失敗，然后系統(tǒng)繼續(xù)執(zhí)行下一個(gè)實(shí)例。

展望

• 動(dòng)態(tài)任務(wù)類型：增加對(duì)于動(dòng)態(tài)任務(wù)類型的支持，例如更復(fù)雜的具有任務(wù)間依賴關(guān)系的任務(wù)調(diào)度。
• 多租戶優(yōu)化：目前對(duì)于任務(wù)使用簡(jiǎn)單的Quota限制，未來對(duì)多租戶的QoS進(jìn)行的進(jìn)一步細(xì)化，以支持更大的Quota設(shè)置。
• API優(yōu)化、完善：目前的任務(wù)類型也在快速更新中，任務(wù)API的迭代速度還有些差距，需要增強(qiáng)任務(wù)API的優(yōu)化，達(dá)到增加一種任務(wù)類型，不需要修改或者少量更新API的目的。