聊聊百度的日誌中臺

日誌數據的生命週期包含日誌採集、接入、傳輸、應用等各個環節。數據的穩定性對於公司報表建設、決策分析、轉化策略效果都有至關重要的影響。本文旨在介紹百度日誌中臺當前的現狀，公司內部應用推廣情況。尤其在數據準確性的建設上，進行深入的探討。數據產生到最終業務應用中各個環節的穩定性建設，包括：數據上報時效性優化、接入持久化的思考、數據流式計算過程中的不重不丟建設等。

簡述

中臺定位

日誌中臺是針對打點數據的一站式服務，實現打點數據的全生命週期管理，只需簡單開發就能快捷完成日誌數據採集、傳輸、管理以及查詢分析等功能，適用於產品運營分析、研發性能分析、運維管理等業務場景，幫助 APP 端、服務端等客戶探索數據、挖掘價值、預見未來。

接入情況

日誌中臺已覆蓋了廠內大多數重點產品，其中包括：百度 APP 全打點、小程序、矩陣 APP 等，接入方面收益如下：

• 接入情況：幾乎覆蓋了廠內已有 APP，小程序，創新孵化 APP，以及廠外收購 APP

• 服務規模：日誌條數 幾千億 條 / 天，高峯 QPS 幾百萬 / 秒，服務穩定性 99.9995 %

名詞解釋

• 客戶端：指用戶可以直接使用的軟件系統，通常部署在用戶手機或 PC 等終端設備上。例如百度 APP、小程序等。

• 服務端：用於響應客戶端發起的網絡請求的服務，通常部署在雲服務器上。

• 日誌中臺：此處特指端日誌中臺，包括端日誌全生命週期的能力建設。包括打點 SDK / 打點 server/ 日誌管理平臺等核心組件。

• 打點 SDK：負責打點日誌的採集、封裝、上報等功能。根據不同的日誌生產端，分爲 APP 端 SDK、H5 端 SDK，根據場景區分爲通用點位 SDK、性能 SDK、小程序 SDK 等，用戶根據需求可以集成不同的 SDK。

• 打點 server：日誌接收服務端，是日誌中臺服務端最核心的模塊。

• 特徵 / 模型服務：日誌中臺將需要進行策略模型計算的點位信息實時轉發給下游 <策略推薦中臺>。特徵 / 模型服務是<策略推薦中臺> 的入口模塊。 

服務全景圖

日誌服務主要包括基礎層、管理平臺、業務數據應用、產品支撐幾個層面。圍繞着各個層級，在 2021.6 月，制定 & 發佈了百度客戶端日誌上報規範。

• 基礎層：支持了 APP-SDK、JS-SDK，性能 SDK、通用 SDK，滿足各類打點需求的快速接入場景。依託大數據基礎服務，將打點數據分發至各個應用方。

• 平臺層：管理平臺支持數據元信息管理、維護，並控制打點生命全週期環節。在線層面支持數據的實時、離線轉發、並依託合理的流量控制、監控保證服務穩定性在 99.995%。

• 業務能力：日誌打點數據輸出至數據中心、性能平臺、策略中臺、增長中臺等，有效助力產品決策分析、端質量監控、策略增長等領域。

• 業務支持：覆蓋重點 APP、新孵化矩陣 APP，橫向通用組件方面。

日誌中臺核心目標

如前文介紹，日誌中臺承載着百度內所有 APP 日誌打點、站在數據生產的最前沿，在保證功能覆蓋全、接入快速 & 靈活的基礎上，面臨的最重要核心挑戰是數據的準確性。整個數據從產出、日誌中臺接入處理、下游應用，一切數據質量問題需要日誌中臺承載。而數據的準確性可以拆解爲 2 部分：

• 不重：保證數據嚴格意義的不重複。需要防止系統層面的各種重試、架構異常恢復導致的數據重複問題；

• 不丟：保證數據嚴格意義的不丟失。需要防止系統層面的故障、代碼層面 bug 等導致的數據丟失問題。

