Scheduled SQL： SLS 大規模日志上的全局分析與排程

大規模日志全局分析的需求

資料大規模與時效性

基于時間的資料（日志、名額）在日積月累後的數量是驚人的。以 SLB 七層通路日志為例，每一個HTTP/HTTPS 通路請求會記錄一條 access log，假設每天産生1000萬條資料，則一年為36億條資料。一方面，長時間的資料存儲需要巨大的存儲空間，而通過減少存儲周期的方式降低存儲空間，雖然控制了存儲成本，但也丢失了有價值的曆史資料。另一方面，大量的資料将造成分析上的性能壓力。

大部分時序資料具有時效性特征。曆史資料可以接受分鐘或小時級别的精度，而新産生的資料需要更高的精度（例如監控、線上問題調查）。資料營運、分析師需要存儲全量的資料以備分析，曆史資料直接 TTL 删除是可能最差的選擇。

例如 Elasticsearch rollup、時序資料庫的降精度用于解決這部分問題。

一份資料在多種場景使用

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

• 實時的資料，需要支援關鍵詞告警、時序資料 ML 巡檢、日志上下文查詢。
• 亞秒級延遲粒度上，有全文關鍵詞的查詢、互動式 SQL 統計分析的需求。
• 以天為機關，需要對日志做營運分析，計算轉化率、設計營運政策。
• 一周前的産生的資料，大部分時候不再會被觸碰到，在支援偶爾的曆史名額檢視以外，審計場景下對全量日志的存儲也是必須項。

一份資料，多處使用，既要滿足業務需求，成本也是需要關心的。

自定義業務分析

雲上日志設施面對的客戶群呈現多樣化，自定義的業務需求舉例如下：

• 電商：計算七日留存率，業務通路 SQL 審計日志對使用者資訊脫敏，等等。
• 線上教育：多平台終端（android、ios、PC）埋點資料的規整，直播課堂生命周期内的異常診斷，等等。
• 遊戲：按遊戲的資料分發存儲，全文搜尋支援工單調查，等等。

阿裡雲 SLS

是雲原生觀測分析平台，為Log/Metric/Trace等資料提供大規模、低成本、實時平台化服務，一站式提供資料采集、加工、分析、告警可視化與投遞功能。我們将以業務為目标的資料處理歸納為兩類需求：

• ETL：将非結構化的日志做預處理，為日志資訊添加業務字段，資料脫敏與分發等。
• 分析：全局資料大表上的查詢和 SQL 分析，支援布爾搜尋、window、aggregate 操作等。

SLS 上的典型分析方案

對于 ETL、分析這兩類計算任務，除了互動式分析以外，還需要常駐作業模式來處理結果落盤。

根據不同的業務需求，這裡總結了幾種常見的 SLS 資料分析方案。

數倉 "T+1"

對于結果實時性不敏感的業務，有較多采用數倉方案：

1. 資料通過 SLS 實時入庫，集中化存儲。
2. 全托管資料投遞到 MaxCompute。
3. 業務規劃小時級或天級的計算任務，生成下遊表，産出業務報表等結果。

流計算

以 Flink、Spark Streaming（continuous mode）、Kafka Streams 為代表的實時計算系統，在資料處理語義（exactly-once）、計算結果修正上的能力強大。該方案會用到 SLS 百 ms 秒級端到端延遲的 pub/sub 能力：

1. 資料實時推送到 SLS 日志庫。
2. 啟動流計算任務，從多個 shard 實時消費資料。
3. 流計算任務根據算子組合情況（stateless、statefull、groupby 等）切分多個拓撲執行，可能涉及到資料 shuffle、watermark、state store 等機制。

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

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

• 計算引擎層面做得均衡，但缺乏存儲層的優化。例如：一個 logstore 上運作 10 個流計算作業，無論實際需要納入計算範圍的資料有多少，最終需要 10 遍全部資料流量的訂閱，從業務角度上看存在網絡、計算資源上的浪費。
• 對于日志使用者來說，在參數配置、性能調優、問題 Debug 有複雜性（複雜常常是通用、強大的另一面）。在複雜場景下，DevOps-er 了解業務需求後，需要設定好進階參數、選擇好 state store 等。
• 計算叢集部署方式，尤其對于自建叢集、資料稀疏的應用，其成本上有影響，例如 JobManager/TaskManager 等角色資源需要攤銷。

自建程式做流式消費

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

• 通過 Logstash/Flume 等開源軟體，加載 SLS source connector。
• 通過函數計算（SLS 提供 FC 觸發器），好處是 Serverless 的 runtime，極緻彈性計費。
• 通過 SLS 的 consumer group library 處理資料，自動負載均衡、failover。

