大白話詳解大資料HBase核心知識點,老劉真的很用心(2)

努力的老劉發表於2020-11-28

 前言:老劉目前為明年校招而努力,寫文章主要是想用大白話把自己複習的大資料知識點詳細解釋出來,拒絕資料上的生搬硬套,做到有自己的理解!

01 HBase知識點

第6點:HRegionServer架構

為什麼要了解HRegionServer的架構呢?因為HBase叢集中資料的儲存和HRegionServer有著非常大的關係,只有搞清楚了它的架構,才能理清楚資料儲存的邏輯。

那就讓老劉好好介紹下HRegionServer架構。

StoreFile

在HRegionServer架構圖中,StoreFile是儲存實際資料的物理檔案,StoreFile是以HFile的形式儲存在HDFS上,每個Store會有一個或多個StoreFile,並且資料在每個StoreFile中都是有序的。為什麼是有序的,會在MEMStore中介紹。

對於HFile是什麼,老劉目前只能理解為它是StoreFile存在HDFS上的儲存格式,也就是說StoreFile是以HFile這種形式儲存在HDFS上。

MemStore

它是寫快取的意思。由於HFile是要求資料是有序的,要按照儲存在HDFS上的資料需要按照rowkey排序,所以資料先儲存在MemStore中,排好序後,達到閾值後才會flush到StoreFile中,每次flush生成一個新的StoreFIle。

那MemStore是如何將資料排序的呢?

很多機構的教學資料都沒講,老劉查了很多資料後,老劉只有一個相對較淺的理解,實現MemStore模型的資料結構是SkipList跳錶,跳錶它可以實現高效的查詢、插入、刪除操作。因為跳錶本質上是由有序連結串列構成的,很多KV資料庫都會使用跳錶實現有序資料集合。所以呢,資料傳入MemStore後,會利用跳錶實現這些資料的有序。

WAL

WAL,全稱是Write Ahead Log,預先寫日誌的意思。由於資料要經MemStore排序後才能刷寫到HFile,但把資料儲存在記憶體中會有很高的概率導致資料丟失的,所以為了解決這個問題,資料會先寫在一個叫做Write Ahead Log的檔案中,然後再寫入MemStore中。所以當系統出現故障的時候,資料就可以通過這個日誌檔案重建,避免資料丟失。

BlockCache

它是讀快取的意思。每次查詢出來的資料會先快取在BlockCache中,方便下次查詢資料。


 

第7點:HBase讀資料流程

首先要說的是,在HBase中只有一張meta表(後設資料表),此表只有一個region表,該region資料儲存在一個HRegionServer上。

還記得HBase的第一篇文章說的ZooKeeper的作用嗎,ZooKeeper裡面儲存了HBase的後設資料meta。再想想我們要讀取資料,是不是相當於去學校訪問一個老師,是不是要先在校門口登記,搞清楚這個老師在學校哪個部門、哪個辦公室之類的。

所以呢,HBase讀資料流程如下:

1、HBase讀取資料首先要與zk進行連線,從zk找到meta表的region位置,就是查詢meta表儲存在哪個HRegionServer,得到訊息後,客戶端就會立馬與這個HRegionServer建立連線,然後讀取meta表中的資料,這個meta表中的資訊有:HBase叢集有哪些表、每個表有哪些Region、都儲存在哪些RegionServer上以及儲存了所有使用者表的Region資訊。

2、我們根據要查詢的namespace(名稱空間,相當於關係型資料庫的資料庫名稱)、表名和rowkey資訊。找到寫入資料對應的Region資訊。

3、然後找到這個Region對應的RegionServer,然後傳送請求。

4、現在就可以查詢並定位到對應的Region了。

5、我們會先從MemStore中查詢資料,如果沒有,就會再從BlockCache上讀取,如果BlockCache中也沒有找到,那就會從最後的StoreFile中讀取,從StoreFile中讀取到資料之後,並不是直接把結果資料返回到客戶端,而是把資料先寫入到BlockCache中,目的是為了加快後續的查詢;然後在返回結果給客戶端。


 

第8點:HBase寫資料流程

 

1、客戶端首先會從zk找到meta表的region位置,然後讀到meta表中的資料,meta表中儲存了使用者表的region資訊。

2、根據我們根據要寫入資料的namespace(名稱空間,相當於關係型資料庫的資料庫名稱)、表名和rowkey資訊。找到寫入資料對應的Region資訊。

3、然後找到這個Region對應的RegionServer,然後傳送請求。

4、現在就可以把資料順序寫入(追加)到WAL。

