日誌服務數據加工的設計與實踐

前言

快速發展的日誌數據

伴隨Logging、Metrics、Tracing三者融合趨勢的部分顯現，日誌類數據的範圍正在泛化，包括：工業傳感器數據、日誌文件、Prometheus採集的雲原生應用指標、Syslog、網絡點擊日誌、stdout、業務埋點等等。

能夠看到：

•數據規模快速增加，日誌類數據是big data的主力。

•採集的日誌數據類別正在增長，其一是日誌類型泛化，其二是過去被丟棄的數據正被重拾起來。

•數據運營的理念在各行各業滲透，更多的日誌數據開始獲得處理，更多的人開始參與日誌分析。

即便在傳統日誌領域，以Kubernetes爲表明的雲原生的流行，也帶來了新的日誌生命週期管理需求。如何從各類日誌源採集數據、分析數據是一項複雜的挑戰。

不平坦的數據分析之路

除了數據科學家、數據工程師，如今運營、DevOps工程師、用戶支持等角色也在分析日誌。假設有N種日誌用戶，對於M種類型日誌，可能會產生N*M種日誌存儲、分析需求。

• 分析首先須要完整的數據採集，尤爲是對大規模數據的集成、預處理和降維能力。
• 多元用戶意味着多樣化工具棧，數據應該保存在開放的存儲系統，而且能夠被更多的工具處理。
• 在傳統的離線分析以外，愈來愈多的延遲敏感型應用出現，數據得不到及時處理會喪失其大部分價值。

上圖（interana.com, State of Data Insights 2017統計）反映了一個事實：73%的人須要花費幾天甚至數星期時間從數據中獲得分析結果。

另外一個被普遍傳播的數字：在數據分析過程當中，數據集成和預處理所耗費的時間佔整體80%以上。

ETL已死？

完成各個數據源採集，接着以儘可能統一的方式（UI、模型、計算架構）對數據作加工、查詢。其中，ETL是關鍵的技術。

近一兩年來，看到一些關於」ETL已死「的文章。但關鍵問題尚未解決：

• OLAP + OLTP一體化的系統使人嚮往，但當前在數據規模、計算任務多樣化上有其限定條件。
• 衆多ETL pipeline維護的複雜性源自數據業務的複雜，例如：數據採集流程、預處理做業依賴。

所以，銀彈尚未出現，對業務需求進行抽象，根據技術指標作合理的存儲、計算選型是一個行之有效的辦法。ETL沒有消失，也在演進：

• 實時化ETL，不管是數據的採集仍是預處理階段。
• 隨着一些存儲、計算系統能力的加強，ETL的過程在向存儲系統遷移。例如：過去在數據庫難以實現大規模預處理，須要專門的ETL工具；當前則能夠在一個分佈式數倉內作ELT，完成系統內數據流轉。
• 中心化採集到統一存儲後加工（類Kafka模式），必定程度上優化了複雜業務上ETL網狀數據拓撲。
• 數據湖爲表明的schema-on-read模式，讓ETL的發生後置。

數據預處理的流派

數據預處理是本文主題，在多年的ETL技術發展中誕生了不少相關係統。這裏選取一部分作回顧：

採集端系統

日誌領域，以Logstash（注：新版本支持hosted模式）、Fluentd、Flume、NXLog、Logtail（阿里巴巴）爲表明，能夠在採集階段利用機器資源完成必定程度的預處理，不須要專用計算集羣作預處理。不足之處是：

• 可用性，一旦單機客戶端非預期失效，數據鏈路也會斷掉。
• 不少數據源是易失的，在客戶端、插件出問題時或業務邏輯改變時，數據重放是困難的。
• ETL運維的複雜度難以獲得改善，配置散落在衆多機器上，加工邏輯變動或做業運維大多依賴機器上操做。
• 單機節點可能出現日誌生產大於消費狀況（取決於軟件實現的性能），致使處理瓶頸。

數據庫系統

它們首先是存儲系統，基於行、列存儲模型優化，支持了必定的複雜計算能力。經典的如SQL Server、Oracle數據庫，現在有OceanBase、Google Spanner這樣的分佈式數據庫。

絕大部分數據庫多用於存儲清洗後的數據，用於在線服務場景。

批量計算系統

