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

數據大規模與時效性

基于時間的數據（日志、指標）在日積月累后的數量是驚人的。以 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"

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

數據通過 SLS 實時入庫，集中化存儲。
全托管數據投遞到 MaxCompute。
業務規劃小時級或天級的計算任務，生成下游表，產出業務報表等結果。

流計算

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

數據實時推送到 SLS 日志庫。
啟動流計算任務，從多個 shard 實時消費數據。
流計算任務根據算子組合情況（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，部署一個常駐程序，設置定時觸發器，周期調度任務執行：

調用 API 讀取 SLS 索引并計算數據。
讀取計算結果寫出到目標做存儲。
用戶除了需要運維程序，還需要考慮以下需求：

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 寫數據庫的支持。
2.數據的完整性

作業上設置延遲執行參數從業務上給與指導，在實例的調度時間點上，往后延遲 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 的被用到很多的基礎計算、存儲服務。在使用過程中如果要得到細粒度可觀察性，都繞不過訪問日志，在深度使用后您可能會有體感：

訪問日志與 request 數一比一關系，數據量很大，造成存儲成本增加并拖慢計算。
訪問日志有時效性，近 15 天日志需要交互式查詢分析支持，歷史數據需要具備降精度的指標查詢能力。
訪問日志有留存的需求，需要長期存儲以備審計。

整體方案

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

基于 Scheduled SQL 功能，將歷史原文數據壓縮為低精度數據，支持長期的索引存儲并大大提升分析效率。
根據業務需要，原文數據支持全局搜索和無損的 SQL 分析，可以設置存儲周期為 15天。
歷史數據原文投遞到 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 上的壓縮格式存儲且做到極低的單價。