Apache HBase MTTR 優(yōu)化實(shí)踐

HBase MTTR 優(yōu)化實(shí)踐

HBase介紹

HBase是Hadoop Database的簡(jiǎn)稱，是建立在Hadoop文件系統(tǒng)之上的分布式面向列的數(shù)據(jù)庫(kù)，它具有高可靠、高性能、面向列和可伸縮的特性，提供快速隨機(jī)訪問(wèn)海量數(shù)據(jù)能力。

HBase采用Master/Slave架構(gòu)，由HMaster節(jié)點(diǎn)、RegionServer節(jié)點(diǎn)、ZooKeeper集群組成，底層數(shù)據(jù)存儲(chǔ)在HDFS上。

整體架構(gòu)如圖所示：

HMaster主要負(fù)責(zé)：

在HA模式下，包含主用Master和備用Master。

主用Master：負(fù)責(zé)HBase中RegionServer的管理，包括表的增刪改查；RegionServer的負(fù)載均衡，Region分布調(diào)整；Region分裂以及分裂后的Region分配；RegionServer失效后的Region遷移等。

備用Master：當(dāng)主用Master故障時(shí)，備用Master將取代主用Master對(duì)外提供服務(wù)。故障恢復(fù)后，原主用Master降為備用。

RegionServer主要負(fù)責(zé)：

存放和管理本地HRegion。

RegionServer負(fù)責(zé)提供表數(shù)據(jù)讀寫等服務(wù)，是HBase的數(shù)據(jù)處理和計(jì)算單元，直接與Client交互。

RegionServer一般與HDFS集群的DataNode部署在一起，實(shí)現(xiàn)數(shù)據(jù)的存儲(chǔ)功能。讀寫HDFS，管理Table中的數(shù)據(jù)。

ZooKeeper集群主要負(fù)責(zé)：

存放整個(gè) HBase集群的元數(shù)據(jù)以及集群的狀態(tài)信息。

實(shí)現(xiàn)HMaster主從節(jié)點(diǎn)的Failover。

HDFS集群主要負(fù)責(zé)：

HDFS為HBase提供高可靠的文件存儲(chǔ)服務(wù)，HBase的數(shù)據(jù)全部存儲(chǔ)在HDFS中。

結(jié)構(gòu)說(shuō)明：

Store

一個(gè)Region由一個(gè)或多個(gè)Store組成，每個(gè)Store對(duì)應(yīng)圖中的一個(gè)Column Family。

MemStore

一個(gè)Store包含一個(gè)MemStore，MemStore緩存客戶端向Region插入的數(shù)據(jù)，當(dāng)RegionServer中的MemStore大小達(dá)到配置的容量上限時(shí)，RegionServer會(huì)將MemStore中的數(shù)據(jù)“flush”到HDFS中。

StoreFile

MemStore的數(shù)據(jù)flush到HDFS后成為StoreFile，隨著數(shù)據(jù)的插入，一個(gè)Store會(huì)產(chǎn)生多個(gè)StoreFile，當(dāng)StoreFile的個(gè)數(shù)達(dá)到配置的閾值時(shí)，RegionServer會(huì)將多個(gè)StoreFile合并為一個(gè)大的StoreFile。

HFile

HFile定義了StoreFile在文件系統(tǒng)中的存儲(chǔ)格式，它是當(dāng)前HBase系統(tǒng)中StoreFile的具體實(shí)現(xiàn)。

HLog（WAL）

HLog日志保證了當(dāng)RegionServer故障的情況下用戶寫入的數(shù)據(jù)不丟失，RegionServer的多個(gè)Region共享一個(gè)相同的HLog。

HBase提供兩種API來(lái)寫入數(shù)據(jù)。

Put：數(shù)據(jù)直接發(fā)送給RegionServer。

BulkLoad：直接將HFile加載到表存儲(chǔ)路徑。

