《海量吞吐的實時NoSQL：HBase的七劍和雙11圣戰(數據脫敏版)》要點：
本文介紹了海量吞吐的實時NoSQL：HBase的七劍和雙11圣戰(數據脫敏版)，希望對您有用。如果有疑問，可以聯系我們。

去年淘寶雙11,作為媒體年夜屏(dataV)、消費記錄、支付寶風控、物流詳情、庫存對賬核心數據庫的集團HBase,當天穩定運行,順利完成了任務.并交出了非常漂亮的幾項數據：QPS=1993W,TPS=3656W,讀流量=56GBps,寫流量=40.6GBps,全天吞吐讀2.0PB,寫1.28PB.

由于HBase團隊的組織架構變動,使得去年雙11的備戰重責落在了幾桿稚嫩的小槍身上了,不是雙11運維、開發新人就是應屆畢業生.備戰過程的『點』,若從DB集群老核心業務整合開始算起,戰役從去年5月就打響了第一槍.備戰過程的『面』,涉及支付寶、平安部、菜鳥、天貓、淘寶技術部、共享業務事業部、航旅、阿里云等幾乎所有BU.在此我想從HBase系統層面和業務層面兩個大方向談談整個備戰過程,進行一次較為全面的總結.

系統層面,經歷了從3u5.5至3u7.5.1的發展,磨礪出了七劍,為HBase系統的性能、穩定性、高可用、單元化保駕護航.所謂開發團隊制造彈藥,PE團隊落地優化.有了這些白和神兵,我們才能披荊斬棘所向披靡.

• ExploringCompaction成為默認選舉算法

• Replication的優化

• 單位化及Diamond整合

• MTTR1期

• 限制大scan哀求的資源使用

• 混合存儲

• 基于虛擬節點的跨ZK集群切庫

HBase的七劍

七劍之莫問：

ExploringCompaction成為默認選舉算法

HBase本身有非常多的業務是以BulkLoad的方式進行離線數據寫入的,對應的在云端插件為HBaseBulkWriter,優點為對線上影響小(不占用服務端線程池),代價為丟失當地化率及帶來部分IO毛刺.3u5.5之前的版本采用的默認文件選擇策略,在BulkLoad的場景下存在缺陷,會導致compaction積壓(IO不能有效地去做文件合并),文件數無法控制,影響在線實時讀性能.3u5.5徹底完成了社區的Exploring選舉算法的引入,極大優化了該場景甚至是泛化場景下的文件compaction.

HBase是采納LSM樹作為存儲引擎的,compaction的目的是減少文件數和刪除無用的數據,優化讀性能,準則是用最小的IO代價去減少最多的文件數.Compaction有2個原則：

