日誌大數據下的魚和熊掌

咱們正處於大數據、多樣化數據（非結構化）的時代，實時的機器數據快速產生，作一家數據公司的核心之一是如何充分利用好大量日誌數據。
由此背景，對日誌的採集、存儲、分析、管理也提出了更高的挑戰，其中包括魚和熊掌的選擇問題：html

魚：成本高昂可能致使數據被刪除，由此錯過了價值發現。在數據量快速增加的同時，客戶要保留更長時間的日誌，還但願在相應場景降低低存儲成本一半或更多。
熊掌：實時數據佔機器數據的比例逐步增長，在實時價值愈來愈受重視的今天，客戶但願繼續獲得交互式、一站式的體驗。

魚和熊掌如何得兼？這裏討論成本與體驗的平衡。
阿里雲日誌服務（SLS）是針對機器數據的一站式服務，爲用戶提供快捷的數據採集、消費、投遞以及查詢分析等功能，提高運維、運營效率。
咱們在服務衆多客戶的時候，觀察到在不少場景下，伴隨日誌量的不斷增加，數據呈現出訪問熱度的差別。例如：正則表達式

機器指標不斷地追加更新，但在監控指標儀表盤上，新數據的訪問頻率遠超過一天前的數據。
排查異常時，研發人員經過 tail 和 grep 關注 ERROR/WARN 日誌的變化，定位問題每每不須要幾天前的程序日誌。
數據按業務屬性有重要程度之分，大量非生產環境日誌數據在7天后被訪問機率很低，而最近的生產日誌須要被靈活訪問到。

本文將爲你們介紹在 SLS 上兼顧日誌數據靈活性、經濟性的存儲策略與實踐。json

基於數據加工與投遞的業務分層

數據系統架構

以 SLB 訪問日誌處理爲例，一個區域下的多個實例數據一般存放在一個全量 Logstore 下（10 秒級延遲）。在該 Logstore 上配置數據加工做業實現數據預處理、按業務標籤作數據流轉。
錯誤、高延時的請求，需保證明時查詢、快速統計能力，能夠規劃到一個帶 SLS 索引的 Logstore。
其它的全部生產域名請求日誌，須要長期存儲以備審計、合規，能夠轉儲臨時 Logstore（充當橋樑）並投遞到更經濟的存儲。後端

運維數據管道每每比較複雜，SLS 提供的 Serverless 的加工、投遞服務，開箱即用。讓如上方案實現起來更容易，且具備成本優點。api

數據加工實現預處理

對於 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 結構化信息。
加工後結果字段以下：less

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 數據湖上，常見有兩種場景：

1.極低成本存儲

投遞時配置開啓壓縮以下降對象文件大小（日誌通常爲5~15倍壓縮比），數據長期冷存儲甚至能夠選擇歸檔存儲類型或低頻訪問存儲類型 OSS bucket。

2.數據湖存儲，兼顧中低頻分析

SLS 投遞 OSS 提供行存（json/csv）格式、列存（parquet）格式選擇，能夠根據自定義 key 列表來構建文件。
根據計算引擎（Spark、DLA 等）的特性，選擇適當文件格式，能夠在計算效率和成本之間取得一個平衡。
例如，使用 OSS select 指定對象文件作簡單的數據查詢，基於 OSS 的多種存儲、計算分離實踐均可以經過 Select 作加速。

總結

隨着業務場景支持的逐步深刻，在 SLS 目前有如下存儲實體：

LogHub：流式存儲，提供實時 pub/sub 能力。
Index：倒排索引、列存等，支撐交互式查詢體驗。
Metric：針對指標數據特徵，作到高效存儲、讀取效率。
外部存儲：OSS、RDS、MaxCompute 等，能夠做爲投遞目標或是富化日誌的源頭。

多個存儲實體之間，經過連線能夠實現數據的流動分層。
在日誌數據融合、價值釋放、高效利用的道路上，SLS 數據加工、投遞持續作好管道服務，知足更多樣化的場景需求。

原文連接

本文爲阿里雲原創內容，未經容許不得轉載。

基於實時ETL的日誌存儲與分析實踐