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

2022-10-02 11:48:15 字數 1452 閱讀 6190

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資料查詢快速

快速查詢可以分作兩方面 一是根據億級的記錄中快速查詢,二是以實時的方式查詢資料。a 如果快速查詢 從磁碟讀資料 hbase是根據rowkey查詢的,只要能快速的定位rowkey,就能實現快速的查詢,主要是以下因素 1 hbase是可劃分成多個region,你可以簡單的理解為關係型資料庫的多個分割槽。...

hbase為什麼不會腦裂

前幾天在思考乙個問題,如果發生了網路隔離,一台region server與其他節點失去連線,但是客戶端是快取了region server位址的,那麼客戶端仍然會向這台region server傳送寫請求.那麼hbase豈不是會發生gluster那樣的腦裂麼?後來又看了下文件,hbase的wal也是寫...

為什麼Hbase能實現快速的查詢

你的快速是指什麼?是根據億級的記錄中快速查詢,還是說以實時的方式查詢資料。a 如果快速查詢 從磁碟讀資料 hbase是根據rowkey查詢的,只要能快速的定位rowkey,就能實現快速的查詢,主要是以下因素 1 hbase是可劃分成多個region,你可以簡單的理解為關係型資料庫的多個分割槽。2 鍵...