By雲深作者：Adam/Schubert/SeymourZ 2008年8月
轉載請註明出處
1 Introduction
隨着互聯網技術的發展，尤其是雲計算平臺的出現，分佈式應用程序需要處理大量的數據(PB級)。在一個或多個雲計算平臺中(成千上萬的計算主機)，如何保證數據的有效存儲和組織，爲應用提供高效和可靠的訪問接口，並且保持良好的伸縮性和可擴展性，成爲雲計算平臺需要解決的關鍵問題之一。分佈式並行文件系統，爲雲計算平臺解決了海量數據存儲問題，並且提供了統一的文件系統命令空間，如GFS、Hadoop HDFS、KFS等，在此基礎上， Hypertable實現了分佈式結構化的數據組織，Hypertable可以對海量的結構化的數據(PB級)提供面向表形式的組織方式,並嚮應用提供類似表訪問的接口(如SQL接口)。
2 Structured Data and Tablet Location
2.1 數據模型（Data Model）
Hypertable採用類似表的形式組織數據，但目前Hypertable並不支持關係數據庫中豐富的關係屬性。Hypertable將數據組織成一個多維稀疏矩陣。該矩陣中的所有行信息可以基於主鍵（Primary Key）進行排序。在該多維矩陣中第一維稱爲行（Row），行鍵值（Row Key）即爲Primary Key；第二維即列族（Column Family），一個列族包含多個列（Column Qualifier）的集合，它們一般具有相同的類型屬性，系統在存儲和訪問表時，都是以Column Family爲單元組織；第三維即列（Column Qualifier），理論上，一個列族中列的個數不受限制，列的命名方式通常採用family:qualifier的方式；最後一維就是時間戳（Timetstamp），它通常是系統在插入一項數據時自動賦予。如果我們把行和列族看成三維矩陣的行和列，那麼我們可以將“時間戳”看成是縱向深度座標。如圖2-1所示，Tn就是每項值（Value）的“深度”標籤。
Figure 2-1 A Multi-Dimensional Table
2.1.1 行鍵（Row Key）
Hypertable中Row Key定義爲任意的字符序列（長度不超過64Kbyte，通常的應用也就百個字節左右），所有行以Row key爲主鍵進行字典排序。在Hypertable中隊行的操作保持原子性，對行的插入（Insert）、更新（Update）、刪除（Delete）等都保持整行的原子操作，無論行操作涉及到的列的個數。在Hypertable中保持行操作的原子性，對應用程序來說顯然具有積極的意義，它使得Hypertable對應用程序來說，行的一致性得到保證。
在Hypertable中，所有的行數據按照Row Key的字典序排列，如圖2-1，隨着數據量的不斷增長（不斷的有新的數據插入），該多維數據表會不斷增長，在一個並行的雲計算平臺中，當該表增長到一定大小時，系統會將該表一分爲二，分別由平臺中不同的主機維護，分裂後的表可以獨立增長，再進行分裂，由此反覆，最終一個多維的Hypertable表實際上是以大量的“小表（Tablet）”的形式存在於雲計算平臺中，它們具有完全對等的屬性，分別維護表中的部分數據；一個小表（Tablet）由一臺主機維護，一臺主機可以維護多個小表。在Hypertable中，表的分裂沿行區間（Row Range）切分，如圖2-2所示，一張表在生長過程中，在一定的行區間被分裂爲多個行區間（Row Range），每一個行區間成文一個新的小表（Tablet）。在Hypertable中缺省是一個Tablet增長到200M左右分裂，同時由於系統在並行處理平臺上運行，會根據負載均衡原則進行調解。在雲計算平臺中，分裂出來的Tablet基於Load Balance原則被分佈在不同的主機上維護，從而，對錶的操作演化成對各小表（Tablet）的操作，處理效率顯然高於對整個大表的操作。用戶在使用Hypertable時合理的選擇Row Key，可以得到更好的數據處理效率。例如在處理大量網頁數據時（網頁crawler獲取的網頁數據），通常把網頁URL作爲Row Key，其中URL的主機域名被反序處理（如maps.google.com/index.html被反置爲com.google.maps/index.html），如此具有相同域的網頁被儘可能的組織在相同或相鄰的Tablet中，因此應用程序在處理這些數據時能得到更好的效率。
2.1.2 列族與列（Column Family & Column Qualifier）
Hypertable表的列鍵（Column Key）被分組爲不同的列族（Column Family），列族（Column Family）是Hypertable系統中數據存儲和訪問控制的基本單元。在一個Column Family中的所有列通常具有相同的類型。在表的生長過程中，新的Column可以被動態創建，在創建Column前，相應的Column Family必須存在。Hypertable系統中，一個表的Column Family個數不大於256，而且一旦Column Family被創建，很少會被修改。
在Hypertable中，Column的個數基本上沒有限制。一個Column Key的命名採用 Column Family:Qualifier形式，其中Column Family是可顯示字符串，代表該Column所屬的Column Family，而Qualifier可以是任意的字符串。如圖2-1所示，該表至少包括兩個Column Family，其中一個Column Family只有一個Qualifier：“contents”,用於存儲網頁的內容；另一個Column Family是“anchor”，用於表示該網頁被其它網頁引用的情況。對於表中的每一行，該Column Family包含有不定數目的列，也即qualifier的個數不定，因此該表在邏輯上會形成一個稀疏矩陣。圖中，www.cnn.com 主頁被www.cnnsi.com 和 www.my.look.ca 分別用“CNN”和“CNN.com”命名的鏈接引用。
在Hypertable中，數據的存儲以Access Group爲單位組織，一個Access Group可以包括一個或多個Column Family。因此數據存儲組織的最小單位是Column Family. 在定義Hypertable表的機構時可以定義Access Group包含的Column Family。
2.1.3 時間戳（Timestamp）
如圖2-1，在Hypertable的表中，任意的格子（cell）都可以保存不同版本數據，用時間戳進行（timestamp）排序，從而形成表的時間維度。在Hypertable系統中，時間戳是由64-bit整數表示，他們值可以有系統自動賦予，也可以在由客戶端應用程序指定。Timestamp在表中以降序排列，最新版本的數據會被最先讀取。客戶端在操作數據時，必須保證數據在時間序的邏輯性。如，當前數據的Timestamp爲T0，新的操作時間戳被指定（客戶端或系統指定）T1，則必須保證T1>T0，操作才能被系統接受。
Hypertable在維護數據版本時，不能無限制的維護版本個數，系統提供了兩種手段維護有限個數的數據版本（Timestamp），一種是系統設置最多能維護的版本個數，當數據版本超出最大版本數時，系統的數據維護模塊會清理版本相對較老的數據；另一種手段是系統動態設置最老版本的時間點，當該參數被更改後，系統數據維護模塊會將舊改時間點的數據版本刪除。
2.1.4 表的扁平化（Flattening）
在Hypertable中，四維（Row Key、Column Family、Column Qualifier、Timestamp）表最終被扁平化處理成（Key、Value）對的形式存儲，其中Key的表示形式爲Row Key，Column Family（處理時使用系統編號），Column Qualifier和Timestamp組成的字符串。Value爲相應的值。如圖2-3所示一個row range的扁平化方式。Row Key保持字典升序排列，Column保持schema定義的順序，Timetamp保持降序排列。
2.2 表的尋址和存儲
Hypertable主要解決的是數據的組織和存儲策略問題，數據的物理存儲由分佈式並行文件系統完成。分佈式並行文件系統作爲雲計算平臺的基礎組件，爲Hypertable提供統一的文件系統命名空間（namespace）。
在Hypertable中，數據在存儲前經過了排序和壓縮，表中的數據類型都被串行化爲字符數據。一張表，在它的生長過程中，會分裂爲許多小表（tablet）,新產生的tablet可以被指定到雲計算平臺中的任意物理主機維護。在Hypertable系統中維護着一個全局Tablet索引表Metadata Table，Metadata Table本身是一張Hypertable表，它負責保存和維護系統中所有小表（Tablet）的索引。
2.2.1 Tablet索引
在Hypertable中，採用三級層次建立tablet的索引。如前所述，表是按row range分裂爲許多的tablet，所有在tablet的集合組成完整的Table。系統中爲了維護每張表的tablet位置信息（tablet分佈在雲計算平臺的主機中），會創建一個特殊的表：Metadata table。Metadata表具備一般用戶表的屬性，也有它的特殊性，根據不同索引級別，分爲兩類tablet：metadata0 tablet和metadata1 tablet，其中：
Metadata 0的位置信息稱爲一級索引，通常是一個位置指針存放在系統中，系統初始化時，讀取該指針獲得metadata0的位置信息；
Metadata 0 tablet作爲二級索引，它是一個不會分裂的tablet，運行時，系統在內存中維護它，同時該tablet被定義爲metadata表的第一個tablet，在初始化時被創建。Metadata 0中保存Metadata 1 tablets的位置信息；
第三級索引爲metadata 1 tablets，這一級的metadata1 tablets具備和用戶tablet相同的屬性，系統初始化時，會創建第一個metdata1 tablet。Metadata tablet中保存用戶表的tablets位置信息。
Figure 2-4 Tablet location hierarchy
Metadata schema的XML文件描述形式爲：
<Schema>
<AccessGroup name="default">
<ColumnFamily>
<Name>LogDir</Name>
</ColumnFamily>
<ColumnFamily>
<Name>Files</Name>
</ColumnFamily>
</AccessGroup>
<AccessGroup name="location" inMemory="true">
<ColumnFamily>
<Name>StartRow</Name>
</ColumnFamily>
<ColumnFamily>
<Name>Location</Name>
</ColumnFamily>
</AccessGroup>
<AccessGroup name="logging">
<ColumnFamily>
<Name>Event</Name>
</ColumnFamily>
</AccessGroup>
</Schema>
表2-1列出了Metadata的表結構。其中最底下彩色區域就是一行metadata的各項值區域。其中：
l Row key：是table_id:end_row_key表示，table id是表在創建時，系統賦予的唯一表標識號，0號碼保留給metadata table用。end_row_key是一個任意字符串，表示該記錄指向的tablet的最後一行的row key。
l Access group：metadata table包括三個access group，分別是：default、Location、Logging。
l Column Family：metadata table包含五個column families，分別是：LogDir、Files、Start row、Location、Event。其中Start row記錄該行指向的tablet的第一行的row key；Location記錄的是該tablet是由雲計算平臺中哪一臺主機維護，以ip:port方式記錄。
l “Files” Column Family：該column family下可能包含多個qualifier項，每一項qualifier指示該記錄對應tablet（表號爲table_id）的一個access group所保存的文件名列表，一個table的access group的個數在table schema中定義，文件名之間用分號隔開。
Table 1: Hypertable metadata table structure
在Hypertable中，metadata表的一條記錄大小約爲1K，如果定一個tablet的大小爲128M，那麼這樣一個三級索引的架構，可以索引的最大Hypertable容量（壓縮後）爲：(128M/1K)* (128M/1K)*128M，約爲2^61bytes。
2.2.2 Tablet存儲
Hypertable爲用戶規劃表數據存儲提供了一定靈活度，從hypertable的扁平化過程可以看出，它採用面向列的存儲模式。Hypertable採用access group方式組織數據存儲（在表schema中定義），一個access group包含一個或多個column family。對於一個row range，屬於一個access group的所有數據被組織在一起存儲，access group是hypertable面向存儲的最小訪問單位。這樣，對於有應用相關性的列，被組織存儲在一起，可以有效地提高數據的讀寫效率。
一個Tablet包含一個表中特定row range的數據，它由系統中一臺主機（range server）維護，系統中一臺主機可以維護多個表的多個tablet。Tablet在存儲前都被扁平化處理，以（key，value）對的形式存儲在文件中，實際存儲中，（key，value）對中加入了該數據的操作類型，如插入、更新、刪除等。Tablet以文件形式存儲。如圖2-5所示，爲一個典型的tablet存儲目錄結構。
Figure 2-5 An example of table directory in range server
在主機在維護tablet時，會在文件系統的table目錄下創建對應的表目錄，目錄用表名命名。如上圖所示，該主機維護了Pages，Accounts兩個表的tablet。在每個table目錄下會根據表的schema創建相應的access group目錄，如Pages有三個access group，Accounts有兩個access group。在access group目錄下，系統會爲每一個tablet創建一個目錄，由系統生成的隨機數（row range 系統編號）字符串命名。當前狀態下，該主機維護了Pages表的兩個tablets。由此可見，一個完整的row range（tablet）數據是指該表目錄下，所有access group目錄中，在相同row range目錄下的文件集合。
如圖2-5所示，表是以cs（CellStore）文件形式存儲。CellStore文件存儲Access Group中的（Key，Value）列表（帶操作類型），文件中的數據經過排序，壓縮，並且不會被修改。在CellStore文件內部包含多個64K（可配置）大小的塊，爲了便於索引CellStore中的數據，在CellStore文件的結尾處保存了這些塊的索引數據，以便系統能迅速定位到數據在文件中的哪個64K塊中。Cell store的索引主要有三個部分：
l Bloom Filter：該索引部分採用Bloom Filter技術，用於64k塊內索引，目前保留，未實現；
l 塊索引：該索引部分記錄每64k塊的索引，用於快速定位塊，它的格式爲 row key + 塊在文件內的偏移；
l Trailer：用於定位Bloom Filter塊，塊索引部分的定位。系統讀取這部分，獲取Bloom Filter和塊索引的位置。
隨着數據的增長，在一個row range（tablet）中，一個access group可以動態產生多個CellStore文件，這些文件由Range Server動態維護，參照Range Server描述。
2.3 一個示例
如圖2-6所示的邏輯模型，示例crawldb table用於存儲從internet抓取的網頁信息，其中：Row Key爲網頁的URL，出於排序效率考慮，URL中主機域名字符順序往往被反置，如www.facebook.com被處理爲com.facebook.www；Column Family包括title、content、anchor，其中tile保存網頁的標題，content保存網頁html內容，anchor保存網頁被其它網頁引用的鏈接，qualifier就是其它網頁的URL，內容爲其它網頁中該鏈接的頁面顯示字符，同樣anchor鏈接的URL主機域字符串被反置。對於不同時間獲取的同一網頁的有關內容被打上不同的時間戳，如圖縱向座標可以看到不同的版本。
Figure 2-6 Crawldb Table Logical Model
在實際的存儲中，圖2-6所示的多維邏輯結構會被二維平面化爲(Key, Value)對，並且進行排序。在（Key，Value）中，Key由四維鍵值組成，包括：Row Key, Column Family（處理時使用８比特編碼）, Column Qualifier和Timestamp，如圖2-7所示，爲Key的實際結構，在對Key進行排序過程中，有最新Timestamp的Key會被排在最前面，flag項用於標明系統需要對該（Key，Value）記錄進行的操作符，如增加、刪除、更新等。
如圖2-8是crawldb二維平面化後經過排序的格式。圖中Key列中的信息由Row Key(頁面的URL)、Column Family、Column Qualifer和Timestamp組成，其中並未顯示Key flag項，flag項主要用於表項處理。
Figure 2-8 Sorted Key/Value list
圖2-9顯示了crawldb table的CellStore文件格式。CellStore文件中存儲了經過排序後的Key，Value對，物理上，這些數據都被壓縮後存儲，以大約64k大小的塊爲單位組織；在文件結尾處，保留有三個索引部分：Bloom Filter、塊索引（row key + 塊在文件內的偏移）、Trailer。
3 Architecture
Hypertable的實現主要包括以下5個部分：
l 應用API Library
l Hyperspace Server
l Master Server
l Range Server
l DFS Broker
如圖3-1所示Hypertable系統側的主要架構。整個系統構建在分佈式並行文件系統之上（本地文件系統也支持）。用戶應用程序通過Hypertable提供的API編程接口庫，使用Hypertable（參見第6章）。
3.1 DFS Broker
Hypertable設計運行在分佈式並行文件系統之上，也不侷限於此，還可以運行在本地文件系統之上，尤其是在用戶單機調試和試用的時候。同時，由於分佈式並行文件系統的類型有很多，爲了使Hypertabe的系統模塊能很好在不同的文件系統上運行，Hypertable提供了一個文件系統訪問抽象層：DFS Broker。
DFS Broker的API接口層，爲Hypertable提供了統一的文件系統訪問接口，Hypertable系統進程調用DFS Broker的文件操作API後，DFS Broker API會將相應的文件操作以消息的形式發送給DFS Broker，DFS Broker根據具體的文件系統類型，調用相應的操作接口，完成文件系統的訪問。目前，Hypertable DFS Broker實現了Hadoop DFS, KFS以及本地（Local）文件系統接口，用戶可以根據自己的需要，在現有的DFS Broker框架下，實現其它分佈式文件系統的接口，將Hypertable擴展到更多的DFS之上。
Figure 3-1 Hypertable System Architecture
3.2 Hyperspace
Hyperspace是類似Google Bigtable系統中的Chubby 功能。Chubby在Google Bigtable系統中主要實現兩個功能，一是爲Bigtable提供一個粗粒度鎖服務；其次是提供高效，可靠的主機選舉服務。由於Bigtable的粗粒度鎖服務往往構建在具有統一namespace的文件系統上（早期在Database上），因此它同時具備輕量級的存儲功能，可以存儲一些元數據信息。如圖3-1所示，Hyperspace作爲一個服務器族存在，通常情況下，一個Hyperspace Server族一般由5或11臺服務器組成，他們基於Paxos選舉算法，在服務器中選舉出一個Active Server，其它的服務器作爲Standby Servers存在，在系統運行過程中，Active Server和Standby Servers之間會同步狀態和數據（數據經常由文件系統或數據庫自己完成）。截至本文檔發佈之前，Hyperspace還未發佈Active/Standby功能。從實現的角度來看，實現1+1的備份方式，也可以作爲Hyperspace HA 的一種實現方法，但顯然可靠性要低於Chubby的實現方式。
目前，Hyperspace基於BSD DB構建它的鎖服務，通過BSD DB API，Hyperspace構建一個namespace，該namespace中包含目錄和文件節點，每一個目錄或文件可以賦予許多的屬性，如鎖的屬性。Hyperspace Client是訪問Hyperspace的客戶端模塊。Hypertable中的其它系統模塊通過該Client與Hyperspace Server建立Session鏈接，通過該鏈接完成Hyperspace中目錄和文件的操作（如讀，寫，鎖操作等）。Session鏈接採用租約機制，客戶端必須定期更新租約期限，如果到期未更新，Hyperspace認爲客戶端out of service，隨機釋放客戶端所佔用的文件和鎖資源。Hyperspace Client爲客戶端應用提供了callback方式的事件通知機制，客戶端應用可以通過Session鏈接，向Hyperspace註冊自己關注的對象（目錄或文件）的有關事件，也可以向Session本身註冊時間callback。如文件，或目錄的刪除時間，鎖操作事件，Session的終止事件等。
由於Hyperspace的設計滿足高可靠性要求，因此它除了提供粗粒度鎖服務以外，還承擔着部分的小數據量的存儲任務。如2.2.1中提到的Metadata0 tablet location就存儲在Hyperspace，作爲整個Hypertable tablets索引的根節點。另外，Hyperspace也會存儲Metadata schema，access control list（目前未實現）；同時，由於Hypersapce提供了Hypertable系統中所有主機節點的鎖服務，所有節點會在Hyperspace的namespace中創建自己的主機節點，並獲取相應的鎖，因此Hyperspace同時充當了記錄Hypertable系統中主機狀態的任務，並且根據客戶端註冊的callback信息分發相應的狀態改變事件。
由此可見，Hyperspace作爲一個需要設計成具有高可用性的子系統，如果Hyperspace停止工作，Hypertable也就對外不能提供服務了。
3.3 Range Server
在Hypertable系統中，表按row range分割爲許多tablet，這些tablet由range server維護，一個range server主機可以維護多個tablet。Range server負責處理所有的該row range的讀寫操作。
如圖3-2，range server處理寫數據（如insert、update、delete等數據操作）時，range server將檢查它的格式是否合法以及該操作的訪問權限（目前還未實現access control）；檢查成功後，先將數據（和操作）寫入Commit Log文件，隨後將數據按順序緩存在Cell Cache中，隨着Cell Cache不斷增長，達到Cell Cache的容量門限，range server將新建一個Cell Cache，將舊的Cell Cache寫入DFS cell store文件，此過程也稱作爲Minor Compaction（次級緊置化）。Minor compaction起到主要作用有兩個，一是通過將Cell Cache寫入DFS，回收Cell Cache內存，使得range server不會因爲cell cache的無限增長而消耗完內存資源；其次，由於range server將寫數據首先保存在commit log文件中，以備系統崩潰後，能讀取commit log恢復到崩潰前的數據狀態；因此，在舊的cell cache被寫入cell store文件後，commit log中相應的log就可以被清除，從而有效地回收了commit log文件空間。
Figure 3-2 A Tablet in Tablet Server
隨着數據操作的不斷增加，Cell Store文件也不斷增多，當文件個數達到門限時，range server將執行merging compaction操作，該操作將選擇部分cell store文件與cell cache合併爲一個較大的cell store文件。此時的merging compaction操作中，所有文件和cache的數據被重新排序到新的cell store文件中，並不執行數據的計算合併操作，因此所有的delete數據仍然存在於新的cell store文件中。
有一種特殊的merging compaction操作，發生在tablet分裂前，range server會將該tablet的所有cell store文件和cell cache合併爲一個大的cell store文件，該操作稱爲Major Compaction（當前hypertable並未實現定時major compaction）。Major compaction在合併文件和cache過程中會對計算數據進行合併計算，所產生的新cell store文件不再包含delete操作的數據。Major compaction可以有效地回收存儲空間，其次，由於新產生的cell store文件已經完成數據操作的合併運算，使得數據的讀寫操作性能更高。
如圖3-2所示，數據讀取操作需要訪問多個cell store文件和cell cache，如2.2.2所述，cell store文件中包含有多個索引塊，這些索引塊運行時緩存在內存中，當一個讀取操作來到range server時，range server將檢查它的格式是否合法以及該操作的訪問權限（目前還未實現access control）；檢查成功後，range server將定位該row key可能存在的所有cell store文件，包括cell cache，掃描相關cell store和cell cache，爲該次讀操作在內存執行merging操作，並返回結果。由於所有key，value數據對在cell store和cache中已經按字典序排列，因此掃描和merging操作的效率較高。
Range server在處理讀寫請求時，仍然可以進行其它的處理操作。在進行minor compaction前，由於range server會新建一個cell cache，因此，在進行minor compaction時不會阻塞讀寫請求。其它的如執行tablet split，merging compaction，以及major compaction時，range server會在cell cache中給新來的寫數據置時間標記，以便和正在參與操作的cache數據區別開來。
Tablet的永久存儲模式是DFS上的cell store文件、log文件以及Hyperspace上的schema，tablet的索引在2.2.1所述的metadata table中。如果一個range server停止服務，hypertable系統（通常是Master調度）將選擇另一個的range server（該range server可能已經維護了其它的tablet）去恢復（Recover）該tablet。Range server在恢復tablet過程中，首先從metadata table中讀取該tablet的metadata，該metadata中包含有cell store文件列表（參見2.2.1），以及一組Redo指針（？？），這些指針指向Commit Log中需要Redo的操作記錄。Range server根據這些信息重構一個tablet，包括爲該tablet創建cell cache，緩存所有cell store的索引，執行Redo操作等。
3.4 Master
如圖3-1所示，master主要負責Hypertable 系統中的調度工作，主要包括：
u 處理元數據操作，如表的創建、和刪除；
u 管理range server池，指派range server所維護的range server，並實現range server的load balance調度（目前使用round robin算法，還爲基於服務器負荷調度）；
u 檢測range server加入/離開Hypertable系統；
u 回收DFS的discarded文件
u 處理表schema變化，如創建新的column family操作（目前爲實現）
Master並不直接處理hypertable client提交的數據，由於metadata表數據作爲一個普通的table由系統中的range server維護，而且metadata0的location存儲在hyperspace中；因此在hypertable系統中出現master server的短暫OOS（out of service）是可以容忍的，在master server短暫的OOS期間，hypertable系統不能處理新表的創建，和range server的調度，但並不妨礙hypertable client對已經存在的表的讀寫操作。
3.5 Chubby or HA
如圖3-1所示，hypertable系統中對於range server而言，它的調度主要由master負責，整個系統的業務邏輯已經包含了range server的高可用性（HA）功能。然而hyperspace和master的高可用性並不包含在hypertable的業務邏輯中。當前的hypertable版本（0.9.x.x）中，hyperspace和master都只實現了單點服務器的模式，從圖3-1所示，hypertable將在近期的版本中規劃這兩個子系統的HA實現，其中hyperspace採用類似Chubby的服務器集羣方式，而master採用1+1的active/standby方式。
注：部分圖片來源於 http://www.hypertable.org/