簡(jiǎn)介： 本文總結(jié)了大規(guī)模日志全局分析的需求，討論SLS上現(xiàn)有的典型分析方案，并延伸到 SLS 原生數(shù)據(jù)處理方案，介紹 Schedueld SQL 功能與最佳實(shí)踐。

大規(guī)模日志全局分析的需求

數(shù)據(jù)大規(guī)模與時(shí)效性

基于時(shí)間的數(shù)據(jù)（日志、指標(biāo)）在日積月累后的數(shù)量是驚人的。以 SLB 七層訪問(wèn)日志為例，每一個(gè)HTTP/HTTPS 訪問(wèn)請(qǐng)求會(huì)記錄一條 access log，假設(shè)每天產(chǎn)生1000萬(wàn)條數(shù)據(jù)，則一年為36億條數(shù)據(jù)。一方面，長(zhǎng)時(shí)間的數(shù)據(jù)存儲(chǔ)需要巨大的存儲(chǔ)空間，而通過(guò)減少存儲(chǔ)周期的方式降低存儲(chǔ)空間，雖然控制了存儲(chǔ)成本，但也丟失了有價(jià)值的歷史數(shù)據(jù)。另一方面，大量的數(shù)據(jù)將造成分析上的性能壓力。

大部分時(shí)序數(shù)據(jù)具有時(shí)效性特征。歷史數(shù)據(jù)可以接受分鐘或小時(shí)級(jí)別的精度，而新產(chǎn)生的數(shù)據(jù)需要更高的精度（例如監(jiān)控、線上問(wèn)題調(diào)查）。數(shù)據(jù)運(yùn)營(yíng)、分析師需要存儲(chǔ)全量的數(shù)據(jù)以備分析，歷史數(shù)據(jù)直接 TTL 刪除是可能最差的選擇。

例如 Elasticsearch rollup、時(shí)序數(shù)據(jù)庫(kù)的降精度用于解決這部分問(wèn)題。

一份數(shù)據(jù)在多種場(chǎng)景使用

對(duì)于同一份日志，可能被多種用戶角色在多種場(chǎng)景下使用到：

• 實(shí)時(shí)的數(shù)據(jù)，需要支持關(guān)鍵詞告警、時(shí)序數(shù)據(jù) ML 巡檢、日志上下文查詢。
• 亞秒級(jí)延遲粒度上，有全文關(guān)鍵詞的查詢、交互式 SQL 統(tǒng)計(jì)分析的需求。
• 以天為單位，需要對(duì)日志做運(yùn)營(yíng)分析，計(jì)算轉(zhuǎn)化率、設(shè)計(jì)運(yùn)營(yíng)策略。
• 一周前的產(chǎn)生的數(shù)據(jù)，大部分時(shí)候不再會(huì)被觸碰到，在支持偶爾的歷史指標(biāo)查看以外，審計(jì)場(chǎng)景下對(duì)全量日志的存儲(chǔ)也是必須項(xiàng)。

一份數(shù)據(jù)，多處使用，既要滿足業(yè)務(wù)需求，成本也是需要關(guān)心的。

自定義業(yè)務(wù)分析

云上日志設(shè)施面對(duì)的客戶群呈現(xiàn)多樣化，自定義的業(yè)務(wù)需求舉例如下：

• 電商：計(jì)算七日留存率，業(yè)務(wù)訪問(wèn) SQL 審計(jì)日志對(duì)用戶信息脫敏，等等。
• 在線教育：多平臺(tái)終端（android、ios、PC）埋點(diǎn)數(shù)據(jù)的規(guī)整，直播課堂生命周期內(nèi)的異常診斷，等等。
• 游戲：按游戲的數(shù)據(jù)分發(fā)存儲(chǔ)，全文搜索支持工單調(diào)查，等等。

阿里云 SLS 是云原生觀測(cè)分析平臺(tái)，為L(zhǎng)og/Metric/Trace等數(shù)據(jù)提供大規(guī)模、低成本、實(shí)時(shí)平臺(tái)化服務(wù)，一站式提供數(shù)據(jù)采集、加工、分析、告警可視化與投遞功能。我們將以業(yè)務(wù)為目標(biāo)的數(shù)據(jù)處理歸納為兩類(lèi)需求：