以上對于行處理場景是适用的，适用面上則需要關注：

• 該方案在絕大部分情況下都不涉及全局計算（視窗、聚集），即使能實作也很複雜。
• 自建程式、開源軟體需要運維人力以及固定機器投入的成本。

自建程式做查詢、分析

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

該方案調用 SLS GetLogs API，部署一個常駐程式，設定定時觸發器，周期排程任務執行：

1. 調用 API 讀取 SLS 索引并計算資料。
2. 讀取計算結果寫出到目标做存儲。

使用者除了需要運維程式，還需要考慮以下需求：

• SQL 運作可能因計算量巨大而逾時，失敗時需排程層的重試支援。
• 執行延遲時告警支援。
• 排程元資訊（schedule_time 等）持久化。
• web console 管理的需求。
• 如何将 SQL 計算結果 exactly-once 入庫。

本文後續重點介紹的 Scheduled SQL，從本質上來講，是對該方案的服務化，對以上問題有更全面的考慮。

SLS 告警

對，你沒看錯。有少數使用者用 SLS 告警曲線救國，圖的是一個全托管、免運維。

SLS 告警功能支援設定定時政策，執行多個 SQL 擷取結果，并将結果編排後發送到内置 logstore（internal-alert-history）或自定義的網關/webhook。

需要說明的是，告警的主要設計場景是面向小的計算結果，按觸發政策、值班表，将事件傳達給接收者。對于嚴苛的業務，不推薦這種做法（可以關注 Scheduled SQL 功能做遷移）：

• 告警的結果寫出可能出現寫出資料大小截斷（1 MB 内）、 exactly-once 等問題。
• 告警 1.0 是串行排程，某一次計算發生延遲後，多次執行執行個體的 SQL 時間視窗會出現空洞。

SLS 原生資料處理方案

用一張圖描述 SLS 原生資料處理功能如下，接下來分别按存儲模型展開介紹：

stream 模型

例如通過 Flink、自建消費組程式進行 SLS 資料分析，都基于 stream 模型。這是 SLS 最基礎的存儲形式（也稱 LogHub），可以了解為 append-only 的 log 結構，通過 多個 shard 組合實作 IO 和存儲的水準擴充。

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

stream 存儲模型在機器資料場景下有多重優勢：

• 寫入模型簡單，不需要 commit 機制，天生支援流式寫入，用戶端（移動端裝置、Agent）友好。
• append-only 保證了寫入吞吐的設計上限，滿足業務高并發、高吞吐需求。
• FIFO 的 changelog 模式，滿足大多數日志、名額類資料的生成與使用場景。

針對流式資料 ETL 場景，SLS 支援資料加工功能，可以實作按量付費、全托管的行處理需求，本文不多介紹，可以參考

SLS 資料加工的設計與實踐

。

table 模型

當 stream 資料寫入後，對于 shard 内的資料，可以同時建構一份包括倒排、列存、bitmap 等資訊的索引資料。shard 内 stream 資料相當于是正文，索引到今天有兩種形式：

• Logstore (with index)：适用于日志模型，形式上是表結構，一條資料由多組 key-value pair 組成。
• Metricstore：對于名額類型資料有針對性優化，有序排列存儲支援快速名額計算，高壓縮率低存儲成本。

例如 Logstore，在計算時稱為 append-only Table 模型。在 SLS 場景下有以下優勢：

• 計算效率高，時間（一級索引）過濾、計算下推都可以直接利用 index 進行，節省網絡、計算的性能開銷與計算成本。當然，index 會有建構費用，SLS 的一份 index 資料可以服務于多個業務場景（告警、儀表盤、全文搜尋、監控）來攤銷成本。
• OLAP 解決确定性問題，按照條件過濾取到資料後，直接進行計算即可，不需要考慮流計算中 watermark、trigger 與 window 配合、state store 資料膨脹（特定場景）等複雜問題。

Scheduled SQL 讓 SQL 可排程

SLS 的每一次 SQL 計算針對預定的一片資料做處理，是以，對全部時間區間（從現在開始一直到未來）資料的 SQL 分析依賴于上層排程，也就是将要介紹的新功能 Scheduled SQL，它支援标準SQL、SLS 查詢和分析語句，按照排程規則周期性執行，并将運作結果寫入到目标庫中。可用于以下場景：

