面對百億資料，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海量資料下的查詢效率。