大規模日誌全域性分析的需求

資料大規模與時效性

基於時間的資料（日誌、指標）在日積月累後的數量是驚人的。以 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 寫資料庫的支援。

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 的被用到很多的基礎計算、儲存服務。在使用過程中如果要得到細粒度可觀察性，都繞不過訪問日誌，在深度使用後您可能會有體感：

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 上的壓縮格式儲存且做到極低的單價。

原文連結
本文為阿里雲原創內容，未經允許不得轉載。