• 定時分析資料：根據業務需求設定分析語句，定時執行，并将分析結果存儲到目标庫中。
• 全局聚合：對全量、細粒度的資料進行聚合存儲，彙總為存儲大小、精度适合的資料，相當于一定程度的有損壓縮資料。例如按照秒級别對 36 億條資料進行聚合存儲，存儲結果為 3150 萬條資料，存儲大小為全量資料的0.875%。
• 投影與過濾：對原始資料的字段進行篩選，按照一定條件過濾資料并存儲到目标Logstore中。該功能還可以通過資料加工實作，資料加工的DSL文法比SQL文法具備更強的ETL表達能力，更多資訊請參見 加工原理

Scheduled SQL 相比于自建程式調用 SLS API 而言，有以下優勢：

• SQL 運作 timeout 提升至 600 秒，單次最大處理百億級資料。
• 計算資源池可選：免費（project 級 15 并發）、付費（彈性擴充，參考 SQL 獨享執行個體 ）。
• 最小 1 分鐘周期執行，支援常駐或固定時間區間内排程運作。
• 支援 靈活的查詢時間視窗 參數配置，滿足多樣化需求。
• exactly-once 寫入目标庫。
• 完善的作業執行個體檢視、重試支援（控制台、API）。
• 全托管運作，自動處理多種異常，排程不收費。
• 執行個體執行失敗內建 SLS 告警通知。

Scheduled SQL 功能介紹

工作機制

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

• 作業：一個 Scheduled SQL 任務對應一個作業，包括排程政策、計算規則等資訊。
• 執行個體：一個 Scheduled SQL 作業按照排程配置按時生成執行執行個體。每一個執行個體對原始資料進行 SQL 計算并将計算結果寫入目标庫。執行個體ID 是其唯一辨別。
• 建立時間：執行個體的建立時間。一般是按照您配置的排程規則生成，在補運作或追趕延遲時會立即生成執行個體。
• 排程時間：由排程規則生成，不會受到上一個執行個體執行逾時、延遲、補運作等情況的影響。大部分場景下，連續生成的執行個體的排程時間是連續的，可處理完整的資料集。

流計算裡有大量篇幅用于處理資料計算的一緻性、完整性問題，Scheduled SQL 則是一種以 small-batch 模拟常駐計算的方案，針對這兩個問題的設計是：

1. 計算一緻性

• • SQL 每次執行會對應到确定的時間視窗，由此得到确定資料集再排程 SQL 計算。Scheduled SQL 執行個體運作時，SQL 查詢的時間視窗是基于排程時間渲染得到，左閉右開格式，與執行個體的建立時間、執行時間無關。例如排程時間為

    2021/01/01 10:00:00

    ，SQL時間視窗的表達式為

    [@m - 10m, @m)

    ，則實際的SQL時間視窗為

    [2021/01/01 09:50:00, 2021/01/01 10:00:00)

  • SQL 計算的結果在插入目标時，需要考慮資料重複可能帶來的業務影響。對于 append 模式寫，例如 Scheduled SQL 結果寫 Logstore，寫入用戶端與 SLS 服務端實作了 exactly-once 協定。對于 overwrite 模式寫，更容易做到原子性，未來會規劃 Scheduled SQL 寫資料庫的支援。

1. 資料的完整性

• • 作業上設定延遲執行參數從業務上給與指導，在執行個體的排程時間點上，往後延遲 N 秒才真正開始觸發執行個體運作，而執行個體查詢的時間範圍不受延遲參數影響。例如設定排程間隔為每小時、延遲執行為30秒，那麼一天生成24個執行個體，其中某執行個體的排程時間為

    2021/4/6 12:00:00

    ，執行時間為

    2021/4/6 12:00:30

    。這個設計在大部分場景下可以解決資料遲到問題，但對于寫 logstore 存儲（資料寫入後将無法更新）來說，完全避免延遲問題是難以實作的。極端情況下，資料遲到問題可通過事後的執行個體重試來補結果。
  • 将 SQL 查詢的時間視窗按分鐘對齊（例如整分鐘），以保證在 SLS 索引模型優化（batch log-group 組成倒排 doc）時依然能保證絕對的計算準确。

排程場景

Scheduled SQL 作業依次排程多個執行個體執行，無論是正常被排程還是被動異常執行個體重試的情況，同時隻有一個執行個體處于運作中，不存在多個執行個體并發執行的情況。

在 SLS 資料場景下，主要的幾種排程場景如下：

• 場景一：執行個體延遲執行

無論執行個體是否延遲執行，執行個體的排程時間都是根據排程規則預先生成的。雖然前面的執行個體發生延遲時，可能導緻後面的執行個體也延遲執行，但通過追趕執行進度，可逐漸減少延遲，直到恢複準時運作。

