性能平台數據提速之路

語言: CN / TW / HK

作者 | 性能中台團隊

導讀

性能平台負責MEG所有研發數據的管理、接入、傳輸、應用等各個環節。數據的提速對於公司報表建設、決策分析、轉化策略效果都有至關重要的影響。重點介紹數據生產端與消費端提速落地實踐,如何高性價比滿足大數據生產端提速?如何在數據合規基礎上快速滿足數據報表提速?本文從業務優化視角整體介紹提速思路,包含5類優化路徑,涉及18種提速方法。

全文3689字,預計閲讀時間10分鐘。

01 概述

1.1 性能平台

性能平台是APP性能追蹤的一站式解決方案平台,為APP提供全面、專業、實時的性能分析服務與工具鏈。基於先進的端異常採集能力、實時反混淆技術等,提供實時性強、定位速度快、場景豐富的應用監控分析能力,並構建異常解決的閉環,在廠內移動端產品得以大範圍應用,保障移動端用户體驗,有效地減少了用户流失。

1.2 接入情況

已覆蓋了廠內大多數重點產品,其中包括:百度APP全打點、小程序、矩陣APP等,數據指標如下:

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

  • 服務規模:處理數據千億/日、端到端入庫時間毫秒級別、覆蓋用户數6億+。

1.3 名詞解釋

圖靈:新一代數倉平台,在實時計算、存儲能力、查詢引擎、資源調度等均有提升。

UDW:Universal Data Warehouse,百度通用數據倉庫,UDW用平台化的存儲管理、數據管理、數據建設過程管理和元數據管理技術,提供全面、一致、高質量、面向分析的用户行為基礎數據,百度早期數據倉庫。

TM:是一個面向工作流的分佈式計算系統,具有簡潔、高可靠性和高吞吐量的特性,且易被方便地管理和監控。能夠滿足準實時(秒到分鐘級)的流式計算需求,故障時可以做到數據不丟不重。

一脈:整合多種數據源的全業務自助分析工具,為分析師、PM、運營、RD各角色提供服務。一脈打破了原有報表、工具的定製限制,支持零SQL基礎的同學可視化拼接查詢條件、或直接SQL查詢,同時提供多種通用分析模板供大家使用。

AFS:百度自研的Append-Only分佈式文件系統產品,覆蓋百度所有業務線,為開發者提供高性能、高可用、高可擴展的存儲能力,廣泛應用於離線計算、AI訓練、數據備份等場景。

1.4 業務介紹

  • 覆蓋範圍:涵蓋崩潰、卡頓、Flutter、端異常、日誌回撈、網絡庫、磁盤等大部分性能場景,覆蓋了公司多條產品線

  • 數據加工:提供實時、可靠準確的實時用户監測,秒級精確加工10萬QPS吞吐數據。

  • 異常感知方面:事前線下檢測,事中平台上線check機制、事後分鐘級告警、感知並分析異常,快速止損;

  • 問題分析階段:多維聚類、多維探測、全網熱力圖、日誌調用鏈分析、日誌回撈等工具,協助快速定位問題; 圖片

02 面臨的問題

2.1 數據生產階段

  • 數據技術基建落後;存儲系統(廠版化無法迭代)、查詢引擎(廠內引擎下線、查詢速度較慢)、實時計算(不支持實時引擎)、資源調度(資源彈性弱)等能力不足;

  • 數據缺少服務分級;核心數據與非核心區分,服務級別保障機制不明確;離線數據流架構不合理、大量使用公共隊列數據SLA無法保障。預期:實時流數據分鐘級別SLA、準實時數據30分鐘級別SLA、離線流數據小時級別SLA;

  • 數據無效/重複上報;部分點位下線、點位之間功能重合度高仍在上報導致數據總量存在虛高;數據報表宂餘,無人訪問或者業務重複;有限計算/存儲資源供給到無效數據上。

2.2 數據消費階段

  • 數據合規性難保障;數據缺少統一出口,數據消費同時存在接口、結果層數據庫、中間層數據等系統中進行數據報表呈現,用於數據分析、報警監控。

  • 數據需求滿足度低;報表類需求佔我們需求整體接近50%, 數據需求需要點對點單獨排期與開發,此研發流程投入大,需求交付速度慢。

  • 用户整體滿意度低;數據實時性差:從數據產生到數據可被查詢,中間存在較高時延(從數十分鐘到天級別不等)查詢較慢,SLA保障機制弱;數據需求交付慢:用户數據需求完全依賴數據團隊產出,當有人力補充時數據維護/學習成本高,容易出現Delay,增加字段/修改數據源等會覆蓋整個流程。

03 優化路徑

3.1 新老基建對比

思路:基於流批一體的思路,通過TM引擎的實時解析平鋪 + Spark動態索引導入圖靈的方式代替QE引擎靜態導入UDW,從而進行ETL階段的提速,在該階段提前將嵌套字段進行鋪平形成圖靈研發大表去除舊數據流中的中間表產出環節。

3.1.1 新老基建對比

圖片

3.1.2 新老數據流

圖片

3.2 數據服務分級

3.2.1 服務分級理論支持

  1. 提高服務效率:更好地瞭解用户的需求,提供更加精準、專業的服務,從而提高服務效率。

  2. 改善服務質量:服務分級可以讓用户享受到更加貼近需求的服務,提高服務的質量和滿意度。

  3. 優化資源配置:更好地根據不同的服務需求和服務對象,優化資源配置,提高資源利用率。

