作者：戴志勇

當“即查即算”遇上數據爆炸

你是否經歷過這樣的場景？

在阿里雲日誌服務裏，一個看似簡單的看板，點開卻要等上幾十秒；高峯期多人同時查日誌，系統直接“卡成 PPT”；更糟的是，有時結果還不準——因為達到資源限制，系統只能“估算”答案。

這背後，是日誌規模爆炸式增長帶來的現實困境：當數據量從 GB 躍升至 TB 甚至 PB 級，“邊查邊算”的傳統模式已力不從心。

• 查得慢： 複雜聚合動輒幾十秒，看板刷新比泡杯咖啡還久
• 扛不住： 一到高峯，查詢互相搶資源，一個慢、全鏈路崩
• 不準了： 資源超限被迫降級，數據失真，決策風險陡增

而這些痛點，恰恰集中在最常用的場景——監控大屏、運營看板、實時報表。它們有個共同特點：查詢模式固定、時間跨度大、但要求秒級響應、結果精準。

現在，阿里雲日誌服務帶來破局利器——物化視圖。

它就像給你的日誌數據“提前算好答案，存好快照”。通過智能增量預計算 + 自動查詢改寫，系統在後台默默把高頻查詢的結果提前準備好。當你發起請求時，不再掃描全量原始日誌，而是直接讀取預計算結果——查詢速度提升數十倍乃至百倍，資源消耗大幅降低，結果還更穩、更準。

用一點額外的存儲空間，換回秒級洞察力。從此，再大的日誌量，也能做到“點開即見，所見即所得”。

日誌服務物化視圖優勢

物化視圖的核心思想是：用額外的存儲空間，換來查詢速度的飛躍。日誌服務的物化視圖主要支持兩種場景的查詢加速。

1. 過濾加速：只留“有用”的日誌

比如你只關心“錯誤日誌”，物化視圖會提前把所有 error 級別的日誌篩選出來單獨存好。下次查錯誤，就不用翻遍全部日誌，直接查這個“精選集”，速度提升幾十倍。

2. 預聚合加速：提前算好統計結果

比如每天要統計“各地區的用户訪問量”，物化視圖會每隔一段時間自動算好這個數據並存起來。你查的時候，系統直接拿現成結果，不用再從原始日誌裏一條條加總——數據量可能從億行變成百行。

與業界其他物化視圖方案相比，日誌服務物化視圖具有以下優勢：

1. 異步物化視圖，增量刷新，不影響寫入性能

物化視圖的構建完全獨立於數據寫入流程，採用異步更新機制，每次刷新只針對新寫入的數據，更新任務由後端託管，對用户透明。

2. 自動數據合併，寫入即可查

自動合併未物化的最近數據和已物化的歷史結果，有效解決了同類產品的關鍵問題：

• 異步刷新痛點：無法讀取最新數據，秒級刷新也無法保證數據實時性
• 同步刷新痛點：嚴重影響寫入性能，系統吞吐量大幅下降

3. 支持複雜聚合函數的改寫

除了常用的聚合函數（sum、count、avg、min、max等），還支持如下複雜的聚合函數：

• count(distinct)：精確去重統計
• approx_percentile：近似百分位數計算
• approx_distinct：高效近似去重

4. 支持動態更新物化視圖

更改物化視圖的 SQL 定義時，歷史物化視圖無需重建，不影響已物化的歷史結果。對於經常動態增加列或減少列的場景，這一特性顯得尤為重要，可以避免頻繁更新物化視圖帶來的存儲和計算成本增加。

5. 透明改寫

除了支持 SQL 的透明改寫，對於查詢語句也可以做謂詞的自動補償。舉例説明：

用户創建物化視圖的語句：

level:error | select latency, host from log where message like '%xxx%'

對於如下的查詢請求：

level:error and latency > 100 | select avg(latency), host from log where message like '%xxx%' group by host

優化器自動添加 latency > 100作為查詢條件去查物化結果，用户完全無感。對於過濾性加速場景，多個 SQL 可以最大化複用物化結果，有效降低了物化帶來的存儲開銷。

原理介紹

對於用户創建的物化視圖，日誌服務會在後台自動託管整個計算與維護流程——無需用户干預，一切靜默完成。

具體來説，系統會為每個物化視圖啓動一個智能定時任務，持續追蹤新寫入的日誌數據。每隔一段時間，它就會自動執行您創建視圖時指定的 SQL（無論是簡單的過濾條件，還是複雜的聚合邏輯），並將計算結果持久化存儲起來。每次任務完成後，系統還會精準記錄“已處理到哪個時間點”，為後續查詢提供優化依據。這一切對用户完全透明：不用寫調度腳本、不用管任務失敗、也不用擔心數據一致性——日誌服務全權負責。

當發起查詢時，基於成本的優化器（CBO）會自動介入：

