快速理解HBase和BigTable

有關系行數據庫經驗的人（比如我），在最初接觸HBase這樣的數據庫時，對數據結構的理解容易遇到障礙。會不自覺的將HBase的行、列等概念映射成關系型數據庫的行、列。為了加速理解HBase的一些概念，翻譯了這篇文章《Understanding HBase and BigTable》（HBase官方文檔推薦閱讀文章）。

學習Hbase（Google BigTable的開源實現）最困難的是理解它的實際概念。

很不幸的是，這兩個偉大的系統在其概念中包含了table和base兩個詞，這往往會導致一些人（比如我） 把它們跟關系型數據庫的東西搞混淆。

本文旨在從概念的角度描述這些分布式數據存儲系統。閱讀之后，你應該能夠更好地判斷，什么時候要使用Hbase，什么時候該更好地使用“傳統”數據庫。

一切都在術語中

幸運的是，Google的BigTable論文清楚地解釋了BigTable究竟是什么。這是“數據模型”部分的第一句話： 

注意：請牢記上邊這句話的每一個詞

BigTable論文繼續說明 

Hadoop wiki的HbaseArchitecture頁面假設：

盡管所有這些看起來都相當神秘，但是一旦你將它分解為單詞，它就變得容易明確了。我喜歡按照這個順序討論它們：map，持久化（persistent），分布式（distributed），有序（sorted），多維（multidimensional）和稀疏（sparse）。

我沒有嘗試一下子描繪完整的系統，而是發現在腦海中構建一個零碎的框架更容易理解HBase……

Map

Hbase / BigTable的核心是map，根據您的編程語言背景，您可能更熟悉這些術語，array (PHP), dictionary (Python), Hash (Ruby), or Object (JavaScript).

維基百科文章顯示，Map是“由一組鍵和一組值組成的抽象數據類型，其中每個鍵與一個值相關聯。”

用JSON來描述一個簡單Map的示例，其中所有值都只是字符串： 

持久化

持久化僅僅意味著在創建或訪問數據的程序完成后，您放入此特殊Map的這些數據“會持久保存”。這在概念上與任何其他類型的持久存儲（例如文件系統上的文件）沒有什么不同。

有序

與大多數Map實現不同，在Hbase / BigTable中，鍵/值對按嚴格的字母順序保存。也就是說，鍵“aaaaa”的行應該在具有鍵“aaaab”的行旁邊，并且與具有鍵“zzzzz”的行相距很遠。

繼續我們的JSON示例，有序版本如下所示： 

由于這些系統往往非常龐大且是分布式，因此這種有序的特性非常重要。具有相似鍵的行在空間上的鄰近性確保了當您必須掃描表時，您最感興趣的條目彼此接近。

選擇行鍵的約定很重要。例如，考慮一個表，其鍵是域名。以反向表示法列出它們是最有意義的（所以“com.jimbojw.www”比“www.jimbojw.com”更好），這樣子域的行（存儲上）將靠近父域行。

值得注意的是，在Hbase / BigTable中，術語“有序”并不意味著“值（values）”已排序。除了鍵之外，沒有任何自動索引，就像在普通Map實現中一樣。

多維

到目前為止，我們還沒有提到任何“列（columns）”的概念，將“表（table）”視為概念中的常規哈希/映射（map）。這是有意為之。 “列（column）”這個詞是另一個加載的詞，如“table”和“base”，它傳承了多年關系型數據庫經驗的情感包袱。

相反，我發現（把HBase）看成一個多維Map更容易思考這個問題 - 如果你愿意的話，可以使用嵌套Map。在之前的JSON示例中添加一個維度： 

在上面的例子中，您現在會注意到每個鍵都指向一個有兩個鍵的Map：“A”和“B”。從此處開始，我們將頂層鍵/映射（key/map）稱為“行”。此外，在BigTable / Hbase命名法中，“A”和“B”映射(mappings)將被稱為“列族”。

創建表時會指定表的列族，以后很難或無法修改。添加新列族代價也很大，因此好的做法是從一開始就指定您需要的所有列族。

幸運的是，列族可以具有任意數量的列，由列“限定符(qualifier)”或“標簽(label)”表示。以下是我們的JSON示例的子集，內置了列限定符維度（qualifier dimension）： 

請注意，在顯示的兩行中，“A”列族有兩列：“foo”和“bar”，“B”列族只有一列，其限定符為空字符串（“”）。

在向Hbase / BigTable詢問數據時，必須以“<family>：<qualifier>”的形式提供完整的列名稱。因此，例如，上例中的兩行都有三列：“A：foo”，“A：bar”和“B：”。

請注意，雖然列族是靜態的，但列本身不是。考慮這個擴展的行： 

在這種情況下，“zzzzz”行只有一列，“A：catch_phrase”。由于每行可能包含任意數量的不同列，因此沒有內置方法可以查詢所有行中所有列的數據（list）。要獲取該信息，您必須進行全表掃描。但是，您可以查詢所有列族的數據，因為它們是不可變的（或多或少）。

Hbase / BigTable中最后一個維度是時間。所有數據都使用整數時間戳（seconds since the epoch）或您選擇的另一個整數進行版本控制。客戶端可以在插入數據時指定時間戳。

看一下使用任意整數時間戳的示例： 

每個列族可能有自己的規則，確定保留的給定單元格的版本數量（單元格由其rowkey / column鍵值對標識）在大多數情況下，應用程序將只詢問給定單元格的數據，而不指定時間戳。在這種常見情況下，Hbase / BigTable將返回最新版本（具有最高時間戳的版本），因為它以時間逆序存儲這些版本數據。

如果應用程序指定時間戳，Hbase將返回時間戳小于或等于所提供時間戳的單元數據。

使用我們想象中的Hbase表，查詢“aaaaa”/“A：foo”的行/列（row/column）將返回“y”，同時查詢“aaaaa”/“A：foo”/ 10的 行/列/時間戳 將返回“M”。查詢“aaaaa”/“A：foo”/ 2的 行/列/時間戳 將返回空結果。

稀疏

最后一個關鍵字是稀疏。如前所述，給定行在每個列族中可以包含任意數量的列，或者根本不包含任何列。另一種類型的稀疏性是基于行的間隙（row-based gaps），這僅僅意味著鍵（key）之間可能存在間隙。

如果您已經按照本文的基于映射（map-based）的術語來思考Hbase / BigTable，而不是用關系型數據庫中的相似概念去思考，那么本文的目的就達到了。

就這樣（And that's about it）

好吧，我希望這有助于您從概念上理解Hbase數據模型的含義。

一如既往，我期待著您的想法，意見和建議。