Bigtable：結構化數據的分佈式存儲系統（四）

譯自Bigtable_A Distributed Storage System for Structured Data 做者：Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C.Hsieh, Deborah A. Wallach Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E.Gruber

8 實際應用

截至2006年8月，Google內部共有388個非測試用Bigtable集羣運行在各種服務器集羣上，合計約爲24500個Tablet服務器。表1爲每一個集羣上Tablet服務器的大體分佈狀況。不少集羣是用於開發環境的，所以會有一段時期比較空閒。觀察一個由14個集羣、8069個Tablet服務器組成的集羣組能夠發現，集羣每秒的吞吐量超過了1200000次請求，發送到系統的RPC請求致使的網絡負載達到741MB/s，系統發出的RPC請求網絡負載約爲16GB/s。

表1：Bigtable集羣中Tablet服務器的數量分佈

表2爲一些目前正在使用的表的相關數據。有些表存儲的是用戶數據，有些存儲的則是用於批處理的數據；表的總大小、每一個數據項的平均大小、從內存中讀取的數據的比例、表的Schema的複雜程度上都有很大的差異。本節主要介紹Bigtable在三個產品研發團隊的應用狀況。

表2：生產環境中部分表的特徵。表大小（壓縮前）及數據項數量爲大約數值。未壓縮的表格無壓縮比。

8.1 Google Analytics

Google Analytics用於幫助Web站點管理員分析其網站的流量特色，涉及總體情況的統計數據（如天天獨立訪問的用戶數量、天天每一個URL的瀏覽次數）及用戶使用網站的行爲報告（好比根據用戶以前訪問的某些頁面，統計出幾成的用戶購買了商品）。

Web站點的管理員只須要在Web頁面中嵌入一小段JavaScript腳本就可使用Bigtable服務了。Javascript程序在頁面被訪問的時候調用，記錄了Google Analytics須要使用的各類信息，好比用戶標識、獲取的網頁相關信息。Google Analytics把彙總的這些數據提供給Web站點管理員。

咱們簡要介紹一下Google Analytics使用的兩類表。RawClick表（大約有200TB數據）的每一行存放了一個終端用戶的會話。行的名字是一個元組，包含Web站點名稱及用戶會話建立時間。這種模式保證了對同一個Web站點的訪問會話是連續的，並按時間順序分類。RawClick表能夠壓縮到原來大小的14%。

Summary表（大約有20TB的數據）包含了關於每一個Web站點的各類預約義彙總信息。MapReduce按期任務根據RawClick表的數據生成 Summary表。每一個MapReduce進程都從RawClick表中提取最新的會話數據。系統的總體吞吐量取決於GFS的吞吐量。Summary表可以壓縮到原來大小的29%。

8.2 Google Earth

Google經過一組服務爲用戶提供高分辨率的地球表面衛星圖像。用戶能夠經過基於Web的GoogleMaps訪問接口（maps.google.com）或定製的客戶端軟件訪問Google Earth。用戶能夠經過GoogleEarth瀏覽地球表面的圖像，並在不一樣的分辨率下平移、查看和註釋這些衛星圖像。這個系統使用一個表存儲預處理數據，使用另一組表存儲用戶數據。

數據預處理環節使用一個表存儲原始圖像。在預處理過程當中，圖像被清除，圖像數據合併到最終的服務數據中。這個表包含了大約70TB的數據，因此須要從磁盤讀取數據。圖像已經被高效壓縮過了，所以存儲在Bigtable後不須要再壓縮了。

Imagery表中每行表明一個地理區域。行都有名稱，確保毗鄰的區域存儲在一塊兒。Imagery表中有一個列族用來記錄每一個區域的數據源。這個列族包含了大量的列：基本上每一個列對應一個原始圖片的數據。因爲每一個地理區域都是由幾張圖片構成的，所以這個列族很是稀疏。

數據預處理高度依賴MapReduce的數據傳輸。在運行某些MapReduce任務的時候，整個系統中每臺Tablet服務器的數據處理速度大於1MB/s。

服務系統使用表來索引GFS中的數據。這個表相對較小（大約是500GB），但必須在保證較短的響應延時的前提下，每秒爲每一個數據中心處理幾萬個查詢請求。所以，這個表存儲在上百個Tablet服務器上，而且保護內存列族。

8.3 Personalized Search

PersonalizedSearch（www.google.com/psearch）是可選服務，記錄用戶的查詢和點擊，涉及Google的各類服務，好比Web查詢、圖像和新聞。用戶能夠瀏覽他們查詢的歷史，重複他們以前的查詢和點擊操做；也能夠定製基於Google歷史使用習慣模式的個性化查詢結果。