5、將資料寫入對應的MemStore,資料會在MemStore進行排序。

6、達到MemStore的刷寫時機後,將資料刷寫到StoreHFile中。

但是大家好好想想,如果資料不停的寫入,是不是會產生很多很多StoreFile?

在HBase叢集中,針對產生的很多很多StoreFile,它會把它們合併為一個大的StoreFile(這是一個小合併),最終所有的StoreFile會進行一個大合併。但是在資料不斷寫入過程中,Region中的資料會越來越大,此時Region就會進行拆分(一分為二),拆分過程比較耗效能,就有了預分割槽。老劉大致說了下HBase中為什麼會有flush和compact機制、Region拆分合並以及預分割槽,下面就詳細講講這些知識點。

第9點:HBase中的flush、compact機制

Flush機制

資料要刷寫到磁碟,它是有很多刷寫時機的,並不是想刷寫就刷寫的。

第一個是達到Memtore級別的限制,當Region中任意一個MemStore的大小達到了上限,預設是128M,就會觸發MemStore重新整理。這個上限的設定如下:

<property>
  <name>hbase.hregion.memstore.flush.size</name>
  <value>134217728</value>
</property>

第二個是達到Region級別的限制,當Region中所有的MemStore的大小總和達到了上限,預設是2*128M=256M,會觸發MemStore重新整理。這個上限的設定如下:

<property>
  <name>hbase.hregion.memstore.flush.size</name>
  <value>134217728</value>
</property>
<property>
  <name>hbase.hregion.memstore.block.multiplier</name>
  <value>2</value>
</property>

第三個是達到RegionServer級別限制,當一個RegionServer中所有MemStore的大小總和超過低水位閾值,RegionServer開始強制Flush;先Flush MemStore最大的Region,再執行次大的,依次執行;

如果寫入速度大於flush寫出的速度,最後導致總MemStore大小超過高水位閾值(預設為JVM記憶體的40%),此時RegionServer會阻塞更新並強制執行flush,直到總MemStore大小低於低水位閾值。這些閾值的設定如下:

<property>
  <name>hbase.regionserver.global.memstore.size.lower.limit</name>
  <value>0.95</value>
</property>
<property>
  <name>hbase.regionserver.global.memstore.size</name>
  <value>0.4</value>
</property>

第四個是當WAL檔案的數量超過hbase.regionserver.max.logs,region會按照時間順序依次進行刷寫,直到WAL檔案數量減小到hbase.regionserver.max.log以下(該屬性名已經廢棄,現無需手動設定,最大值為32)。

第五個是定期重新整理MemStore,預設週期為1小時,確保MemStroe不會長時間沒有持久化。為避免所有的MemStore在同一時間都進行flush導致的問題,定期的flush操作會有20000左右的隨機延時。

Compact合併機制

為什麼有Compact合併機制?

hbase為了防止小檔案過多,以保證查詢效率,hbase需要在必要的時候將這些小的store file合併成相對較大的store file,這個過程就稱之為compaction。

在hbase中主要存在兩種型別的compaction合併:

minor compaction 小合併

 它會將Store中多個HFile合併為一個HFile。在這個過程中它會選取一些小的、相鄰的StoreFile將他們合併成一個更大的StoreFile。

對於超過了TTL(生存時間)的資料、更新的資料、刪除的資料僅僅只是做了標記。並沒有進行物理刪除,進行一次Minor Compaction的結果是產生數量上更少並且記憶體上更大的StoreFile。這種合併的觸發頻率很高。

minor compaction觸發條件由以下幾個引數共同決定:

<!--表示至少需要三個滿足條件的store file時,minor compaction才會啟動-->
<property>
  <name>hbase.hstore.compactionThreshold</name>
  <value>3</value>
</property>

<!--表示一次minor compaction中最多選取10個store file-->
<property>
  <name>hbase.hstore.compaction.max</name>
  <value>10</value>
</property>

<!--預設值為128m,
表示檔案大小小於該值的store file 一定會加入到minor compaction的store file中
-->
<property>
  <name>hbase.hstore.compaction.min.size</name>
  <value>134217728</value>
</property>

<!--預設值為LONG.MAX_VALUE,
表示檔案大小大於該值的store file 一定會被minor compaction排除-->
<property>
  <name>hbase.hstore.compaction.max.size</name>
  <value>9223372036854775807</value>
</property>

