文 / 楊棟
Hypertable是一個開源、高性能、可伸縮的數(shù)據(jù)庫，采用與Google的BigTable相似的模型。BigTable讓用戶可以通過一些主鍵來組織海量數(shù)據(jù)，并實現(xiàn)高效的查詢。Hypertable和HBase分別是BigTable的兩個開源實現(xiàn)：HBase主要使用Java語言開發(fā)，而Hypertable使用Boost C++，另外在一些細節(jié)的設計理念上也有所不同。
Hypertable系統(tǒng)主要包括Hyperspace、Master和Range Server三大組件（如圖1所示）。Hyperspace是一個鎖服務，地位相當于Google的Chubby，主要用于同步、檢測節(jié)點是否發(fā)生故障和存放頂層位置信息；Master主要用于完成任務分配，未來會有負載均衡以及災后重建（Range Server失效后自動恢復服務）等其他作用；Range Server是Hypertable的實際工作者，主要負責對一個Range中的數(shù)據(jù)提供服務，此外它還肩負起災后重建的責任，即重放本地日志恢復自身故障前狀態(tài)；另外，還有訪問Hypertable的客戶端Client等組件。
圖1 Hypertable原有架構(gòu)示意圖
業(yè)務應用
Facebook在SIGMOD 2011會議上介紹了基于Hadoop/HBase的三種應用系統(tǒng)：Titan（Facebook Messages）、Puma（Facebook Insights）和ODS（Facebook Internal Metrics）。Titan主要用于用戶數(shù)據(jù)存儲，Puma用于MapReduce分布式計算，ODS用于存儲公司內(nèi)部監(jiān)控數(shù)據(jù)，Facebook基于HBase的應用方式與國內(nèi)幾大互聯(lián)網(wǎng)公司類似。
和ODS類似，對于一些硬件或軟件的運行數(shù)據(jù)，我們會保存監(jiān)控數(shù)據(jù)到數(shù)據(jù)庫中，供軟件工程師或者運維工程師查詢。這里的查詢可能是大批量的，也可能是個別條目；可能是延遲查詢，也可能是即時查詢。將此類業(yè)務的需求總結(jié)如下。
- 要求存儲容量非常大，往往達到10～100TB，10億～100億條記錄。
- 需要支持自動擴容，因為數(shù)據(jù)的增長模式不易估計，可能出現(xiàn)短時間的爆炸性增長。
- 寫吞吐的壓力較大，每秒超過1萬次的插入。
- 近期導入數(shù)據(jù)能夠快速檢索。
- 需要支持掃描早期的大量數(shù)據(jù)，例如支持周期性的檢查或回滾。
這里可選的一個方案是使用傳統(tǒng)的DBMS（如MySQL）。但它存在如下弊端：首先MySQL單機存儲有上限，一般超過1.5GB性能就會有波動；不過即使MySQL支持拆表，也并非完全分布式的，由于表的大小限制，對于不規(guī)則的數(shù)據(jù)增長模式，分布式MySQL也并不能很好地應對，如果抖動頻率較大，需要引入較多的人工操作來進行數(shù)據(jù)遷移；再者MySQL也不支持表的Schema動態(tài)改變。另一個可選方式是使用Hadoop。不過MapReduce并非實時計算，并且HDFS不支持隨機寫，隨機讀性能也很差。
綜上分析，我們選擇BigTable類型的系統(tǒng)來支持業(yè)務需求，即使用Hypertable+Hadoop的方式（如圖2所示）。
圖2 監(jiān)控數(shù)據(jù)收集與查詢示意圖
高可用改進
元數(shù)據(jù)集中化
挑戰(zhàn)：在Hypertable或其他類似BigTable的系統(tǒng)中，元數(shù)據(jù)一般采用一種兩級的類B+樹結(jié)構(gòu)，這主要是出于規(guī)模的考慮：采用這種結(jié)構(gòu)理論上可以支持存放并索引2EB的用戶數(shù)據(jù)。若要索引這么多用戶數(shù)據(jù)，所需的元數(shù)據(jù)就高達16TB，一臺機器是存不下的，因此在類BigTable系統(tǒng)中，元數(shù)據(jù)也是分布在不同節(jié)點上進行管理的，集群中任意一個節(jié)點既可能包含用戶Range也可能包含元數(shù)據(jù)Range。
雖然這種做法可以解決規(guī)模問題，但在管理上帶來了一些困難，特別是進行故障恢復時，由于用戶表的Range恢復過程中需要讀取元數(shù)據(jù)，所以必須先恢復METADATA表中的Range，再恢復用戶表中的Range。如果有多臺Range Server同時故障，這種跨節(jié)點的依賴性處理起來非常困難，其他一些維護性操作同樣具有類似問題。此外，由于一條METADATA實際上覆蓋了一個200MB的Range，所以任何一臺包含METADATA的Range Server發(fā)生故障，都可能導致這部分METADATA所涵蓋的一大批數(shù)據(jù)不可訪問。將METADATA分布到多個不同的Range Server上，無異于給系統(tǒng)增加了很多單點，降低了系統(tǒng)可靠性。
解決：本著簡單原則，我們認為將元數(shù)據(jù)與用戶數(shù)據(jù)分離，放在專用的Meta Range Server上更具有可操作性。元數(shù)據(jù)集中化的唯一缺點是，由于受Meta Range Server內(nèi)存限制，32GB物理內(nèi)存所能存放的元數(shù)據(jù)理論上只能支持上PB的用戶數(shù)據(jù)。但考慮一般機房所能容納的機器規(guī)模，PB級的數(shù)據(jù)規(guī)模完全可以滿足大多數(shù)公司的需要。
圖3 Hypertable高可用改進架構(gòu)示意圖
圖3給出了Hypertable元數(shù)據(jù)集中管理的整體結(jié)構(gòu)。目前的實現(xiàn)將Hypertable中的數(shù)據(jù)服務器（Range Server）分為兩種：Meta Range Server和User Range Server。Meta Range Server只管理Root表和METADATA表的Range，User Range Server只管理用戶表的Range。由于Master的負載較輕，因此一般將Meta Range Server與Master放在同一個節(jié)點上。
系統(tǒng)啟動時，每個Range Server從配置文件得知自己的類型，并在注冊時匯報自己的類型。Master記錄每臺Range Server的信息。當Master需要將Range分配給Range Server時（例如表格創(chuàng)建和Range分裂），會根據(jù)Range所在表格的類型來選擇合適的Range Server，元數(shù)據(jù)Range分配到Meta Range Server，用戶Range則分配到User Range Server。