摘要：通過(guò)機(jī)制將多個(gè)合并成一個(gè)以控制每個(gè)內(nèi)的的數(shù)目在一定范圍內(nèi)，當(dāng)然還有其他的作用，比如數(shù)據(jù)本地化率，多版本數(shù)據(jù)的合并，數(shù)據(jù)刪除標(biāo)記的清理等等，本文不做展開(kāi)。

HBase 是一個(gè)基于 Google BigTable 論文設(shè)計(jì)的高可靠性、高性能、可伸縮的分布式存儲(chǔ)系統(tǒng)。 網(wǎng)上關(guān)于 HBase 的文章很多，官方文檔介紹的也比較詳細(xì)，本篇文章不介紹HBase基本的細(xì)節(jié)。

本文從 HBase 寫(xiě)鏈路開(kāi)始分析，然后針對(duì)少量隨機(jī)讀和海量隨機(jī)寫(xiě)入場(chǎng)景入手，全方面量化分析各種資源的開(kāi)銷(xiāo), 從而做到以下兩點(diǎn)：

在給定業(yè)務(wù)量級(jí)的情況下，預(yù)先評(píng)估好集群的合理規(guī)模

在 HBase 的眾多參數(shù)中，選擇合理的配置組合

HBase 的寫(xiě)入鏈路基于 LSM（Log-Structured Merge-Tree), 基本思想是把用戶(hù)的隨機(jī)寫(xiě)入轉(zhuǎn)化為兩部分寫(xiě)入：

Memstore 內(nèi)存中的 Map, 保存隨機(jī)的隨機(jī)寫(xiě)入，待 memstore 達(dá)到一定量的時(shí)候會(huì)異步執(zhí)行 flush 操作，在 HDFS 中生成 HFile 中。 同時(shí)會(huì)按照寫(xiě)入順序，把數(shù)據(jù)寫(xiě)入一份到 HDFS 的 WAL（Write Ahead Log）中，用來(lái)保證數(shù)據(jù)的可靠性，即在異常（宕機(jī)，進(jìn)程異常退出）的場(chǎng)景下，能夠恢復(fù) Memstore 中還沒(méi)來(lái)得及持久化成 HFile 的數(shù)據(jù).

上一節(jié)中，介紹了 HBase 的寫(xiě)路徑，其中 HFile 是 HBase 數(shù)據(jù)持久化的最終形態(tài), 本節(jié)將介紹 HBase 如何生成 HFile 和管理 HFile。關(guān)于 HFile， 主要涉及到兩個(gè)核心操作：

Flushing

Compaction

上一節(jié)中提到，HBase 的寫(xiě)入最先會(huì)放入內(nèi)存中，提供實(shí)時(shí)的查詢(xún)，當(dāng) Memstore 中數(shù)據(jù)達(dá)到一定量的閾值（128MB），會(huì)通過(guò) Flush 操作生成 HFile 持久化到 HDFS 中，隨著用戶(hù)的寫(xiě)入，生成的 HFile 數(shù)目會(huì)逐步增多，這會(huì)影響用戶(hù)的讀操作，同時(shí)也會(huì)系統(tǒng)占用（HDFS 層 block 的數(shù)目， regionserver 服務(wù)器的文件描述符占用）， region split 操作，region reopen 操作也會(huì)受到不同程度影響。
HBase 通過(guò) Compaction 機(jī)制將多個(gè) HFile 合并成一個(gè) HFile 以控制每個(gè) Region 內(nèi)的 HFile 的數(shù)目在一定范圍內(nèi)， 當(dāng)然 Compaction 還有其他的作用，比如數(shù)據(jù)本地化率，多版本數(shù)據(jù)的合并，數(shù)據(jù)刪除標(biāo)記的清理等等，本文不做展開(kāi)。

另外還有一點(diǎn)需要知道的是，HBase 中 Flush 操作和 Compaction 操作和讀寫(xiě)鏈路是由獨(dú)立線(xiàn)程完成的，互不干擾。

為了簡(jiǎn)化計(jì)算，本節(jié)針對(duì)事件類(lèi)數(shù)據(jù)寫(xiě)吞吐型場(chǎng)景，對(duì) HBase 系統(tǒng)中的開(kāi)銷(xiāo)做定量的分析，做以下假設(shè)：

數(shù)據(jù)寫(xiě)入的 Rowkey 是打散的，不存在寫(xiě)熱點(diǎn)