HBase為了保證數(shù)據(jù)可靠性，使用WAL（Write Ahead Log）來(lái)保證數(shù)據(jù)可靠性。它是HDFS上的一個(gè)文件，記錄HBase中數(shù)據(jù)的所有更改。所有的寫操作都會(huì)先保證將數(shù)據(jù)寫入這個(gè)文件后，才會(huì)真正更新MemStore，最后寫入HFile中。如果寫WAL文件失敗，則操作會(huì)失敗。在正常情況下，不需要讀取WAL文件，因?yàn)閿?shù)據(jù)會(huì)從MemStore中持久化為HFile文件。但是如果RegionServer在持久化MemStore之前崩潰或者不可用，系統(tǒng)仍然可以從WAL文件中讀取數(shù)據(jù)，回放所有操作，從而保證數(shù)據(jù)不丟失。

寫入流程如圖所示：

默認(rèn)情況下RegionServer上管理的所有HRegion共享同一個(gè)WAL文件。WAL文件中每個(gè)記錄都包括相關(guān)Region的信息。當(dāng)打開(kāi)Region時(shí)，需要回放WAL文件中屬于該Region的記錄信息。因此，WAL文件中的記錄信息必須按Region進(jìn)行分組，以便可以回放特定Region的記錄。按Region分組WAL的過(guò)程稱為WAL Split。

WAL Split由HMaster在集群?jiǎn)?dòng)時(shí)完成或者在RegionServer關(guān)閉時(shí)由ServershutdownHandler完成。在給定的Region再次可用之前，需要恢復(fù)和回放所有的WAL文件。因此在數(shù)據(jù)恢復(fù)之前，對(duì)應(yīng)的Region無(wú)法對(duì)外服務(wù)。

HBase啟動(dòng)時(shí)，Region分配簡(jiǎn)要分配流程如下：

HMaster啟動(dòng)時(shí)初始化AssignmentManager。

AssignmentManager通過(guò)hbase:meta表查看當(dāng)前Region分配信息。

如果Region分配依然有效（Region所在RegionServer依然在線），則保留分配信息。

如果Region分配無(wú)效，調(diào)用LoadBalancer來(lái)進(jìn)行重分配。

分配完成后更新hbase:meta表。

本文主要關(guān)注集群重新啟動(dòng)和恢復(fù)相關(guān)內(nèi)容，著重描述相關(guān)優(yōu)化，減少HBase恢復(fù)時(shí)長(zhǎng)。

RegionServer故障恢復(fù)流程

當(dāng)HMaster檢測(cè)到故障時(shí)，會(huì)觸發(fā)SCP（Server Crash Procedure）流程。SCP流程包括以下主要步驟：

HMaster創(chuàng)建WAL Split任務(wù)，用于對(duì)屬于崩潰RegionServer上Region進(jìn)行記錄分組。

將原屬于崩潰RegionServer上Region進(jìn)行重分配，分配給正常RegionServer。

正常RegionServer執(zhí)行Region上線操作，對(duì)需要恢復(fù)數(shù)據(jù)進(jìn)行回放。

故障恢復(fù)常見(jiàn)問(wèn)題

HMaster等待Namespace表超時(shí)終止

當(dāng)集群進(jìn)行重啟時(shí)，HMaster進(jìn)行初始化會(huì)找到所有的異常RegionServer（Dead RegionServer）并開(kāi)始SCP流程，并繼續(xù)初始化Namespace表。

如果SCP列表中存在大量的RegionServer，那么Namespace表的分配將可能被延遲并超過(guò)配置的超時(shí)時(shí)間（默認(rèn)5分鐘），而這種情況在大集群場(chǎng)景下是最常見(jiàn)的。為臨時(shí)解決該問(wèn)題，常常將默認(rèn)值改大，但是必不能保證一定會(huì)成功。

