通過(guò)百度大規(guī)模時(shí)序數(shù)據(jù)存儲(chǔ)系列文章的介紹，想必讀者對(duì)百度智能監(jiān)控系統(tǒng) Noah 的 TSDB 不再陌生，它主要用來(lái)存儲(chǔ) Noah 監(jiān)控系統(tǒng)的時(shí)序指標(biāo)數(shù)據(jù)，包括但不限于硬件和軟件的可用性指標(biāo)、資源使用率指標(biāo)和性能指標(biāo)等。今天主要聊聊在百度智能監(jiān)控場(chǎng)景下的 HBase 相關(guān)實(shí)踐經(jīng)驗(yàn)，先簡(jiǎn)單介紹一下 HBase。

HBase 架構(gòu)簡(jiǎn)介

HBase 是一個(gè)基于 Java、開源的、非關(guān)系型的、面向列存儲(chǔ)的分布式可擴(kuò)展的大數(shù)據(jù)存儲(chǔ)數(shù)據(jù)庫(kù)。HBase 的集群主要由 HMater 和 RegionServer 兩種角色組成，底層以 HDFS 作為存儲(chǔ)設(shè)施，集群由 Zookeeper 協(xié)助管理。其架構(gòu)如下圖所示：

 

 

圖 1 HBase 架構(gòu)圖

簡(jiǎn)單介紹一下 HBase 中相關(guān)組件的作用：

HMaster

HMaster 是整個(gè)集群的大腦，負(fù)責(zé)數(shù)據(jù)表的操作、集群的負(fù)載均衡和故障恢復(fù)等集群管理工作。

RegionServer

HBase 將表以行為單位劃分成許多片段，每個(gè)片段稱為一個(gè) Region。這些 Region 被分配到 RegionServer 進(jìn)行管理。在讀寫流程中，定位到數(shù)據(jù)所在 RegionServer 后，Client 與 RegionServer 直接交互進(jìn)行數(shù)據(jù)的讀寫。

Zookeeper

HBase 作為一個(gè)大規(guī)模的分布式系統(tǒng)，Zookeeper 的作用是至關(guān)重要的。首先 Zookeeper 作為 HMaster HA 解決方案，保證了至少有一個(gè) HMaster 處于工作狀態(tài)。其次 Zookeeper 通過(guò)心跳機(jī)制探活 RegionServer，當(dāng) RegionServer 故障時(shí)及時(shí)通知 HMaster 進(jìn)行故障處理工作。最后 Zookeeper 保存了維護(hù)全局元信息的 META 表的路徑，Client 第一次與 HBase 集群交互時(shí)，需要通過(guò) META 表來(lái)獲取目標(biāo)數(shù)據(jù)所在的 RegionServer。

上面簡(jiǎn)單介紹了 HBase 的架構(gòu)和各組件的基本信息，下面和大家分享一下在百度最大規(guī)模時(shí)序數(shù)據(jù)庫(kù)的場(chǎng)景下使用 HBase 時(shí)遇到的幾個(gè)典型問(wèn)題和優(yōu)化方案。

熱點(diǎn)問(wèn)題

大家都知道木桶效應(yīng)，對(duì)于 TSDB 系統(tǒng)來(lái)說(shuō)，熱點(diǎn) Region 所在的 RegionServer 就是影響整個(gè)”水桶”容量最短的那塊木板。理想情況下 HBase 中所有的請(qǐng)求應(yīng)該均勻的分布在所有 RgionServer 的所有 Region 上，當(dāng)個(gè)別 Region 收到的讀寫請(qǐng)求數(shù)量大幅超過(guò)其它的 Region，它所在的 Region 就有可能成為熱點(diǎn)。

 

 

圖 2 RegionServer 信息(此圖來(lái)源網(wǎng)絡(luò)非百度實(shí)際數(shù)據(jù))

Noah-TSDB 初期曾遇到監(jiān)控元數(shù)據(jù)表設(shè)計(jì)不合理導(dǎo)致熱點(diǎn)的問(wèn)題。當(dāng)時(shí)研發(fā)同學(xué)收到 Noah-TSDB寫入模塊隊(duì)列堵塞的業(yè)務(wù)報(bào)警，從 Noah 監(jiān)控系統(tǒng)上看到同時(shí)間段訪問(wèn) HBase 異常明顯增長(zhǎng)。HBase 中的個(gè)別 RegionServer 頻繁進(jìn)行 GC，網(wǎng)絡(luò) I/O 和磁盤 I/O 密集，操作隊(duì)列中待執(zhí)行的請(qǐng)求堆積嚴(yán)重，負(fù)載明顯高于其它的 RegionServer。查看異常 RegionServer 的日志發(fā)現(xiàn)大量請(qǐng)求訪問(wèn)的是同一個(gè) Region：”tsdb-meta,*** 1.”。初步定位是由于該 Region負(fù)載過(guò)高，導(dǎo)致它所在的 RegionServer 成為熱點(diǎn)，進(jìn)而導(dǎo)致系統(tǒng)的吞吐量下降，上游寫入模塊請(qǐng)求堆積。

