面對百億資料，HBase為什麼查詢速度依然非常快？

HBase適合儲存PB級別的海量資料（百億千億量級條記錄），如果根據記錄主鍵Rowkey來查詢，能在幾十到百毫秒內返回資料。

那麼HBase是如何做到的呢？

接下來，簡單闡述一下資料的查詢思路和過程。

查詢過程

第1步：

專案有100億業務資料，儲存在一個HBase叢集上（由多個伺服器資料節點構成），每個資料節點上有若干個Region（區域），每個Region實際上就是HBase中一批資料的集合（一段連續範圍rowkey的資料）。

我們現在開始根據主鍵RowKey來查詢對應的記錄，通過meta表可以幫我們迅速定位到該記錄所在的資料節點，以及資料節點中的Region，目前我們有100億條記錄，佔空間10TB。所有記錄被切分成5000個Region，那麼現在，每個Region就是2G。

由於記錄在1個Region中，所以現在我們只要查詢這2G的記錄檔案，就能找到對應記錄。

第2步：

由於HBase儲存資料是按照列族儲存的。比如一條記錄有400個欄位，前100個欄位是人員資訊相關，這是一個列簇（列的集合）；中間100個欄位是公司資訊相關，是一個列簇。另外100個欄位是人員交易資訊相關，也是一個列簇；最後還有100個欄位是其他資訊，也是一個列簇

這四個列簇是分開儲存的，這時，假設2G的Region檔案中，分為4個列族，那麼每個列族就是500M。

到這裡，我們只需要遍歷這500M的列簇就可以找到對應的記錄。

第3步：

如果要查詢的記錄在其中1個列族上，1個列族在HDFS中會包含1個或者多個HFile。

如果一個HFile一般的大小為100M，那麼該列族包含5個HFile在磁碟上或記憶體中。

由於HBase的記憶體進而磁碟中的資料是排好序的，要查詢的記錄有可能在最前面，也有可能在最後面，按平均來算，我們只需遍歷2.5個HFile共250M，即可找到對應的記錄。

第4步：

每個HFile中，是以鍵值對(key/value)方式儲存，只要遍歷檔案中的key位置即可，並判斷符合條件可以了。

一般key是有限的長度，假設key/value比是1:24，最終只需要10M的資料量，就可獲取的對應的記錄。

如果資料在機械磁碟上，按其訪問速度100M/S，只需0.1秒即可查到。

如果是SSD的話，0.01秒即可查到。

當然，掃描HFile時還可以通過布隆過濾器快速定位到對應的HFile，以及HBase是有記憶體快取機制的，如果資料在記憶體中，效率會更高。

總結

正因為以上大致的查詢思路，保證了HBase即使隨著資料量的劇增，也不會導致查詢效能的下降。

同時，HBase是一個面向列儲存的資料庫（列簇機制），當表字段非常多時，可以把其中一些欄位獨立出來放在一部分機器上，而另外一些欄位放到另一部分機器上，分散儲存，分雜湊查詢。

正由於這樣複雜的儲存結構和分散式的儲存方式，保證了HBase海量資料下的查詢效率。