另外一種方式是在HMaster上啟用表來(lái)避免此問(wèn)題（hbase.balancer.tablesOnMaster=hbase:namespace)，HMaster會(huì)優(yōu)先將這些表進(jìn)行分配。但是如果配置了其它表也可以分配到HMaster或者由于HMaster性能問(wèn)題，這將無(wú)法做到100%解決此問(wèn)題。此外在HBase 2.X版本中也不推薦使用HMaster來(lái)啟用表。解決這個(gè)問(wèn)題的最佳方法是支持優(yōu)先表和優(yōu)先節(jié)點(diǎn)，當(dāng)HMaster觸發(fā)SCP流程時(shí)，優(yōu)先將這些表分配到優(yōu)先節(jié)點(diǎn)上，確保分配的優(yōu)先級(jí)，從而完全消除此問(wèn)題。

批量分配時(shí)RPC超時(shí)

HBase專門線性可擴(kuò)展性而設(shè)計(jì)。如果集群中的數(shù)據(jù)隨著表增加而增多，集群可以很容易擴(kuò)展添加RegionServer來(lái)管理表和數(shù)據(jù)。例如：如果一個(gè)集群從10個(gè)RegionServer擴(kuò)展到20個(gè)RegionServer，它在存儲(chǔ)和處理能力方面將會(huì)增加。

隨著RegionServer上Region數(shù)量的增加，批量分配RPC調(diào)用將會(huì)出現(xiàn)超時(shí)（默認(rèn)60秒）。這將導(dǎo)致重新進(jìn)行分配并最終對(duì)分配上線時(shí)間產(chǎn)生嚴(yán)重影響。

在10個(gè)RegionServer節(jié)點(diǎn)和20個(gè)RegionServer節(jié)點(diǎn)的測(cè)試中，RPC調(diào)用分別花費(fèi)了約60秒和116秒。對(duì)于更大的集群來(lái)說(shuō)，批量分配無(wú)法一次成功。主要原因在于對(duì)ZooKeeper進(jìn)行大量的讀寫操作和RPC調(diào)用，用來(lái)創(chuàng)建OFFLINE ZNode節(jié)點(diǎn)，創(chuàng)建正在恢復(fù)的Region ZNode節(jié)點(diǎn)信息等。

恢復(fù)可擴(kuò)展性測(cè)試

在10到100個(gè)節(jié)點(diǎn)的集群測(cè)試中，我們觀察到恢復(fù)時(shí)間隨著集群規(guī)模的增大而線性增加。這意味著集群越大，恢復(fù)所需的時(shí)間就越多。特別是當(dāng)要恢復(fù)WAL文件時(shí)，恢復(fù)時(shí)間將會(huì)非常大。在100個(gè)節(jié)點(diǎn)的集群中，通過(guò)Put請(qǐng)求寫入數(shù)據(jù)的情況下，恢復(fù)需要進(jìn)行WAL Split操作，發(fā)現(xiàn)需要100分鐘才能從集群崩潰中完全恢復(fù)。而在相同規(guī)模的集群中，如果不寫入任何數(shù)據(jù)大約需要15分鐘。這意味著85%以上的時(shí)間用于WAL Split操作和回放用于恢復(fù)。

下面我們將分析測(cè)試過(guò)程中發(fā)現(xiàn)的瓶頸在哪里？

恢復(fù)耗時(shí)分析

HDFS負(fù)載

在10個(gè)節(jié)點(diǎn)的HBase集群上，通過(guò)JMX來(lái)獲取HDFS的RPC請(qǐng)求監(jiān)控信息，發(fā)現(xiàn)在啟動(dòng)階段有1200萬(wàn)讀取RPC調(diào)用。

其中GetBlockLocationNumOps：380萬(wàn)、GetListingNumOps：13萬(wàn)、GetFileInfoNumOps：840萬(wàn)。

