搜索數據建設系列之數據架構重構

導讀

主要概述百度搜索業務數據建設的創新實踐，重點圍繞寬表模型設計、計算引擎優化和新一代業務服務交付模式（圖靈3.0開發模式）三大方向，解決了傳統數倉在搜索場景下面臨的諸多挑戰，實現了搜索數據建設的高效、穩定、低成本；為百度搜索業務敏捷迭代奠定夯實基礎。

名詞解釋

TDS（Turing Data Studio）：是基于圖靈（百度內部數據分析平臺）的數據建設解決方案，提供數據開發、數倉管理、監控運維、資源管理等一站式服務的數據開發平臺。詳情參見：百度MEG數據開發治理平臺-TDS

TDA（Turing Data Analysis）：是一款可視化BI產品，旨在幫助用戶輕松上手及使用，進行拖拽式可視化數據分析及儀表盤建設。產品模塊包括儀表盤、數據集、可視化分析及智能分析模塊。詳情參見：百度一站式數據自助分析平臺（TDA）建設

TDE（Turing Data Engine ）：是基于圖靈生態的計算引擎，包含Spark計算引擎和ClickHouse。詳情參見：揭秘百度數倉融合計算引擎ClickHouse在百度MEG數據中臺的落地和優化

UPI（Udw-API）：百度內部編程訪問接口；以Map/Reduce計算框架為主，適用于計算邏輯復雜，以及多種數據源混合計算的例行離線數據挖掘業務

數倉融合計算引擎：是百度自主研發，基于spark自研的adhoc服務。提供數據查詢分析，具有簡單易用、超大規模支持、成本極低等特點，能實現T級數據秒級查詢，也適用于例行生產的 ETL 場景。

函谷：圖靈核心模塊，作為圖靈查詢的gateway，完成圖靈查詢的接收、分發、提交執行、查詢進展輪詢、結果獲取等一系列功能。

01 背景與問題

1.1 背景

在當今互聯網產品發展日新月異、業務迭代迅猛的時代；跨業務分析的需求日益增長，這種變化既為企業創造了敏捷決策、精準運營的新機遇，也帶來數據割裂、價值釋放滯后等嚴峻挑戰。特別是大型互聯網企業，往往構建有復雜的多業務、多模塊、多線條體系，每日持續產出海量的數據信息。這些數據的服務對象正逐步從數據研發人員擴展至更為廣泛的產品相關人員，如何高效開展數據獲取工作，打破數據孤島現象，充分挖掘并釋放數據驅動業務的潛力，已成為業界廣泛關注和討論的焦點議題。針對該問題，業界傳統數倉常采用的是經典分層模型的數倉架構，從ODS（Operational Data Store）>DWD（Data Warehouse Detail）>DWS（Data Warehouse Summary）>ADS（Application Data Store）逐層建模，但我們會發現，從傳統固化開發的角度來看，傳統經典數倉模型是比較有優勢的。然而，面對當下數據需求靈活多變的時代，其局限性也日益凸顯。如下圖

1.2 搜索場景下的困境與挑戰

搜索作為百度的核心支柱業務，涵蓋通用搜索、智能搜索、阿拉丁與垂類等多元化、多模態的搜索產品，具有快速迭代、模塊多元化且復雜的特性，搜索數據更是復雜多樣，整體數倉規模達到數百PB以上。

隨著搜索業務各個模塊之間的聯系日益緊密，交叉分析的需求也在不斷增長。使用人員對數據獲取的便捷性提出了更高的要求，其中涵蓋了數據分析師、策略、業務產品經理、運營、評估等多類角色。他們的訴求期望能夠跨越復雜的數據架構壁壘，以更加高效、直觀、快速的方式獲取到所需數據。

而傳統的搜索數倉建設體系無論從建模角度還是技術框架上，都與現階段用戶訴求背道而馳。

建模角度：多層的傳統分層建模。往往會出現（大表數據量大、查詢慢、存儲冗余、口徑不統一）等問題，影響業務分析效率，從而達不到數據驅動業務的效果。數據開發側作為需求的被動承接方，根據業務側提出的數據需求進行數據開發與交付，存在需求交付周期長、人力成本高等問題。
技術框架角度：搜索數倉過去大多是采用UPI框架（以C++ MR計算框架為主）進行ETL處理。由于該框架技術陳舊，往往會出現以下問題影響數倉整體時效、穩定。從而使業務部門感知需求支持遲緩、數據產出延遲及數據質量低等一系列問題。