tsdb-meta 是用來(lái)存儲(chǔ)監(jiān)控指標(biāo)的名稱、周期等元信息的表，表中紅色填充的行代表其擁有數(shù)據(jù)量超過(guò)正常水平的，表結(jié)構(gòu)如下：

表 1 原始 tsdb-meta 表

 

 

分析上面的存儲(chǔ)結(jié)構(gòu)，我們可以知道：

同一個(gè)監(jiān)控對(duì)象(namespace)的監(jiān)控指標(biāo)元信息將會(huì)存儲(chǔ)在 HBase 表的同一行。

不同監(jiān)控對(duì)象的指標(biāo)數(shù)量不同，將導(dǎo)致行的大小不均勻。

HBase 中數(shù)據(jù)分片是以行為單位，每行的數(shù)據(jù)存儲(chǔ)在同一個(gè) Region 中，當(dāng)某一行存儲(chǔ)的監(jiān)控指標(biāo)數(shù)量遠(yuǎn)大于正常水平時(shí)，該行就有可能成為熱點(diǎn)。

綜上所述，當(dāng)個(gè)別監(jiān)控對(duì)象擁有的監(jiān)控指標(biāo)個(gè)數(shù)過(guò)多時(shí)，tsdb-meta 可能會(huì)出現(xiàn)熱點(diǎn)問(wèn)題。同時(shí)經(jīng)我們驗(yàn)證發(fā)現(xiàn)，成為熱點(diǎn)的監(jiān)控對(duì)象擁有的監(jiān)控指標(biāo)的數(shù)量大約是正常水平的 20 倍左右，進(jìn)一步確認(rèn)了故障原因。

定位到根因后，我們決定從兩個(gè)方面來(lái)著手解決這個(gè)問(wèn)題。一方面，定期統(tǒng)計(jì)監(jiān)控對(duì)象擁有的指標(biāo)個(gè)數(shù)，及時(shí)發(fā)現(xiàn)由于監(jiān)控配置異常和不合理使用導(dǎo)致的個(gè)別監(jiān)控對(duì)象擁有的監(jiān)控指標(biāo)過(guò)多的問(wèn)題。第二方面，對(duì) tsdb-meta 表結(jié)構(gòu)改造，將原來(lái)按列分布的數(shù)據(jù)修改為按行展開平鋪，充分打平數(shù)據(jù)，利用 HBase 按行自動(dòng)分片的機(jī)制來(lái)達(dá)到負(fù)載均衡的狀態(tài)。第一方面主要是從業(yè)務(wù)層面對(duì)不合理使用的情況進(jìn)行人工干預(yù)。今天主要著重介紹第二方面。

tsdb-meta 表 Schema 改造

前文大體介紹了表結(jié)構(gòu)改造的思路，避免單行數(shù)據(jù)過(guò)大導(dǎo)致熱點(diǎn)問(wèn)題。我們將監(jiān)控對(duì)象和監(jiān)控指標(biāo)的名稱信息一起作為行鍵，只保留一列用于存儲(chǔ)指標(biāo)的其余信息，避免了因單行數(shù)據(jù)過(guò)大導(dǎo)致的熱點(diǎn)問(wèn)題。

表 2 優(yōu)化后的 tsdb-meta 表

 

 

預(yù)分區(qū)

tsdb-meta 表優(yōu)化后，我們發(fā)現(xiàn)生產(chǎn)環(huán)境存儲(chǔ)數(shù)據(jù)的 tsdb-data 表也存在熱點(diǎn)問(wèn)題。tsdb-data 是用來(lái)存儲(chǔ)監(jiān)控指標(biāo)數(shù)值的表，生產(chǎn)環(huán)境是按時(shí)間跨度進(jìn)行分表，每?jī)商斓臄?shù)據(jù)存儲(chǔ)在一張表中。數(shù)據(jù)的行鍵由數(shù)據(jù) hash 后的特征變量 ts_uid 和時(shí)間基準(zhǔn) timestamp_base 組成，利用 HBase 存儲(chǔ)時(shí)按行鍵的字典順序排序的特點(diǎn)，將不同的監(jiān)控指標(biāo)的數(shù)據(jù)散列到不同的 Region，相同監(jiān)控對(duì)象的指標(biāo)數(shù)據(jù)順序排列，達(dá)到優(yōu)化查詢的效果。由于 tsdb-data 表的日常訪問(wèn)量基數(shù)較大，當(dāng)某個(gè)監(jiān)控對(duì)象擁有的指標(biāo)數(shù)量高于平均水平，那么該監(jiān)控對(duì)象的監(jiān)控指標(biāo)很大概率會(huì)被分配到相同的 Region，導(dǎo)致該 Region 過(guò)大，進(jìn)成為熱點(diǎn)，集群會(huì)分裂過(guò)大的 Region 來(lái)維持負(fù)載均衡的狀態(tài)。頻繁的分裂操作會(huì)占用大量資源，影響 RegionServer 的吞吐量。為解決因 Region 過(guò)大導(dǎo)致的熱點(diǎn)，我們采用了對(duì)數(shù)據(jù)表進(jìn)行預(yù)分區(qū)的方法。