數(shù)據(jù)寫(xiě)入量及總量是可評(píng)估的，會(huì)對(duì)數(shù)據(jù)做預(yù)先分區(qū)，定量分析基于 region 分布穩(wěn)定的情況下

假設(shè)隨機(jī)讀的數(shù)目很小，小到可以忽略 IO 開(kāi)銷(xiāo)，且對(duì)讀 RT 不敏感

數(shù)據(jù)沒(méi)有更新，沒(méi)有刪除操作，有生命周期TTL設(shè)置

HBase 寫(xiě)入鏈路中不存在隨機(jī)磁盤(pán)，所以隨機(jī) IOPS 不會(huì)成為瓶頸

一般大數(shù)據(jù)機(jī)型的多個(gè) SATA 盤(pán)的順序?qū)懲掏麓笥谌f(wàn)兆網(wǎng)卡

忽略掉RPC帶來(lái)的額外的帶寬消耗

單條數(shù)據(jù)大小 -> s （bytes）

峰值寫(xiě) TPS -> T

HFile 副本數(shù)→ R1 （一般為3）

WAL 副本數(shù) → R2 (一般為3)

WAL 數(shù)據(jù)壓縮比 → Cwal (一般是1)

HFile 壓縮比 → C (采用 DIFF + LZO， 日志場(chǎng)景壓縮比一般為 0.2左右)

FlushSize → F (這里跟 regionserver 的 memstore 內(nèi)存容量，region 數(shù)目，寫(xiě)入是否平均和 flushsize 的配置有關(guān)，簡(jiǎn)化分析，認(rèn)為內(nèi)存是足夠的 128MB)

hbase.hstore.compaction.min → CT （默認(rèn)是 3， 一般情況下，決定了歸并系數(shù)，即每次 compaction 參與的文件數(shù)目，在不存在 compaction 積壓的情況下， 實(shí)際運(yùn)行時(shí)也是在 3 左右）

數(shù)據(jù)生命周期 → TTL (決定數(shù)據(jù)量的大小，一般寫(xiě)吞吐場(chǎng)景，日志會(huì)有一定的保存周期, 單位天)

單機(jī)數(shù)據(jù)量水位 → D ( 單位 T，這里指 HDFS 上存放 HFile 數(shù)據(jù)的數(shù)據(jù)量平均分擔(dān)到每臺(tái)機(jī)器上)

MajorCompaction 周期 → M( hbase.hregion.majorcompaction 決定，默認(rèn) 20 天)

以上 11 個(gè)參數(shù)，是本次量化分析中需要使用到的變量，系統(tǒng)資源方面主要量化以下兩個(gè)指標(biāo)：

磁盤(pán)開(kāi)銷(xiāo)

網(wǎng)絡(luò)開(kāi)銷(xiāo)

這里只考慮磁盤(pán)空間方面的占用，相關(guān)的變量有：

單條數(shù)據(jù)大小 s

峰值寫(xiě)入 TPS

HFile 副本數(shù) R1

HFile 壓縮比 c

數(shù)據(jù)生命周期 TTL

HFile的磁盤(pán)容量量化公式

V = TTL  86400  T  s  C * R1

假設(shè) s = 1000, TTL = 365， T = 200000, C = 0.2 , R1 = 3 的情況下，HFile 磁盤(pán)空間需求是：

  V = 30 * 86400 * 200000 * 1000 * 0.2 * 3  
    = 311040000000000.0 bytes
    = 282T 

在這里我們忽略了其他占用比較小的磁盤(pán)開(kāi)銷(xiāo)，比如：

WAL的磁盤(pán)開(kāi)銷(xiāo)，在沒(méi)有 Replication，寫(xiě)入平均的情況下，WAL 的日志量約定于 (hbase.master.logcleaner.ttl /1000) s TPS + totalMemstoreSize

Compaction 臨時(shí)文件，Split 父 Region 文件等臨時(shí)文件

Snapshot 文件

等等

HBase中會(huì)造成巨大網(wǎng)絡(luò)開(kāi)銷(xiāo)的主要由一下三部分組成，他們是相互獨(dú)立，異步進(jìn)行的，這里做個(gè)比方，HBase 這三個(gè)操作和人吃飯很像，這里做個(gè)類(lèi)比

回歸正題，下面按照發(fā)生順序，從三個(gè)角度分別分析：

寫(xiě)路徑

Flush

Compaction