3.2.2 數據流/報表SLA

圖片

3.3 數據點位/指標/報表治理

3.3.1 治理思路

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ezx2sPvX-1678155747102)(https://mmbiz.qpic.cn/mmbiz_png/5p8giadRibbO9765J2SfqzcZFneaEYktrhGsuY2DPzAUO42UkeViblKmWILWHbAzch1Hibk1w6dibcGZyHWD202KHWA/640?wx_fmt=png)]

3.4 數據合規性治理

3.4.1 背景介紹

2021年9月1日正式實施《中華人民共和國數據安全法》,涉及數據的出口管制、數據分類分級、數據合規性等一系列數據方面法律法規要求。數據消費流程增加勢必會影響用户使用體驗,如何在數據滿足合規的基礎上快速助力業務發展是我們的努力的方向。

數據BI平台/ 性能平台/其他數據分析平台數據接入方案大致分為如下幾種:

1、直連存儲引擎;

2、數據抽象API ;

3、數據自產自銷;我們的業務特點連接雙端研發、多方數據、QA等多方面角色對接,初中期適合API方式,慢慢收斂到數據自產自銷。

圖片

補充説明:

市面上的BI分析均支持API方式連接,基本已實現協議標準化。BI連接數據庫查詢方式,主要優點在於快速實現報表,但是在數據合規、數據緩存、負載均衡、多引擎數據聚合等能力上明顯弱於API方式。

3.4.2 API優化點舉例説明

圖片

3.4.3 元數據查詢協議説明

// Schema 數據獲取能力描述
// 協議能力描述:
// 1. 數據查詢能力,多引擎/標準SQL查詢能力封裝「如:palo/mysql/clickhouse/es-sql等」Query結構。
// 2. 數據聚合能力,具備單關鍵字數據組合&Merge能力,如果Len(Schema.Query)>1:具備數據聚合能力. 
// 3. 數據緩存能力,兩層級緩存能力封裝,Cache結構。
type Schema struct {
  // 元數據查詢能力描述
  Query []Query `json:"query"`
  // 元數據整體緩存能力描述
  Cache Cache `json:"cache"`
}

// Query 數據查詢能力描述
type Query struct {
  // 結構化查詢描述
  SQL string `json:"sql"`
  // 產品線信息, rpc_name = meta_{engine}_{prod}.toml, rpc通信具備超時控制、服務發現、高級負載均衡策略等穩定性提升能力
  Prod string `json:"prod"`
  // 存儲引擎描述, 調用不同引擎能力
  Engine string `json:"engine"`
  // 單次查詢緩存能力描述
  Cache Cache `json:"cache"`
}

3.5 數據自助化建設

3.5.1 背景介紹

通過近一年需求數據分析,報表類需求佔整體數據需求的50%,如果實現數據報表自助化,需要按照數倉分層,可達成數據消費側的需求快速交付與報表時效性提升。

自助化方式與數據流有關,針對實時數據流採用內存方式構建寬表,準實時/離線採用磁盤寬表構建。

圖片

3.5.2 實時化自助化(內存)

內存自助化核心邏輯包含:

  • 日誌協議Schema的解析;性能平台在業務方配置自助化任務之前,會採用離線任務天級別的將性能平台涉及到的UBC點位進行Schema的解析,即將UBC協議的Schema進行按層級全局展開,供業務方在界面上進行勾選。

  • 內存寬表的建立; 業務方在性能平台上完成自助配置化任務時,勾選自身需要清洗的UBC點位日誌經過平鋪後的協議字段,通過性能平台提供的通用函數解析(透傳、時間函數、網絡函數等)以及性能平台提供的自定義函數QLExpress進行原始協議的清洗,然後平鋪成一張內存寬表。

  • 寬表數據聚合;業務方自身的需求往往有PV聚合、UV聚合、分位數聚合等一些常用指標的聚合計算,此時利用性能平台提供的聚合模板選擇相應維度指標進行計算,形成最終的聚合結果指標。

  • UI配置、告警配置;業務方得到最終的聚合結果指標後,可以選擇聚合後的維度和指標構建UI,例如折線圖,表格等。同時,也可以根據聚合後的指標配置閾值告警。最終,通過上述的流程,業務方自助化的完成了數據流的建立、UI報表的生成,告警的配置。

3.5.3 準實時&離線數據自助化(磁盤)

以Feed研發寬表舉例説明,通過數據分層強化數據層職責範圍,每一層級數據量級明顯減少,對用户側結果數據報表提速明顯。數據研發同學關注各層之間數據SLA與需求功能的滿足;用户通過業務寬表、寬表説明文檔、報表自助化平台實現報表自助化,來達成需求快速實現。

圖片

04 未來展望

前文介紹了性能平台在數據生產與數據消費端的提速手段與具體案例,所做的一些努力。後面我們還會繼續優化系統,如:

  • 數據時效性可説明,報表承諾時間與報表實際產出時間,各個階段數據漏斗,達到時效性數據的沉澱與可分析。

  • 數據準確性可證明,在APP接入層與數據報表之間,通過構造預期Case與實際數據做對比,來判別系統數據準確性;

希望,性能平台在數據安全合規的基礎上快速賦能支撐業務發展。

——END——

推薦閲讀:

採編式AIGC視頻生產流程編排實踐

百度工程師漫談視頻理解

百度工程師帶你瞭解Module Federation

巧用Golang泛型,簡化代碼編寫

Go語言DDD實戰初級篇

Diffie-Hellman密鑰協商算法探究