聊聊百度的日誌中臺

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

簡述

中臺定位

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

接入情況

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

名詞解釋

服務全景圖

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

日誌中臺核心目標

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

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

日誌中臺架構

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

數據應用方式不同,有以下集中類型:

面臨的問題

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

不重不丟實現

數據不丟的理論基礎

1、唯 2 丟失數據理論

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

數據接入層面:

下游轉發層面:

架構拆解

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

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

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

日誌優先持久化:

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

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

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

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

流式計算思考:

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

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

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

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

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

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

展望

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

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

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

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

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

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