以Hive、MapReduce計算爲表明的Hadoop生態系統，主要是面向 OLAP、批操做設計。以可擴展的計算和海量存儲能力，解決了big data分析難題。

在延遲敏感型業務佔比愈來愈大的背景下，離線系統的延遲高、交互性差，已經不能再唱獨角戲。

流計算引擎

Flink、Spark是開源社區很是流行的流計算系統，流模式讓ETL變得實時化，定位於通用場景。

雲上數據平臺

以Alooma、AWS Glue、Azure DataFactory、阿里雲DataWorks、Google Cloud DataProc爲表明，各個雲服務廠商基於的存儲、計算服務，在一個系統上爲用戶提供通用、綜合的數據集成、開發能力。

流式存儲與計算

在很長一段時間內，以Kafka爲表明的數據隊列系統被用於臨時數據存儲。通過近些年的發展，流式存儲上拓展了數據分層，基於之上的計算也已成爲一個事實。例如：AWS Kinesis Streams、Kafka（KSQL/Kafka Streams）、Apache Pulsar（Pulsar Functions）。

日誌服務上的數據預處理場景

阿里雲日誌服務（原SLS）是針對日誌類數據的一站式服務，在阿里巴巴集團經歷大量大數據場景錘鍊而成。爲用戶提供快捷的日誌數據採集、消費、投遞以及查詢分析等功能，提高運維、運營效率。

數據源

在日誌服務，目前天天的數據處理規模在PB級，涵蓋主要日誌生態的數據源。數據集成手段包括：

• 客戶端採集：處理機器上各類各樣的日誌文件、程序指標、網絡數據包等。
• 服務端採集：以分佈式、全託管服務方式採集雲產品、服務上的數據。例如：雲產品訪問日誌（SLB、OSS、CDN、API網關），網絡流日誌（VPC、CEN），開放服務上存儲的數據（OSS文件、MaxCompute表等）。
• 自建軟件：應用程序能夠自由選擇基礎的Restful API，多種語言SDK，基於SDK高級封裝的producer lib或是logger appender上報數據。
• 協議網關：日誌服務服務端對於Kafka、Syslog等數據協議提供接入網關，最小化日誌採集代價。

場景與挑戰

在日誌服務上，大量的、多樣的數據在日誌庫（Logstore）存儲，進行數據分析要解決三個挑戰：

• 規模問題

  • 普遍類型的數據採集能力，一套存儲完成全部類型數據的集中化。
  • 海量、可伸縮的集中式存儲，支撐例如審計場景下日誌長期存儲場景。
  • 彈性擴展的數據處理，按照業務峯谷配置計算，下降爲burst高峯預留資源帶來的高額成本。

• 多元化分析需求

  • 數據鏈路實時性要求變高，存儲和計算要具有微批、流的能力。
  • 一份數據能夠在多處被使用，讓數據開放並自由流動。
  • 較好的工具集成完整度和豐富的生態對接能力，適應不一樣用戶的分析技術棧。

• 數據預處理的易用性

  • 數據加工代碼複雜度儘可能低，常見日誌處理邏輯作到複用。
  • 全託管、服務化處理，屏蔽運維細節（failover，資源擴容）。
  • GUI幫助收斂數據流程的調試、維護成本。

數據加工功能

在日誌服務，數據加工功能用於完成對Logstore數據的預處理，爲後續的分析階段準備數據。

數據加工基於日誌服務的流式存儲，調度動態數目的worker作計算。計算上提供豐富的算子和場景化UDF，對於複雜需求則能夠經過流程控制、條件判斷實現行內邏輯組合，跨行的pipeline組合簡化數據的嵌套處理需求。

日誌服務數據加工的設計

數據模型與存儲

日誌服務使用一套通用的數據模型應對各類各樣的數據類型。一條Log由保留字段（時間，來源等）和日誌內容（多個Key-Value對）組成：

message Log
{
    required uint32 Time = 1;// UNIX Time Format
    message Content
    {
        required string Key = 1;
        required string Value = 2;
    }  
    repeated Content Contents = 2;
}

結構化的數據能夠在這個數據模型上定義出表結構：

__time__ : 1572784373
__source__ : 192.168.2.13
key_a : value a
key_b : value b

一樣的，對於非結構化或半結構化數據，能夠在把所有內容放入一個字段中，並選擇性地對字段值作一些處理（例如編碼）。

