日志大資料下的魚和熊掌
我們正處于大資料、多樣化資料（非結構化）的時代，實時的機器資料快速産生，做一家資料公司的核心之一是如何充分利用好大量日志資料。
由此背景，對日志的采集、存儲、分析、管理也提出了更高的挑戰，其中包括魚和熊掌的選擇問題：
- 魚：成本高昂可能導緻資料被删除，由此錯過了價值發現。在資料量快速增長的同時，客戶要保留更長時間的日志，還希望在相應場景下降低存儲成本一半或更多。
- 熊掌：實時資料占機器資料的比例逐漸增加，在實時價值越來越受重視的今天，客戶希望繼續得到互動式、一站式的體驗。
魚和熊掌如何得兼？這裡讨論成本與體驗的平衡。
阿裡雲日志服務（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 資料加工、投遞持續做好管道服務，滿足更多樣化的場景需求。