HBase與Bigtable的關鍵區別點

本文首發于"NoSQL漫談(nosqlnotes.com)"：眾所周知，HBase最初的實現完全參考了Bigtable的論文。前面幾篇文章已經詳細探討了Bigtable的架構設計與最新進展信息，這篇文章重點討論HBase與Bigtable的一些關鍵區別點。

基礎架構

Bigtable與HBase在技術棧上的組成是類似的：

GFS/Colossus對應HDFS

Chubby對應ZooKeeper

Bigtable與GFS/Colossus中的管理節點是否支持備節點，在相關材料中并沒有提及，這里猜測這應該是需要具備的一個基礎能力。

Column Family

Column Family是一些列的集合，在這層概念上，兩者是類似的。但有如下明顯的區別：

物理存儲Bigtable的Column Family更像是一個邏輯概念，多個Column Families可以組成一個Locality Group。同一個Locality Group中的多個Column Families數據可以被存儲在同一個SSTable文件中。

HBase中的不同的Column Family的數據是隔離在不同的存儲路徑中的。

支持的數量Bigtable的Column Family相對更加輕量級，因此數量通常可以配置為幾十個級別。

HBase的Column Family數量通常不建議過多，通常小于5個。

可配置性Bigtable中允許配置的參數非常少，相對而言，HBase中提供的配置參數更加多樣化。

WAL

單節點提供寫服務的WAL數量

Bigtable: 一個Tablet Server在任意時間點只支持一個正在提供寫服務的WAL，

HBase: 1.0+版本中，HBase已經支持Multi-WAL特性，即同一個RegionServer(對應Tablet Server)在任意時間點可同時支持多個提供寫服務的WAL，可更充分的利用磁盤IO能力。

寫內存與寫WAL的順序

WAL的全稱Write-Ahead-Log，顧名思義，數據在寫入到Memtable/MemStore之前，應該要首先寫入到WAL中保證數據的可靠性。Bigtable與早期的HBase版本的確也都是這么做的。但后來，HBase調整了兩者的順序，數據先寫入到MemStore中，而后再寫WAL，如果WAL寫不成功，則回滾MemStore中的數據。這樣是為了更快釋放行鎖，加快性能。

性能／時延優化

Bigtable中支持Group Commit能力，同時利用Two-Writing Threads來優化訪問時延，有效緩和因GFS的讀寫IO帶來的時延毛刺問題。

HBase中基于Disruptor提供高并發下的Group Commit能力，減少Sync請求次數；支持WAL異步Sync能力。

Access Control

Bigtable的最小權限控制單元為Column Family。

HBase不僅支持Column Family級別，也可支持到Cell-Level。

Flush&Compaction

在功能上，兩者無明顯差別，只是在概念名稱上有所不同。

Bigtable中的Minor Compaction過程，在HBase中稱之為Flush。Bigtable經Minor Compaction之后生成的文件為SSTable，HBase中經Flush之后生成的文件為HFile。

Bigtable中的Merge Compaction過程，對應于HBase中的Minor Compaction。

Bigtable中的Major Compaction在HBase中也稱之為Major Compaction。

關于Compaction算法，Bigtable論文中并沒有過多透露。HBase目前能夠支持多種Compaction算法，且支持插件化定制。

子表路由

Bigtable中的Tablet，在HBase中稱之為Region，為了能夠統一一下名稱，這里統計將其稱之為子表。

Bigtable的子表路由是有三層組成的：

HBase的早期版本中，也是與Bigtable類似的三層路由結構。但從HBase 0.98版本開始，移除了Root表，直接將META表的路由信息存儲在了ZooKeeper中。另外，在當前HBase版本中，META子表依然是不可分裂的。

讀寫時延

文章中，講到了Bigtable在讀寫時延方面所做的一些改進。

從Cloud Table官方提供的平均時延與P99讀寫時延方面來看，這一點比起HBase的確有一些優勢。

底層存儲文件

Bigtable的底層文件存儲格式為SSTable，這是Google內部多項目共享的文件存儲格式，先于Bigtable而出現。關于SSTable的組成結構，可以從LevelDB的File Format定義中找到：

[data block 1]

[data block 2]

...

[data block N]

[meta block 1]

...

[meta block K]

[metaindex block]

[index block]

[Footer]? (fixed size; starts at file_size - sizeof(Footer))

HBase的底層文件存儲格式為HFile，是HBase的自定義格式，目前已經演進到第三代。HBase的第一代文件格式HFile的定義與上面的SSTable的結構是類似的：

在支持該格式的時候，HBase的Region數據量不建議超過GB級別（可以推斷，Bigtable的一個Tablet的大小也應該不超過該級別），尤其是帶有Bloom Filter數據時，HBase RegionServer服務啟動時非常慢，因為需要加載所有的元數據信息，內存占用也非常多。因此，HBase演進出了第二代HFile格式：

將元數據部分也分成了多層，啟動時僅加載第一層的元數據信息，其它的元數據按需加載。這樣不僅能夠啟動速度，更能有效降低內存占用大小。關于HFile的結構，這里不做過多的展開。

高級特性

上篇文章中也提到，在Bigtable官方公布的材料中，并未見到明顯的大特性。對比而言，HBase在近些年新增了很多新特性，這里僅做簡單的羅列：

Snapshot 表支持數據快照

Namespace 表命名空間

Replication 跨集群異步容災特性

Region Replica 一個Region能夠有多個副本，當主副本不可用時，備副本可提供弱一致性讀取模式，提高讀請求的高可用性

In-memory Flush & Compaction 可有效降低因頻繁Flush與Compaction帶來的IO讀寫放大

…….

這些特性在后面的文章中將會展開詳細介紹。

References

LevelDB file format

Change the HFile format

Bigtable: A Distributed Storage System for Structured Data

回顧Bigtable的經典設計

Bigtable在近些年的演進

本文首發于：NoSQL漫談(nosqlnotes.com)? 永久鏈接：HBase與Bigtable的關鍵區別點

hbase

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。