容易出現服務不穩定。
處理能力薄弱：處理不了特殊字符，從而導致數據丟失或任務失敗等。
只能通過物理機遠程執行的方式提交，有單節點風險。
無法Writer將數據寫到Parquet文件，需要進行特定腳本ETLServer框架進行轉換。

思考：如何更好的滿足用戶角色需求，進一步降低數據獲取的使用門檻？

破局：擁抱變化，以用戶訴求為核心出發點。探索更適合用戶的 體系化建模 來進行實質、有效的數據管理。

體系化建模：以業務產品需求驅動模型設計，以模型設計驅動和約束開發實施，防止因模型設計與業務產品割裂、開發實施缺少約束帶來的無序、“煙囪式”開發。在機制上形成模型設計與開發實施的有效協同。

切入點：以規范“基礎數據建設”，消除因“煙囪式”開發給業務帶來的困擾和技術上的浪費。

由此我們探索出一套新的建模體系：大寬表+數據集：其核心點就是基于寬表將之前的"需求-交付"解耦為以數據集為中心的建設，從而提升搜索內業務數據分析效率與分析深度，更好助力業務決策。以下將從寬表建模、計算引擎架構優化、新型業務交付模式等方向為大家介紹搜索數據團隊業務實踐。

02 搜索建模思路與技術方案

2.1 建模模型

2.1.1 思路

基于搜索產品功能特性與差異化業務場景，我們對日志數據進行主題化的分類。在每個主題域內，結合業務運營的具體環節特征，構建具備高整合度的寬表模型。在模型構建過程中，保持 ODS（操作數據存儲）層與 DWD（明細數據層）的表結構粒度一致，確保數據的一致性與連貫性。所構建的寬表不僅完整涵蓋下游業務所需的全部字段，包括業務明細表中的基礎數據，還整合了各層級的維度屬性與計算指標。通過這種方式，形成一個全面、統一的數據底座，為上層業務的多維分析、指標監控及決策支持提供堅實的數據支撐，有效滿足多樣化的業務分析需求。

2.1.1.1 舉例

以展點主題為例，從歷史的模型表粒度和模型層級來分析：ODS與DWD、DWS表行為、檢索、點擊各個主題在同層模型或者跨模型之間都存在字段、口徑的冗余，如下圖

2.1.1.2 思路分析過程

核心思想過程：展點主題下明確粒度，豐富維度&指標建設寬表模型。

將展點主題下各層之間的事實表復雜嵌套字段打平后與各個維度表、指標等進行join生成寬表，寬表的列最終分為公共屬性、展點行為屬性、業務屬性和指標屬性。

消除：

數倉層間：字段存儲冗余問題
數倉層內：口徑不一致問題

2.1.2 建模核心思想

基于思路分析過程，總結出一套核心建模理論，核心思想如下圖

構建搜索系統性數據建模：根據產品功能和業務不同，按照不同主題構建寬表。從而達到節約存儲、精簡表數量、口徑更清晰的目標。

2.1.3 整體模型架構

基于核心建模思想理論得到整體的模型架構，如下圖

采用Parquet列式存儲，可支持寬表數百、千列，超多字段，再經過按列的高效壓縮（bucket sort后，壓縮率更高），降低了數倉整體存儲空間，提高了IO效率，起到了降低上層應用延遲的效果。
將各層之間的表復雜嵌套字段打平后與各個維度表、指標等進行join生成百列寬表，寬表的列最終分為公共屬性、業務維度屬性和指標屬性，便于業務分析，實現快速迭代。

2.2 計算引擎

為了保證數據生產穩定、準確性。我們對計算引擎的選擇做了升級，采用傳統Spark結合數倉融合計算引擎對搜索數倉ETL進行重構。

2.2.1 從架構&處理流程上

C++ MR ：多進程，每個任務獨立運行，必須經過Map-Shuffle-Reduce，然后中間結果寫磁盤。
Spark ：多線程，任務在Executor內以線程執行。基于DAG，可以在內存中緩存數據，減少IO。

Spark 框架相較于 MR框架優勢在于

