hello，大家好，我是小樓。

今天給大家分享一個(gè)關(guān)于HBase數(shù)據(jù)傾斜的排查案例，不懂調(diào)用鏈?不懂HBase?沒關(guān)系，看完包懂！

背景

最近HBase負(fù)責(zé)人反饋HBase存儲(chǔ)的調(diào)用鏈數(shù)據(jù)偶爾出現(xiàn)極其嚴(yán)重的傾斜情況，并且日常的傾斜情況也比較大，講的通俗點(diǎn)就是出現(xiàn)了熱點(diǎn)機(jī)器。

舉個(gè)例子，有三臺(tái)HBase機(jī)器存儲(chǔ)調(diào)用鏈數(shù)據(jù)，其中大部分?jǐn)?shù)據(jù)讀寫都在一臺(tái)機(jī)器上，導(dǎo)致機(jī)器負(fù)載特別大，經(jīng)常告警，這就是HBase傾斜，也叫熱點(diǎn)現(xiàn)象。本文主要講述了治理傾斜情況的過程，以及踩的幾個(gè)坑。

知識(shí)鋪墊

為什么會(huì)出現(xiàn)HBase傾斜的情況呢?既然是調(diào)用鏈數(shù)據(jù)HBase傾斜，那么首先簡單介紹下幾個(gè)調(diào)用鏈和HBase的背景知識(shí)。

全鏈路追蹤

全鏈路追蹤可能是一個(gè)比較統(tǒng)一的叫法，平常最多的叫法叫調(diào)用鏈，也可能有其他的叫法，不過說的都是同一個(gè)東西，本文全都用調(diào)用鏈來指代。

調(diào)用鏈?zhǔn)欠植际椒?wù)化場景下，跨應(yīng)用的問題排查和性能分析的工具。

說的直白點(diǎn)，就是可以讓你看到你的代碼邏輯在哪個(gè)地方調(diào)用了什么東西，比如在serviceA的methodA的邏輯里，依次調(diào)用了redis、mysql、serviceB等，可以看到每個(gè)調(diào)用的耗時(shí)、報(bào)錯(cuò)、出入?yún)ⅰp地址等信息，這就是調(diào)用鏈。

目前調(diào)用鏈有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)，以前叫OpenTracing，現(xiàn)在與其他的一些標(biāo)準(zhǔn)整合進(jìn)了OpenTelemetry，不過調(diào)用鏈的標(biāo)準(zhǔn)基本沒變。

調(diào)用鏈標(biāo)準(zhǔn)的最核心的概念如下，只列出了一些最核心的元素，不代表全部:

• Span：調(diào)用鏈最基本的元素就是Span，一次 Dubbo Server 請求處理，一次 HTTP 客戶端請求，乃至一次線程池異步調(diào)用都可以作為一個(gè) Span。

SpanID：一個(gè)Span的唯一標(biāo)識(shí)，需要保證全局唯一。

TraceID：一條調(diào)用鏈的唯一標(biāo)識(shí)，會(huì)在整個(gè)調(diào)用鏈路中傳遞。

ParentID：父 Span 的 SpanID。當(dāng)存在 A -> B 這樣的調(diào)用關(guān)系時(shí)，B Span 的 ParentID 是 A Span 的 SpanID。ParentID 用來構(gòu)造整個(gè)調(diào)用鏈路的樹形結(jié)構(gòu)。每次發(fā)起新的請求時(shí)，都要把當(dāng)前的 SpanID 作為 ParentID 傳遞給下一個(gè) Span。

• Segment：Segment是特殊的Span，一般表示這是一個(gè)應(yīng)用的邊界 Span。如作為 Dubbo Server 的一次請求處理;作為 HTTP Server 的一次請求處理;作為 NSQ Consumer 的一次消息處理等。
• Trace：一條調(diào)用鏈就是一條Trace，Trace是一堆Span的集合，每一個(gè)Trace理論上來說是一顆樹。

下面用一張圖來演示一次簡單的三個(gè)服務(wù)間的Dubbo調(diào)用來展示調(diào)用鏈的數(shù)據(jù)是如何、何時(shí)產(chǎn)生的，以及各Span之間是通過什么關(guān)聯(lián)起來的，用于深入理解上面的核心概念。