當(dāng)集群規(guī)模達(dá)到100個(gè)時(shí)，RPC調(diào)用和文件操作將會(huì)非常大，從而對(duì)HDFS負(fù)載造成很大壓力，成為瓶頸?？赡苡捎谝韵略?qū)е翲DFS寫入失敗、WAL Split和Region上線緩慢超時(shí)重試。

巨大的預(yù)留磁盤空間。

并發(fā)訪問(wèn)達(dá)到DataNode的xceiver的限制。

HMaster負(fù)載

HMaster使用基于ZooKeeper的分配機(jī)制時(shí)，在Region上線過(guò)程中HMaster會(huì)創(chuàng)建一個(gè)OFFLINE ZNode節(jié)點(diǎn)，RegionServer會(huì)將該ZNode更新為OPENING和OPENED狀態(tài)。對(duì)于每個(gè)狀態(tài)變化，HMaster都會(huì)進(jìn)行監(jiān)聽(tīng)并處理。

對(duì)于100個(gè)節(jié)點(diǎn)的HBase集群，大概將會(huì)有6，000，000個(gè)ZNode創(chuàng)建和更新操作和4,000,000個(gè)監(jiān)聽(tīng)事件要進(jìn)行處理。

ZooKeeper的監(jiān)聽(tīng)事件通知處理是順序的，旨在保證事件的順序。這種設(shè)計(jì)在Region鎖獲取階段將會(huì)導(dǎo)致延遲。在10個(gè)節(jié)點(diǎn)的集群中發(fā)現(xiàn)等待時(shí)間為64秒，而20節(jié)點(diǎn)的集群中等待時(shí)間為111秒。

GeneralBulkAssigner 在批量發(fā)送OPEN RPC請(qǐng)求到RegionServer之前會(huì)獲取相關(guān)Region的鎖，再收到RegionServer的OPEN RPC請(qǐng)求響應(yīng)時(shí)才會(huì)釋放該鎖。如果RegionServer再處理批量OPEN RPC請(qǐng)求時(shí)需要時(shí)間，那么在收到確認(rèn)響應(yīng)之前GeneralBulkAssigner將不會(huì)釋放鎖，其實(shí)部分Region已經(jīng)上線，也不會(huì)單獨(dú)處理這些Region。

HMaster按照順序創(chuàng)建OFFLINE ZNode節(jié)點(diǎn)。觀察發(fā)現(xiàn)在執(zhí)行批量分配Region到RegionServer之前將會(huì)有35秒的延遲來(lái)創(chuàng)建ZNode。

采用不依賴ZooKeeper的分配機(jī)制將會(huì)減少ZooKeeper的操作，可以有50%左右的優(yōu)化。HMaster依然會(huì)協(xié)調(diào)和處理Region的分配。

提升WAL Split性能

持久化FlushedSequenceId來(lái)加速集群重啟WAL Split性能(HBASE-20727)

ServerManager有每個(gè)Region的flushedSequenceId信息，這些信息被保存在一個(gè)Map結(jié)構(gòu)中。我們可以利用這些信息來(lái)過(guò)濾不需要進(jìn)行回放的記錄。但是這個(gè)Map結(jié)構(gòu)并沒(méi)有被持久化，當(dāng)集群重啟或者HMaster重啟后，每個(gè)Region的flushedSequenceId信息將會(huì)丟失。

如果這些信息被持久化那么即使HMaster重啟，這些依然存在可用于過(guò)濾WAL記錄，加快恢復(fù)記錄和回放?！甴base.master.persist.flushedsequenceid.enabled’ 可用于配置是否開(kāi)啟此功能。flushedSequenceId信息將會(huì)定時(shí)持久化到如下目錄/.lastflushedseqids?？梢酝ㄟ^(guò)參數(shù)’hbase.master.flushedsequenceid.flusher.interval’ 來(lái)配置持久化間隔，默認(rèn)為3小時(shí)。

注意：此特性在HBase 1.X版本不可用。

改善WAL Split在故障切換時(shí)穩(wěn)定性(HBASE-19358)

