[[151361]]

Hi，大家好！我叫祝海林，微信號叫祝威廉，本來微博也想叫祝威廉的，可惜被人占了，于是改名叫祝威廉二世。然后總感覺哪里不對。目前在樂視云數據部門里從事實時計算，數據平臺、搜索和推薦等多個方向。曾從事基礎框架，搜索研發四年，大數據平臺架構、推薦三年多，個人時間現專注于集群自動化部署，服務管理，資源自動化調度等方向。

這次探討的主題是：

基于 HBase 做 Storm 實時計算指標存儲

HBase 實時指標存儲是我入職樂視云后對原有的實時系統改造的

一部分。部分分享內容其實還處于實施階段。架構方案設計的話應該是仁者見仁智者見智，也會有很多考慮不周的地方，歡迎大家批評指正。說不定大家聽完分享后好的提議我們會用到工程上，也為后面的實際課程做好準備。

HBase 存儲設計

Storm 結果如何存儲到 HBase

HBase 寫入性能優化

與傳統方案 (Redis/MySQL) 對比

樂視云內部用 Storm 做 CDN，點播，直播流量的計算，同時還有慢速比，卡頓比等統計指標。相應的指標會由指標名稱，業務類型，客戶，地域，ISP 等多個維度組成。指標計算一個比較大的問題是 Key 的集合很大。

舉個例子，假設我們有客戶 10w，計算指標假設 100 個，5 個 ISP，30 個地域，這樣就有億級以上的 Key 了，我們還要統計分鐘級別，小時級別，天級別，月級別。所以寫入量和存儲量都不小。

如果采用 Redis/Memcached 寫入速度是沒有問題的，畢竟完全的內存操作。但是 key 集合太大，其實壓力也蠻大的，我去的時候因為加了指標，結果導致 Memcache 被寫爆了，所以緊急做了擴容。

首先是 Redis 查起來的太麻煩。客戶端為了某個查詢，需要匯總成千上萬個 Key。。。業務方表示很蛋疼，我們也表示很蛋疼

其次，內存是有限的，只能存當天的。以前的數據需要轉存。

第三，你還是繞不過持久化存儲，于是引入 MySQL，現在是每天一張表。那 Redis 導入到 MySQL 本身就麻煩。所以工作量多了，查詢也麻煩，查一個月半年的數據就吐血了。

鑒于以上原因，我們就想著有沒有更合適的方案。

我們首先就想到了 HBase，因為 HBase 還是具有蠻強悍的寫入性功能以及優秀的可擴展性。而事實上經過調研，我們發現 HBase 還是非常適合指標查詢的，可以有效的通過列來減少 key 的數量。

舉個例子，我現在想繪制某一個視頻昨天每一分鐘的播放量的曲線圖。如果是 Redis，你很可能需要查詢 1440 個 Key。如果是 HBase，只要一條記錄就搞定。

我們現在上圖：

這里，我們一行可以追蹤某個指標一天的情況。如果加再加個維度，無非增加一條記錄。而如果是 redis，可能就多了一倍，也就是 2880 個 key 了。

假設該視頻是 A，已經在線上 100 天了。我們會記錄這個視頻所有的 1 分鐘播放數，用 Redis 可能有 100*1440 個 key，但是 HBase只要獲取 100 條記錄就可以找出來，我們把時間粒度轉化為了 hbase 的列，從而減少行 (Key)。

我們知道 HBase 是可以多列族，多 Column，Schemaless 的。所以這里，我們建了一個列族，在該列族上，直接建了 1440 個 Column。Column 的數目和時間粒度有關。如果是一分鐘粒度，會有 1440 個，如果是五分鐘粒度的會有 288 個，如果是小時粒度的，會有 24 個。不同的粒度，我們會建不同的表。

寫入的時候，我們可以定位到 rowkey，以及對應的 column，這里一般不會存在并發寫。當然 HBase 的 increment 已經解決了并發問題，但是會造成一定的性能影響。

查詢的時候，可根據天的區間查出一條相應的記錄。我們是直接把記錄都取出來，Column 只是一個 Int/Long 類型，所以 1440 個 Column 數據也不算大。

Storm 計算這一塊，還有一個比較有意思的地方。假設 A 指標是五分鐘粒度的，也就是說我們會存儲 A 指標每個五分鐘的值。但是在實際做存儲的時候，他并不是五分鐘結束后就往 HBase 里存儲，而是每隔(幾秒/或者一定條數后)就 increment 到 HBase 中，然后清除重新計數。

這里其實我要強調的是，到 HBase 并不是覆蓋某個 Rowkey 特定的 Cloumn 值，而是在它原有的基礎上，做加法。這樣做可以防止時間周期比較長的指標，其累計值不會因為有拓撲當掉了而丟失數據(其實還是會丟的，但可能損失的計數比較少而已)。

丟數據比如你 kill-9 了。

大家可以想象一下，如果我計算一個五分鐘的指標，到第三分鐘掛掉了，此時累計值是 1000，接著拓撲重啟了，五分鐘還沒完，剩下的兩分鐘它會接著累計，此時是 500。如果是覆蓋寫，就會得到不正確的結果，實際上整個完整的計數是 1500。

