面對百億數據，HBase為什么查詢速度依然非常快？

• • 查詢過程
  • • • • 第1步：
        • 第2步：
        • 第3步：
        • 第4步：
      • 總結

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海量數據下的查詢效率。

總結

以上是生活随笔為你收集整理的面对百亿数据，HBase为什么查询速度依然非常快？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。