在對(duì) tsdb-data 表進(jìn)行預(yù)分區(qū)時(shí)，我們發(fā)現(xiàn)只通過(guò)指定 Region 數(shù)量來(lái)實(shí)現(xiàn)預(yù)分區(qū)的效果并不理想，因?yàn)闀?huì)出現(xiàn)實(shí)際寫入量與槽位分配不均的問(wèn)題。HBase 數(shù)據(jù)表是按照行鍵的字節(jié)空間均勻劃分而不是按照實(shí)際存儲(chǔ)的數(shù)據(jù)量進(jìn)行劃分。如下圖所示，圖中紅色方塊代表實(shí)際存儲(chǔ)的數(shù)據(jù)，白色的方塊代表無(wú)實(shí)際數(shù)據(jù)的行。

 

 

圖 3 原始 Region 預(yù)分區(qū)

如上圖，雖然數(shù)據(jù)表已經(jīng)按照行鍵的字節(jié)空間劃分成 3 個(gè) Region 了，但是明顯 Region 3 中實(shí)際存儲(chǔ)的數(shù)據(jù)量遠(yuǎn)大于 Region 1 和 Region 2。這種情況下 Region 3 有成為熱點(diǎn)的可能性。為了改善這種情況，Noah-TSDB 結(jié)合了生產(chǎn)環(huán)境中的 tsdb-data 表按等間隔時(shí)間跨度分表的特點(diǎn)，決定參照歷史表的使用情況對(duì)新表進(jìn)行預(yù)分區(qū)。根據(jù)生產(chǎn)環(huán)境實(shí)際產(chǎn)生的行鍵和預(yù)期的分區(qū)大小計(jì)算出 Region 分界值，然后根據(jù)分界值將表劃分成實(shí)際水位相近的 Region，這樣雖然每個(gè) Region 的槽位大小不一樣，但是每個(gè) Region 實(shí)際存儲(chǔ)的數(shù)量是相當(dāng)?shù)模�進(jìn)一步降低產(chǎn)生熱點(diǎn)的風(fēng)險(xiǎn)。

 

 

圖 4 優(yōu)化后的 Region 預(yù)分區(qū)

如何合理的設(shè)置 Region 數(shù)量

在前文介紹的預(yù)分區(qū)策略中，除了需要參考生產(chǎn)環(huán)境的實(shí)際使用情況外還需要根據(jù)機(jī)器資源和分裂閾值等系統(tǒng)參數(shù)來(lái)預(yù)估合適的 Region 大小，Region 大小確定后，我們可以預(yù)估出整體的 Region 數(shù)量。那么如何判斷當(dāng)前集群是否能夠承載調(diào)整后的 Region 數(shù)量呢?如果 Region 的數(shù)量不合理有哪些危害呢?在討論 Region 數(shù)量對(duì)集群的影響之前，我們先了解一些基礎(chǔ)知識(shí)：

在 HBase 的數(shù)據(jù)寫入流程中，數(shù)據(jù)是先寫到 Memstore(寫緩存)排序，然后異步 Flush 追加到 HFile 中。一個(gè) Region 中的多個(gè)列族對(duì)應(yīng)多個(gè) Memstore，Memstore Flush 的最小單位是 Region。

當(dāng)一個(gè) RegionServer 中所有 Memstore 的大小總和達(dá)到閾值 hbase.regionserver.global.memstore.upperLimit * hbase_heapsize 會(huì)觸發(fā) Memstore Flush。根據(jù) Memstore 從大到小依次 Flush，直至 MemStore 內(nèi)存使用量低于閾值 hbase_heapsize * hbase.regionserver.global.memstore.lowerLimit。

HBase 會(huì)定期 Flush Memstore 來(lái)保障 Memstore 不會(huì)長(zhǎng)時(shí)間沒(méi)有持久化。為避免所有的 MemStore 在同一時(shí)間都進(jìn)行 Flush 導(dǎo)致的問(wèn)題，定期的 Flush 操作有隨機(jī)延時(shí)。

