快速理解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”比“”更好），這樣子域的行（儲存上）將靠近父域行。

值得注意的是，在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資料模型的含義。

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