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出來。
為了知道這樣查詢效能有多慢，特意做了一次效能測試，結果如下：
| span數量(個) | scan(ms) | search_es(ms) | gets(ms) | gets_parallel_batch100(ms) | gets_parallel_batch200(ms) | gets_parallel_batch300(ms) | gets_parallel_batch500(ms) |
|---|---|---|---|---|---|---|---|
| 100 | 5 | 12 | 12+10 | ||||
| 265 | 10 | 20 | 20+25 | 20+10 | 20+15 | ||
| 336 | 10 | 20 | 20+28 | 20+10 | 20+15 | ||
| 562 | 10 | 25 | 25+45 | 25+15 | 25+15 | 25+23 | |
| 1759 | 30 | 57 | 57+130 | 57+38 | 57+40 | 57+45 | 57+45 |
| 2812 | 70 | 85 | 85+210 | 85+70 | 85+70 | 85+70 | 85+70 |
| 8000 | 170 | 210 | 210+700 | 210+180 | 210+180 | 210+180 | 210+200 |
之前的設計查詢一整個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，不過要一點一點的灰度釋出才可以
搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。