hello，大家好，我是小樓。

今天給大家分享一個關于HBase數據傾斜的排查案例，不懂調用鏈?不懂HBase?沒關系，看完包懂！

背景

最近HBase負責人反饋HBase存儲的調用鏈數據偶爾出現極其嚴重的傾斜情況，并且日常的傾斜情況也比較大，講的通俗點就是出現了熱點機器。

舉個例子，有三臺HBase機器存儲調用鏈數據，其中大部分數據讀寫都在一臺機器上，導致機器負載特別大，經常告警，這就是HBase傾斜，也叫熱點現象。本文主要講述了治理傾斜情況的過程，以及踩的幾個坑。

知識鋪墊

為什么會出現HBase傾斜的情況呢?既然是調用鏈數據HBase傾斜，那么首先簡單介紹下幾個調用鏈和HBase的背景知識。

全鏈路追蹤

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

調用鏈是分布式服務化場景下，跨應用的問題排查和性能分析的工具。

說的直白點，就是可以讓你看到你的代碼邏輯在哪個地方調用了什么東西，比如在serviceA的methodA的邏輯里，依次調用了redis、mysql、serviceB等，可以看到每個調用的耗時、報錯、出入參、ip地址等信息，這就是調用鏈。

目前調用鏈有一個統一的標準，以前叫OpenTracing，現在與其他的一些標準整合進了OpenTelemetry，不過調用鏈的標準基本沒變。

調用鏈標準的最核心的概念如下，只列出了一些最核心的元素，不代表全部:

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

SpanID：一個Span的唯一標識，需要保證全局唯一。

TraceID：一條調用鏈的唯一標識，會在整個調用鏈路中傳遞。

ParentID：父 Span 的 SpanID。當存在 A -> B 這樣的調用關系時，B Span 的 ParentID 是 A Span 的 SpanID。ParentID 用來構造整個調用鏈路的樹形結構。每次發起新的請求時，都要把當前的 SpanID 作為 ParentID 傳遞給下一個 Span。

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

下面用一張圖來演示一次簡單的三個服務間的Dubbo調用來展示調用鏈的數據是如何、何時產生的，以及各Span之間是通過什么關聯起來的，用于深入理解上面的核心概念。

文字描述：外部請求調用了ServiceA.MethodA， SA.MA依次調用了SB.MB、Redis、MySQL， SB.MB調用了SC.MC， SC.MC內部只有計算邏輯。

注意：

圖里Span內容只包含了一部分，不代表全部內容。

可能不同的調用鏈系統上報存儲的方式不一樣，有的是每個Segment上報一次，有的是每個Span上報一次，圖中表示的是每個Span上報一次。

HBase

不調用鏈系統上報存儲的方式不一樣，有的是每個Segment上報一次，有的是每個Span上報一次，圖中表示的是每個Span上報一次。

網上關于HBase介紹的文章很多，這里不做詳細的介紹，只是列出來一些基本的概念用于理解。

HBase是一個可以存儲海量數據的數據庫，既然是數據庫，那么最基本的操作就是添加和查詢。

• RowKey

HBase基本的數據操作都是通過RowKey這個東西，RowKey是HBase的一個核心概念，如何設計Rowkey是使用HBase最關鍵的部分。

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

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

• Region

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

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

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

當Region的數據量到達某個閾值后，Region會自動分裂為兩個Region，避免性能降低，HBase還有一個功能是預分區，比如在新建Table后，可以在Table里預先指定256個分區，StartKey和EndKey依次是00-01、01-02一直到FE-FF(前提是你的所有的RowKey的前綴都在00-FF區間內)，預分區的好處是避免HBase最開始過多的自動分裂，因為分裂時數據是不可用的，過多的分裂會導致性能降低。

問題分析

介紹完了調用鏈和HBase的基本概念，這里介紹下我們調用鏈系統的存儲架構，以及為什么會產生傾斜問題。

首先是調用鏈TraceID的設計，格式是 service_name-xx-yy-zz，也就是應用名+時間戳+IP+隨機數。

調用鏈數據存儲有兩部分，一部分在ES，一部分在HBase，為什么不直接把原始數據存到ES里?因為ES機器比較貴，用的固態盤，為了節省成本。

ES里存儲的是索引數據，也就是一些篩選條件，例如根據appName、startTime、耗時、是否有報錯這些屬性篩選調用鏈，這些可以用來篩選調用鏈的屬性是存儲在ES里的，并且為了節省空間，除了TraceID和SpanID這兩個屬性，其他屬性的doc_value是關掉的，也就是只存了索引，沒有存數據，因為要篩選出來TraceID和SpanID，然后根據這兩個ID去HBase里取原始數據。

HBase里存儲的是HBase的原始數據，除了TraceID和SpanID，因為這兩個屬性的數據在ES里已經有了。HBase里的每條數據是一個Span，每條數據的RowKey是xx-TraceID-SpanID，最開始的兩個字符是TraceID做hash取前兩位，為什么要做個hash?因為我們TraceID的開頭是應用名，如果不加前面兩位hash值的話，根據HBase存儲數據的策略，前綴一樣的會存儲到一起，也就是同一個應用的Trace會存儲到一起，那么流量大的應用Trace會很多，這樣就會導致傾斜問題，加兩位hash值可以讓數據分散開，并且同一個TraceID的數據會存儲到一起，可以一次性Scan出來。

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

方案設計

在定位到問題后，最直接的想法就是徹底打散RowKey，也就是把SpanID的MD5當作RowKey，因為SpanID是全局唯一的，所以MD5必然是徹底打散的，不過這樣做有一個壞處，就是數據徹底打散后，要查出一整個Trace的話，就得一個Span一個Span去查，不像之前的RowKey設計可以一次性Scan出來。

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

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

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

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

踩的坑

在開發完成后，在測試環境測試無誤后就直接發了線上，由于最開始不太了解HBase的Region相關的概念，所以誤以為RowKey改成MD5后傾斜情況會直接消失，就直接發布了HBase數據寫入的服務，發布后HBase那邊立刻出現了非常嚴重的傾斜情況，導致HBase寫入超時，kafka堆積，趕緊回滾了，HBase負責人查看監控發現大部分數據寫入到了一臺機器上。

為什么會出現這種情況?測試環境為什么沒有出現這個問題?

根據上面介紹的HBase的Region相關的概念，出現這種情況的原因可能是RowKey沒有匹配到任何一個Region，所以數據寫入到了新建的Region上，也就是一臺機器上。

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

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

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

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

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

調試一波，發現了問題，這里用一個簡單的demo演示下，邏輯就是用md5加密"abc"這個字符串。

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

看到加密后的byte數組應該就可以知道了為什么一發布就嚴重熱點了，因為byte數組里面的東西根本不是正常的0-F之間的字符，雖然hbase的rowkey是只要是byte(-127~128)就行，但是現在MD5加密出的byte數組匹配不到原有的Region的StartKey和EndKey，全都寫到新建的Region里了，那么我只需要把RowKey搞成MD5的16進制字符不就可以匹配到原有的Region了么?

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

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

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

那么看下encodeHex里是怎么把md5byte數組轉成十六進制字符串的：

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

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

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

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

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

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

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

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

改進

知道原因后，把RowKey的MD5改成十六進制字符，重新發布，果然沒有出現嚴重熱點問題，監控曲線跟之前一樣，說明復用了已有的Region，日常傾斜情況需要跑一段時間才可以解決。

總結

HBase的RowKey設計是使用HBase最最重要的地方。

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

其實直接使用那個16長度的byte數組當作RowKey也可以，雖然基本不會復用已有的Region，不過要一點一點的灰度發布才可以。