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

全文4047字，預計閱讀時間12分鐘

一 簡述

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 日志優先持久化

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

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

實時流：避免直接對接消息隊列，優先采用落盤+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%+。

四、展望

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

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

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

總結

以上是生活随笔為你收集整理的日志中台不重不丢实现浅谈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。