基于內存計算，處理速度快。
支持多種計算模式，功能豐富，適合迭代處理數據。
提供了高級的 API，開發效率高。
基于平臺提交，有效避免單節點計算風險。

且在有shuffle情況下計算表現更好（MR在Shuffle時默認進行排序，spark對shuffle有優化，只有在部分場景才需要排序），在具體業務實踐中：同耗時的情況下，Spark計算資源相較于MR節省20%左右。

2.2.2 ETLServer到數倉融合引擎轉變

各主題寬表模型的計算通過數倉融合計算引擎（通過Spark Application Context常駐方式做到資源有效復用；省去了啟動Driver的時間實現任務的快速啟動，來提升任務執行時間）可直接Writer將數據寫到Parquet文件，文件無需進行多次腳本server轉換。

在具體業務實踐中各主題計算耗時由之前40min 縮短至 10min（減少了30min），實現數倉快速產出。

2.3 新數據模型及架構下的挑戰與解決方案

任何數倉模型架構不會存在一個絕對完美的、涵蓋所有方面的解決方案。寬表設計僅是當前環境數倉模型的最優解，它依然面臨著諸多不容忽視的挑戰。

2.3.1 挑戰1解決方案

列式存儲&讀取：

寬表采用了Parquet列式存儲，以及ZSTD高效壓縮算法。結合數倉融合引擎，達到Data Skipping（即讀的越少、計算越快）的效果，僅需讀取查詢涉及的分區及列，減少了磁盤 I/O 和內存傳輸的數據量來提升查詢效率，通過Sql分析服務發現熱點復雜字段，主動引導業務建設物化列，命中后查詢性能提升80%。

復雜嵌套字段打平：

業務常用核心指標以及高頻字段口徑下沉寬表。雖然行數變多了，但是避免了explode，get_json_object、array、map等復雜字段獲取的耗時操作，查詢性能相較于之前提升了2.1倍。

2.3.2 挑戰2解決方案

搜索數據升級到了湖倉一體架構，借助Iceberg Merge Into功能，實現高效回溯方式：對表數據進行行級別的更新或刪除。相比insert overwrite 操作更加高效，減少了不必要的數據移動和存儲浪費。

通過單一原子操作實現了復雜的數據整合需求。相比傳統的先刪除再插入的方式，Merge Into提供了更好的性能和一致性保證，其原理是通過重寫包含需要刪除和更新行數據所在的date files。Merge Into可以使用一個查詢結果數據來更新目標表的數據，其語法類似join關聯方式，根據指定的匹配條件對匹配的行數據進行相應的操作

Merge Into基本語法

回溯原理流程如下圖

1. 關聯匹配：

目標表和源表根據指定key進行join操作。

2. 條件判斷：

若Key匹配：根據源表操作類型，對目標表中的記錄執行相應的操作（更新或刪除）。
若Key不匹配：執行Insert操作，將源表數據插入目標表。

3. 原子性操作：

整個流程是事務性的，確保數據一致性。

以下是特定回溯場景下 hive與iceberg不同方式的回溯耗時對比，可以看的出來用merge into代替insert overwrite進行回溯，回溯更新效率整體可提高54%左右。

2.3.3 挑戰3解決方案

2.3.3.1 重排序、高效壓縮

開發ATO優化器(通過任務依次執行重排序、壓縮等一系列Rules，實現分區優化和數據重分布)，高效率壓縮，解決存儲成本，存儲節約20%。

（1）壓縮編碼

數倉表字段元信息采集：通過任務對圖靈寬表表進行字段元信息采集，分析數據分布情況，獲取重排序字段。

具體做法：通過RLE、Delta等縮碼方式來提升數據壓縮效率；數據重復度越高、連續性越好（有序）的場景，壓縮效率會越高，RLE、Delta編碼原理如下。

（2）壓縮格式

使用ZSTD壓縮格式和更大的壓縮level，在不影響查詢性能的情況下，更大的壓縮level能進一步提高壓縮率，level=9時在壓縮效率和耗時上最為平衡，讀寫耗時和壓縮率對比效果如下。

（3） Page Size

針對Parquet文件格式特性進行深入挖掘，對Parquet page size進行分頁擴容，將Page Size從1MB增大至5MB，讓更多相似的數據集中到同一個數據頁中，充分利用編碼的壓縮特性，進一步減少各個數據頁之間存在的相似數據。在ZSTD的基礎上，能進一步提升壓縮效果，效果如下

