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

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

一 簡述

1.1 中臺定位

日志中臺是針對打點數(shù)據(jù)的一站式服務，實現(xiàn)打點數(shù)據(jù)的全生命周期管理，只需簡單開發(fā)就能快捷完成日志數(shù)據(jù)采集、傳輸、管理以及查詢分析等功能，適用于產品運營分析、研發(fā)性能分析、運維管理等業(yè)務場景，幫助APP端、服務端等客戶探索數(shù)據(jù)、挖掘價值、預見未來。

1.2 接入情況

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

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

• 服務規(guī)模：日志條數(shù) 幾千億 條/天，高峰QPS 幾百萬/秒，服務穩(wěn)定性 99.9995 %

1.3 名詞解釋

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

服務端：用于響應客戶端發(fā)起的網絡請求的服務，通常部署在云服務器上。

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

打點SDK：負責打點日志的采集、封裝、上報等功能。根據(jù)不同的日志生產端，分為APP端SDK、H5端SDK，根據(jù)場景區(qū)分為通用點位SDK、性能SDK、小程序SDK等，用戶根據(jù)需求可以集成不同的SDK。

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

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

1.4 服務全景圖

日志服務主要包括基礎層、管理平臺、業(yè)務數(shù)據(jù)應用、產品支撐幾個層面。圍繞著各個層級，在2021.6月，制定&發(fā)布了百度客戶端日志上報規(guī)范。

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

• 平臺層：管理平臺支持數(shù)據(jù)元信息管理、維護，并控制打點生命全周期環(huán)節(jié)。在線層面支持數(shù)據(jù)的實時、離線轉發(fā)、并依托合理的流量控制、監(jiān)控保證服務穩(wěn)定性在99.995%。

• 業(yè)務能力：日志打點數(shù)據(jù)輸出至數(shù)據(jù)中心、性能平臺、策略中臺、增長中臺等，有效助力產品決策分析、端質量監(jiān)控、策略增長等領域。

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

?

二、日志中臺核心目標

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

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

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

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

2.1 日志中臺架構

接入日志中臺打點數(shù)據(jù)從端上生產至在線服務到最終（實時/離線）轉發(fā)至下游，需要經過如下幾個環(huán)節(jié)：

• 數(shù)據(jù)應用方式不同，有以下集中類型：

  • 實時

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

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

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

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

2.2 面臨的問題

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

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

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

  • 扇出多：有10+個業(yè)務扇出流，通過打點server轉發(fā)。

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

• 業(yè)務無等級劃分：

  • 核心業(yè)務與非核心業(yè)務架構部署耦合

  • 相互迭代、相互影響

三、不重不丟實現(xiàn)

3.1 數(shù)據(jù)不丟的理論基礎

3.1.1 唯2丟失數(shù)據(jù)理論

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

• 接入層：由于服務器不可避免的存在故障（服務重啟、服務器故障）的可能性，也存在一定的數(shù)據(jù)丟失概率

• 計算層：接入點之后，基于流式框架，建設需要嚴格意義的保證數(shù)據(jù)不重不丟。

3.1.2 日志中臺架構優(yōu)化方向

數(shù)據(jù)接入層面：

• • 先持久化數(shù)據(jù)，后業(yè)務處理的原則

  • 降低邏輯復雜度

下游轉發(fā)層面：

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

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

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

  • 區(qū)分優(yōu)先級：按照業(yè)務對不同數(shù)據(jù)訴求，區(qū)分不同類型

3.2 架構拆解

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

3.2.1 打點server服務拆解（優(yōu)化接入層數(shù)據(jù)丟失）

基于以上不重不丟的理論，日志接入層進行了如下幾個方面的建設，盡可能做到數(shù)據(jù)不重不丟。

• 日志優(yōu)先持久化：盡可能降低接入點因服務器故障等原因導致的數(shù)據(jù)丟失問題；

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

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

3.2.1.1 日志優(yōu)先持久化

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

持久化：接入層在真正業(yè)務處理之前，優(yōu)先將數(shù)據(jù)持久化處理，“盡可能”先保證數(shù)據(jù)不丟失。

實時流：避免直接對接消息隊列，優(yōu)先采用落盤+minos轉發(fā)消息隊列方式，保證數(shù)據(jù)至多分鐘級延遲的情況下，盡量不丟。

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

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

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

  • 接入層：功能單一，設計目標為數(shù)據(jù)盡可能不丟，保證數(shù)據(jù)第一時間持久化；

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

  • 業(yè)務層：組合訂閱扇出層數(shù)據(jù)，完成業(yè)務自有的需求實現(xiàn)，負責將打點數(shù)據(jù)生產并轉發(fā)至下游；

• 高時效類業(yè)務：

  • 策略實時推薦類的業(yè)務，單獨抽離服務，支撐rpc類的數(shù)據(jù)轉發(fā)，保證超高時效并保證數(shù)據(jù)轉發(fā)SLA達到99.95%以上；

• 其他類業(yè)務：

  • 數(shù)據(jù)監(jiān)控、vip、灰度等業(yè)務，對時效、丟失率要求進一步降低，可將這部分業(yè)務抽離至單獨服務；

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

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

3.2.1.3 流式計算思考

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

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

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

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

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

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

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

  • 輸出：數(shù)據(jù)混合計算后，輸出至業(yè)務消息隊列，業(yè)務方自行訂閱處理；

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

3.2.2 打點SDK數(shù)據(jù)上報優(yōu)化（解決端上報數(shù)據(jù)丟失）

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

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

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

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

四、展望

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

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

希望，日志中臺持續(xù)不斷優(yōu)化，為業(yè)務準確使用打點數(shù)據(jù)做出貢獻。

總結

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

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