眼見不一定為實：呼叫鏈HBase傾斜修復

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

網上關于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，日常傾斜情況需要跑一段時間才可以解決，

總結

1. HBase的RowKey設計是使用HBase最最重要的地方
2. 注意Java的MD5加密出來的東西不一定是你想要的
3. 其實直接使用那個16長度的byte陣列當作RowKey也可以，雖然基本不會復用已有的Region，不過要一點一點的灰度發布才可以

搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、原始碼閱讀、問題排查、踩坑實踐，

標籤：Java

上一篇：Halo 開源專案學習（四）：發布文章與頁面

下一篇：R2DBC正式范訓成功，利好Spring Webflux