PersonalizedSearch使用Bigtable存儲每一個用戶的數據。每一個用戶都有一個惟一的用戶id，每一個用戶id與一個列名綁定。不一樣類型的行爲存儲在單獨的列族中（好比，有的列族用來存儲全部的Web查詢）。每一個數據項都被用做Bigtable的時間戳，記錄了相應的用戶行爲發生的時間。PersonalizedSearch經過MapReduce任務生成用戶數據圖表，用於個性化當前的查詢結果。

Personalized Search的數據會複製到幾個Bigtable集羣上，這樣就加強了數據可用性，同時減小了由客戶端與Bigtable集羣之間的「距離」形成的延時。PersonalizedSearch的開發團隊最初創建了一個基於Bigtable的「客戶側」複製機制，確保全部複製節點的一致性。當前系統則使用了內建的複製子系統。

PersonalizedSearch存儲系統容許其它團隊在本身的列中加入新的用戶數據，所以不少Google服務使用PersonalizedSearch存儲系統保存用戶級的配置參數和設置，這樣便產生了大量的列族。爲了更好地支持數據共享，咱們增長了簡單的配額機制，限制用戶在共享表中使用的空間，同時也爲使用PersonalizedSearch系統存儲用戶級信息的產品團體提供了隔離機制。

9 經驗教訓

在設計、實現、維護和支持Bigtable的過程當中，咱們積累了不少有用的經驗教訓。

好比，咱們發現，不少類型的錯誤都會致使大型分佈式系統受損，這些錯誤不只僅是常見的網絡中斷或不少分佈式協議中設想的fail-stop類型的錯誤。咱們遇到的錯誤類型包括內存數據損壞、網絡中斷、時鐘誤差、機器掛起、擴展的非對稱網絡分區、其它系統的Bug（好比Chubby）、GFS配額溢出、計劃內和計劃外的硬件維護。基於經驗積累，咱們學會了經過修改協議來解決這些問題。咱們在RPC機制中使用了校驗和。設計系統功能時，不對其它功能作任何假設。例如，咱們再也不假設一個特定的Chubby操做只返回錯誤碼集合中的一個值。

另外，要在全面瞭解一個新功能的潛在用途後，再決定是否開發這一功能。好比，根據最初的計劃，咱們的API支持常見事務處理。但考慮到暫時還用不到這個功能，所以沒有去實現。如今，Bigtable上已經有了不少實際應用。通過觀察，咱們發現大多數應用程序只須要單個行上的事務功能。有些應用須要分佈式事務功能，用於維護二級索引，咱們經過特殊機制來知足這一需求。新機制的通用性雖然比分佈式事務差不少，但更有效（特別是對於涉及上百行數據的更新操做時），並且很是符合跨數據中心複製方案的優化策略。

咱們還發現，系統級的監控對Bigtable很是重要（好比，監控Bigtable自身及使用Bigtable的客戶端程序）。咱們擴展了RPC系統，所以一個RPC調用的例子能夠詳細記錄表明RPC調用的不少重要操做。經過這個功能，咱們能夠檢測修正不少問題，好比Tablet數據結構上的鎖的內容；在修改操做提交時對GFS的寫入很是慢的問題；以及在METADATA表的Tablet不可用時，對METADATA表的訪問掛起的問題。每一個Bigtable集羣都在Chubby中註冊了，經過監控，咱們能夠了解集羣的狀態、大小、集羣運行的軟件版本、集羣流入數據的流量以及是否有致使集羣高延時的潛在因素。

最寶貴的經驗是簡單設計的價值。考慮到系統現有的代碼量（約100000行生產代碼）、將來新增代碼以各類計劃外狀況，咱們認爲簡潔的設計和編碼可以極大地便利維護和調試工做。以Tablet服務器成員協議爲例。咱們初版的協議很簡單：Master服務器按期與Tablet服務器簽定租約，租約過時時Tablet服務器Kill掉本身的進程。不過出現網絡問題時，協議的可用性會大大下降，Master服務器恢復時間也會延長。爲此，咱們們屢次從新設計了該協議。不過最終的協議過於複雜，且依賴了其餘應用不多用到的Chubby功能。但調試Bigtable代碼和Chubby代碼的過程當中浪費了大量時間。最後，咱們只好廢棄了這個協議，從新制訂了一個只使用Chubby經常使用功能的簡單協議。

10 相關工做

Boxwood項目的有些組件在某些方面與Chubby、GFS及Bigtable相似，也支持分佈式協議、鎖、分佈式Chunk存儲以及分佈式B-tree存儲。但Boxwood的組件提供更底層的服務，目的在於提供建立相似文件系統、數據庫等高級服務的基礎構件，而Bigtable則直接支持客戶端程序的數據存儲。