• ETL：將非結(jié)構(gòu)化的日志做預(yù)處理，為日志信息添加業(yè)務(wù)字段，數(shù)據(jù)脫敏與分發(fā)等。
• 分析：全局?jǐn)?shù)據(jù)大表上的查詢和 SQL 分析，支持布爾搜索、window、aggregate 操作等。

SLS 上的典型分析方案

對(duì)于 ETL、分析這兩類(lèi)計(jì)算任務(wù)，除了交互式分析以外，還需要常駐作業(yè)模式來(lái)處理結(jié)果落盤(pán)。

根據(jù)不同的業(yè)務(wù)需求，這里總結(jié)了幾種常見(jiàn)的 SLS 數(shù)據(jù)分析方案。

數(shù)倉(cāng) "T+1"

對(duì)于結(jié)果實(shí)時(shí)性不敏感的業(yè)務(wù)，有較多采用數(shù)倉(cāng)方案：

數(shù)據(jù)通過(guò) SLS 實(shí)時(shí)入庫(kù)，集中化存儲(chǔ)。

全托管數(shù)據(jù)投遞到 MaxCompute。

業(yè)務(wù)規(guī)劃小時(shí)級(jí)或天級(jí)的計(jì)算任務(wù)，生成下游表，產(chǎn)出業(yè)務(wù)報(bào)表等結(jié)果。

流計(jì)算

以 Flink、Spark Streaming（continuous mode）、Kafka Streams 為代表的實(shí)時(shí)計(jì)算系統(tǒng)，在數(shù)據(jù)處理語(yǔ)義（exactly-once）、計(jì)算結(jié)果修正上的能力強(qiáng)大。該方案會(huì)用到 SLS 百 ms 秒級(jí)端到端延遲的 pub/sub 能力：

數(shù)據(jù)實(shí)時(shí)推送到 SLS 日志庫(kù)。

啟動(dòng)流計(jì)算任務(wù)，從多個(gè) shard 實(shí)時(shí)消費(fèi)數(shù)據(jù)。

流計(jì)算任務(wù)根據(jù)算子組合情況（stateless、statefull、groupby 等）切分多個(gè)拓?fù)鋱?zhí)行，可能涉及到數(shù)據(jù) shuffle、watermark、state store 等機(jī)制。

這個(gè)方案在算子豐富度、實(shí)時(shí)能力、性能上綜合表現(xiàn)全面，是一把牛刀，例如在電商實(shí)時(shí)大屏場(chǎng)景上是非常好的選擇。

如果抱著挑刺的眼光來(lái)看：

• 計(jì)算引擎層面做得均衡，但缺乏存儲(chǔ)層的優(yōu)化。例如：一個(gè) logstore 上運(yùn)行 10 個(gè)流計(jì)算作業(yè)，無(wú)論實(shí)際需要納入計(jì)算范圍的數(shù)據(jù)有多少，最終需要 10 遍全部數(shù)據(jù)流量的訂閱，從業(yè)務(wù)角度上看存在網(wǎng)絡(luò)、計(jì)算資源上的浪費(fèi)。
• 對(duì)于日志用戶來(lái)說(shuō)，在參數(shù)配置、性能調(diào)優(yōu)、問(wèn)題 Debug 有復(fù)雜性（復(fù)雜常常是通用、強(qiáng)大的另一面）。在復(fù)雜場(chǎng)景下，DevOps-er 理解業(yè)務(wù)需求后，需要設(shè)置好高級(jí)參數(shù)、選擇好 state store 等。
• 計(jì)算集群部署方式，尤其對(duì)于自建集群、數(shù)據(jù)稀疏的應(yīng)用，其成本上有影響，例如 JobManager/TaskManager 等角色資源需要攤銷(xiāo)。

自建程序做流式消費(fèi)

還是圍繞 SLS 的 pub/sub 能力，以 SLS SDK 方式調(diào)用 PullData API，例如：

• 通過(guò) Logstash/Flume 等開(kāi)源軟件，加載 SLS source connector。
• 通過(guò)函數(shù)計(jì)算（SLS 提供 FC 觸發(fā)器），好處是 Serverless 的 runtime，極致彈性計(jì)費(fèi)。
• 通過(guò) SLS 的 consumer group library 處理數(shù)據(jù)，自動(dòng)負(fù)載均衡、failover。

以上對(duì)于行處理場(chǎng)景是適用的，適用面上則需要關(guān)注：