寫(xiě)路徑的網(wǎng)絡(luò)開(kāi)銷(xiāo)，主要是寫(xiě) WAL 日志方面, 相關(guān)的變量有：

單條數(shù)據(jù)大小 s

峰值寫(xiě)入 TPS

WAL 副本數(shù) R2

WAL 壓縮比 Cwal

寫(xiě)路徑中，產(chǎn)生的網(wǎng)絡(luò)流量分為兩部分，一部分是寫(xiě) WAL 產(chǎn)生的流量，一部分是外部用戶(hù) RPC 寫(xiě)入的流量， In 流量和 Out 流量計(jì)算公式為：

NInWrite = T  s   Cwal  (R2 - 1)  + （T  s )
NOutWrite = T  s   Cwal * (R2 - 1)

假設(shè) T = 20W，s = 1000, Cwal = 1.0, R2 = 3

      NInwrite = 200000 * 1000  * 1 * (3-1) + 200000 * 1000

               = 600000000 bytes/s

               = 572MB/s

     NOutwrite = 200000 * 1000* 1 * (3-1)

               = 400000000 bytes/s

               = 381MB/s

Flush 的網(wǎng)絡(luò)開(kāi)銷(xiāo)，主要是生成 HFile 后，將 HFile 寫(xiě)入到 HDFS 的過(guò)程，相關(guān)的變量有：

單條數(shù)據(jù)大小 s

峰值寫(xiě)入 T

HFIle 副本數(shù) R1

HFile 壓縮比 C

Flush 產(chǎn)生的 In 流量和 Out 流量計(jì)算公式為：

NInWrite = s  T  (R1 - 1) * C
NOutWrite = s  T  (R1 - 1) * C

假設(shè) T = 20W， S = 1000， R1 = 3， C = 0.2

  NInwrite  = 200000 * 1000 * (3 - 1) * 0.2 

            = 80000000.0 bytes/s

            =76.3MB/s

 NOutwrite  = 200000 * 1000 * (3 - 1) * 0.2 

            = 120000000.0 bytes/s

            =76.3MB/s

Compaction 比較復(fù)雜，在有預(yù)分區(qū)不考慮 Split 的情況下分為兩類(lèi)：

Major Compaction

Minor Compaction

兩者是獨(dú)立的，下面將分別針對(duì)兩種 Compaction 做分析，最后取和：

4.3.3.1 Major Compaction

Major Compaction 的定義是由全部 HFile 參與的 Compaction， 一般在發(fā)生在 Split 后發(fā)生，或者到達(dá)系統(tǒng)的 MajorCompaction 周期， 默認(rèn)的 MajorCompaction 周期為 20 天，這里我們暫時(shí)忽略 Split 造成的 MajorCompaction 流量. 最終 Major Compaction 開(kāi)銷(xiāo)相關(guān)的變量是:

單機(jī)數(shù)據(jù)量水位 D

HFIle 副本數(shù) R1

MajorCompaction 周期 → M (默認(rèn) 20 天)

這里假設(shè)數(shù)據(jù)是有本地化的，所以 MajorCompaction 的讀過(guò)程，走 ShortCircuit，不計(jì)算網(wǎng)絡(luò)開(kāi)銷(xiāo)，并且寫(xiě) HFile 的第一副本是本地流量，也不做流量計(jì)算，所以 MajorCompaction 的網(wǎng)絡(luò)流量計(jì)算公式是：

NInMajor = D * (R1 - 1) / M
NOutMajor = D * (R1 - 1) / M

假設(shè) D = 10T, R1 = 3, M = 20

    NInMajor =  10 * 1024 * 1024 * 1024 * 1024 * (3 - 1) / (20 * 86400)

             = 12725829bytes/s 

             = 12MB/s

   NOutMajor =  10 * 1024 * 1024 * 1024 * 1024 * (3 - 1) / (20 * 86400)

             = 12725829bytes /s 

             = 12MB/s

4.3.3.2 Minor Compaction

量化之前，先問(wèn)一個(gè)問(wèn)題，每條數(shù)據(jù)在第一次 flush 成為 HFile 之后，會(huì)經(jīng)過(guò)多少次 Minor Compaction?