文字描述：外部請求調(diào)用了ServiceA.MethodA， SA.MA依次調(diào)用了SB.MB、Redis、MySQL， SB.MB調(diào)用了SC.MC， SC.MC內(nèi)部只有計(jì)算邏輯。

注意：

圖里Span內(nèi)容只包含了一部分，不代表全部內(nèi)容。

可能不同的調(diào)用鏈系統(tǒng)上報(bào)存儲(chǔ)的方式不一樣，有的是每個(gè)Segment上報(bào)一次，有的是每個(gè)Span上報(bào)一次，圖中表示的是每個(gè)Span上報(bào)一次。

HBase

不調(diào)用鏈系統(tǒng)上報(bào)存儲(chǔ)的方式不一樣，有的是每個(gè)Segment上報(bào)一次，有的是每個(gè)Span上報(bào)一次，圖中表示的是每個(gè)Span上報(bào)一次。

網(wǎng)上關(guān)于HBase介紹的文章很多，這里不做詳細(xì)的介紹，只是列出來一些基本的概念用于理解。

HBase是一個(gè)可以存儲(chǔ)海量數(shù)據(jù)的數(shù)據(jù)庫，既然是數(shù)據(jù)庫，那么最基本的操作就是添加和查詢。

• RowKey

HBase基本的數(shù)據(jù)操作都是通過RowKey這個(gè)東西，RowKey是HBase的一個(gè)核心概念，如何設(shè)計(jì)Rowkey是使用HBase最關(guān)鍵的部分。

RowKey在HBase里的作用是什么?一個(gè)是數(shù)據(jù)的操作要通過rowkey，可以把rowkey理解為mysql的主鍵，有索引的作用，另一個(gè)是用來做負(fù)載均衡。Rowkey的數(shù)據(jù)格式是字節(jié)流，也就是byte數(shù)組，這個(gè)概念很重要。

什么是byte?就是一個(gè)8位字符，值在-128到127之間，所以即使你的rowkey不是那128個(gè)ascii碼，也是可以存的，例如你的rowkey有三個(gè)字節(jié)，十進(jìn)制表示分別是-56、-110、-27，發(fā)送到HBase也是可以存儲(chǔ)的，不過你要展示出來給人看，可能就不太好展示這個(gè)RowKey了。

• Region

Region是HBase數(shù)據(jù)分片的基本單位，可以把Region理解為HBase的數(shù)據(jù)分片。

HBase是按什么來做分片的?如果你有搭建過HBase的話，并且看過HBase的web界面，可以看到Region部分有兩個(gè)屬性，Start Key和End Key。

這兩個(gè)屬性代表什么意思?舉個(gè)例子，現(xiàn)在有兩個(gè)Region，RegionA的StartKey和EndKey是00和01，RegionB的StartKey和EndKey是01和02，你要存兩條數(shù)據(jù)，RowKey分別是0000ABC和0100DEF，第一條數(shù)據(jù)就會(huì)落到RegionA里，第二條數(shù)據(jù)就會(huì)落到RegionB里，簡單來講就是根據(jù)RowKey的前綴來決定這條RowKey落到哪個(gè)Region里，如果Rowkey匹配不到任何一個(gè)Region，那么會(huì)新建一個(gè)Region存儲(chǔ)數(shù)據(jù)。

當(dāng)Region的數(shù)據(jù)量到達(dá)某個(gè)閾值后，Region會(huì)自動(dòng)分裂為兩個(gè)Region，避免性能降低，HBase還有一個(gè)功能是預(yù)分區(qū)，比如在新建Table后，可以在Table里預(yù)先指定256個(gè)分區(qū)，StartKey和EndKey依次是00-01、01-02一直到FE-FF(前提是你的所有的RowKey的前綴都在00-FF區(qū)間內(nèi))，預(yù)分區(qū)的好處是避免HBase最開始過多的自動(dòng)分裂，因?yàn)榉至褧r(shí)數(shù)據(jù)是不可用的，過多的分裂會(huì)導(dǎo)致性能降低。

問題分析