• 該方案在絕大部分情況下都不涉及全局計(jì)算（窗口、聚集），即使能實(shí)現(xiàn)也很復(fù)雜。
• 自建程序、開(kāi)源軟件需要運(yùn)維人力以及固定機(jī)器投入的成本。

自建程序做查詢、分析

在 SLS 的流式存儲(chǔ)之上，開(kāi)啟了索引分析功能，帶來(lái)了全文索引、列式下推、SQL 計(jì)算能力加持。

該方案調(diào)用 SLS GetLogs API，部署一個(gè)常駐程序，設(shè)置定時(shí)觸發(fā)器，周期調(diào)度任務(wù)執(zhí)行：

調(diào)用 API 讀取 SLS 索引并計(jì)算數(shù)據(jù)。

讀取計(jì)算結(jié)果寫(xiě)出到目標(biāo)做存儲(chǔ)。

用戶除了需要運(yùn)維程序，還需要考慮以下需求：

• SQL 運(yùn)行可能因計(jì)算量巨大而超時(shí)，失敗時(shí)需調(diào)度層的重試支持。
• 執(zhí)行延遲時(shí)告警支持。
• 調(diào)度元信息（schedule_time 等）持久化。
• web console 管理的需求。
• 如何將 SQL 計(jì)算結(jié)果 exactly-once 入庫(kù)。

本文后續(xù)重點(diǎn)介紹的 Scheduled SQL，從本質(zhì)上來(lái)講，是對(duì)該方案的服務(wù)化，對(duì)以上問(wèn)題有更全面的考慮。

SLS 告警

對(duì)，你沒(méi)看錯(cuò)。有少數(shù)用戶用 SLS 告警曲線救國(guó)，圖的是一個(gè)全托管、免運(yùn)維。

SLS 告警功能支持設(shè)置定時(shí)策略，執(zhí)行多個(gè) SQL 獲取結(jié)果，并將結(jié)果編排后發(fā)送到內(nèi)置 logstore（internal-alert-history）或自定義的網(wǎng)關(guān)/webhook。

需要說(shuō)明的是，告警的主要設(shè)計(jì)場(chǎng)景是面向小的計(jì)算結(jié)果，按觸發(fā)策略、值班表，將事件傳達(dá)給接收者。對(duì)于嚴(yán)苛的業(yè)務(wù)，不推薦這種做法（可以關(guān)注 Scheduled SQL 功能做遷移）：

• 告警的結(jié)果寫(xiě)出可能出現(xiàn)寫(xiě)出數(shù)據(jù)大小截?cái)?#xff08;1 MB 內(nèi)）、 exactly-once 等問(wèn)題。
• 告警 1.0 是串行調(diào)度，某一次計(jì)算發(fā)生延遲后，多次執(zhí)行實(shí)例的 SQL 時(shí)間窗口會(huì)出現(xiàn)空洞。

SLS 原生數(shù)據(jù)處理方案

用一張圖描述 SLS 原生數(shù)據(jù)處理功能如下，接下來(lái)分別按存儲(chǔ)模型展開(kāi)介紹：

stream 模型

例如通過(guò) Flink、自建消費(fèi)組程序進(jìn)行 SLS 數(shù)據(jù)分析，都基于 stream 模型。這是 SLS 最基礎(chǔ)的存儲(chǔ)形式（也稱 LogHub），可以理解為 append-only 的 log 結(jié)構(gòu)，通過(guò) 多個(gè) shard 組合實(shí)現(xiàn) IO 和存儲(chǔ)的水平擴(kuò)展。

LogHub 與開(kāi)源軟件 Kafka 是類(lèi)似的功能形態(tài)，SLS 底層是共享分布式存儲(chǔ)（盤(pán)古），這避免了 Kafka 在機(jī)器磁盤(pán)空間 re-balance、機(jī)器替換、存儲(chǔ)規(guī)模的一些缺陷。

stream 存儲(chǔ)模型在機(jī)器數(shù)據(jù)場(chǎng)景下有多重優(yōu)勢(shì)：

• 寫(xiě)入模型簡(jiǎn)單，不需要 commit 機(jī)制，天生支持流式寫(xiě)入，客戶端（移動(dòng)端設(shè)備、Agent）友好。
• append-only 保證了寫(xiě)入吞吐的設(shè)計(jì)上限，滿足業(yè)務(wù)高并發(fā)、高吞吐需求。
• FIFO 的 changelog 模式，滿足大多數(shù)日志、指標(biāo)類(lèi)數(shù)據(jù)的生成與使用場(chǎng)景。

