眼見不一定為實：調用鏈HBase傾斜修復

• 2022 年 4 月 26 日
• 筆記
• HBase, md5, 數據傾斜

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，不過要一點一點的灰度發布才可以

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