2.3.3.2 歷史裁剪，管理有效字段

開發了一套半自動化的通用裁剪模式，通過采集日常任務代碼，sql parser模塊解析出無用字段信息（尤其是大json 大map類型擴展字段的無用字段）自動化實現了裁剪。減少了 50% 的回溯任務計算資源消耗，將人力投入從5人/天降低到0.5人/天。

字段頻率統計模塊：通過對函谷 SQL 數據庫和 TDS 平臺 No SQL 任務的物理執行計劃進行解析，實現對寬表 SQL 任務和非 SQL 任務的字段訪問頻率的自動化統計。
裁剪字段抽取模塊：基于字段訪問頻率，每月抽取冷溫字段，形成可視化的字段訪問頻率報表，生成裁剪 SQL。
**冷溫字段告警模塊：**通過對比前一個月和本月冷溫字段列表，生成當月新增冷溫字段列表，然后向產品研發團隊和數據RD團隊發出告警，確認需要動態調整的裁剪字段；引入冷溫字段告警模塊，成功實現了裁剪字段的動態調整。最后，通過滾動裁剪模塊自動裁剪395天前的數據，進一步降低人力/資源的消耗。
滾動裁剪模塊：自動化滾動裁剪，裁剪寬表中395天前的數據。

基于業務實踐證明：寬表數倉模型與數倉融合計算引擎的結合比傳統數倉模型更適合面向服務于快速迭代的驅動型業務，主要體現在

1. 查詢性能巨大提升帶來快速響應支持業務需求：

簡單查詢場景：Adhoc查詢場景，耗時在數十秒級別，相比于普通Spark性能提升5倍。

復雜場景：業務常用復雜字段拆分打平，避免數組、map等復雜字段耗時操作、查詢性能提升2.1倍。

2.口徑封裝下沉：封裝業務核心口徑，解決業務長期數據源多、口徑不一致帶來的數據準確性問題，省去不必要的溝通，使用更加簡便。

3.減少冗余存儲：相較于經典傳統數倉同主題模型下存儲降低30%左右。

03 基于建模與技術框架初步整合探討圖靈3.0生態新一代業務服務交付模式

隨著搜索數倉模型&計算引擎架構的重構和技術棧統一，搜索數倉定義逐步清晰化、數倉個數大幅度降低，整體趨向更加緊湊、高效以及收斂的態勢。在此基礎上，為了助力數據迭代效率和分析效率進一步提升，在業務線基礎數倉及應用層數據建設上，百度MEG內部開發了圖靈3.0生態系統（即數倉合理建設，數據分析需求盡可能收斂到TDA平臺，配套數據集建設完善），包括Turing Data Engine(TDE)計算引擎、Turing Data Studio(TDS)數據開發治理平臺和Turing Data Analysis(TDA)可視化BI產品。依托圖靈3.0生態，我們進而形成了一套新的開發范式—— 圖靈3.0新開發模式，用來提升搜索內業務數據分析效率與分析深度，如下圖（階段三）所示

3.1 階段一到階段二

如之前所述：由于搜索數倉早期查詢性能不理想，為了提升業務分析效率建設了大量的業務表。從而導致數據冗余、數據鏈路穩定性差、效率低、指標口徑不一致等一系列問題。搜索數據團隊通過數倉模型（將多層數據模型控制在1-2層）以及計算引擎架構升級重構、湖倉一體、高效壓縮、裁剪等一系列措施解決了這些問題。數據建設更加完善規范化，搜索數倉表的數量由過去的數百張減少至20張左右，時效性大幅提升，全數據鏈路全流程提速4H+，數據穩定性及運維成本降低30%。

3.2 階段二到階段三

隨著圖靈3.0生態系統（包括TDA、TDS、TDE）及搜索數倉模型的日益完善，內部提出了以數據集為核心來構建數據應用層，將數據開發側與業務側的依賴關系從之前的"需求-交付"解耦為以數據集為中心的建設，實現數據集<->可視化分析<->儀表盤的數據分析閉環，解決業務常用維度、指標長周期的查詢分析需求 ——> 圖靈3.0新開發模式。