介紹完了調(diào)用鏈和HBase的基本概念，這里介紹下我們調(diào)用鏈系統(tǒng)的存儲(chǔ)架構(gòu)，以及為什么會(huì)產(chǎn)生傾斜問題。

首先是調(diào)用鏈TraceID的設(shè)計(jì)，格式是 service_name-xx-yy-zz，也就是應(yīng)用名+時(shí)間戳+IP+隨機(jī)數(shù)。

調(diào)用鏈數(shù)據(jù)存儲(chǔ)有兩部分，一部分在ES，一部分在HBase，為什么不直接把原始數(shù)據(jù)存到ES里?因?yàn)镋S機(jī)器比較貴，用的固態(tài)盤，為了節(jié)省成本。

ES里存儲(chǔ)的是索引數(shù)據(jù)，也就是一些篩選條件，例如根據(jù)appName、startTime、耗時(shí)、是否有報(bào)錯(cuò)這些屬性篩選調(diào)用鏈，這些可以用來篩選調(diào)用鏈的屬性是存儲(chǔ)在ES里的，并且為了節(jié)省空間，除了TraceID和SpanID這兩個(gè)屬性，其他屬性的doc_value是關(guān)掉的，也就是只存了索引，沒有存數(shù)據(jù)，因?yàn)橐Y選出來TraceID和SpanID，然后根據(jù)這兩個(gè)ID去HBase里取原始數(shù)據(jù)。

HBase里存儲(chǔ)的是HBase的原始數(shù)據(jù)，除了TraceID和SpanID，因?yàn)檫@兩個(gè)屬性的數(shù)據(jù)在ES里已經(jīng)有了。HBase里的每條數(shù)據(jù)是一個(gè)Span，每條數(shù)據(jù)的RowKey是xx-TraceID-SpanID，最開始的兩個(gè)字符是TraceID做hash取前兩位，為什么要做個(gè)hash?因?yàn)槲覀僒raceID的開頭是應(yīng)用名，如果不加前面兩位hash值的話，根據(jù)HBase存儲(chǔ)數(shù)據(jù)的策略，前綴一樣的會(huì)存儲(chǔ)到一起，也就是同一個(gè)應(yīng)用的Trace會(huì)存儲(chǔ)到一起，那么流量大的應(yīng)用Trace會(huì)很多，這樣就會(huì)導(dǎo)致傾斜問題，加兩位hash值可以讓數(shù)據(jù)分散開，并且同一個(gè)TraceID的數(shù)據(jù)會(huì)存儲(chǔ)到一起，可以一次性Scan出來。

既然RowKey的設(shè)計(jì)已經(jīng)考慮到了傾斜問題，已經(jīng)做了hash分散數(shù)據(jù)，那為什么日常會(huì)存在傾斜問題?而且偶爾會(huì)出現(xiàn)很嚴(yán)重的傾斜問題?原因是每個(gè)Trace的Span數(shù)量是不一樣的，有的Trace可能就幾個(gè)Span，有的Trace有幾萬個(gè)Span，還會(huì)出現(xiàn)一種極端情況，一個(gè)MQ消費(fèi)者消費(fèi)消息后又向好幾個(gè)Topic里發(fā)送了消息，后續(xù)的消費(fèi)者重復(fù)這樣的操作，導(dǎo)致一條消息最終放大了幾萬甚至幾十萬倍，導(dǎo)致一個(gè)Trace里有幾十萬甚至幾千萬個(gè)Span，這只是其中一種場景，也可能業(yè)務(wù)開發(fā)做了什么騷操作，也會(huì)導(dǎo)致一個(gè)Trace包含的Span數(shù)量非常多，那么根據(jù)現(xiàn)在的存儲(chǔ)架構(gòu)，同一個(gè)Trace的數(shù)據(jù)會(huì)存儲(chǔ)到一起，這就導(dǎo)致了傾斜問題。

方案設(shè)計(jì)

在定位到問題后，最直接的想法就是徹底打散RowKey，也就是把SpanID的MD5當(dāng)作RowKey，因?yàn)镾panID是全局唯一的，所以MD5必然是徹底打散的，不過這樣做有一個(gè)壞處，就是數(shù)據(jù)徹底打散后，要查出一整個(gè)Trace的話，就得一個(gè)Span一個(gè)Span去查，不像之前的RowKey設(shè)計(jì)可以一次性Scan出來。