針對(duì)流式數(shù)據(jù) ETL 場(chǎng)景，SLS 支持?jǐn)?shù)據(jù)加工功能，可以實(shí)現(xiàn)按量付費(fèi)、全托管的行處理需求，本文不多介紹，可以參考SLS 數(shù)據(jù)加工的設(shè)計(jì)與實(shí)踐。

table 模型

當(dāng) stream 數(shù)據(jù)寫(xiě)入后，對(duì)于 shard 內(nèi)的數(shù)據(jù)，可以同時(shí)構(gòu)建一份包括倒排、列存、bitmap 等信息的索引數(shù)據(jù)。shard 內(nèi) stream 數(shù)據(jù)相當(dāng)于是正文，索引到今天有兩種形式：

• Logstore (with index)：適用于日志模型，形式上是表結(jié)構(gòu)，一條數(shù)據(jù)由多組 key-value pair 組成。
• Metricstore：對(duì)于指標(biāo)類(lèi)型數(shù)據(jù)有針對(duì)性優(yōu)化，有序排列存儲(chǔ)支持快速指標(biāo)計(jì)算，高壓縮率低存儲(chǔ)成本。

例如 Logstore，在計(jì)算時(shí)稱為 append-only Table 模型。在 SLS 場(chǎng)景下有以下優(yōu)勢(shì)：

• 計(jì)算效率高，時(shí)間（一級(jí)索引）過(guò)濾、計(jì)算下推都可以直接利用 index 進(jìn)行，節(jié)省網(wǎng)絡(luò)、計(jì)算的性能開(kāi)銷(xiāo)與計(jì)算成本。當(dāng)然，index 會(huì)有構(gòu)建費(fèi)用，SLS 的一份 index 數(shù)據(jù)可以服務(wù)于多個(gè)業(yè)務(wù)場(chǎng)景（告警、儀表盤(pán)、全文搜索、監(jiān)控）來(lái)攤銷(xiāo)成本。
• OLAP 解決確定性問(wèn)題，按照條件過(guò)濾取到數(shù)據(jù)后，直接進(jìn)行計(jì)算即可，不需要考慮流計(jì)算中 watermark、trigger 與 window 配合、state store 數(shù)據(jù)膨脹（特定場(chǎng)景）等復(fù)雜問(wèn)題。

Scheduled SQL 讓 SQL 可調(diào)度

SLS 的每一次 SQL 計(jì)算針對(duì)預(yù)定的一片數(shù)據(jù)做處理，因此，對(duì)全部時(shí)間區(qū)間（從現(xiàn)在開(kāi)始一直到未來(lái)）數(shù)據(jù)的 SQL 分析依賴于上層調(diào)度，也就是將要介紹的新功能 Scheduled SQL，它支持標(biāo)準(zhǔn)SQL、SLS 查詢和分析語(yǔ)句，按照調(diào)度規(guī)則周期性執(zhí)行，并將運(yùn)行結(jié)果寫(xiě)入到目標(biāo)庫(kù)中。可用于以下場(chǎng)景：

• 定時(shí)分析數(shù)據(jù)：根據(jù)業(yè)務(wù)需求設(shè)置分析語(yǔ)句，定時(shí)執(zhí)行，并將分析結(jié)果存儲(chǔ)到目標(biāo)庫(kù)中。
• 全局聚合：對(duì)全量、細(xì)粒度的數(shù)據(jù)進(jìn)行聚合存儲(chǔ)，匯總為存儲(chǔ)大小、精度適合的數(shù)據(jù)，相當(dāng)于一定程度的有損壓縮數(shù)據(jù)。例如按照秒級(jí)別對(duì) 36 億條數(shù)據(jù)進(jìn)行聚合存儲(chǔ)，存儲(chǔ)結(jié)果為 3150 萬(wàn)條數(shù)據(jù)，存儲(chǔ)大小為全量數(shù)據(jù)的0.875%。
• 投影與過(guò)濾：對(duì)原始數(shù)據(jù)的字段進(jìn)行篩選，按照一定條件過(guò)濾數(shù)據(jù)并存儲(chǔ)到目標(biāo)Logstore中。該功能還可以通過(guò)數(shù)據(jù)加工實(shí)現(xiàn)，數(shù)據(jù)加工的DSL語(yǔ)法比SQL語(yǔ)法具備更強(qiáng)的ETL表達(dá)能力，更多信息請(qǐng)參見(jiàn)加工原理。