如今很多項目已經實現了在廣域網上的分佈式數據存儲或者高級服務，一般是 「Internet規模」的，例如CAN、Chord、Tapestry和Pastry項目關於分佈式Hash表的研究。這些系統應對的問題主要包括不一樣的傳輸帶寬、不可信的協做者及頻繁的更改配置等。另外，Bigtable也不關注去中心化和Byzantine災難冗餘。

就提供給應用程序開發者的分佈式數據存儲模型而言，分佈式B-Tree和分佈式Hash表提供的Key-value對模型有很大的侷限性。Key-value對模型很是有用，但咱們還應該爲開發者提供更多組件。咱們的模型提供的組件支持稀疏的半結構化數據。另外，這些組件也很是簡單，可以高效地處理平面文件；且足夠透明（經過位置組），容許用戶調整系統的重要行爲。

有些數據庫廠商已經開發出了並行數據庫系統，可以存儲海量數據。Oracle的RAC使用共享磁盤存儲數據（Bigtable使用 GFS），並配有分佈式鎖管理系統（Bigtable 使用 Chubby）。IBMDB2並行版基於相似於Bigtable但不共享任何信息的架構。每一個DB2的服務器負責處理存儲在關係型數據庫中的表中某個行的子集。這些產品都提供了具備事務功能的完整關係模型。

Bigtable的位置組提供了基於列的存儲方案，實現了出色的壓縮和磁盤讀取性能。相似產品包括C-Store、商業產品SybaseIQ、SenSage、KDB+及MonetDB/X100的ColumnDM存儲層。AT&T的Daytona數據庫在平面文件中提供垂直和水平數據分區，且數據壓縮性能良好。位置組不支持Ailamaki系統在CPU緩存級別的優化功能。

Bigtable經過memtable和SSTable存儲對錶的更新，這一點與Log-StructuredMerge Tree存儲索引數據更新的方法相似。在兩個系統中，排序數據在寫入磁盤前都先存放在內存中，讀取操做必須從內存和磁盤中合併數據。

C-Store和Bigtable比較類似：二者都採用Shared-nothing架構；都有兩種不一樣的數據結構，一種用於當前的寫操做，另一種存放「長時間使用」的數據；而且提供兩個存儲結構間的數據搬運機制。但兩個系統在API接口函數方面差別很大：C-Store的操做更像關係型數據庫；而Bigtable則提供了低層次的讀寫操做接口，且設計目標是可以支持每臺服務器每秒數千次操做。C-Store同時也是「讀性能優化的關係型數據庫」，而Bigtable對於讀寫密集型應用都具有良好的性能。

Bigtable也須要解決全部的Shared-nothing數據庫所面對的負載和內存均衡方面的問題。咱們的問題在某種程度上簡單一些：（1）咱們不須要考慮同一份數據可能有多個拷貝的問題，即同一份數據可能因爲視圖或索引的緣由以不一樣的形式呈現出來；（2）咱們讓用戶決定哪些數據應該放在內存裏、哪些放在磁盤上；（3）咱們的系統中沒有複雜的查詢執行或優化工做。

11 結論

Bigtable集羣從2005年4月開始已經投入使用。截至目前，咱們用了約7人年來設計和實現這個系統。截至2006年4月，已經有60多個項目在使用Bigtable。咱們的用戶對Bigtable提供的高性能和高可用性表示滿意。用戶能夠根據自身系統對資源的需求，通增長機器，擴展系統的承載能力。

因爲Bigtable提供的編程接口並不常見，用戶適應新的接口有必定難度。新用戶開始確實不熟悉Bigtable接口的使用方法，但最終都能熟練掌握。事實證實，咱們的設計在實踐中行之有效。

咱們如今正在設計新功能，好比支持二級索引、支持多Master節點的跨數據中心複製的Bigtable的基礎構件。咱們如今已經開始將Bigtable部署爲服務，供其它產品團隊使用。這樣產品團隊就再也不須要維護本身的Bigtable集羣。隨着服務集羣的擴展，咱們須要在Bigtable系統內部處理更多關於資源共享的問題。

最後，咱們發現，開發Google本身的存儲解決方案具備不少優勢。爲Bigtable設計本身的數據模型後，咱們的系統變得更加靈活。另外，因爲咱們決定着Bigtable的實現過程及其使用的Google的其餘基礎構件，所以在系統遇到瓶頸或效率低下時，可以快速解決這些問題。

參考資料

1. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C.Hsieh, Deborah A. Wallach Mike Burrows, Tushar Chandra, Andrew Fikes and Robert E.Gruber. Bigtable_A Distributed Storage System for Structured Data
2. Yan Wei. Google Bigtable中文版