綜上可知，一方面由于同一個(gè) RegionServer 共享 Memstore，Region 數(shù)量過(guò)多會(huì)導(dǎo)致 Memstore Flush 的頻率變快，產(chǎn)生的 HFile 變多，HBase 持續(xù)的進(jìn)行 Compaction，引發(fā)合并風(fēng)暴。另一方面由于 HBase 定期 Flush Memstore，每次執(zhí)行 Flush 需要將每個(gè) Region 的每個(gè)列族對(duì)應(yīng)的 Memstore 寫入文件并存到 HDFS， Region 數(shù)量越多，每次需要一起處理的文件數(shù)量就越大，即使存在隨機(jī)時(shí)延機(jī)制，短時(shí)間內(nèi)文件的創(chuàng)建和數(shù)據(jù)的遷移較多也會(huì)加大集群負(fù)載，可能引起快照超時(shí)、客戶端超時(shí)和批量加載超時(shí)，降低 TSDB 系統(tǒng)性能。因此 Region 數(shù)量過(guò)多會(huì)降低系統(tǒng)吞吐量。

Region 數(shù)量過(guò)少也會(huì)降低系統(tǒng)性能。當(dāng)數(shù)據(jù)量不變的情況下，由于 Region 數(shù)量過(guò)少導(dǎo)致單個(gè) Region 過(guò)大，每個(gè) Region 處理的寫入請(qǐng)求數(shù)偏高，當(dāng) Flush 的速度慢慢被寫入速度追上并趕超時(shí)，就會(huì)堵塞寫入，影響 RPC，進(jìn)而影響 HBase 的整體寫入和查詢，降低系統(tǒng)的吞吐量。

Region 數(shù)量設(shè)置不合理，會(huì)降低 TSDB 系統(tǒng)整體性能與可靠性，一般推薦的單個(gè) RegionServer 管理的 Region 數(shù)量計(jì)算方法如下：

#{Region} = (RS memory)*(total memstore fraction)/((memstore size)*(# {column families}))

舉個(gè)例子，如果 RegionServer 的參數(shù)如下：

Java Heap Size of HBase RegionServer in Bytes 設(shè)置的是 20G

hbase.regionserver.global.memstore.upperLimit 是 0.4

hbase.hregion.memstore.flush.size 是 128M

多個(gè)表的列族個(gè)數(shù)共 2 個(gè)

那么 #{Region} = 20 * 1024 * 0.4/ (128 * 2) = 32。這個(gè)公式是在假設(shè)所有的 Region 都在以相同的速率寫的前提下，如果實(shí)際只有部分 Region 在寫入數(shù)據(jù)，結(jié)果可以根據(jù)比例、結(jié)合業(yè)務(wù)進(jìn)行調(diào)整。例如 Noah-TSDB 的場(chǎng)景下，數(shù)據(jù)是按照時(shí)間分表，一般兩天的數(shù)據(jù)存在一張數(shù)據(jù)表中，數(shù)據(jù)的寫入都集中在最近的一張表，因此實(shí)際寫入活躍的 Region 數(shù)量遠(yuǎn)小于 Region 的總數(shù)量，所以實(shí)際每個(gè) RegionServer 管理的 Region 的數(shù)量大約是通過(guò)上述公式直接計(jì)算結(jié)果的 3 倍左右。

預(yù)估出整體的 Region 數(shù)量和單個(gè) RegionServer 管理的 Region 數(shù)量后，就可以合理的進(jìn)行容量規(guī)劃，在集群調(diào)整的時(shí)候預(yù)估需要的機(jī)器資源。

總結(jié)

上面就是今天介紹的全部?jī)?nèi)容了，給大家簡(jiǎn)單分享了一些使用 HBase 的實(shí)踐經(jīng)驗(yàn)。其實(shí)在實(shí)際使用時(shí)我們也發(fā)現(xiàn)了 HBase 過(guò)重，運(yùn)維成本較高等問(wèn)題，也在持續(xù)的進(jìn)行調(diào)研和架構(gòu)升級(jí)，大家有什么好的建議歡迎不吝賜教。另外文中如果有理解不到位或者偏差的地方，歡迎大家指正。

作者簡(jiǎn)介

張洋洋，百度高級(jí)研發(fā)工程師。負(fù)責(zé)百度智能運(yùn)維產(chǎn)品(Noah)的分布式時(shí)序數(shù)據(jù)庫(kù)和通用配額管理平臺(tái)的設(shè)計(jì)研發(fā)工作，在分布式存儲(chǔ)和配額管理方向有廣泛的實(shí)踐經(jīng)驗(yàn)。

標(biāo)簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。