熟女丰满第二区,久国产精品自产自拍

海量吞吐的實時NoSQL：HBase的七劍和雙11圣戰(zhàn)(數(shù)據(jù)脫敏版)?

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

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

系統(tǒng)層面，經(jīng)歷了從3u5.5至3u7.5.1的發(fā)展，磨礪出了七劍，為HBase系統(tǒng)的性能、穩(wěn)定性、高可用、單元化保駕護航。所謂開發(fā)團隊制造彈藥，PE團隊落地優(yōu)化。有了這些利劍和神兵，我們才能披荊斬棘所向披靡。

ExploringCompaction成為默認(rèn)選舉算法

Replication的優(yōu)化

單元化及Diamond整合

MTTR1期

限制大scan請求的資源使用

混合存儲

基于虛擬節(jié)點的跨ZK集群切庫

HBase的七劍

>>>>

七劍之莫問：

ExploringCompaction成為默認(rèn)選舉算法

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

HBase是采用LSM樹作為存儲引擎的，compaction的目的是減少文件數(shù)和刪除無用的數(shù)據(jù)，優(yōu)化讀性能，準(zhǔn)則是用最小的IO代價去減少最多的文件數(shù)。Compaction有2個原則：

所有StoreFile按照順序進行排列（此順序為：老文件在前，新文件在后。BulkLoad進來的文件總是排在HBase內(nèi)部生成的文件之前。詳細(xì)的順序排列參考Store#sortAndClone）；

參與compaction的文件必須是連續(xù)的。

先來看看默認(rèn)的選舉算法RatioBasedCompaction：

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

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

BulkLoad的場景下，會產(chǎn)生很多小文件。舉個例子，典型的會有如下的file list（ratio=1）：300MB(BulkLoad), 5MB(BulkLoad), 1GB, 23MB, 12MB, 12MB。那么默認(rèn)的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，默認(rèn)算法會選擇：20MB, 20MB, 1GB, 4MB, 3MB, 2MB, 1MB，打開8個句柄，讀1074MB、寫1074MB，減少6個文件；但是我們想要的選擇是： 4MB, 3MB, 2MB, 1MB，打開5個句柄，讀10MB、寫10MB，減少3個文件。

因此ExploringCompaction算法就非常適合我們，檢查Storefile列表的每一個子隊列，從中找出一個最優(yōu)子隊列，參與compaction：

隊列中的每一個文件符合ratio準(zhǔn)則；

1條件下?lián)碛懈嗟奈募?shù)目；

1, 2 條件下?lián)碛懈〉奈募笮　?/p>

相較于默認(rèn)的算法，Exploring更為『智能』，是七劍中的莫問。

>>>>

七劍之游龍：Replication的優(yōu)化

Replication是HBase實現(xiàn)集群內(nèi)部同步的重要組件，是業(yè)務(wù)高可用、單元化的基礎(chǔ)，2015年我們主要在優(yōu)化同步積壓和積壓影響組級別隔離兩方面做了努力。

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

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

>>>>

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

異地多活、單元化等關(guān)鍵詞充斥著2015上半年，HBase也有部分業(yè)務(wù)涉及單元化的一中心、多單元的部署架構(gòu)需求。3u7版本前的HBase只支持主主(Peer To Peer)同步備份，無法支持單元化。

實現(xiàn)單元化過程中的主要通過數(shù)據(jù)打標(biāo)的辦法解決了數(shù)據(jù)環(huán)路問題，并且開發(fā)出了一套可視化的運維控制臺。Replication的單元化功能上線后，可以支持如下圖的復(fù)雜部署，滿足單元化的需求：

并且，用戶可以選擇使用diamond的方式訪問HBase集群，利用diamond進行數(shù)據(jù)源地址推送，和單元化分流。多Peer+diamond使得HBase似七劍天瀑，轉(zhuǎn)易顛倒，意到隨成，數(shù)據(jù)做到真正的任意流轉(zhuǎn)，業(yè)務(wù)做到真正的異地多活。

>>>>

七劍之青干：MTTR一期

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

場景改進前改進后

split-log過程中過濾已flush的entry耗時18 min耗時5 min

普通RS和服務(wù)Meta的RS先后宕機，優(yōu)先恢復(fù)Meta Region耗時4 min耗時35 sec

recoverLease機制優(yōu)化由worker進行l(wèi)ease recover由master進行l(wèi)ease recover

避免HDFS故障導(dǎo)致的RS宕機HDFS故障后1分鐘內(nèi)RS abortHDFS故障后RS不abort，且可繼續(xù)提供不涉及HDFS操作的讀寫服務(wù)

Split hlog時過濾過時的edits/entry

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

宕機時優(yōu)先恢復(fù)Meta region

該優(yōu)化點針對的情況是當(dāng)有兩臺RS先后宕機，后宕機的RS上服務(wù)meta region且宕機前存在建表/刪表操作的情況下，加速meta region上線速度。優(yōu)化后，我們會在每次處理掉一個split log task之后動態(tài)獲取任務(wù)列表（之前是靜態(tài)），并且優(yōu)先處理meta region的相關(guān)的task。

recoverLease機制優(yōu)化

該優(yōu)化點主要針對split-log產(chǎn)生大量recovered.edits文件導(dǎo)致HDFS性能緩慢情況下recoverLease長期無法完成拖慢整體log split速度的問題，改進split-log過程中recoverLease的機制，加速failover。

HDFS故障導(dǎo)致的RS宕機

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

>>>>

七劍之舍神：

限制大scan請求的資源使用

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

因此我們針對性的對bigcall進行了截流，實現(xiàn)了BigCallThrottle。限制大請求的資源消耗，讓正常的請求可以獲取資源。通過sleep達到目的。中斷掉對客戶端來說已經(jīng)超時的請求，這種請求繼續(xù)運行沒有意義。中斷請求釋放資源。優(yōu)化似七劍舍神，使得服務(wù)端具有強烈的生命力。經(jīng)過優(yōu)化，消費記錄在之后的歷次大促和雙11中，系統(tǒng)非常穩(wěn)定，沒有出現(xiàn)過因大請求導(dǎo)致的服務(wù)宕機，業(yè)務(wù)抖動。

>>>>

七劍之日月：混合存儲

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

選擇SATA？高毛刺高RT，低下的IOPS能力，肯定不行。

選擇SSD？高昂的資源開銷，這個也承受不住，并且存儲空間也還是問題。

選擇混合存儲機型的SSD做二級緩存？不同的業(yè)務(wù)具有不同的命中率，無法提升命中率則一旦抖到SATA盤上還是然并卵。我們是要做一種通用的解決方案，這也不行。

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

>>>>

七劍之競星：

基于虛擬節(jié)點的跨ZK集群切庫

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

老集群業(yè)務(wù)平滑遷移，即使客戶端改造為虛擬節(jié)點的方式連接ZK，仍不能保證過程透明；

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

基于diamond的高可用架構(gòu)下，但凡diamond本身無法保障高可用的情況。

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

經(jīng)平臺同意授權(quán)轉(zhuǎn)載

來源：云棲社區(qū)

作者：中間件那珂

近期熱文（點擊標(biāo)題可閱讀全文）