Scheduled SQL 相比于自建程序調(diào)用 SLS API 而言，有以下優(yōu)勢(shì)：

• SQL 運(yùn)行 timeout 提升至 600 秒，單次最大處理百億級(jí)數(shù)據(jù)。
• 計(jì)算資源池可選：免費(fèi)（project 級(jí) 15 并發(fā)）、付費(fèi)（彈性擴(kuò)展，參考SQL 獨(dú)享實(shí)例）。
• 最小 1 分鐘周期執(zhí)行，支持常駐或固定時(shí)間區(qū)間內(nèi)調(diào)度運(yùn)行。
• 支持靈活的查詢時(shí)間窗口參數(shù)配置，滿足多樣化需求。
• exactly-once 寫(xiě)入目標(biāo)庫(kù)。
• 完善的作業(yè)實(shí)例查看、重試支持（控制臺(tái)、API）。
• 全托管運(yùn)行，自動(dòng)處理多種異常，調(diào)度不收費(fèi)。
• 實(shí)例執(zhí)行失敗集成 SLS 告警通知。

Scheduled SQL 功能介紹

工作機(jī)制

Scheduled SQL 涉及以下幾個(gè)重要概念：

• 作業(yè)：一個(gè) Scheduled SQL 任務(wù)對(duì)應(yīng)一個(gè)作業(yè)，包括調(diào)度策略、計(jì)算規(guī)則等信息。
• 實(shí)例：一個(gè) Scheduled SQL 作業(yè)按照調(diào)度配置按時(shí)生成執(zhí)行實(shí)例。每一個(gè)實(shí)例對(duì)原始數(shù)據(jù)進(jìn)行 SQL 計(jì)算并將計(jì)算結(jié)果寫(xiě)入目標(biāo)庫(kù)。實(shí)例ID 是其唯一標(biāo)識(shí)。
• 創(chuàng)建時(shí)間：實(shí)例的創(chuàng)建時(shí)間。一般是按照您配置的調(diào)度規(guī)則生成，在補(bǔ)運(yùn)行或追趕延遲時(shí)會(huì)立即生成實(shí)例。
• 調(diào)度時(shí)間：由調(diào)度規(guī)則生成，不會(huì)受到上一個(gè)實(shí)例執(zhí)行超時(shí)、延遲、補(bǔ)運(yùn)行等情況的影響。大部分場(chǎng)景下，連續(xù)生成的實(shí)例的調(diào)度時(shí)間是連續(xù)的，可處理完整的數(shù)據(jù)集。

流計(jì)算里有大量篇幅用于處理數(shù)據(jù)計(jì)算的一致性、完整性問(wèn)題，Scheduled SQL 則是一種以 small-batch 模擬常駐計(jì)算的方案，針對(duì)這兩個(gè)問(wèn)題的設(shè)計(jì)是：

計(jì)算一致性

• • SQL 每次執(zhí)行會(huì)對(duì)應(yīng)到確定的時(shí)間窗口，由此得到確定數(shù)據(jù)集再調(diào)度 SQL 計(jì)算。Scheduled SQL 實(shí)例運(yùn)行時(shí)，SQL 查詢的時(shí)間窗口是基于調(diào)度時(shí)間渲染得到，左閉右開(kāi)格式，與實(shí)例的創(chuàng)建時(shí)間、執(zhí)行時(shí)間無(wú)關(guān)。例如調(diào)度時(shí)間為2021/01/01 10:00:00，SQL時(shí)間窗口的表達(dá)式為[@m - 10m, @m)，則實(shí)際的SQL時(shí)間窗口為[2021/01/01 09:50:00, 2021/01/01 10:00:00)。
  • SQL 計(jì)算的結(jié)果在插入目標(biāo)時(shí)，需要考慮數(shù)據(jù)重復(fù)可能帶來(lái)的業(yè)務(wù)影響。對(duì)于 append 模式寫(xiě)，例如 Scheduled SQL 結(jié)果寫(xiě) Logstore，寫(xiě)入客戶端與 SLS 服務(wù)端實(shí)現(xiàn)了 exactly-once 協(xié)議。對(duì)于 overwrite 模式寫(xiě)，更容易做到原子性，未來(lái)會(huì)規(guī)劃 Scheduled SQL 寫(xiě)數(shù)據(jù)庫(kù)的支持。

