[[151361]]

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

這次探討的主題是：

基于 HBase 做 Storm 實時計算指標(biāo)存儲

HBase 實時指標(biāo)存儲是我入職樂視云后對原有的實時系統(tǒng)改造的

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

HBase 存儲設(shè)計

Storm 結(jié)果如何存儲到 HBase

HBase 寫入性能優(yōu)化

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

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

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

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

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

其次，內(nèi)存是有限的，只能存當(dāng)天的。以前的數(shù)據(jù)需要轉(zhuǎn)存。

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

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

我們首先就想到了 HBase，因為 HBase 還是具有蠻強悍的寫入性功能以及優(yōu)秀的可擴展性。而事實上經(jīng)過調(diào)研，我們發(fā)現(xiàn) HBase 還是非常適合指標(biāo)查詢的，可以有效的通過列來減少 key 的數(shù)量。

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

我們現(xiàn)在上圖：

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

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

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

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

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

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

這里其實我要強調(diào)的是，到 HBase 并不是覆蓋某個 Rowkey 特定的 Cloumn 值，而是在它原有的基礎(chǔ)上，做加法。這樣做可以防止時間周期比較長的指標(biāo)，其累計值不會因為有拓撲當(dāng)?shù)袅硕鴣G失數(shù)據(jù)(其實還是會丟的，但可能損失的計數(shù)比較少而已)。

丟數(shù)據(jù)比如你 kill-9 了。

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

防止拓撲當(dāng)?shù)舨⒉皇沁@樣設(shè)計的主要原因，還有一點是計算延時了，比如某個數(shù)據(jù)片段因為某個原因，延時了十分鐘才到 Storm 實時計算集群，這個時候新得到的值還可以加回去，如果是覆蓋，數(shù)據(jù)就錯誤了。

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

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

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

但實際并發(fā)應(yīng)該是只有 40 左右的。300 個線程并沒有起到太多作用。

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

但在我們的測試中，還是比較平穩(wěn)的，整個寫入狀態(tài)。抖動不大。

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

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

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

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

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

每個JVM實例會構(gòu)建一個擁有10個線程的線程池。

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

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

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

這種方案我測試的結(jié)果是：

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

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

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

我們總結(jié)下上面的內(nèi)容：

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

HBase 表結(jié)構(gòu)設(shè)計，充分李永樂 HBase 自身的特點，有效的減少Key的數(shù)量，提高查詢效率。

Storm 寫入方案，用以保證出現(xiàn)數(shù)據(jù)延時或者 Storm 拓撲當(dāng)?shù)艉蟛粫?dǎo)致數(shù)據(jù)不可用。

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

 

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

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

第三個圓圈就是對外吐出數(shù)據(jù)了，由我們的統(tǒng)一查詢引擎對外提供支持查詢支持了。

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

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

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

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

上面就是今天分享的內(nèi)容了。

感謝大家。