major compaction 大合併

 將所有的StoreFile合併成一個StoreFile,在這個過程中還會清理三類無意義資料:被刪除的資料、TTL過期資料、版本號超過設定版本號的資料。它的合併頻率比較低,預設7天執行一次,並且效能的消耗是非常大的,一般建議生產關閉,在應用空閒時間手動觸發。一般可以是手動控制進行合併,這樣可以防止出現在業務高峰期。

major compaction觸發時間條件(7天)

<!--預設值為7天進行一次大合併,-->
<property>
  <name>hbase.hregion.majorcompaction</name>
  <value>604800000</value>
</property>

手動觸發

#使用major_compact命令
major_compact tableName

 

第10點:Region拆分

region中儲存的是大量的rowkey資料,當region中的資料條數過多的時候,直接影響查詢效率。當region過大的時候。hbase會拆分region,這也是Hbase的一個優點。

HBase的region split策略一共有以下幾種,先說說3種。

1、ConstantSizeRegionSplitPolicy

它是0.94版本前預設切分策略。

當region的大小大於某個閾值(hbase.hregion.max.filesize=10G)之後就會觸發切分,一個region會等分為2個region。但是這種切分策略卻有相當大的弊端:切分策略對於大表和小表沒有明顯的區分。閾值設定較大對大表比較友好,但是小表就有可能不會觸發分裂,極端情況下可能就1個,這對業務來說並不是什麼好事。如果設定較小則對小表友好,但一個大表就會在整個叢集產生大量的region,這對於叢集的管理、資源使用、failover來說都不是一件好事。

2、IncreasingToUpperBoundRegionSplitPolicy

它是0.94版本~2.0版本預設切分策略。

切分策略稍微有點複雜,總體看和ConstantSizeRegionSplitPolicy思路相同,一個region大小大於設定閾值就會觸發切分。但是這個閾值並不像ConstantSizeRegionSplitPolicy是一個固定的值,而是會在一定條件下不斷調整,調整規則和region所屬表在當前regionserver上的region個數有關係。

3、SteppingSplitPolicy

它是2.0版本預設切分策略

這種切分策略的切分閾值又發生了變化,就是一般剛設計出來都會存在一些不合理的地方,隨著慢慢的發展,設計師們逐漸完善。

相比之前的IncreasingToUpperBoundRegionSplitPolicy,它會簡單一些,依然和待分裂region所屬表在當前regionserver上的region個數有關係,如果region個數等於1,切分閾值為flush size * 2,否則為MaxRegionFileSize。這種切分策略對於大叢集中的大表、小表會比 IncreasingToUpperBoundRegionSplitPolicy 更加友好,小表不會再產生大量的小region,而是適可而止。

還有幾個不講了,老劉快記不住了。


 

第11點:Region合併

什麼時候需要Region合併?

比如有一張表在拆分後,一分為二,但是在使用過程中,對這兩個表進行了資料的刪除,資料量變小了,為了方便管理之類的,可以把他們合併。

又比如刪除了大量的資料 ,這個時候每個Region都變得很小 ,儲存多個Region就浪費了 ,這個時候可以把Region合併起來,進而可以減少一些Region伺服器節點 。

總之,Region合併不是為了效能,而是為了方便維護管理。


第12點:HBase表的預分割槽

當一個table表剛被建立的時候,HBase會預設的分配一個region給這個table。這就相當於說,在這個時候,所有的讀寫請求都會訪問到同一個regionServer的同一個region中,這個時候就達不到負載均衡的效果了,因為叢集中的其他regionServer就可能會處於比較空閒的狀態。出現了一人幹活,其他人看戲的現象。

解決這個問題可以用預分割槽,在建立table表的時候就配置好,生成多個region。

預分割槽原理

每一個region都維護著startRow與endRowKey,如果加入的資料符合某個region維護的rowKey範圍,就會把該資料交給這個region維護。如何手動指定預分割槽

方式一:

create 'person','info1','info2',SPLITS => ['1000','2000','3000','4000']

就會有如下這種效果:

方式二:

把分割槽規則建立於檔案中

cd /kkb/install

vim split.txt

在裡面新增這樣的內容:

aaa
bbb
ccc
ddd

在執行這樣的命令:

create 'student','info',SPLITS_FILE => '/kkb/install/split.txt'

就會得到這樣的效果:

 02 總結

好啦,大資料HBase的第二部分知識點就總結的差不多了,內容比較多,大家需要仔細理解,爭取做到用自己的話把這些知識點講述出來。

最後,如果覺得有哪裡寫的不好或者有錯誤的地方,可以聯絡公眾號:努力的老劉,進行交流哦!希望能夠對大資料開發感興趣的同學有幫助,希望能夠得到同學們的指導。

 

相關文章