數(shù)據(jù)的完整性

• • 作業(yè)上設(shè)置延遲執(zhí)行參數(shù)從業(yè)務(wù)上給與指導(dǎo)，在實(shí)例的調(diào)度時(shí)間點(diǎn)上，往后延遲 N 秒才真正開(kāi)始觸發(fā)實(shí)例運(yùn)行，而實(shí)例查詢的時(shí)間范圍不受延遲參數(shù)影響。例如設(shè)置調(diào)度間隔為每小時(shí)、延遲執(zhí)行為30秒，那么一天生成24個(gè)實(shí)例，其中某實(shí)例的調(diào)度時(shí)間為2021/4/6 12:00:00，執(zhí)行時(shí)間為2021/4/6 12:00:30。這個(gè)設(shè)計(jì)在大部分場(chǎng)景下可以解決數(shù)據(jù)遲到問(wèn)題，但對(duì)于寫(xiě) logstore 存儲(chǔ)（數(shù)據(jù)寫(xiě)入后將無(wú)法更新）來(lái)說(shuō)，完全避免延遲問(wèn)題是難以實(shí)現(xiàn)的。極端情況下，數(shù)據(jù)遲到問(wèn)題可通過(guò)事后的實(shí)例重試來(lái)補(bǔ)結(jié)果。
  • 將 SQL 查詢的時(shí)間窗口按分鐘對(duì)齊（例如整分鐘），以保證在 SLS 索引模型優(yōu)化（batch log-group 組成倒排 doc）時(shí)依然能保證絕對(duì)的計(jì)算準(zhǔn)確。

調(diào)度場(chǎng)景

Scheduled SQL 作業(yè)依次調(diào)度多個(gè)實(shí)例執(zhí)行，無(wú)論是正常被調(diào)度還是被動(dòng)異常實(shí)例重試的情況，同時(shí)只有一個(gè)實(shí)例處于運(yùn)行中，不存在多個(gè)實(shí)例并發(fā)執(zhí)行的情況。

在 SLS 數(shù)據(jù)場(chǎng)景下，主要的幾種調(diào)度場(chǎng)景如下：

• 場(chǎng)景一：實(shí)例延遲執(zhí)行

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

• 場(chǎng)景二：從某個(gè)歷史時(shí)間點(diǎn)開(kāi)始執(zhí)行Scheduled SQL作業(yè)

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

• 場(chǎng)景三：固定時(shí)間內(nèi)執(zhí)行Scheduled SQL作業(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í)例。

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

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

• 場(chǎng)景五：重試失敗的實(shí)例

正常情況下，一個(gè)Scheduled SQL作業(yè)按照調(diào)度時(shí)間的遞增順序生成執(zhí)行實(shí)例。如果實(shí)例執(zhí)行失敗（例如權(quán)限不足、源庫(kù)不存在、目標(biāo)庫(kù)不存在、SQL語(yǔ)法不合法），系統(tǒng)支持自動(dòng)重試，當(dāng)重試次數(shù)超過(guò)您配置的最大重試次數(shù)或重試時(shí)間超過(guò)您配置的最大運(yùn)行時(shí)間時(shí)，重試結(jié)束，該實(shí)例狀態(tài)被置為失敗，然后系統(tǒng)繼續(xù)執(zhí)行下一個(gè)實(shí)例。

您可以對(duì)失敗的實(shí)例設(shè)置告警通知并進(jìn)行手動(dòng)重試。您可以對(duì)最近7天內(nèi)創(chuàng)建的實(shí)例進(jìn)行查看、重試操作。調(diào)度執(zhí)行完成后，系統(tǒng)會(huì)根據(jù)實(shí)際執(zhí)行情況變更實(shí)例狀態(tài)為成功或失敗。

Scheduled SQL 在訪問(wèn)日志上的應(yīng)用

場(chǎng)景需求