為了知道這樣查詢性能有多慢，特意做了一次性能測試，結(jié)果如下：

之前的設(shè)計(jì)查詢一整個(gè)Trace的步驟就是直接用TraceID去HBase里scan，不用查詢ES，也就是第二列的耗時(shí)。

如果改成一個(gè)Span一個(gè)Span去查的話，查詢步驟變成了兩步，第一步先用TraceID從ES里查詢出這個(gè)Trace所有的SpanID，然后再根據(jù)SpanID去HBase里批量gets，表格里的后5列就是兩步查詢的耗時(shí)，加號前面是查詢ES的耗時(shí)，加號后面是HBase批量gets的耗時(shí)。第四列表示串行g(shù)ets，后四列表示并行g(shù)ets，并對不同batch的大小做了測試。

根據(jù)測試結(jié)果，串行g(shù)ets的性能要比并行g(shù)ets的性能低3-4倍，所以不考慮串行g(shù)ets。并行batch的大小對性能影響不大，并且最終耗時(shí)相比只scan的耗時(shí)也就增大一倍，例如查詢8000個(gè)Span，前后方案查詢耗時(shí)對比為170ms:390ms，實(shí)際上用戶感知不到，所以方案就定為用MD5徹底打散數(shù)據(jù)。

踩的坑

在開發(fā)完成后，在測試環(huán)境測試無誤后就直接發(fā)了線上，由于最開始不太了解HBase的Region相關(guān)的概念，所以誤以為RowKey改成MD5后傾斜情況會(huì)直接消失，就直接發(fā)布了HBase數(shù)據(jù)寫入的服務(wù)，發(fā)布后HBase那邊立刻出現(xiàn)了非常嚴(yán)重的傾斜情況，導(dǎo)致HBase寫入超時(shí)，kafka堆積，趕緊回滾了，HBase負(fù)責(zé)人查看監(jiān)控發(fā)現(xiàn)大部分?jǐn)?shù)據(jù)寫入到了一臺(tái)機(jī)器上。

為什么會(huì)出現(xiàn)這種情況?測試環(huán)境為什么沒有出現(xiàn)這個(gè)問題?

根據(jù)上面介紹的HBase的Region相關(guān)的概念，出現(xiàn)這種情況的原因可能是RowKey沒有匹配到任何一個(gè)Region，所以數(shù)據(jù)寫入到了新建的Region上，也就是一臺(tái)機(jī)器上。

但是代碼里寫的明明就是MD5，并且在測試環(huán)境測試無誤，之前的RowKey方案的前兩位hash在00-FF之間，MD5的前綴肯定也在00-FF之間啊，按理說肯定可以匹配到一個(gè)Region的，為什么還會(huì)寫到新的Region里?直接上代碼：

import org.apache.commons.codec.digest.DigestUtils;

// 用spanId的MD5值當(dāng)作RowKey，寫入到HBase里
public static byte[] rowKeyMD5(String spanId) {
    // DigestUtils只是JDK加密包的封裝，底層還是調(diào)用JDK本身的MD5加密
    return DigestUtils.md5(spanId);
}

DigestUtils是org.apache.commons.codec.digest.DigestUtils包里帶的，實(shí)際還是調(diào)用的JDK自帶的MD5庫，等同于如下的寫法。

import java.security.MessageDigest;
// MessageDigest是JDK自帶的加密包，里面有MD5加密算法
MessageDigest.getInstance("md5").digest(spanId.getBytes(StandardCharsets.UTF_8));

調(diào)試一波，發(fā)現(xiàn)了問題，這里用一個(gè)簡單的demo演示下，邏輯就是用md5加密"abc"這個(gè)字符串。

一般我們看到的加密后的MD5是16個(gè)或者32個(gè)0-F之間的字符，0-F的ASCII碼是48-57和97-102，但是加密后的byte數(shù)組有的byte是負(fù)的，那加密出來的這16個(gè)byte是什么玩意?雖然繼續(xù)看了MD5加密的源碼，但是水平不足，看不懂加密原理......