• 如果發現有匹配的物化視圖，它會智能選擇最優的一個；
• 對於非聚合類查詢，優化器將執行計劃改寫為“原始數據 + 物化數據”的輕量級 Union；
• 對於聚合類查詢，則巧妙地將新數據實時聚合後，再與預計算結果合併。

整個過程無縫銜接，既保證了結果的實時性與準確性，又大幅降低了查詢延遲和資源開銷。整個架構圖如下所示（以聚合場景為例）。

案例分享：Dashboard 從“超時失敗”到“秒級響應”

在 Dashboard 場景中，用户對儀表盤打開時間極為敏感，通常要求秒級響應。當多個用户同時刷新 Dashboard 時，如果單個 SQL 請求消耗大量計算資源，會導致計算資源爭搶，所有用户都在等待，嚴重影響用户體驗。通過物化視圖預計算關鍵指標，可以將原本需要分鐘級計算的複雜查詢優化為秒級響應，顯著提升用户體驗。

舉個真實場景：當系統延遲突然飆升，如何快速定位問題？

假設一個高併發的在線服務，其日誌數據被寫入某個 Logstore 中。每條日誌記錄的關鍵信息：

• 請求延遲（latency）
• 請求類型（RequestType）
• 用户 ID（ProjectId）
• 狀態碼（Status）
• 請求數據量（InFlow）
• 返回數據量（OutFlow）

某時刻，監控告警響起——系統平均延遲突然升高！是正常波動？是流量激增導致？還是某個特定用户或接口出了問題？你需要立刻響應，不想等上幾十秒甚至最後超時無法看到結果。

創建物化視圖的 SQL：

*| select avg(latency) as avg_latency,date_trunc('hour', __time__) as time from log group by time
*| select sum(InFlow) as in_flow,sum(OutFlow) as out_flow,avg(latency) as latency, ProjectId,RequestType,Status from log group by ProjectId,RequestType,Status

儀表盤使用的 SQL：

統計每個小時的平均延遲同比一天前、三天前和一週前的變化
*| select time,diff[1] as day1,diff[2] as day2,diff[3] as day3, diff[4] as day7 from ( select time,ts_compare(avg_latency, 86400,172800,604800) as diff from (select avg(latency) as avg_latency,date_trunc('hour', __time__) as time from log group by time) group by time order by time) limit all
按照 ProjectId 維度統計讀寫流量和延遲的變化
*| select sum(InFlow)/1024/1024/1024 as in_flow,sum(OutFlow)/1024/1024/1024 as out_flow,avg(latency) as latency,ProjectId from log group by ProjectId order by in_flow desc limit 10
按照 Status 維度和 ProjectId 的維度，統計平均延遲大於 200 的讀寫流量
*| select sum(InFlow)/1024/1024/1024 as in_flow,sum(OutFlow)/1024/1024/1024 as out_flow,avg(latency) as latency,ProjectId from log group by Status,ProjectId having latency > 200 order by in_flow desc  limit 10

1. 查看近一週延遲同比的變化情況，開啓了物化視圖的請求，千億以上數據秒內出結果，未開啓的請求直接超時。

2. 按照 ProjectId 維度統計讀寫流量和延遲的變化，開啓了物化視圖的請求，千億以上數據不到 400 毫秒返回結果，而未開啓的請求 54 秒才返回，性能提升 100 倍以上。

3. 按照 Status 維度和 ProjectId 的維度，統計平均延遲大於 200 的讀寫流量，由於統計的維度更多了，未使用物化視圖的請求最後超時了，而使用物化視圖後，800 多毫秒返回。

有趣的是，創建物化視圖時寫的 SQL 和系統實際執行的 SQL 並不完全相同。這正是阿里雲日誌服務強大的智能優化器在幕後工作——它能自動識別和改寫查詢邏輯，讓用户無需深入瞭解底層細節，就可以輕鬆為儀表盤查詢加速。

在千億級數據規模的實測中，採用物化視圖的圖表可以秒開，而相同的 SQL 若不使用物化視圖，即使是最快的情況也需要 50 多秒，更多時候會直接超時無法返回結果。這不僅是性能的提升，更是體驗的質的飛躍。理論上來説數據規模越大，加速效果越好。在數據規模更加龐大的另一個 Region 中，萬億級數據的 SQL 查詢也能穩定在 3 秒左右完成，進一步驗證了隨着數據量的增長，物化視圖帶來的性能收益呈現出更為顯著的加速效果。

展望

在數據驅動的時代，阿里雲日誌服務物化視圖通過預計算技術，從根本上解決了大規模日誌分析中的性能瓶頸和吞吐量限制問題，為實時日誌分析提供了新的技術解決方案。未來，我們將繼續在以下方向深耕：

• 智能推薦：自動識別高頻查詢模式，一鍵生成最優物化視圖
• 擴展使用場景：支持 join 算子的物化視圖，支持數據刪除場景
• 改寫增強：支持表達式非精確匹配的改寫