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

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

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

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

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

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

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

對于同一份日志，可能被多種用戶角色在多種場景下使用到：

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

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

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

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

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

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

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

SLS 上的典型分析方案

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

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

數(shù)倉 "T+1"

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

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

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

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

流計(jì)算

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

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

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

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

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

如果抱著挑刺的眼光來看：

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

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

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

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

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

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

自建程序做查詢、分析

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

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

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

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

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

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

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

SLS 告警

對，你沒看錯。有少數(shù)用戶用 SLS 告警曲線救國，圖的是一個全托管、免運(yùn)維。

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

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

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

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

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

stream 模型

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

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

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

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

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

table 模型

當(dāng) stream 數(shù)據(jù)寫入后，對于 shard 內(nèi)的數(shù)據(jù)，可以同時構(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：對于指標(biāo)類型數(shù)據(jù)有針對性優(yōu)化，有序排列存儲支持快速指標(biāo)計(jì)算，高壓縮率低存儲成本。

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

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

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

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

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

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

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

Scheduled SQL 功能介紹

工作機(jī)制

Scheduled SQL 涉及以下幾個重要概念：

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

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

計(jì)算一致性

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

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

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

調(diào)度場景

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

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

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

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

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

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

• 場景三：固定時間內(nèi)執(zhí)行Scheduled SQL作業(yè)

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

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

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

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

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

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

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

場景需求

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

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

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

訪問日志有留存的需求，需要長期存儲以備審計(jì)。

整體方案

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

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

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

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

整體方案圖如下：

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

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

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

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

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

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

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

方案效果

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

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

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

總結(jié)

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

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