圖靈3.0新開發模式核心思想在于數據集的建設，我們將不再僅僅只是根據業務需求來定制開發數據報表，而是構建一個靈活、可擴展的數據集。使業務側能夠自主地根據需求從中提取、分析和可視化數據，以滿足不斷變化的業務需求。

那么，在數據集建模實踐中，如何才能合理構建一個靈活、可擴展且高質量的數據集？是數據研發對數據集建模關鍵核心，也是最大的挑戰。

3.2.1 數據集建模合理度挑戰

1. 為了滿足業務需求的多樣性與廣泛性，并支持更多的維度和指標。我們往往會傾向于在單個數據集中不斷疊加新的維度和指標，這種做法雖然表面上看起來方便快捷，但實際上卻導致了數據集行數的急劇增加，進而對聚合查詢的性能造成了不利影響

為了確保查詢的高效性，同時兼顧更多維度與指標的業務需求。我們往往的做法就是建立更多的數據集，以空間換時間去滿足查詢性能。

顯然，這些做法之間存在著明顯的矛盾，具體如下圖。

3.2.2 解決方案

為了更好地找到平衡點，搜索數據團隊采取了以下解決措施：

明確邊界：分主題建設對應數據集，單主題內數據集盡量做到合并統一，以達到更高的集成度與一致性。
明確粒度：從業務場景需求出發，單主題內數據集建設前明確數據集最小粒度，確保數據最小粒度既能滿足主題分析的精度要求，又避免因過度細化或粗放導致的分析效能損耗，為后續數據集的結構化構建與高效奠定基礎。
深度性能優化：充分利用了TDE-ClickHouse強大基礎引擎，例如在處理高基數去重計數字段時創新性地采用NoMerge技術來替代傳統的COUNT(DISTINCT)方法，降低了聚合層的計算負擔，實現了查詢性能5至10倍的提升，極大地優化了數據處理速度。

3.3 新模式帶來的改變

△ 圖靈3.0的數據開發新模式

強化主動能力，業務自助效率顯著提升：相較于以往被動式的一對一需求定制化開發模式，數據研發工作已從單純響應被動需求轉變為主動規劃構建數據集。圖靈3.0新開發模式下，實現數據集<->可視化分析<->儀表盤的數據分析閉環（滿足 90%查詢；其余10%長尾交給Adhoc查詢），業務人員對日常通用需求的分析工作轉移到數據集自助查詢與分析上（根據數據集自助創建可視化數據報表）。可視化分析占比、業務自助率提高至90%，數據研發日常需求量減少80%。
非核心常用維度指標查詢性能顯著提升：非核心常用維度指標由以往業務提需查表或單獨建設報表來獲取數據的方式轉變為通過數據集自助下鉆、拖拉拽自由組合常用維度指標，實現可視化分析的方式。借助TDE-ClickHouse 強大基礎引擎能力：可視化分析效率大幅提升，從小時、分鐘級的數據分析效率提升至秒級分析。單次查詢數據周期由1周內提升至1年內（秒級完成查詢），真正做到即需即查即用。
血緣管理規范化，運維效率顯著提升：數據血緣更加完整流程化，數倉-數據集血緣在TDS完成閉環，數據集內字段血緣在TDA完成閉環，以數據集為紐帶串聯整個數據流全過程，數據鏈路運維效率提升2-3倍。

目前，該模式已經廣泛應用于搜索各業務數據運營人員早報、周報等多種業務匯報場景。得益于該模式，搜索產品線下儀表盤周均查詢（PV）高達1.7W次左右，可視化分析周均0.93W次左右，每周超過400多名用戶參與TDA搜索數據分析工作。更重要的是，需求的交付周期實現了顯著縮短，由以往的單/雙周縮短至按天交付；甚至在某些情況下，業務人員能夠直接自助獲取所需數據。在處理重點項目時，該模式也能確保業務團隊在第一時間獲取到P0級別的關鍵數據。這種方式的轉變不僅能夠減輕數據開發團隊的工作負擔——人力成本由原先的3人銳減至1人，還能提高業務側的數據使用效率和自主性，使得團隊得以從繁瑣的“取數”與“跑數”任務中解放出來，將更多的精力投入到數倉模型的優化、技術框架的探索與治理等更具戰略價值的工作中去。