百度搜索中臺海量數據管理的雲原生和智能化實踐

一、背景

1.1 背景簡介

百度搜索中臺支持的業務線多、業務層面的差異性很大，使得數據的管理、存儲和計算的成本，對檢索架構形成巨大挑戰。比如傳統模式下的業務接入，我們要人工評估數據規模進而設計合理的在線部署方案、實現合理的成本，但是業務很難知道自己的數據規模、或者在較短時間內數據有了數倍的增長，需要人工調整部署方案，這個不僅週期長、人力投入大，也會導致穩定性和效果方面的風險。

爲了高效支撐衆多業務內容數據的接入、迭代，我們設計了雲原生時代的內容數據智能架構，通過數據管理的智能化實現人工維護效率的極大提升，並實現按需分配優化成本；在海量數據的檢索下，實現高可用和高性能，用創新技術保障用戶體驗。

本文的主要內容集中在下圖中的中間部分：

大致流程如下：

1. 業務經過離線建庫環節產出建庫包，並生效到消息中間件中。

2. 業務內容數據（比如索引數據、正排數據）按大小拆成相應的分片服務，並通過訂閱分片映射的消息 Topic 數據，實現流式更新。

3. 每個分片由 PaaS 容器承載，啓動時從 DFS 拉取對應的存量數據，並定時將數據持久化上傳到 DFS 中；並從數據中間件讀取增量數據，從而實現有狀態服務的雲原生。

4. 業務檢索請求通過 PaaS 層面的服務發現，檢索對應業務的內容數據。

和其他業務場景不同，我們搜索業務的特點主要有：

1. 存儲 / 計算難以分離： 搜索場景的高性能、低延遲要求，計算和存儲難以拆開專項優化，需要本地化的存儲 + 計算。

2. 全扇出的併發模式： 搜索場景是 Query 到 Doc 的映射，需要經過語義解析、構建檢索表達式、扇出所有的分片服務、合併結果，而常規場景下的 Key/Value 查詢，可以通過 Hash 關係實現精準的扇出。

3. 最終一致性保證： 副本間沒有通信，通過消息隊列增量更新方式，保證秒級別的最終一致性。

1.2 上代內容數據管理架構存在的問題

上述架構很好的完成了 PaaS 化、自動化運維的歷史目標，但隨着新業務的接入和存量業務的迭代深耕，差異化 / 高頻化的內容數據需求場景，給這種偏靜態模式下的管理架構帶來了極大的挑戰，具體體現在：

1. 效率方面：偏靜態模式下的容量調整，需要人工調整數據的分佈、分片的大小、扇出的規則，往往需要周級別甚至是月級別才能完成，越來越高頻的容量調整需求，使得上述架構無法在效率層面繼續滿足業務的需求。

