百度萬億量級資料庫Tera架構應用、設計與實踐全攻略

信息技術發展突飛猛進，網路數據呈現爆炸之勢，搜索引擎的實時性面臨巨大挑戰。百度搜索引擎每天處理著數萬億次的鏈接分析和數百億次的互聯網資源採集。作為百度搜索引擎的核心資料庫 Tera，是如何支撐萬億量級的實時數據處理呢？

在 5 月 20 日百度開發者中心主辦、極客邦科技承辦的 71 期百度技術沙龍上，百度網頁搜索基礎架構技術經理齊志宏和資深工程師鄭然，為大家免費放送了大型分布式表格系統 Tera 在百度搜索引擎中的應用、以及 Tera 架構設計與實踐的全攻略。

Tera 在百度搜索引擎中的應用

在講解 Tera 的應用之前，百度網頁搜索基礎架構技術經理齊志宏首先介紹了百度搜索架構，百度搜索引擎的作用是連接人與信息、連接人與服務，信息抓取、索引構建、檢索系統構成了搜索引擎最經典的三大板塊。

互聯網上的信息是如何通過搜索引擎最終展示給用戶的？首先，網頁被搜索引擎發現，通過抓取進入搜索引擎；然後，有價值的網頁經過篩選，進行正排計算和倒排計算，完成索引構建；最後，通過檢索系統將最終的結果呈現給用戶。

伴隨互聯網信息爆髮式的增長，百度搜索架構也在逐漸向實時化方向演進，在介紹完搜索架構之後，齊志宏從鏈接存儲、索引篩選、用戶行為分析三個場景切入，詳細講解了 Tera 在實時搜索架構中的應用。

齊志宏先為大家解釋什麼是 Tera：一種大型分布式表格存儲系統，具有高性能、可伸縮等存儲特點，最初的設計是為了管理萬億量級的超鏈和網頁信息。Tera 在架構演進中到底扮演了怎樣的核心角色呢？

首先來看存儲鏈接。百度推出的 Spider 3.0 系統是基於 Tera 的實時架構，以 Tera 為核心，承載了鏈接庫、網頁庫的存儲，將原有基於 MapReduce 的批量計算轉變為基於 Tera 的實時計算，實現每秒億級的數據隨機讀寫、每天處理萬億量級的鏈接操作，信息抓取模塊（即 Spider）進入了實時處理時代。

第二個是索引篩選。索引篩選的核心作用是讓有價值的信息進入索引。Tera 架構作為數據存儲中心，存儲了包含網頁庫、去重庫、結果庫在內的所有中間數據和最終結果，通過流式計算的方式完成頁面特徵拼接、頁面價值計算、網頁去重以及索引排序等核心操作的實時化改造。網頁從抓取到篩選完成的整個過程，實現了從天級變到分鐘級甚至秒級的飛躍。

最後一個是用戶行為分析。用戶行為分析在搜索效果改進和搜索引擎的評價等方面，都具有重要價值。基於 Tera 的實時用戶行為數據流，將用戶數據的時效性推向新高度。實時數據產出的延遲可降至秒級，突發時效性識別、用戶意圖分析、產品迭代評估等多個維度均可實時獲取用戶數據，進行實時分析，對時效性和用戶體驗有很大的提升。

總體上，Tera 支撐了著搜索引擎大規模的實時數據讀寫，將批量、全量計算轉變為增量、實時的數據計算，極大的提升了搜索引擎的實時數據處理能力，Tera 是百度搜索引擎從批量處理邁向實時計算的架構基礎。

Tera 大型分布式表格系統的設計與實踐

Tera 完成了百度搜索向萬億級數據實時搜索的躍進，成為炙手可熱的資料庫系統，那麼，如何做好 Tera 架構的設計與實踐成為開發者最為關心的問題。百度網頁搜索基礎架構資深工程師鄭然在演講過程中，圍繞背景、數據模型、架構與設計、高可用實踐以及性能優化等方面，詳細講解了 Tera 設計和實踐過程。

鄭然表示，百度搜索引擎面臨三大業務特點：

數據量大，PB 到百 PB 這樣的量級；