要回答這個(gè)問(wèn)題之前，要先了解現(xiàn)在 HBase 默認(rèn)的 compaction 的文件選取策略，這里不展開(kāi)，只做簡(jiǎn)單分析，MinorCompaction 選擇的文件對(duì)象數(shù)目，一般處于 hbase.hstore.compaction.min（默認(rèn) 3）和 hbase.hstore.compaction.max（默認(rèn) 10）之間, 總文件大小小于 hbase.hstore.compaction.max.size（默認(rèn) Max）， 如果文件的 Size 小于 hbase.hstore.compaction.min.size（默認(rèn)是 flushsize）， 則一定會(huì)被選中； 并且被選中的文件size的差距不會(huì)過(guò)大, 這個(gè)由參數(shù) hbase.hstore.compaction.ratio 和 hbase.hstore.compaction.ratio.offpeak 控制，這里不做展開(kāi).

所以，在 Compaction 沒(méi)有積壓的情況下，每次 compaction 選中的文件數(shù)目會(huì)等于 hbase.hstore.compaction.min 并且文件 size 應(yīng)該相同量級(jí)， 對(duì)穩(wěn)定的表，對(duì)每條數(shù)據(jù)來(lái)說(shuō)，經(jīng)過(guò)的 compaction 次數(shù)越多，其文件會(huì)越大. 其中每條數(shù)據(jù)參與 Minor Compaction 的最大次數(shù)可以用公式 math.log( 32000 / 25.6, 3) = 6 得到

這里用到的兩個(gè)變量是：

FlushSize 默認(rèn)是 128 MB

HFile 壓縮比例，假設(shè)是 0.2

所以剛剛 Flush 生成的 HFile 的大小在 25.6MB 左右，當(dāng)集齊三個(gè) 25.6MB 的 HFile 后，會(huì)觸發(fā)第一次 Minor Compaction， 生成一個(gè) 76.8MB 左右的 HFile

對(duì)于一般情況，單個(gè) Region 的文件 Size 我們會(huì)根據(jù)容量預(yù)分區(qū)好，并且控制單個(gè) Region 的 HFile 的總大小 在 32G 以?xún)?nèi)，對(duì)于一個(gè) Memstore
128MB, HFile 壓縮比 0.2， 單個(gè) Region 32G 的表，上表中各個(gè) Size 的 HFile 數(shù)目不會(huì)超過(guò) 2 個(gè)(否則就滿(mǎn)足了觸發(fā) Minor Compaction 的條件)

32G = 18.6G + 6.2G + 6.2G + 690MB + 230MB + 76.8MB + 76.8MB

到這里，我們知道每條寫(xiě)入的數(shù)據(jù)，從寫(xiě)入到 TTL 過(guò)期，經(jīng)過(guò) Minor Compaction 的次數(shù)是可以計(jì)算出來(lái)的。 所以只要計(jì)算出每次 Compaction 的網(wǎng)絡(luò)開(kāi)銷(xiāo)，就可以計(jì)算出，HBase 通過(guò) Minor Compaction 消化每條數(shù)據(jù)，所占用的總的開(kāi)銷(xiāo)是多少，這里用到的變量有：

單條數(shù)據(jù)大小 s

峰值寫(xiě)入 T

HFIle 副本數(shù) R1

HFile 壓縮比 C

計(jì)算公式如下：

NInMinor = S  T  （R1-1）  C  總次數(shù)
NOutMinor = S  T  （R1-1）  C  總次數(shù)

假設(shè) S = 1000, T = 20W， R1 = 3, C = 0.2， 總次數(shù) = 6

    NInminor = 1000 * 200000 * (3 - 1) * 0.2 * 6

             = 480000000.0bytes/s

             = 457.8MB/s 

   NOutminor = 1000 * 200000 * (3 - 1) * 0.2 * 6

             = 480000000.0bytes/s

             = 457.8MB/s 

在用戶(hù)寫(xiě)入 TPS 20W, 單條數(shù)據(jù)大小 1000 bytes的場(chǎng)景下，整體網(wǎng)絡(luò)吞吐為：

NIntotal   = NInwrite + NInflush + NInmajor + NInminor

           = 572MB/s + 76.3MB/s  + 12MB/s + 457.8MB/s

           = 1118.1MB/s

NOuttotal  = NOutwrite + NOutflush + NOutmajor + NOutminor

           = 381MB/s + 76.3MB/s  + 12MB/s + 457.8MB/s

           = 927.1MB

當(dāng)然這是理想情況下的最小開(kāi)銷(xiāo)，有很多種情況，可以導(dǎo)致實(shí)際網(wǎng)絡(luò)開(kāi)銷(xiāo)超過(guò)這個(gè)理論值, 以下情況都會(huì)導(dǎo)致實(shí)際流量的升高：