日誌服務存儲引擎（LogHub）實現了對數據的統一存儲，支持如下特性：

• 流式存儲，十毫秒級可見。
• 分佈式服務，多拷貝保證可靠性。
• append寫入，支持增量（實時）消費以及存量（回搠位置）消費。
• 支持Ad-hoc構建索引，結合高效編碼、列存對原文存儲實現快速查詢、分析。

存儲與計算分離

數據加工實現的是脫離存儲系統以外的計算過程。基於Pull模型獲取數據，能夠根據worker自身的負載狀況決定數據加載的速率。worker與存儲系統的網絡請求走阿里雲內部網絡，每次讀取批量的數據塊，結合傳輸過程的壓縮特性，保證了同region下跨系統交換數據不會成爲性能瓶頸。

日誌服務的一個Logstore的數據分佈在多個shard上，每個shard被append寫入數據。調度器負責如下工做：

• 管理N個worker到M個shard之間的映射關係，保證shard在數量維度上的負載均衡。
• 支持worker的水平擴展以應對大規模流量，在衆多shard狀況下，協調多個worker共同、完整地處理整個Logstore的數據。
• worker的健康管理，動態地註冊新worker或踢出失效worker。
• 持久化worker對shard消費進度，例如worker#1失效後，其對shard 0/1的處理進度能夠被新加入的worker#3繼承。

彈性是雲服務的標誌，在大部分日誌的流量特徵而言，伸縮能力顯得尤其重要。

例如：直播應用的CDN access log，21:00 ~ 23:00是業務訪問高峯期併產生大量日誌，到了凌晨1:00 ~ 7:00日誌流量跌至高峯時的10%。按業務峯值規劃資源必將產生大量閒置成本。

處理延遲、數據規模、成本三者看起來是魚和熊掌的關係，在日誌服務上，嘗試從兩個層面來彈性應對：

• 存儲：基於shard的動態merge/split能力實現對寫入存儲流量的控制，高峯時使用更多的shard。
• 計算：數據加工實現了基於流量的併發度控制，shard數目做爲一個參考指標，根據當前總體的資源指標（cpu使用率等）動態擴容或縮容worker數目。

做業模式

日誌處理場景下繞不過的是時間，時間的定義確又不那麼簡單。

名稱	定義	日誌服務上應用
event-time	事件時間，真實的業務時間	通常建議設置值到__time__字段，如寫入時未作規劃則須要從數據中自行提取
server-arrived-time	該事件到達服務端時間	日誌服務在接收數據時記錄值並填入__tag__:__receive_time__字段
processing-time	數據加工處理該事件的時間	不肯定，取決於做業模式以及加工速率

對於一個加工任務而言，加工的延遲定義爲processing-time - server-arrived-time(latest log)。因爲數據可能遲到或生產者發送了亂序數據，event-time與server-arrived-time、processing-time可能會有較大差別。

數據加工根據server-arrived-time定義數據源範圍，並提供兩種做業模式：

• 實時模式：持續運行並加載新到來數據，無界的流任務，[FROM server-arrived-time, -)。
• 區間模式：有界的任務，[FROM server-arrived-time, TO server-arrived-time)，常見的有補數據場景，能夠重複地對過去一個時間段作加工。

場景化UDF

相較於業內流行的SQL、DSL、Python等ETL語言，日誌服務數據加工提供的是類Python DSL，封裝了日誌領域下通用加工過程。

做爲業務邏輯開發的重要一環，數據加工DSL提供如下能力：

• 函數級能力：支持數據過濾、抽取、分裂、富化、分發操做，能夠快速解決如JSON、Nginx access log、Syslog日誌解析等場景。
• 行內組合能力：經過條件判斷與流程控制，能夠組合多個函數調用完成複雜操做，例如：e_if_else(condition_1, e_compose(operation_1, operation_2, operation_3), operation_4)。
• 跨行組合能力：經常使用於數據處理pipeline，做用相似SQL子查詢。數據加工跨行組合是類管道式語法，從代碼調試效率和可讀性上看，比SQL子查詢表現更好。

例如，在數據加工DSL中實現對一條日誌的分裂、拷貝、條件判斷，其內部編排邏輯以下圖：

DevOps效率

開發、運維效率是考量數據流程維護成本的重要指標。

日誌服務數據加工是全託管的服務，使用它不感知機器資源，經過web控制檯實現對做業的管理與監控。

