信息技術發展日新月異,網絡數據呈現爆炸之勢,搜索引擎的實時性面臨巨大挑戰。百度搜索引擎天天處理着數萬億次的連接分析和數百億次的互聯網資源採集。做爲百度搜索引擎的核心數據庫 Tera,是如何支撐萬億量級的實時數據處理呢?數據庫
在 5 月 20 日百度開發者中心主辦、極客邦科技承辦的 71 期百度技術沙龍上,百度網頁搜索基礎架構技術經理齊志宏和資深工程師鄭然,爲你們免費放送了大型分佈式表格系統 Tera 在百度搜索引擎中的應用、以及 Tera 架構設計與實踐的全攻略。緩存
Tera 在百度搜索引擎中的應用性能優化
在講解 Tera 的應用以前,百度網頁搜索基礎架構技術經理齊志宏首先介紹了百度搜索架構,百度搜索引擎的做用是鏈接人與信息、鏈接人與服務,信息抓取、索引構建、檢索系統構成了搜索引擎最經典的三大板塊。服務器
互聯網上的信息是如何經過搜索引擎最終展現給用戶的?首先,網頁被搜索引擎發現,經過抓取進入搜索引擎;而後,有價值的網頁通過篩選,進行正排計算和倒排計算,完成索引構建;最後,經過檢索系統將最終的結果呈現給用戶。網絡
伴隨互聯網信息爆發式的增加,百度搜索架構也在逐漸向實時化方向演進,在介紹完搜索架構以後,齊志宏從連接存儲、索引篩選、用戶行爲分析三個場景切入,詳細講解了 Tera 在實時搜索架構中的應用。架構
齊志宏先爲你們解釋什麼是 Tera:一種大型分佈式表格存儲系統,具備高性能、可伸縮等存儲特色,最初的設計是爲了管理萬億量級的超鏈和網頁信息。Tera 在架構演進中到底扮演了怎樣的核心角色呢?負載均衡
首先來看存儲連接。百度推出的 Spider 3.0 系統是基於 Tera 的實時架構,以 Tera 爲核心,承載了連接庫、網頁庫的存儲,將原有基於 MapReduce 的批量計算轉變爲基於 Tera 的實時計算,實現每秒億級的數據隨機讀寫、天天處理萬億量級的連接操做,信息抓取模塊(即 Spider)進入了實時處理時代。異步
第二個是索引篩選。索引篩選的核心做用是讓有價值的信息進入索引。Tera 架構做爲數據存儲中心,存儲了包含網頁庫、去重庫、結果庫在內的全部中間數據和最終結果,經過流式計算的方式完成頁面特徵拼接、頁面價值計算、網頁去重以及索引排序等核心操做的實時化改造。網頁從抓取到篩選完成的整個過程,實現了從天級變到分鐘級甚至秒級的飛躍。分佈式
最後一個是用戶行爲分析。用戶行爲分析在搜索效果改進和搜索引擎的評價等方面,都具備重要價值。基於 Tera 的實時用戶行爲數據流,將用戶數據的時效性推向新高度。實時數據產出的延遲可降至秒級,突發時效性識別、用戶意圖分析、產品迭代評估等多個維度都可實時獲取用戶數據,進行實時分析,對時效性和用戶體驗有很大的提高。ide
整體上,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% 左右的讀性能。