兌吧：從自建HBase遷移到阿里雲HBase實戰經驗

摘要： 業務介紹 兌吧集團包含兌吧網絡和推啊網絡，兌吧網絡是一家致力於幫助互聯網企業提高運營效率的用戶運營服務平臺，提供積分商城和媒體運營服務。推啊網絡是一家互動式廣告平臺，通過多年的探索與實踐，獨創了全新的移動廣告模式，實現了廣告主、媒體、用戶多方雙贏。

業務介紹

兌吧集團包含兌吧網絡和推啊網絡，兌吧網絡是一家致力於幫助互聯網企業提高運營效率的用戶運營服務平臺，提供積分商城和媒體運營服務。推啊網絡是一家互動式廣告平臺，通過多年的探索與實踐，獨創了全新的移動廣告模式，實現了廣告主、媒體、用戶多方雙贏。在推啊的廣告場景中，廣告主可得到更好的投放效果，媒體方能獲得更好的流量變現效率，受衆端具備更好的用戶體驗，目前推啊已經服務超過15000家媒體，阿里雲hbase主要服務於"推啊"的廣告業務。

"推啊"的總體業務流程以下圖：

總體產品架構

廣告平臺基礎架構完善，能有效支持業務，其中核心數據平臺爲公司全部業務提供強有力的數據支撐。其中整個數據平臺根據處理業務不一樣大體分爲3個模塊：

• 離線統計模塊：對數據進行離線統計，提供報表和相應的後臺數據分析
• 實時統計模塊：實時數據主要用來對接算法，用於統計用戶的實時行爲，好比對不一樣廣告的曝光，點擊等行爲，要求快速計算響應，因此咱們採用低延遲的流式計算
• 實時OLAP分析模塊：多維實時分析，定位是提供分鐘粒度的統計數據，主要用於任意維度和指標的統計

HBase在"推啊"使用場景

HBase在推啊主要用於流式數據統計，存儲用戶畫像的相關數據，屬於實時統計模塊中主要存儲。
實時統計時，對用戶的行爲數據根據不一樣維度不一樣指標進行統計，好比會記錄用戶在不一樣廣告上的曝光，點擊，參與等數據，也會記錄用戶的相應屬性，好比用戶對哪類廣告比較感興趣，用戶的年齡，性別，職業，愛好等特徵。這些數據所有存儲在HBase集羣中。

爲何從物理HBase遷移到阿里雲HBase

最開始咱們是物理機房自建HBase，選擇阿里雲HBase主要出於如下幾個考慮：

1. 雲HBase服務基本免運維。減輕運維和系統調優壓力，由阿里雲hbase專家團隊提供專業的運維服務。
2. HBase基礎設施重要性高。HBase做爲底層存儲系統，一旦出現系統故障，排查週期長，難度高，短期內難以解決，直接影響到線上系統的穩定性，在這方面阿里雲Hbase能提供強大的技術支撐，阿里雲有國內最強大的內核團隊，據瞭解阿里目前有3個pmc，6個committer，是中國擁有最多HBase committer的公司。
3. 雲HBase服務好。在使用Hbase上有任何疑問均可以直接諮詢阿里雲Hbase同窗，他們響應及時，服務周到，能給出專業的建議。

整個遷移實戰過程

根據咱們業務的發展，從3個階段闡述下阿里雲hbase的使用狀況以及遇到的問題

階段一：承擔數據集市做用，分解業務訪問壓力

這個階段咱們的數據中心是搭建在本身的IDC機房裏，使用CDH 的hadoop來搭建的集羣，全部的組件包括hive，JStorm，Druid等都安裝在一個集羣裏，JStorm計算時會使用hadoop自帶的HBase用來計算和統計數據，計算完成後，會將成品數據寫入到阿里雲的HBase上，業務系統會訪問阿里雲的HBase來獲取計算好的數據，這樣作的緣由主要從2個方面考慮：

• 業務系統使用的是阿里雲的ecs服務器，和IDC機房是經過專線連通的，跨公網傳輸，佔用帶寬，網絡質量沒法保證。
• 不但願業務系統直接訪問IDC機房中的HBase集羣，主要是擔憂併發高，會拉高整個集羣的負載，影響到集羣中的其它業務。
  這個階段的HBase配置是4核8G 2節點 100G 4 2 SSD，大概同步20%的業務數據給線上系統使用， 數據量大概在200G左右，查詢QPS在500左右，單條查詢平均耗時在2ms

階段二：全面遷移，雲HBase替換線下物理機HBase

這階段咱們將IDC的hadoop集羣遷移到阿里雲上，新買了阿里雲的HBase集羣用來替換原先CDH中的HBase集羣。IDC機房遷移到阿里雲主要基於如下幾點來考慮：

• IDC機房裏由於全部的組件都部署在相同服務器上，會致使資源間相互競爭，各組件運行相互影響的狀況，對組件所使用的資源進行隔離，但發現效果不理想。
• 咱們覈算了下，發如今5年內IDC自建機房的費用比用阿里雲的服務器要貴不少。
• 遷移到阿里雲後，咱們全部的系統和服務都處於同一個內網環境，網絡質量要比原先的走公網專線更有保障。

這個階段hbase的配置是8核32G 4節點 200G 4 4 SSD存儲，預估支撐20萬的qps訪問，目前大概存儲了600G數據，集羣的qps在峯值時能達到10萬左右。

階段三：優化改造，保障極致讀取時延

因爲HBase基於java虛擬機原生機制問題，業務系統在讀取HBase數據時，因爲GC會致使讀取抖動到100-200ms，對於廣告推薦系統來講，一次廣告推薦要求在200ms內完成，這樣的抖動顯然是不能接受的，諮詢過阿里雲HBase同窗後，咱們對系統進行了以下改造：

1. 業務上增長延遲控制，讀取HBase超過100ms，直接斷開，業務上走降級方式，隨機推薦廣告。
2. 業務拆分，新買一個HBase集羣，只開放給對延遲要求高的業務使用。將一些對延遲要求高的業務遷移過去，遷移後，延遲抖動從原先的千分之二，下降到萬分之六，延遲狀況獲得改善。

另外據阿里HBase的同窗介紹，阿里雲近期會推出的HBase 2.0，在架構級別作了優化，會從根本上解決因爲Java GC機制致使的延遲抖動，很是期待。

總結

整體來講，阿里雲HBase是很是優秀的。也感謝阿里雲技術同窗，幫咱們解決了底層系統的運維和性能調優，保證了底層系統的穩定，使咱們能夠更加專一的服務業務，幫助業務發展的更快。

原文連接