看到加密后的byte數(shù)組應(yīng)該就可以知道了為什么一發(fā)布就嚴(yán)重?zé)狳c(diǎn)了，因?yàn)閎yte數(shù)組里面的東西根本不是正常的0-F之間的字符，雖然hbase的rowkey是只要是byte(-127~128)就行，但是現(xiàn)在MD5加密出的byte數(shù)組匹配不到原有的Region的StartKey和EndKey，全都寫到新建的Region里了，那么我只需要把RowKey搞成MD5的16進(jìn)制字符不就可以匹配到原有的Region了么?

那么Java怎么MD5加密出一般我們看到的那種16進(jìn)制字符的呢?比較方便的寫法是：

import org.apache.commons.codec.binary.Hex;

Hex.encodeHex(DigestUtils.md5(str));

那么看下encodeHex里是怎么把md5byte數(shù)組轉(zhuǎn)成十六進(jìn)制字符串的：

每個(gè)byte是8位，但是每個(gè)16進(jìn)制字符，也就是0-F只需要四位bit就可以表示，所以一個(gè)byte可以表示兩個(gè)16進(jìn)制字符，也就是我們?nèi)粘懙?xFF表示一個(gè)byte，上面的邏輯就是把一個(gè)byte的前四位和后四位分開，分別表示一個(gè)16進(jìn)制字符，那么16個(gè)byte就可以拆成32個(gè)16進(jìn)制字符，這就對上了，接下來看下encodeHex的輸出：

abc經(jīng)過MD5加密后的16進(jìn)制字符串是900150983cd24fb0d6963f7d28e17f72，我們按照encodeHex的邏輯來手動(dòng)拆下byte看看對不對的上。

首先看bs[0]，也就是-112，用二進(jìn)制表示就是10010000，注意，這是個(gè)補(bǔ)碼，簡單解釋下原碼和補(bǔ)碼，計(jì)算機(jī)中的數(shù)值都是用二進(jìn)制補(bǔ)碼來存儲(chǔ)的，正數(shù)的補(bǔ)碼是它本身，也就是它的原碼，負(fù)數(shù)的補(bǔ)碼是它的原碼除了符號位取反加1，詳細(xì)的可以去看看計(jì)算機(jī)基礎(chǔ)的書籍。

那么-112的原碼就是11110000，補(bǔ)碼就是10010000，拆成兩部分也就是1001和0000，也就是9和0，跟16進(jìn)制字符串的前兩位，也就是90，對上了。

再拆下bs[1]，也就是1，用二進(jìn)制表示就是00000001，拆成兩部分也就是0000和0001，也就是0和1，跟16進(jìn)制字符串的三四位，也就是01，對上了。

再拆下bs[2]，也就是80，用二進(jìn)制表示就是01010000，拆成兩部分也就是0101和0000，也就是5和0，跟16進(jìn)制字符串的五六位，也就是50，對上了。

后面的同理，就不寫了，看到這里我們就知道了那個(gè)16長度的byte數(shù)組到底是什么玩意，就是把每兩個(gè)16進(jìn)制字符合并成了一個(gè)byte。

所以，我們經(jīng)常以為或經(jīng)常看到Java中的MD5每一位都是0-F的字符串是經(jīng)過了encodeHex處理，但RowKey實(shí)際上用的是處理之前的byte[]，它并不在0-F這個(gè)范圍。

改進(jìn)

知道原因后，把RowKey的MD5改成十六進(jìn)制字符，重新發(fā)布，果然沒有出現(xiàn)嚴(yán)重?zé)狳c(diǎn)問題，監(jiān)控曲線跟之前一樣，說明復(fù)用了已有的Region，日常傾斜情況需要跑一段時(shí)間才可以解決。

總結(jié)

HBase的RowKey設(shè)計(jì)是使用HBase最最重要的地方。

注意Java的MD5加密出來的東西不一定是你想要的。

其實(shí)直接使用那個(gè)16長度的byte數(shù)組當(dāng)作RowKey也可以，雖然基本不會(huì)復(fù)用已有的Region，不過要一點(diǎn)一點(diǎn)的灰度發(fā)布才可以。