1. 程式人生 > >兌吧:從自建HBase遷移到阿裏雲HBase實戰經驗

兌吧:從自建HBase遷移到阿裏雲HBase實戰經驗

2.0 系統故障 環境 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是非常優秀的。也感謝阿裏雲技術同學,幫我們解決了底層系統的運維和性能調優,保證了底層系統的穩定,使我們可以更加專註的服務業務,幫助業務發展的更快。

原文鏈接


兌吧:從自建HBase遷移到阿裏雲HBase實戰經驗