而做到系統層面的近乎 100% 的不重不丟，需要面臨較多的難題。

日誌中臺架構

接入日誌中臺打點數據從端上生產至在線服務到最終（實時 / 離線）轉發至下游，需要經過如下幾個環節：

數據應用方式不同，有以下集中類型：

• 實時：

• 準實時流（消息隊列）：供下游數據分析使用，特點：較高（min）時效性，需要嚴格意義的數據準確。典型應用：研發平臺、trace 平臺；

• 純實時流（RPC 代理）：供下游策略應用，特點：秒級時效性，允許一定程度的數據丟失。典型應用：推薦架構。

• 離線：離線大表，所有日誌全集，特點：天級 / 小時級時效性，需要嚴格意義的數據準確。

• 其他：需要一定時效性和準確率

面臨的問題

從上面日誌中臺架構來看，存在如下問題：

• 巨型模塊：打點 server 承載了所有的數據處理邏輯，功能耦合嚴重：

• 功能多：接入 & 持久化、業務邏輯處理、各種類型轉發（rpc、消息隊列、pb 落盤）；

• 扇出多：有 10 + 個業務扇出流，通過打點 server 轉發。

• 直接對接消息隊列：從業務視角看，存在發送消息隊列消息丟失風險，且無法滿足業務不重不丟要求。

• 業務無等級劃分：

• 核心業務與非核心業務架構部署耦合

• 相互迭代、相互影響

不重不丟實現

數據不丟的理論基礎

1、唯 2 丟失數據理論

• 端：由於移動端的客觀環境影響，如白屏、閃退、無法常駐進程、啓動週期不確定等因素，導致客戶端消息會存在一定概率丟失

• 接入層：由於服務器不可避免的存在故障（服務重啓、服務器故障）的可能性，也存在一定的數據丟失概率

• 計算層：接入點之後，基於流式框架，建設需要嚴格意義的保證數據不重不丟。

2、日誌中臺架構優化方向

數據接入層面：

• 先持久化數據，後業務處理的原則

• 降低邏輯複雜度

下游轉發層面：

• 實時流類：嚴格意義不丟失

• 高時效類：保證數據時效，允許可能存在的部分丟失

• 資源隔離：將不同業務的部署進行物理隔離，避免不同業務相互影響

• 區分優先級：按照業務對不同數據訴求，區分不同類型

架構拆解

基於日誌中臺現狀分析，結合日誌打點服務的唯 2 理論，我們針對日誌中臺對現有架構進行問題拆解和架構重構。

1、打點 server 服務拆解（優化接入層數據丟失）

基於以上不重不丟的理論，日誌接入層進行了如下幾個方面的建設，儘可能做到數據不重不丟。

• 日誌優先持久化：儘可能降低接入點因服務器故障等原因導致的數據丟失問題；

• 巨型服務拆解：接入點應該秉承簡單、輕量的思路建設，避免過多業務屬性導致的服務穩定性問題；

• 靈活 & 易用：在不重不丟的同時，基於業務需求特點，設計合理的流式計算架構。

日誌優先持久化：

日誌中臺現有的扇出數據，需要優先進行持久化，這是日誌接入層基本要求。而實時流方面，在保證業務數據轉發分鐘級延遲的情況下，要做到數據 “儘可能不丟”。

• 持久化：接入層在真正業務處理之前，優先將數據持久化處理，“儘可能” 先保證數據不丟失。

• 實時流：避免直接對接消息隊列，優先採用落盤 + minos 轉發消息隊列方式，保證數據至多分鐘級延遲的情況下，儘量不丟。

巨型服務拆解 & 功能下沉：

爲降低日誌服務過多的功能迭代帶來的穩定性風險，同時需要滿足下游業務靈活訂閱的需求，需要保證日誌中臺扇出的合理性。我們將在線服務進一步拆解：

• 實時流類業務：打點消息流轉經過接入層→ 扇出層→ 業務層→ 業務。

• 接入層：功能單一，設計目標爲數據儘可能不丟，保證數據第一時間持久化；

