如何進行基于實時ETL的日志存儲與分析實踐

這篇文章將為大家詳細講解有關如何進行基于實時ETL的日志存儲與分析實踐，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

日志大數據下的魚和熊掌

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

• 魚：成本高昂可能導致數據被刪除，由此錯過了價值發現。在數據量快速增長的同時，客戶要保留更長時間的日志，還希望在相應場景下降低存儲成本一半或更多。

• 熊掌：實時數據占機器數據的比例逐步增加，在實時價值越來越受重視的今天，客戶希望繼續得到交互式、一站式的體驗。

魚和熊掌如何得兼？這里討論成本與體驗的平衡。
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:  callbackuri.url:  https%3A%2F%2Fmini.yyrtv.com%2Fr%2F80ba436b763b747d.html%3Ffrom%3D320101%26site%3D1ua.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 投遞。

• 計算后端服務器處理延遲超過 60 秒的請求來源 IP 地理分布

SLS 數據 投遞到 OSS 數據湖上，常見有兩種場景：

1.極低成本存儲

投遞時配置開啟壓縮以降低對象文件大小（日志一般為5~15倍壓縮比），數據長期冷存儲甚至可以選擇歸檔存儲類型或低頻訪問存儲類型 OSS bucket。

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

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

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

關于如何進行基于實時ETL的日志存儲與分析實踐就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。