效能平臺數據提速之路

語言: CN / TW / HK

時間 2023-03-07 15:01:43 百度Geek說

主題:

作者 | 效能中臺團隊

導讀

效能平臺負責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 服務分級理論支援

提高服務效率：更好地瞭解使用者的需求，提供更加精準、專業的服務，從而提高服務效率。
改善服務質量：服務分級可以讓使用者享受到更加貼近需求的服務，提高服務的質量和滿意度。
優化資源配置：更好地根據不同的服務需求和服務物件，優化資源配置，提高資源利用率。

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——