防止拓撲當掉并不是這樣設計的主要原因，還有一點是計算延時了，比如某個數據片段因為某個原因，延時了十分鐘才到 Storm 實時計算集群，這個時候新得到的值還可以加回去，如果是覆蓋，數據就錯誤了。

所以 HBase 存儲這塊就變成做加法操作而不僅僅是簡單的更新了。目前 HBase 添加了計數的功能 (Incrment)，但是我發現跨行，沒有批量更新的的接口。

而 HBase 的 Client 也是非常的奇特，比如 HTablePool 竟然是對象池而不是鏈接池，多個 HTable 對象是共享一個 Connection 鏈接的。當然，這里 HTable 的 Connection 會比較復雜，因為要連 Zookeeper 還有各個 Region。

又沒有批量接口，一個 Client 只能有一個 Connection 鏈接，所以導致客戶端的寫入量死活上不去。16 臺 32G，24 核的服務器，我做了預分區 (60個左右)，用了四十個進程，300 個左右的線程去寫，也就只能寫到 60000/s 而已。

但實際并發應該是只有 40 左右的。300 個線程并沒有起到太多作用。

還有就是，HBase 的 incrementColumnValue 的性能確實不高。至少和批量 Put 差距很大。

但在我們的測試中，還是比較平穩的，整個寫入狀態。抖動不大。

這里要強調一點，HBase 看場景，在我們這個場景下是預分區是非常重要的。否則一開始都集中在一臺機器的一個 Regin 上寫，估計很快寫的進程就都堵住了。上線就會掛。

所以我事先收集了幾天的 key，然后預先根據 key 的分布做了分區。我測試過，在我們的集群上，到了 60 個分區就是一個瓶頸，再加分區已經不能提升寫入量。

寫入我們也做了些優化，因為寫的線程和 Storm 是混用的(其實就是 Storm 在寫)。我們不能堵住了 Storm。

當用戶提交了N條記錄進行更新操作，我會做如下操作：

將N條分成10份，每份N/10條。

每個JVM實例會構建一個擁有10個線程的線程池。

線程池中的每個線程都會維護一個Connection（通過ThreadLocal完成）。

線程會對自己的這N/10條數據順序進行incrementColumnValue。

做這個優化的原因是我上面提到的，HTable 的連接池是共享 Connnection 的。我們這里是為了讓每個線程都有一個 Connection。具體分成多少份(我這里采用的是 10)，是需要根據 CPU 來考量的。我們的服務器 CPU 并不是很多。值不是越大越好。如果太大，比如我起了 40 個虛擬機。每個虛擬機 10 個線程，那么會有 400 個到 Zookeeper 和 HBase 的連接。值設置的過大，會對 Zookeeper 有一定的壓力。

這種方案我測試的結果是：

吞吐量上去了。在 1500w 左右的測試數據中，原有的方式大概平均只有 3w/s 左右的寫入量。 通過新的方式，大概可以提高到 5.4w/s，只要 4 分鐘左右就能完成 1500w 條數據的寫入。

峰值略微提升了一些。之前大約 6.1w/s，現在可以達到 6.6w/s。

因為我用同一集群上的 Spark 模擬的提交，所以可能會對 HBase 的寫入有一點影響，如果想要繼續提升寫入性能，只能重寫 HBase 這塊客戶端的代碼。

我們總結下上面的內容：

Redis/Mysql 存儲方案存在的一些缺點。

HBase 表結構設計，充分李永樂 HBase 自身的特點，有效的減少Key的數量，提高查詢效率。

Storm 寫入方案，用以保證出現數據延時或者 Storm 拓撲當掉后不會導致數據不可用。

我們再看看整個存儲體系完整的拓撲圖。

 

第五個圓圈是為了在實時計算出錯時，通過 Spark/MR 進行數據恢復。

第二個圓圈和第四個圓圈是為了做維度復制，比如我計算了五分鐘的值，這些值其實可以自動疊加到對應的小時和天上。我們稱為分裂程序

第三個圓圈就是對外吐出數據了，由我們的統一查詢引擎對外提供支持查詢支持了。

我們對查詢做一個推演。如果我要給用戶繪制流量的一個月曲線圖。曲線的最小粒度是小時，小時的值是取 12 個五分鐘里最高的值，我們看看需要取多少條記錄完成這個查詢。

我們需要取 31 條五分鐘的記錄，每條記錄有 288 個點，對這 288 個點分成 24 份(具體就是把分鐘去掉 groupBy 一下)，求出每份里的最大值(每組 SortBy 一下)，這樣就得到了 24 個值。

我取過兩天的，整個 HTTP 響應時間可以控制 50ms 左右（本機測試）。

上面的整體架構中，分裂程序是為了緩解實時寫入 HBase 的壓力，同時我們還利用 MR/Spark 做為恢復機制，如果實時計算產生問題，我們可以在小時內完成恢復操作，比如日志的收集程序、分揀程序、以及格式化程序。格式化程序處理完之后是 kafka，Storm 對接的是 Kafka 和 HBase。

上面就是今天分享的內容了。

感謝大家。