在WAL記錄恢復(fù)期間，WAL Split任務(wù)將會(huì)將RegionServer上的所有待恢復(fù)記錄輸出文件打開(kāi)。當(dāng)RegionServer上管理的Region數(shù)量較多時(shí)將會(huì)影響HDFS，需要大量的磁盤保留空間但是磁盤寫入非常小。

當(dāng)集群中所有RegionServer節(jié)點(diǎn)都重啟進(jìn)行恢復(fù)時(shí)，情況將變得非常糟糕。如果一個(gè)RegionServer上有2000個(gè)Region，每個(gè)HDFS文件為3副本，那么將會(huì)導(dǎo)致每個(gè)WAL Splitter打開(kāi)6000個(gè)文件。

通過(guò)啟用hbase.split.writer.creation.bounded可以限制每個(gè)WAL Splitter打開(kāi)的文件。當(dāng)設(shè)置為true時(shí)，不會(huì)打開(kāi)任何recovered.edits的寫入直到在內(nèi)存積累的記錄已經(jīng)達(dá)到 hbase.regionserver.hlog.splitlog.buffersize（默認(rèn)128M），然后一次性寫入并關(guān)閉文件，而不是一直處于打開(kāi)狀態(tài)。這樣會(huì)減少打開(kāi)文件流數(shù)量，從hbase.regionserver.wal.max.splitters * the number of region the hlog contains減少為hbase.regionserver.wal.max.splitters * hbase.regionserver.hlog.splitlog.writer.threads。

通過(guò)測(cè)試發(fā)現(xiàn)在3節(jié)點(diǎn)集群中，擁有15GB WAL文件和20K Region的情況下，集群整體重啟時(shí)間從23分鐘縮短為11分鐘，減少50%。

hbase.regionserver.wal.max.splitters = 5

hbase.regionserver.hlog.splitlog.writer.threads= 50

WAL Split為HFile(HBASE-23286)

WAL恢復(fù)時(shí)使用HFile文件替換Edits文件這樣可以避免在Region上線過(guò)程中寫入。Region上線過(guò)程中需要完成HFile文件校驗(yàn)、執(zhí)行bulkload加載并觸發(fā)Compaction來(lái)合并小文件。此優(yōu)化可以避免讀取Edits文件和持久化內(nèi)存帶來(lái)的IO開(kāi)銷。當(dāng)集群中的Region數(shù)量較少時(shí)（例如50個(gè)Region）觀察發(fā)現(xiàn)性能有顯著提升。

當(dāng)集群中有更多的Region時(shí)，測(cè)試發(fā)現(xiàn)由于大量的HFile寫入和合并將會(huì)導(dǎo)致CPU和IO的增加。可以通過(guò)如下額外的措施來(lái)減少IO。

將故障RegionServer作為首選WAL Splitter，減少遠(yuǎn)程讀取。

將Compaction延遲后臺(tái)執(zhí)行，加快region上線處理。

Observer NameNode(HDFS-12943)

當(dāng)HBase集群規(guī)模變大時(shí)，重啟會(huì)觸發(fā)大量的RPC請(qǐng)求，使得HDFS可能成為瓶頸，可以通過(guò)使用Observer NameNode負(fù)擔(dān)讀請(qǐng)求來(lái)降低HDFS的負(fù)載。

總結(jié)

通過(guò)上述分析，可以配置如下參數(shù)來(lái)提升HBase MTTR，尤其是在集群整體從崩潰中恢復(fù)的情況。

參考

HBase ZK-less Region Assignment : Apache HBase

Apache HBase ? Reference Guide

NoSQL HBase schema design and SQL with Apache Drill (slideshare.net)

MapReduce服務(wù) MRS_華為云 (huaweicloud.com)

EI企業(yè)智能 FusionInsight HBase MapReduce服務(wù) 大數(shù)據(jù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。