日誌大數據下的魚和熊掌
我們正處於大數據、多樣化數據（非結構化）的時代，實時的機器數據快速產生，做一家數據公司的核心之一是如何充分利用好大量日誌數據。
由此背景，對日誌的採集、存儲、分析、管理也提出了更高的挑戰，其中包括魚和熊掌的選擇問題：
- 魚：成本高昂可能導致數據被刪除，由此錯過了價值發現。在數據量快速增長的同時，客戶要保留更長時間的日誌，還希望在相應場景下降低存儲成本一半或更多。
- 熊掌：實時數據佔機器數據的比例逐步增加，在實時價值越來越受重視的今天，客戶希望繼續得到交互式、一站式的體驗。
魚和熊掌如何得兼？這裡討論成本與體驗的平衡。
阿里雲日誌服務（SLS）是針對機器數據的一站式服務，為用戶提供快捷的數據採集、消費、投遞以及查詢分析等功能，提升運維、運營效率。
我們在服務眾多客戶的時候，觀察到在很多場景下，伴隨日誌量的不斷增長，數據呈現出訪問熱度的差異。例如：
- 機器指標不斷地追加更新，但在監控指標儀表盤上，新數據的訪問頻率遠超過一天前的數據。
- 排查異常時，研發人員通過 tail 和 grep 關注 ERROR/WARN 日誌的變化，定位問題往往不需要幾天前的程序日誌。
- 數據按業務屬性有重要程度之分，大量非生產環境日誌數據在7天后被訪問概率很低，而最近的生產日誌需要被靈活訪問到。
本文將為大家介紹在 SLS 上兼顧日誌數據靈活性、經濟性的存儲策略與實踐。
基於數據加工與投遞的業務分層
數據系統架構
以 SLB 訪問日誌處理為例，一個區域下的多個實例數據通常存放在一個全量 Logstore 下（10 秒級延遲）。在該 Logstore 上配置數據加工作業實現數據預處理、按業務標籤做數據流轉。
錯誤、高延時的請求，需保證實時查詢、快速統計能力，可以規劃到一個帶 SLS 索引的 Logstore。
其它的所有生產域名請求日誌，需要長期存儲以備審計、合規，可以轉儲臨時 Logstore（充當橋樑）並投遞到更經濟的存儲。
運維數據管道往往比較複雜，SLS 提供的 Serverless 的加工、投遞服務，開箱即用。讓如上方案實現起來更容易，且具有成本優勢。
數據加工實現預處理
對於 SLB 七層監聽的訪問日誌，URI 字段包含高價值的業務 key-value 字段，UserAgent 字段可以輔助監控各個端上的服務質量、穩定性。
加工前原日誌部分字段：
request_uri: /api/get.convert.v2?fn=callback&url=https%3A%2F%2Fmini.yyrtv.com%2Fr%2F80ba436b763b747d.html%3Ffrom%3D320101%26site%3D1
http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3947.100 Safari/537.36加工 DSL 針對日誌規整、抽取場景做處理：
- 通過 e_kv 抽取 URI 中的業務 key-value 對。
- 通過 ua_parse_all 對 http_user_agent 字符串做自動抽取。
e_kv('request_uri', prefix = 'uri.')
e_set('ua', ua_parse_all(v('http_user_agent')))
e_json("ua", depth = 1, fmt = 'root')
e_drop_fields('ua', '__tag__:__receive_time__')URI 抽取得到 fn、url 兩個業務 key-value 對，使用 e_json 函數對 ua_parse_all 的結果做進一步抽取得到設備、OS、UA 結構化信息。
加工後結果字段如下：
uri.fn: callback
uri.url: https%3A%2F%2Fmini.yyrtv.com%2Fr%2F80ba436b763b747d.html%3Ffrom%3D320101%26site%3D1
ua.device: {"family": "Other"}
ua.os: {"family": "Windows", "major": "7"}
ua.user_agent: {"family": "Chrome", "major": "69", "minor": "0", "patch": "3947"}數據加工實現數據分流
加工提供算子快速實現多源的數據彙集、同源數據的多目標分發，支持攢批發送（增加吞吐、利於壓縮存儲）、數據寫入異常自動重試。
如下加工 DSL 實現了：
- 如果 RS 處理延遲有值且大於5.0秒，或者狀態碼非200，這部分數據寫入目標 debug。
- 符合正則表達式的線上域名產生的訪問日誌，全部寫入到目標 product-host。
e_if(op_or(
op_and(op_ne(v('upstream_response_time'), '-'), op_ge(ct_float(v('upstream_response_time')), 5.0)),
op_ne(v('status'), '200')),
e_coutput(name = 'debug'))
e_if(e_search('host ~= ".*-prod\.com"'), e_output(name = 'product-host'))
e_drop()源 Logstore 不開啟索引並縮短存儲週期到 1 天，將上述兩段 DSL 保存到一個加工作業運行，數據實時處理後流向兩個下游 Logstore：
- debug：存儲週期設置為 30 天，開啟索引。
- product-host：存儲週期設置為 1 天，開啟 OSS 投遞。
索引計算實現在線分析
SLS 開啟 Logstore 索引大大提高了數據分析的靈活性，適合熱的數據存儲與處理場景。可以完成實時的查詢、同步的 SQL 交互、豐富的可視化、基於業務日誌的告警。
- 通過 UserAgent 統計設備廠商、設備 OS 分佈
- 計算後端服務器處理延遲超過 60 秒的請求來源 IP 地理分佈
數據投遞實現OSS數據湖
SLS 投遞服務幫助實現數據在阿里雲生態、開源軟件上自由流轉，破除數據孤島，提升客戶上雲的靈活性，降低系統適配成本。
按下圖配置，對全量生產域名的訪問日誌（product-host），在 Logstore 開啟 OSS 投遞，將數據以分鐘級延遲同步到 OSS 存儲桶。
SLS 數據 投遞到 OSS 數據湖上，常見有兩種場景：
- 極低成本存儲
投遞時配置開啟壓縮以降低對象文件大小（日誌一般為5~15倍壓縮比），數據長期冷存儲甚至可以選擇歸檔存儲類型或低頻訪問存儲類型 OSS bucket。
- 數據湖存儲，兼顧中低頻分析
SLS 投遞 OSS 提供行存（json/csv）格式、列存（parquet）格式選擇，可以根據自定義 key 列表來構建文件。
根據計算引擎（Spark、DLA 等）的特性，選擇適當文件格式，可以在計算效率和成本之間取得一個平衡。
例如，使用 OSS select 指定對象文件做簡單的數據查詢，基於 OSS 的多種存儲、計算分離實踐都可以通過 Select 做加速。
總結
隨著業務場景支持的逐步深入，在 SLS 目前有以下存儲實體：
- LogHub：流式存儲，提供實時 pub/sub 能力。
- Index：倒排索引、列存等，支撐交互式查詢體驗。
- Metric：針對指標數據特徵，做到高效存儲、讀取效率。
- 外部存儲：OSS、RDS、MaxCompute 等，可以作為投遞目標或是富化日誌的源頭。
多個存儲實體之間，通過連線可以實現數據的流動分層。
在日誌數據融合、價值釋放、高效利用的道路上，SLS 數據加工、投遞持續做好管道服務，滿足更多樣化的場景需求。