離線處理過程中，以站點等前綴方式訪問數據是普遍的需求；

數據類型不固定。

這樣的業務特點決定著 Tera 設計和實踐的過程。

Tera 設計的數據模型

Tera 的數據模型有以下幾個特點，首先它是 Key-Value 模型，再深入一層，它是典型的 BigTable 模型，同時，一個非常重要的特點就是全局有序。這幾個特點結合在一起，就是 Tera 數據模型的設計目標。

Tera 設計的系統架構

Tera 系統主要由 Tabletserver、Master 和 ClientSDK 三部分構成, 數據持久化到底層的分布式文件系統中。其中 Tabletserver 是核心伺服器，承載著所有的數據管理與訪問；Master 是系統的仲裁者，負責表格的創建、Schema 更新與負載均衡；ClientSDK 包含供管理員使用的命令行工具 Teracli 和給用戶使用的 SDK。

表格被按 RowKey 全局排序，並橫向切分成多個 Tablet，每個 Tablet 負責服務 RowKey 的一個區間，表格又被縱向且分為多個 LocalityGroup，一個 Tablet 的多個 LocalityGroup 在物理上單獨存儲，可以選擇不同的存儲介質，用以優化訪問效率。

Tera 的高可用實踐

Tera 的高可用性比較關鍵，直接影響整個系統的服務質量，其實現方式包括兩個方面：Tablet Server 可用性以及負載均衡。

Tablet Server 的可用性：1）Tablet Server 向 ZooKeeper 註冊，利用 ZooKeeper 檢測 Tablet Server 的存活；2）Tablet Server 掛掉之後，Master 收到 ZooKeeper 通知，進行 Tablet 遷移。具體遷移過程，會把掛掉的 Tablet Server 節點遷移到 Kick 節點上，當 Tablet Server 發現自己出現在 Kick 節點下面，自行退出。

負載均衡：負載均衡會直接影響整個集群的可用性，所以負載均衡更本質上來說是實現高可用的技術手段。影響 Tera 負載均衡的因素相對較少，主要在 SSD 容量、隨機讀和隨機寫這三個方面。針對上述影響因素, Tera 從兩個層面來進行負載均衡策略的設計。首先平衡各個 Tablet Server 讀請求 Pending 的數據量, 同時利用歷史值來平滑負載短時間內抖動的影響 ; 其次根據 SSD 容量平衡各個 Tablet 的數據大小。

Tera 設計的性能優化

鄭然表示，Tera 設計的性能優化，是百度在做設計過程中總結出來的，實用性較強。

第一個經驗是需要考慮對分布式文件系統友好。Tera 的數據持久化在分布式文件系統上，必須考慮對其友好的使用。根據 LevelDb 的特點，數據首先要持久化在 WAL 上，確保異常情況下不丟數據，所以寫 WAL 的延遲和吞吐直接決定了用戶寫請求的延遲和吞吐。然而分布式文件系統需要寫多個數據副本，在某些副本異常情況下，如果依賴分布式文件系統層面去自動恢復的話，可能大幅增加延遲。Tera 針對寫 WAL 異常情況，採用關閉舊文件創建新文件的方法，規避分布式文件系統的短板。同時 WAL 持久化成功才能保證用戶數據不丟，所以 WAL 寫完之後必須 sync 強制數據落盤，而 sst 文件不強制要求每次寫請求落盤，從而減少對分布式文件系統的壓力。

第二個經驗是關於 SSD 的運用。SATA 的隨機讀能力很差，雖然 LevelDb 做了很多優化，但是仍然無法突破硬體瓶頸，SSD 的價格現在是越來越便宜，但成本依然比 SATA 高。Tera 的數據全部持久化在 SATA 上，僅把 SSD 作為 Cache 使用，這是平衡性能和成本的一種途徑。

第三個經驗是非同步邏輯設計。Tera 裡面所有可能阻塞的邏輯都是非同步的，非同步邏輯可以很好提高性能，另外客戶端緩存 Tablet 位置信息，因為 tablet 位置信息通常情況下變化的也不頻繁，同時擴展了 LevelDb 的 BloomFilter 機制，可以提升 20% 左右的讀性能。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！