2. 成本方面：部分業務具有多種場景的內容數據，不同場景的數據訪問頻度差異是巨大的，靜態的數據管理架構難以實現資源的按需分配和 rebalance(再平衡）。

3. 穩定性方面：單業務數據量級由億級別突破至 50 億級別，全扇出模式下需要扇出數百個分片服務，極大扇出帶來的是可用性的急劇下降。

4. 性能方面：關聯計算（比如 join 操作）需要上游多次檢索查詢 & 合併，性能層面難以滿足業務的延遲要求。

爲了解決上述問題，我們以雲原生化的思路對上述架構進行了改造，通過彈性伸縮和按需分配機制來解決效率和成本問題，然後基於雲原生之上引入數據調度策略來解決穩定性和性能問題。

二、整體架構設計

2.1 架構概述

名詞解釋：

• 分區 (slot)：數據管理的最小單元（比如一組索引數據），進一步抽象和拆解上代架構中關於消息中間件 Topic 的概念。

• 分片 (shard)：承載一組 slot 數據的引擎服務。

• 副本 (replica)：分片中的一個實例。

• 套餐類型：預定義的一系列標準化的容器資源規格（比如存儲類型可選用 RAM/SSD/DISK 等介質），滿足各類檢索場景對資源的匹配訴求。

架構核心組成：

1. 分區控制單元：根據業務場景和內容數據的特徵，控制建庫時的分區策略，比如按某特徵匯聚（實現關聯計算）、某維度打散（實現冷熱分離）等等。

2. 分片控制單元：根據檢索場景的數據量，控制所需要的分片規模，實現分片的容量調整。

3. 副本控制單元：根據檢索場景的資源訴求、流量、性能要求，控制分片所使用的套餐類型和副本個數，同時對接 PaaS 系統，實現套餐資源池的管理。

4. 尋址控制單元：根據業務的分區策略和分片策略，結合數據 slot 層面的服務發現機制，實現數據層面的動態尋址能力。

2.2 核心工作流程

1. 評估業務檢索場景和內容數據的特徵等，生成相關控制策略，比如分區策略、分片策略、副本策略、尋址策略。

2. 內容建庫數據通過【分區控制器】寫入到數據中心。

3. 【分片控制器】初始化分片的服務信息，比如分片的個數和要管控的數據分區等。

4. 【副本控制器】根據副本策略和分片策略來分配實例、註冊服務。

5. 【尋址控制器】實現數據層面的服務註冊和發現機制。

6. 業務通過【尋址控制器】來訪問相應的內容數據。

三、雲原生化設計

針對容量調整效率低下和冷熱差異大導致的成本浪費問題，我們以雲原生化的思路對上代架構進行了改造，實現了數據的彈性伸縮和資源的按需分配。

3.1 彈性伸縮機制設計

彈性伸縮包括垂直伸縮和水平伸縮，各自特點簡介如下：

• 垂直伸縮：調整物理硬件配置的方式，來增強系統的彈性，比如調大容器的資源配額、更換 ssd 等。

• 好處：速度快、操作簡單等

• 缺點：容器遷移 & 故障恢復週期長、有瓶頸問題（天花板較低）。

• 水平伸縮：調整副本數來應對流量、數據量的漲幅情況。

• 好處：天花板足夠高。

• 缺點：實現困難、門檻較高。

垂直伸縮受限比較多，我們採取了水平伸縮方案，針對搜索場景下如何實現水平伸縮呢？

3.1.1 針對流量上漲場景下的水平伸縮

由於最終一致性的前提約束，可以通過增加 shard-0 副本數的方式，實現水平擴展。

3.1.2 針對數據量上漲場景下的水平伸縮

1. 系統檢測到分片服務容量達到閾值，或者人工發起容量指令，比如遊戲檢索數據由 2 分片調整爲 4 分片。

2. 分片控制器計算調整後的分片需求，並初始化新的數據分片所綁定的數據區間，shard1=[2,4)、shard3=[6,8)

3. 尋址控制器通過服務發現機制，感知到分片調整 & 新分片服務 ready 後，開始更新路由規則，由 2 分片調整爲 4 分片。

4. 路由切換後，開始清除舊分片無用的數據，shard0=[0,4) -> shard0=[0,2)、shard1=[4,8) -> shard2=[4,6)。

通過上述流程實現了數據量上漲的情況下，分片原地擴容的方案。

3.1.3 實際效果

通過自動化的彈性伸縮能力，實現了業務數據流量、容量快速變化場景下的極致伸縮，容量調整由周級別降低爲小時級。

3.2 資源按需分配機制設計

資源按需分配機制常常出現在離線計算領域，由於它對延遲不太敏感、更注重吞吐，目前有一些比較成熟的解決思路。但對延遲和性能要求比較苛刻的在線檢索領域，如何實現資源的按需分配呢？我們目前的解決思路是冷熱數據的分離。

3.2.1 冷熱分離機制實現資源的按需分配

搜索業務一般包含多種檢索場景（比如問答場景、推薦場景等等），每種檢索場景的數據量和檢索性能特徵不盡相同，關鍵特徵如下：

ofl6lM

根據業務場景特徵決策的數據分佈和尋址情況如下圖所示：

1. 【分區控制器】根據業務的數據特徵規劃數據的分佈，比如按冷熱屬性、按場景屬性等，場景 A 分佈在 [0,4)、場景 B 分佈在 [4,20)。

2. 【分片控制器】根據數據規模、拉鍊長度等特徵確定分片規模，場景 A 劃分 1 個分片，場景 B 劃分 4 個分片。

3. 【副本控制器】根據數據訪問 qps 和延遲特徵，挑選不同存儲介質和副本數，場景 A&B 選擇高性能 / 低延遲容器組，場景 C 選擇大容量 / 低成本容器組，場景 A 需要 5 副本，其他僅需要 2 副本。

4. 【尋址控制器】提供業務不同場景數據的服務發現能力。

通過冷熱分離機制 & 結合業務檢索特徵，選擇相應的資源套餐，實現資源的按需分配。

3.2.3 實際效果

業務平均節省成本 30%，典型業務場景下可節省成本 80%。

四、進階雲原生

通過雲原生化的改造，我們解決了上代架構面臨的效率和成本問題，對於極大扇出帶來的穩定性問題和典型場景下的性能退化問題，我們的解決思路是引入數據調度策略：**控制檢索數據分佈和計算方向，**實現最大化的精準扇出和本地化的計算加速。

4.1 精準扇出數據調度策略

搜索場景是 Query 到 Doc 的映射，全分片扇出的併發模式。對於超大規模業務來說，需要劃分衆多的數據分片，全扇出模式下會帶來一些穩定性問題，比如業務 A 需要劃分 100 個分片，每個分片的服務可用性是 99.99%，在全扇出模式下，整體可用性只有 99.99% ^ 100 ≈ 99%。

爲了解決上述問題，我們設計了精準扇出數據調度策略，針對極大扇出的業務檢索場景，抽取業務檢索的通用特徵（比如按用戶 ID、按店鋪 ID），控制數據的分佈和計算方向，實現大規模檢索場景下的精準扇出。

4.1.1 解決極大扇出帶來的穩定性問題

以店鋪內檢索場景爲例，其場景特點如下：

• 業務特徵：檢索數據均帶有店鋪 ID 標識、用戶請求是按照店鋪級別搜索，整體數據量級十億級。

• 檢索請求：

• 查詢某個店鋪的商品

• …

• 建庫請求：

• 某個店鋪商品信息的更新

• …

精準扇出調度策略示例如下：

1. 【分區控制器】根據業務攜帶的 uid 信息，劃分數據分區並寫入到數據中心，根據 sliceKey=uid-123 確定 group0 數據分區組，再根據 DocID 在 group 內再次均分數據。

2. 【分片控制器】根據各個數據分區組的容量等情況，劃分數據分片。比如分區組 [0,32) 容量小，只需要 2 個分片服務就能承載所有數據，而分區組 [64,96) 則需要 32 個分片服務承載所有數據。

3. 【尋址控制器】根據業務攜帶的 uid 信息，確定對應的分區組 group，並路由到對應的分片服務組。

4.1.2 實際效果

對於店鋪內檢索場景來說，由數百層的扇出規模，降低爲 32 層扇出，部分情況下可降低爲 2 層扇出。

4.2 本地化計算數據調度策略

針對具有關聯檢索的場景，抽取關聯屬性的特徵（比如用戶和商品的連接關係），業務對具備關聯屬性的數據攜帶相同的標識，使得相關聯的數據內聚化，從而實現計算的本地化。

4.2.1 直播帶貨場景下的關聯計算問題

什麼是關聯計算？對於數據庫領域來說，關聯計算 = Join 操作，對於檢索場景來說，關聯計算 = 檢索到 A 條件情況下，再用 A 的結果檢索 B。檢索場景常因數據量級的問題，需要觸發多次分佈式的檢索，容易造成延遲突增的性能問題。

以直播電商搜索場景爲例，其場景特點如下：

• 業務特徵：主播可以選擇多個商品售賣，商品能被多個主播帶貨，主播量級在十萬級，商品量級在億級別。

• 檢索請求：

• 查詢某個主播所帶貨的商品列表

• …

• 建庫請求：

• 商品的屬性變更

• 主播的信息變更

• …

爲了支持搜索場景下的主播商品關聯需求，一般有如下兩種方案：

• 拆分兩張表：主播信息表和商品信息表

• 主播查詢商品：需要先查詢主播信息表，再查商品信息表。

• 缺點：需要 2 次分佈式檢索，延遲較高。

• 只保留一張表：主播信息和商品信息進行叉乘

• 主播查詢商品：只需要查一張表

• 缺點：成本浪費嚴重，更新困難（熱門商品更新情況下，需要同步更新 10W + 主播，延遲不可接受）

4.2.2 本地化計算優化帶貨場景關聯計算的性能

我們的解決思路是將關聯數據內聚化，實現計算的本地化，從而優化檢索性能，如下圖所示：

1. 建庫側：對於需要關聯的關係數據和商品數據攜帶相同的特徵標識，比如 sliceKey=sid-1，

2. 分區控制器：根據直播帶貨的關聯分區策略，確保關聯數據的數據分區是相同的（內聚化）。

3. 分片控制器：相同分區的數據被規劃到相同的分片服務中（索引計算服務），實現關聯數據的本地化和計算的本地化。

4. 檢索側：攜帶特徵標識 sliceKey=sid=1 定位數據分區，通過尋址控制器找到對應的分片服務。

4.2.3 實際效果

1. 通過本地化計算，解決了直播帶貨場景下因分佈式檢索 Join 帶來的性能下降問題，平均延遲降低 50%。

2. 提供了一種關聯計算速度優化的思路。

五、總結 & 展望

本文以百度搜索中臺上代檢索數據管理架構面臨的問題爲出發點，基於雲原生設計了數據智能化的彈性伸縮和資源的按需分配，解決了效率和成本方面問題。除此之外，在雲原生之上引入了精準扇出和本地化計算的數據調度策略，解決了穩定性和性能方面的問題。

目前業務數據冷熱屬性評估成本較高，並且隨着業務迭代其冷熱屬性也在不斷變化，重新調整需要一定的週期和成本。後續我們會嘗試自動化挖掘業務數據的冷熱特徵和引入更多的目標優化的特徵因素，期望在多目標特徵因素的約束情況下，最大化程度實現搜索場景下資源的按需分配。

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