• 場景二：從某個曆史時間點開始執行Scheduled SQL作業

在目前時間點建立Scheduled SQL作業後，按照排程規則對曆史資料進行處理，從排程的開始時間建立補運作的執行個體，補運作的執行個體依次執行直到追上資料處理進度後，再按照預定計劃執行新執行個體。

• 場景三：固定時間内執行Scheduled SQL作業

如果需要對指定時間段的日志做排程，則可設定排程的時間範圍。如果設定了排程的結束時間，則最後一個執行個體（排程時間小于排程結束時間）執行完成後，不再産生新的執行個體。

• 場景四：修改排程配置對生成執行個體的影響

修改排程配置後，下一個執行個體按照新配置生成。一般建議同步修改SQL時間視窗、排程頻率等配置，使得執行個體之間的SQL時間範圍可以連續。

• 場景五：重試失敗的執行個體

正常情況下，一個Scheduled SQL作業按照排程時間的遞增順序生成執行執行個體。如果執行個體執行失敗（例如權限不足、源庫不存在、目标庫不存在、SQL文法不合法），系統支援自動重試，當重試次數超過您配置的最大重試次數或重試時間超過您配置的最大運作時間時，重試結束，該執行個體狀态被置為失敗，然後系統繼續執行下一個執行個體。

您可以對失敗的執行個體設定告警通知并進行手動重試。您可以對最近7天内建立的執行個體進行檢視、重試操作。排程執行完成後，系統會根據實際執行情況變更執行個體狀态為成功或失敗。

Scheduled SQL 在通路日志上的應用

場景需求

在阿裡雲上，SLB/OSS 的被用到很多的基礎計算、存儲服務。在使用過程中如果要得到細粒度可觀察性，都繞不過通路日志，在深度使用後您可能會有體感：

1. 通路日志與 request 數一比一關系，資料量很大，造成存儲成本增加并拖慢計算。
2. 通路日志有時效性，近 15 天日志需要互動式查詢分析支援，曆史資料需要具備降精度的名額查詢能力。
3. 通路日志有留存的需求，需要長期存儲以備審計。

整體方案

以 SLB 七層通路日志為例，這裡介紹一種實踐：

1. 基于 Scheduled SQL 功能，将曆史原文資料壓縮為低精度資料，支援長期的索引存儲并大大提升分析效率。
2. 根據業務需要，原文資料支援全局搜尋和無損的 SQL 分析，可以設定存儲周期為 15天。
3. 曆史資料原文投遞到 OSS，支援極低成本存儲，低頻的審計撈資料操作也是友善的。

整體方案圖如下：

OSS投遞操作步驟參考

将日志服務資料投遞到OSS

Scheduled SQL 配置使用增強型資源池，預設 STS 角色授權，最終計算結果寫同區域 Logstore：

使用Scheduled SQL時，建議根據業務情況，同時兼顧資料實時性和準确性。

• 考慮資料上傳日志服務存在延遲情況，您可以結合資料采集延遲以及業務能夠容忍的最大結果可見延遲，設定執行延遲和SQL時間視窗（結束時間往前一點），避免執行個體執行時SQL時間視窗内的資料未全部到達。
• 建議SQL時間視窗按分鐘對齊（例如整分鐘、整小時），以保證上傳局部亂序資料時的資料準确度。

在這裡每分鐘排程一次 SQL 計算最近一分鐘視窗的資料，并設定延遲執行（如果對于實時性要求不高，建議這個值設定大一些）：

Scheduled SQL 寫出到目标 Logstore 資料的結果如下圖，其中 tag 字段是系統預設添加的資訊，用于資料的搠源。

Scheduled SQL 排程生成的執行個體資訊在任務管理頁面可以檢視，對于失敗的任務可以做重試。

方案效果

• 功能體驗上：

• • 熱、溫資料存儲、分析，支援互動式查詢、分析的能力，保留了靈活性。
  • 冷資料分析，支援分鐘粒度的自定義名額查詢（例如本文是 host、method、status 次元統計），可以快速實作問題分析，同樣查詢範圍延遲降低兩個數量級。
  • 冷資料存儲，以壓縮格式投遞到 OSS 存儲，保留了審計能力。

• 存儲成本上：在永久存儲的背景下，存儲量降低到之前的 1/1000，OSS 上的壓縮格式存儲且做到極低的單價。

注：目前 Scheduled SQL 已釋出部分區域（參考

快速開始使用 Scheduled SQL

），其它區域正在逐個開放中，如有問題或需求可以工單或釘釘群聯系 SLS 團隊。