預(yù)分區(qū)不足或者業(yè)務(wù)量增長(zhǎng)，導(dǎo)致 Region 發(fā)生 Split， Split 會(huì)導(dǎo)致額外的 Compaction 操作

分區(qū)寫(xiě)入不平均，導(dǎo)致少量 region 不是因?yàn)榈竭_(dá)了 flushsize 而進(jìn)行 flush，導(dǎo)致 flush 下來(lái)的文件 Size 偏小

HFile 因?yàn)?balance 等原因?qū)е卤镜鼗实?，也?huì)導(dǎo)致 compaciton 產(chǎn)生更多的網(wǎng)卡開(kāi)銷(xiāo)

預(yù)分區(qū)數(shù)目過(guò)多，導(dǎo)致全局 memstore 水位高，memstore 沒(méi)辦法到達(dá) flushsize 進(jìn)行 flush，從而全局都 flush 出比較小的文件

等等

有了這個(gè)量化分析后，我們能做什么優(yōu)化呢？ 這里不深入展開(kāi)，簡(jiǎn)單說(shuō)幾點(diǎn)已經(jīng)在有贊生產(chǎn)環(huán)境得到驗(yàn)證具有實(shí)效的優(yōu)化點(diǎn)：

業(yè)務(wù)接入初期，協(xié)助業(yè)務(wù)做 Rowkey 的設(shè)計(jì)，避免寫(xiě)入熱點(diǎn)

增加 hbase.hstore.compaction.min，增加每次 Compaction參加的文件數(shù)，相當(dāng)于減少了每條數(shù)據(jù)整個(gè)生命周期經(jīng)歷過(guò)的 Compaction 次數(shù)

根據(jù)業(yè)務(wù)穩(wěn)態(tài)的規(guī)模，做好預(yù)分區(qū)，盡量減少 Split 造成的額外開(kāi)銷(xiāo)

對(duì)于讀 RT 不敏感的業(yè)務(wù)，可以設(shè)置 hbase.hstore.compaction.max.size 為 4g，盡可能減少過(guò)大的文件做 Compaction，因?yàn)榇笪募?compaction 的 ROI 實(shí)在太低

對(duì)于沒(méi)有多版本并且有 TTL 的數(shù)據(jù)，可以關(guān)閉系統(tǒng)的 MajorCompaction 周期，數(shù)據(jù)過(guò)期采用文件整體過(guò)期的方式，消除 MajorCompaction 的系統(tǒng)開(kāi)銷(xiāo)

對(duì)于吞吐大的場(chǎng)景，用戶(hù)在寫(xiě)入數(shù)據(jù)的時(shí)候就對(duì)數(shù)據(jù)做壓縮，減小寫(xiě)路徑造成的網(wǎng)絡(luò)開(kāi)銷(xiāo)，畢竟 WAL 是不能壓縮的（壓縮功能形同虛設(shè)）

調(diào)整 Memstore 的內(nèi)存比例，保證單機(jī)上每個(gè) Region 盡可能的分配到 Flushsize 大小的內(nèi)存，盡可能的 flush 大文件，從而減少后續(xù) Compaction 開(kāi)銷(xiāo)

到這里，HBase 的寫(xiě)吞吐場(chǎng)景的資源定量分析和優(yōu)化的介紹就算結(jié)束了，本文基于 HBase1.2.6 版本。 對(duì)很多 HBase 的細(xì)節(jié)沒(méi)有做展開(kāi)說(shuō)明，有些地方因?yàn)樽髡哒J(rèn)知有限，難免紕漏，歡迎各位同行指出。

最后打個(gè)小廣告，有贊大數(shù)據(jù)團(tuán)隊(duì)基礎(chǔ)設(shè)施團(tuán)隊(duì)，主要負(fù)責(zé)有贊的數(shù)據(jù)平臺(tái)（DP), 實(shí)時(shí)計(jì)算(Storm, Spark Streaming, Flink)，離線(xiàn)計(jì)算(HDFS,YARN,HIVE, SPARK SQL)，在線(xiàn)存儲(chǔ)（HBase），實(shí)時(shí) OLAP(Druid) 等數(shù)個(gè)技術(shù)產(chǎn)品，歡迎感興趣的小伙伴聯(lián)系 [email protected]

參考文獻(xiàn)

Google BigTable

HBase 官方網(wǎng)站