Hypertable是一個開源、高性能、可伸縮的數(shù)據(jù)庫，采用與Google的BigTable相似的模型。BigTable讓用戶可以通過一些主鍵來組織海量數(shù)據(jù)，并實(shí)現(xiàn)高效的查詢。Hypertable和HBase分別是BigTable的兩個開源實(shí)現(xiàn)：HBase主要使用Java語言開發(fā)，而Hypertable使用Boost C++，另外在一些細(xì)節(jié)的設(shè)計(jì)理念上也有所不同。

Hypertable系統(tǒng)主要包括Hyperspace、Master和Range Server三大組件（如圖1所示）。Hyperspace是一個鎖服務(wù)，地位相當(dāng)于Google的Chubby，主要用于同步、檢測節(jié)點(diǎn)是否發(fā)生故障和存放頂層位置信息；Master主要用于完成任務(wù)分配，未來會有負(fù)載均衡以及災(zāi)后重建（Range Server失效后自動恢復(fù)服務(wù)）等其他作用；Range Server是Hypertable的實(shí)際工作者，主要負(fù)責(zé)對一個Range中的數(shù)據(jù)提供服務(wù)，此外它還肩負(fù)起災(zāi)后重建的責(zé)任，即重放本地日志恢復(fù)自身故障前狀態(tài)；另外，還有訪問Hypertable的客戶端Client等組件。

圖1 Hypertable原有架構(gòu)示意圖

業(yè)務(wù)應(yīng)用

Facebook在SIGMOD 2011會議上介紹了基于Hadoop/HBase的三種應(yīng)用系統(tǒng)：Titan（Facebook Messages）、Puma（Facebook Insights）和ODS（Facebook Internal Metrics）。Titan主要用于用戶數(shù)據(jù)存儲，Puma用于MapReduce分布式計(jì)算，ODS用于存儲公司內(nèi)部監(jiān)控?cái)?shù)據(jù)，Facebook基于HBase的應(yīng)用方式與國內(nèi)幾大互聯(lián)網(wǎng)公司類似。

和ODS類似，對于一些硬件或軟件的運(yùn)行數(shù)據(jù)，我們會保存監(jiān)控?cái)?shù)據(jù)到數(shù)據(jù)庫中，供軟件工程師或者運(yùn)維工程師查詢。這里的查詢可能是大批量的，也可能是個別條目；可能是延遲查詢，也可能是即時查詢。將此類業(yè)務(wù)的需求總結(jié)如下。

•  要求存儲容量非常大，往往達(dá)到10～100TB，10億～100億條記錄。
• 需要支持自動擴(kuò)容，因?yàn)閿?shù)據(jù)的增長模式不易估計(jì)，可能出現(xiàn)短時間的爆炸性增長。
• 寫吞吐的壓力較大，每秒超過1萬次的插入。
•  近期導(dǎo)入數(shù)據(jù)能夠快速檢索。
• 需要支持掃描早期的大量數(shù)據(jù)，例如支持周期性的檢查或回滾。

這里可選的一個方案是使用傳統(tǒng)的DBMS（如MySQL）。但它存在如下弊端：首先MySQL單機(jī)存儲有上限，一般超過1.5GB性能就會有波動；不過即使MySQL支持拆表，也并非完全分布式的，由于表的大小限制，對于不規(guī)則的數(shù)據(jù)增長模式，分布式MySQL也并不能很好地應(yīng)對，如果抖動頻率較大，需要引入較多的人工操作來進(jìn)行數(shù)據(jù)遷移；再者MySQL也不支持表的Schema動態(tài)改變。另一個可選方式是使用Hadoop。不過MapReduce并非實(shí)時計(jì)算，并且HDFS不支持隨機(jī)寫，隨機(jī)讀性能也很差。

綜上分析，我們選擇BigTable類型的系統(tǒng)來支持業(yè)務(wù)需求，即使用Hypertable+Hadoop的方式（如圖2所示）。

圖2 監(jiān)控?cái)?shù)據(jù)收集與查詢示意圖

高可用改進(jìn)

元數(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ù)就高達(dá)16TB，一臺機(jī)器是存不下的，因此在類BigTable系統(tǒng)中，元數(shù)據(jù)也是分布在不同節(jié)點(diǎn)上進(jìn)行管理的，集群中任意一個節(jié)點(diǎn)既可能包含用戶Range也可能包含元數(shù)據(jù)Range。

雖然這種做法可以解決規(guī)模問題，但在管理上帶來了一些困難，特別是進(jìn)行故障恢復(fù)時，由于用戶表的Range恢復(fù)過程中需要讀取元數(shù)據(jù)，所以必須先恢復(fù)METADATA表中的Range，再恢復(fù)用戶表中的Range。如果有多臺Range Server同時故障，這種跨節(jié)點(diǎn)的依賴性處理起來非常困難，其他一些維護(hù)性操作同樣具有類似問題。此外，由于一條METADATA實(shí)際上覆蓋了一個200MB的Range，所以任何一臺包含METADATA的Range Server發(fā)生故障，都可能導(dǎo)致這部分METADATA所涵蓋的一大批數(shù)據(jù)不可訪問。將METADATA分布到多個不同的Range Server上，無異于給系統(tǒng)增加了很多單點(diǎn)，降低了系統(tǒng)可靠性。

解決：本著簡單原則，我們認(rèn)為將元數(shù)據(jù)與用戶數(shù)據(jù)分離，放在專用的Meta Range Server上更具有可操作性。元數(shù)據(jù)集中化的唯一缺點(diǎn)是，由于受Meta Range Server內(nèi)存限制，32GB物理內(nèi)存所能存放的元數(shù)據(jù)理論上只能支持上PB的用戶數(shù)據(jù)。但考慮一般機(jī)房所能容納的機(jī)器規(guī)模，PB級的數(shù)據(jù)規(guī)模完全可以滿足大多數(shù)公司的需要。