在阿里云上，SLB/OSS 的被用到很多的基礎(chǔ)計(jì)算、存儲(chǔ)服務(wù)。在使用過(guò)程中如果要得到細(xì)粒度可觀察性，都繞不過(guò)訪問(wèn)日志，在深度使用后您可能會(huì)有體感：

訪問(wèn)日志與 request 數(shù)一比一關(guān)系，數(shù)據(jù)量很大，造成存儲(chǔ)成本增加并拖慢計(jì)算。

訪問(wèn)日志有時(shí)效性，近 15 天日志需要交互式查詢分析支持，歷史數(shù)據(jù)需要具備降精度的指標(biāo)查詢能力。

訪問(wèn)日志有留存的需求，需要長(zhǎng)期存儲(chǔ)以備審計(jì)。

整體方案

以 SLB 七層訪問(wèn)日志為例，這里介紹一種實(shí)踐：

基于 Scheduled SQL 功能，將歷史原文數(shù)據(jù)壓縮為低精度數(shù)據(jù)，支持長(zhǎng)期的索引存儲(chǔ)并大大提升分析效率。

根據(jù)業(yè)務(wù)需要，原文數(shù)據(jù)支持全局搜索和無(wú)損的 SQL 分析，可以設(shè)置存儲(chǔ)周期為 15天。

歷史數(shù)據(jù)原文投遞到 OSS，支持極低成本存儲(chǔ)，低頻的審計(jì)撈數(shù)據(jù)操作也是方便的。

整體方案圖如下：

OSS投遞操作步驟參考將日志服務(wù)數(shù)據(jù)投遞到OSS。

Scheduled SQL 配置使用增強(qiáng)型資源池，默認(rèn) STS 角色授權(quán)，最終計(jì)算結(jié)果寫(xiě)同區(qū)域 Logstore：

使用Scheduled SQL時(shí)，建議根據(jù)業(yè)務(wù)情況，同時(shí)兼顧數(shù)據(jù)實(shí)時(shí)性和準(zhǔn)確性。

• 考慮數(shù)據(jù)上傳日志服務(wù)存在延遲情況，您可以結(jié)合數(shù)據(jù)采集延遲以及業(yè)務(wù)能夠容忍的最大結(jié)果可見(jiàn)延遲，設(shè)置執(zhí)行延遲和SQL時(shí)間窗口（結(jié)束時(shí)間往前一點(diǎn)），避免實(shí)例執(zhí)行時(shí)SQL時(shí)間窗口內(nèi)的數(shù)據(jù)未全部到達(dá)。
• 建議SQL時(shí)間窗口按分鐘對(duì)齊（例如整分鐘、整小時(shí)），以保證上傳局部亂序數(shù)據(jù)時(shí)的數(shù)據(jù)準(zhǔn)確度。

在這里每分鐘調(diào)度一次 SQL 計(jì)算最近一分鐘窗口的數(shù)據(jù)，并設(shè)置延遲執(zhí)行（如果對(duì)于實(shí)時(shí)性要求不高，建議這個(gè)值設(shè)置大一些）：

Scheduled SQL 寫(xiě)出到目標(biāo) Logstore 數(shù)據(jù)的結(jié)果如下圖，其中 tag 字段是系統(tǒng)默認(rèn)添加的信息，用于數(shù)據(jù)的搠源。

Scheduled SQL 調(diào)度生成的實(shí)例信息在任務(wù)管理頁(yè)面可以查看，對(duì)于失敗的任務(wù)可以做重試。

方案效果

• 功能體驗(yàn)上：

• ? 熱、溫?cái)?shù)據(jù)存儲(chǔ)、分析，支持交互式查詢、分析的能力，保留了靈活性。
• 冷數(shù)據(jù)分析，支持分鐘粒度的自定義指標(biāo)查詢（例如本文是 host、method、status 維度統(tǒng)計(jì)），可以快速實(shí)現(xiàn)問(wèn)題分析，同樣查詢范圍延遲降低兩個(gè)數(shù)量級(jí)。
• 冷數(shù)據(jù)存儲(chǔ)，以壓縮格式投遞到 OSS 存儲(chǔ)，保留了審計(jì)能力。
• 存儲(chǔ)成本上：在永久存儲(chǔ)的背景下，存儲(chǔ)量降低到之前的 1/1000，OSS 上的壓縮格式存儲(chǔ)且做到極低的單價(jià)。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Scheduled SQL： SLS 大规模日志上的全局分析与调度的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。