• 開發與調試：web控制檯操做。

• 部署與迭代：調試完成的代碼一鍵保存做業運行。DSL代碼更新後，控制檯上進行重啓完成從新部署。
• 指標監控：包括概覽、加工吞吐、shard級消費延遲與速率指標。

• 診斷日誌：匯聚了加工過程錯誤日誌，能夠根據reason字段進行細節定位。

• 做業告警：在加工任務運行指標的儀表盤上，能夠對某個指標設置監控告警，也能夠訂閱儀表盤發送到釘釘webhook。作到對數據加工做業的運行狀態的充分掌握。

基於數據加工的場景實踐

流動的數據

在日誌的整個生命週期內，數據採集到日誌服務存儲，數據加工在這以後起着承轉啓合做用。經過數據加工完成清洗、預處理、分發，讓數據在生態流轉起來，並更好地適配目標存儲的schema要求。

規整

數據規整包括字段抽取、過濾、清洗等工做，完成後數據被轉儲到下游。規整的意義在於能爲下游帶來哪些幫助：

• Logstore的數據規整後寫入新Logstore，在後者基礎上精細化Key-Value索引能夠幫助優化成本，提高查詢分析效率，讓儀表盤與告警表達更加豐富。
• Logstore數據規整後寫入OSS bucket，如此構建的數據湖能夠大大優化存儲成本和後續分析效率。參考Analyzing Data in S3 using Amazon Athena數字，對於S3上的ELB訪問日誌，結構化良好的parquet文件對比普通text文件，能夠縮小87%存儲空間並在部分場景下提高34倍分析效率。
• Logstore數據規整後寫入數據庫是剛需，整條日誌原文存儲數據庫在後續面臨性能開銷、不規則數據帶來計算不肯定性（可能引入複雜的兼容邏輯）。

以下，content字段是完整的Syslog日誌原文，這樣一條非結構化數據，經過兩行加工代碼分別完成Syslog字段抽取、priority字段映射。

對於JSON格式的結構化日誌，以下兩行代碼經過JMES語法對數組作分拆，分拆後每一個子對象分別作嵌套字段提取。

更多實踐：

數據脫敏

日誌時間處理

複雜JSON字段提取

類JSON、非標準JSON、XML格式解析

分隔符日誌字段提取

Key-Value格式字段提取

Ngnix日誌解析

Syslog數據解析

分發

日誌分發、複製是一種典型的數據場景。

例如：Kubernetes上採集的衆多pod日誌集中化到一個Logstore上，能夠經過數據加工快速實現按namespace轉發到下游Logstore，在下游Logstore上分別設置存儲週期、索引分析字段。

數據除了在Logstore之間作流轉之外，還能夠流向異構存儲系統，例如投遞到OSS、MaxCompute、ADB等。

更多實踐：

多目標Logstore數據分發

多源Logstore數據彙總

Logstore數據投遞OSS

富化

對於一個典型的SLB+ECS+Nginx架構，Nginx access log上包括請求來源（__source__字段，記錄vpc子網ip）、請求資源（request_uri字段，參數記錄了業務租戶的project信息）。

RDS中維護了兩張維表：

• 用戶元信息表，主鍵爲業務租戶的project信息。
• ECS服務器元信息表，主鍵爲內網ip。

數據加工首先對request_uri作參數拆分，獲取project信息。接下來分別經過ip與project值與兩個維表作join，獲得結果是更完整的日誌信息（包括後端服務器的tag、租戶project的打標內容）。

數據加工目前支持四種數據源作查找富化：本地配置、RDS表、OSS文件、日誌服務Logstore。

更多實踐：

從RDS MySQL獲取數據作富化

從OSS文件獲取數據作富化

從日誌服務 Logstore獲取數據作富化

自定義條件實現數據富化的複雜映射

寫在最後，ETL業務場景變幻無窮，數據加工在數據分析場景支撐的路上將持續迭代優化。

 

雙11福利來了！先來康康#怎麼買雲服務器最便宜# [並不簡單]參團購買指定配置雲服務器僅86元/年，開團拉新享三重禮：1111紅包+瓜分百萬現金+31%返現，爆款必買清單，還有iPhone 11 Pro、衛衣、T恤等你來抽，立刻來試試手氣 https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110

 

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。