• 扇出層：保證下游靈活的訂閱方式，進行數據拆分 & 重組（目前基於打點 id 維度扇出）；

• 業務層：組合訂閱扇出層數據，完成業務自有的需求實現，負責將打點數據生產並轉發至下游；

• 高時效類業務：策略實時推薦類的業務，單獨抽離服務，支撐 rpc 類的數據轉發，保證超高時效並保證數據轉發 SLA 達到 99.95% 以上；

• 其他類業務：數據監控、vip、灰度等業務，對時效、丟失率要求進一步降低，可將這部分業務抽離至單獨服務；

• 技術選型：針對數據流式計算特點，我們選用了 streamcompute 架構，保證數據在經過接入層之後，全流程的 “不重不丟”。

因此，將日誌服務進一步拆解，如下圖所示：

流式計算思考：

爲了保證嚴格數據流穩定性，需要依賴流式計算架構，在解決數據在業務計算過程中完全的不重不丟同時，滿足業務不同場景獲取數據的訴求。針對日誌中臺特點，我們對流式計算處理架構進入如下設計：

• 打點 server：將實時流通過消息隊列，單獨扇出至流式框架（分流 flow 入口）

• 分流 flow：將不同點位信息，基於流量大小，進行拆分輸出至不同消息隊列。這樣做的好處是兼顧了數據靈活扇出要求，下游可以靈活訂閱；

• QPS 小於某些閾值 or 橫向點位等：單獨消息隊列輸出，達到靈活扇出；

• QPS 較小點位，進行聚合輸出至聚合隊列，以便節省資源；

• 業務 flow：如果業務有自己的數據流式處理需求，可以單獨部署作業，以便各個作業資源隔離。

• 輸入：組合訂閱分流 flow 的不同扇出數據，進行數據計算；

• 輸出：數據混合計算後，輸出至業務消息隊列，業務方自行訂閱處理；

• 業務 filter：作爲發送至業務層的終極算子，負責各個數據流在端到端層面。（打點 server、端的系統重試數據）的不重。打點 server 將每一條打點數據生成唯一標識（類似一條數據 md5），業務 flow filter 算子進行全局的去重。

2、打點 SDK 數據上報優化（解決端上報數據丟失）

客戶端打點，因端所處的環境問題，會存在一定的數據丟失風險。尤其當打點調用併發較高時候，數據不可能第一時間全部發送到服務端。

因此，客戶端需要將業務打點數據暫存本地的數據庫，然後異步進行消息發送至服務端，以達到異步發送、優先本地持久化不丟的保證。

但是，APP 可以在任何情況下退出、卸載，那數據在本地停留越久，對業務數據價值越小，更容易丟失，所以我們需要針對數據上報進行如下方向的優化：

• 增加上報時機：單獨定時任務輪詢、業務打點時觸發攜帶緩存數據、緩存消息達到閾值觸發（實驗獲得）等手段，提高緩存數據的上報的時機，儘量降低消息在本地緩存時間。

• 增加上報消息個數：在保證數據上報大小、條數（實驗對比得到閾值），將上報消息的條數進行調整，取得合理上報個數，達到消息第一時間到達服務端的最大收益。

通過客戶端發送邏輯不斷優化，在時效性上也取得了巨大收益。收斂率雙端提升 2%+。

展望

前文介紹了日誌中臺服務在打點數據準確性保障方面，做的一些努力。當然，後面我們還會繼續深挖系統的風險點，如：

磁盤故障導致數據丟失：接入層後續針對磁盤故障，基於公司的數據持久化能力，建設數據的嚴格不丟失基礎

希望，日誌中臺持續不斷優化，爲業務準確使用打點數據做出貢獻。

本文源自公衆號百度 Geek 說，分佈式實驗室已獲完整授權。

分佈式實驗室 關注分佈式相關的開源項目和基礎架構，致力於分析並報道這些新技術是如何以及將會怎樣影響企業的軟件構建方式。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/4cnimz5LOSaNpXjJX6mv9Q