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

一 簡述

1.1 中臺定位

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

1.2 接入情況

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

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

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

1.3 名詞解釋

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

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

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

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

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

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

1.4 服務全景圖

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

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

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

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

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

二、日誌中臺核心目標

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

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

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

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

2.1 日誌中臺架構

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

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

• 實時

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

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

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

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

2.2 面臨的問題

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

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

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

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

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

• 業務無等級劃分：

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

• 相互迭代、相互影響

三、不重不丟實現

3.1 數據不丟的理論基礎

3.1.1 唯 2 丟失數據理論

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

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

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

3.1.2 日誌中臺架構優化方向

數據接入層面：

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

• 降低邏輯複雜度

下游轉發層面：

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

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

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

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

3.2 架構拆解

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

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

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

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

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

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

3.2.1.1 日誌優先持久化

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

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

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

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

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

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

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

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

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

• 高時效類業務：

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

• 其他類業務：

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

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

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

3.2.1.3 流式計算思考

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

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

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

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

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

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

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

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

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

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

客戶端打點，因端所處的環境問題，會存在一定的數據丟失風險。尤其當打點調用併發較高時候，數據不可能第一時間全部發送到服務端。因此，客戶端需要將業務打點數據暫存本地的數據庫，然後異步進行消息發送至服務端，以達到異步發送、優先本地持久化不丟的保證。但是，APP 可以在任何情況下退出、卸載，那數據在本地停留越久，對業務數據價值越小，更容易丟失，所以我們需要針對數據上報進行如下方向的優化：

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

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

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

四、展望

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

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

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

作者：振興

來源：百度 Geek 說

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