1. 所有StoreFile依照順序進行排列(此順序為：老文件在前,新文件在后.BulkLoad進來的文件總是排在HBase內部生成的文件之前.詳細的順序排列參考Store#sortAndClone)；

2. 參與compaction的文件必需是連續的.

先來看看默認的選舉算法RatioBasedCompaction：

從Storefile列表中,從老到新(即隊列中從頭到尾),挑選起始的那個StoreFile,挑選的依據是： 文件大小不能超過配置中的max size(默認2GB),而且文件大小不能超過后面文件的大小sum*ratio(默認為1.2倍)；

決定終止的StoreFile,一般便是列表中的最后一個文件,但是要求參與compaction的文件數不能超過配置的max files數目,默認為10個,如果超過10個了,那么終止的StoreFile為 起始位置+max files ；

BulkLoad的場景下,會發生很多小文件.舉個例子,典型的會有如下的file list(ratio=1)：300MB(BulkLoad), 5MB(BulkLoad), 1GB, 23MB, 12MB, 12MB.那么默認的ratio算法會選擇：5MB, 1GB, 23MB, 12MB, 12MB,這樣我們的IO代價大,收效甚微(打開5個文件句柄,讀1076MB,寫1076MB,減少4個文件).其實這樣的情況下,我們最想要得到的是： 23MB, 12MB, 12 MB.因為這樣是以最小的IO代價(打開4個句柄,讀47MB、寫47MB),減少2個文件.再舉個例子,flie list為：20MB(BulkLoad), 20MB(BulkLoad), 1GB, 4MB, 3MB, 2MB, 1MB,默認算法會選擇：20MB, 20MB, 1GB, 4MB, 3MB, 2MB, 1MB,打開8個句柄,讀1074MB、寫1074MB,減少6個文件；但是我們想要的選擇是： 4MB, 3MB, 2MB, 1MB,打開5個句柄,讀10MB、寫10MB,減少3個文件.

因此ExploringCompaction算法就非常適合我們,檢查Storefile列表的每一個子隊列,從中找出一個最優子隊列,介入compaction：

隊列中的每一個文件相符ratio準則；

1條件下擁有更多的文件數目 ；

1, 2 條件下擁有更小的文件年夜小.

相較于默認的算法,Exploring更為『智能』,是七劍中的莫問.

七劍之游龍：Replication的優化

Replication是HBase實現集群內部同步的重要組件,是業務高可用、單位化的基礎,2015年我們主要在優化同步積壓和積壓影響組級別隔離兩方面做了努力.

主線程shipEdits多線程化.Alimonitor是雙11需要P1級別保障的業務,它的歷史監控繪圖數據存儲在HBase,日常是有主備實時同步進行高可用保障的,主庫主要有宕機或者1分鐘以上的抖動,就會立刻執行切庫,保障系統的穩定.但是2015年年初,有一個問題困擾我們,就是alimonitor因為業務特性,存在和時間序列相關的持續熱點,這個熱點也不是很熱,大約就是其他節點的+10%.主備庫同步經常積壓,造成即使可以切庫,也會有大量監控繪圖有斷圖的現象.于是我們對Replication進行了改造,用多線程的方式,將這些數據推送(shipEdits)到備集群的多臺regionserver.即shipEdits動作,由單線程改為多線程,而hlog的read動作,仍然保持單線程.受益的業務不僅包含Alimonitor,也涉及到依賴中美同步的廣大AE和ICBU的同胞們、以及所有單元化、高可用架構用戶.似七劍游龍,攻勢兇猛,分分鐘消化同步積壓,為主備庫高可用保駕護航.

積壓影響組級別隔離.HBase早在2013年就開始了大集群運維策略,一個業務或一個BU的業務隔離出一個分組,底層HDFS可以共享IO,并且可以容易地進行資源調度.引入了Replication后有一個問題,就是GroupA的同步產生了積壓,會導致備庫所有業務的同步數據積壓.因此,我們對其進行了改造,在選擇備庫代理發出put哀求的服務器時,指定在和主庫group name一致分組下的機器中進行選擇.這樣即使GroupA的同步積壓,也不會波及其他『無辜』的業務分組了.

七劍之天瀑：單位化及diamond整合

異地多活、單元化等關鍵詞充斥著2015上半年,HBase也有部門業務涉及單元化的一中心、多單元的部署架構需求.3u7版本前的HBase只支持主主(Peer To Peer)同步備份,無法支持單元化.

實現單元化過程中的主要通過數據打標的方法解決了數據環路問題,并且開發出了一套可視化的運維控制臺.Replication的單元化功能上線后,可以支持如下圖的復雜部署,滿足單元化的需求：

并且,用戶可以選擇使用diamond的方式拜訪HBase集群,利用diamond進行數據源地址推送,和單元化分流.多Peer+diamond使得HBase似七劍天瀑,轉易顛倒,意到隨成,數據做到真正的任意流轉,業務做到真正的異地多活.

七劍之青干：MTTR一期

對于分布式數據庫,單個節點宕機(服務宕機、物理宕機)是一個可能會產生的常態.3u7版本前的HBase只要跪一臺regionserver,就會引起業務抖動近18分鐘.MTTR優化一期,主要關注的是單臺RS宕機后的恢復過程優化和改進.單臺regionserver宕機的failover過程可以參看：http://blog.csdn.net/hljlzc2007/article/details/10963425.拿集團TT這樣體量的業務來說,MTTR一期優化后,單臺物理宕機恢復時間縮短至了7分鐘.整個MTTR似七劍青干,象征“防守&迅捷”,快速恢復.其中,我們主要做了以下四項優化(數據只是測試數據)：

Split hlog時過濾過時的edits/entry

該優化點主要是在split-log過程中生成recovered.edits時skip掉已經flush的entry,從而加速整個split過程.線上環境通常配置HBase.regionserver.maxlogs為96,也便是說hlog總大小為96*256MB,而Memstore總大小通常不超過10GB,從這個角度看該特性應該可以在split-log時過濾掉一半以上數據.

宕機時優先規復Meta region

該優化點針對的情況是當有兩臺RS先后宕機,后宕機的RS上服務meta region且宕機前存在建表/刪表操作的情況下,加速meta region上線速度.優化后,我們會在每次處理掉一個split log task之后動態獲取任務列表(之前是靜態),而且優先處理meta region的相關的task.

recoverLease機制優化

該優化點主要針對split-log發生大量recovered.edits文件導致HDFS性能緩慢情況下recoverLease長期無法完成拖慢整體log split速度的問題,改進split-log過程中recoverLease的機制,加速failover.

HDFS故障導致的RS宕機

3u7之前,當HDFS出現問題時(例如網絡問題,進入safemode,或者整個hdfs集群宕機等),RegionServer會很快檢測到(flush/hlog_roll都會觸發對filesystem的檢查)并abort,這樣帶來的最大問題是HDFS恢復后會有大量的split-log發生,導致非常長的恢復時間.實際上,當HDFS出現問題時,可以捕捉相關異常,并死等HDFS恢復,在此期間讀寫仍可進行直至觸發HDFS操作.同時由于不觸發server abort,不會導致split-log,因此可大大縮短恢復時間.實測效果顯示,HDFS故障1小時后恢復仍然可以保證HBase恢復并保證數據一致性,這大大降低了HDFS故障的影響,并在最差情況下可以通過重啟HDFS來辦理故障,而不用擔心split-log及恢復時間過長的問題.

七劍之舍神：

限制大scan哀求的資源使用

2015年,支付寶消費記錄去了MySQL,把所有實時查詢都搬上了HBase,是歷史以來責任最重的雙11,試想當你們支付寶支付完成之后,看不到消費轉賬記錄是何等的心情.但是,在年初的時候,消費記錄的HBase集群,會經常遇到單臺regionserver handler(線程池)打爆,LOAD飆高至不可接受導致服務宕機的問題.消費記錄是一個從MYSQL遷移過來的應用,查詢場景包含了大量scan+filter,并且skip的kv異常多,查詢范圍廣.但凡有跨N多datablock的查詢,服務端總會把資源消耗在這種大查詢之上,導致阻塞后續的查詢.大哀求(bigcall)的定義：對系統資源消耗特別大的哀求,典型的例子就是帶有filter的scan,這個filter過濾掉了大量的數據,導致一個next操作會訪問成百上千個block.當block大部分都在內存時,這種scan就會消耗大量資源.當多個大哀求并發訪問服務器時,會造成load飆高,吞吐量下降.在實際的問題中,大哀求可能幾個小時都執行不完.

因此我們針對性的對bigcall進行了截流,實現了BigCallThrottle.限制大哀求的資源消耗,讓正常的哀求可以獲取資源.通過sleep達到目的.中斷掉對客戶端來說已經超時的哀求,這種哀求繼續運行沒有意義.中斷哀求釋放資源.優化似七劍舍神,使得服務端具有強烈的生命力.經過優化,消費記錄在之后的歷次大促和雙11中,系統非常穩定,沒有出現過因大哀求導致的服務宕機,業務抖動.

七劍之日月：混合存儲

混合存儲是2015年強推的一個大優化,似七劍日月,是最耀眼的優化.隨著集團HBase承接業務范圍的擴大,越來越多實時性要求高(99.9% 200ms內)、數據海量(往往跨越幾十TB)的業務在硬件選擇上遇到了難題：

選擇SATA?高毛刺高RT,低下的IOPS才能,肯定不行.

選擇SSD?昂揚的資源開銷,這個也承受不住,并且存儲空間也還是問題.

選擇混合存儲機型的SSD做二級緩存?不同的業務具有不同的命中率,無法提升命中率則一旦抖到SATA盤上還是然并卵.我們是要做一種通用的辦理方案,這也不行.

在尋求硬件開銷&性能&存儲空間的tradeoff中,我們想到了真正的混合存儲：12個硬盤slot中有3個是SSD,別的9個是SATA.數據寫入的時候,可以指定寫入1份SSD還是3份,抑或不寫,讀取的時候可以選擇是否優先走SSD讀.這個功能一上線,太多太多的業務都爭先恐后上去,目前集團+支付寶已經有30%的機器被替換成了混合存儲,在預算持平的情況下,讀RT從99% 200ms優化至99.9% 200ms,用戶體驗上升.

七劍之競星：

基于虛擬節點的跨ZK集群切庫

3u7.1之前的HBase客戶端只能進行同ZK集群下基于虛擬節點的切庫.但是有幾個問題需要辦理：

1. 老集群業務平滑遷移,即使客戶端改造為虛擬節點的方式連接ZK,仍不克不及保證過程透明；

2. 單元沒有提供2:2:1部署ZK集群條件的,必需進行跨ZK集群多單元部署的情況；

3. 基于diamond的高可用架構下,但凡diamond自己無法保障高可用的情況.

基于以上三種場景,我們需要基于虛擬節點的跨ZK集群切庫這一功能.這在正如衣服內短小的競星劍,非需要時刻不出手,出手時迅雷不及掩耳.

經平臺批準授權轉載

歡迎參與《海量吞吐的實時NoSQL：HBase的七劍和雙11圣戰(數據脫敏版)》討論，分享您的想法，維易PHP學院為您提供專業教程。

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/10124.html