本文來(lái)自于NoSQLFan聯(lián)合作者@koven2049，他在淘寶從事Hadoop及HBase相關(guān)的應(yīng)用和優(yōu)化。對(duì)Hadoop、HBase都有深入的了解，本文就是其在工作中對(duì)HBase的應(yīng)用優(yōu)化小結(jié)，分享給大家。

原文地址：http://walkoven.com/?p=57

文章PDF下載：hbase optimization and apply summary in taobao.pdf

1 前言

hbase是從hadoop中分離出來(lái)的apache頂級(jí)開(kāi)源項(xiàng)目。由于它很好地用java實(shí)現(xiàn)了google的bigtable系統(tǒng)大部分特性，因此在數(shù)據(jù)量猛增的今天非常受到歡迎。對(duì)于淘寶而言，隨著市場(chǎng)規(guī)模的擴(kuò)大，產(chǎn)品與技術(shù)的發(fā)展，業(yè)務(wù)數(shù)據(jù)量越來(lái)越大，對(duì)海量數(shù)據(jù)的高效插入和讀取變得越來(lái)越重要。由于淘寶擁有也許是國(guó)內(nèi)最大的單一hadoop集群(云梯)，因此對(duì)hadoop系列的產(chǎn)品有比較深入的了解，也就自然希望使用hbase來(lái)做這樣一種海量數(shù)據(jù)讀寫(xiě)服務(wù)。本篇文章將對(duì)淘寶最近一年來(lái)在online應(yīng)用上使用和優(yōu)化hbase的情況做一次小結(jié)。

2 原因

為什么要使用hbase？

淘寶在2011年之前所有的后端持久化存儲(chǔ)基本上都是在mysql上進(jìn)行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由于開(kāi)源，并且生態(tài)系統(tǒng)良好，本身?yè)碛蟹謳?kù)分表等多種解決方案，因此很長(zhǎng)一段時(shí)間內(nèi)都滿足淘寶大量業(yè)務(wù)的需求。

但是由于業(yè)務(wù)的多樣化發(fā)展，有越來(lái)越多的業(yè)務(wù)系統(tǒng)的需求開(kāi)始發(fā)生了變化。一般來(lái)說(shuō)有以下幾類(lèi)變化：

• a) 數(shù)據(jù)量變得越來(lái)越多，事實(shí)上現(xiàn)在淘寶幾乎任何一個(gè)與用戶相關(guān)的在線業(yè)務(wù)的數(shù)據(jù)量都在億級(jí)別，每日系統(tǒng)調(diào)用次數(shù)從億到百億都有，且歷史數(shù)據(jù)不能輕易刪除。這需要有一個(gè)海量分布式文件系統(tǒng)，能對(duì)TB級(jí)甚至PB級(jí)別的數(shù)據(jù)提供在線服務(wù)
• b) 數(shù)據(jù)量的增長(zhǎng)很快且不一定能準(zhǔn)確預(yù)計(jì)，大多數(shù)應(yīng)用系統(tǒng)從上線起在一段時(shí)間內(nèi)數(shù)據(jù)量都呈很快的上升趨勢(shì)，因此從成本的角度考慮對(duì)系統(tǒng)水平擴(kuò)展能力有比較強(qiáng)烈的需求，且不希望存在單點(diǎn)制約
• c) 只需要簡(jiǎn)單的kv讀取，沒(méi)有復(fù)雜的join等需求。但對(duì)系統(tǒng)的并發(fā)能力以及吞吐量、響應(yīng)延時(shí)有非常高的需求，并且希望系統(tǒng)能夠保持強(qiáng)一致性
• d) 通常系統(tǒng)的寫(xiě)入非常頻繁，尤其是大量系統(tǒng)依賴(lài)于實(shí)時(shí)的日志分析
• e) 希望能夠快速讀取批量數(shù)據(jù)
• f ) schema靈活多變，可能經(jīng)常更新列屬性或新增列
• g) 希望能夠方便使用，有良好且語(yǔ)義清晰的java接口

以上需求綜合在一起，我們認(rèn)為hbase是一種比較適合的選擇。首先它的數(shù)據(jù)由hdfs天然地做了數(shù)據(jù)冗余，云梯三年的穩(wěn)定運(yùn)行，數(shù)據(jù)100%可靠己經(jīng)證明了hdfs集群的安全性，以及服務(wù)于海量數(shù)據(jù)的能力。其次hbase本身的數(shù)據(jù)讀寫(xiě)服務(wù)沒(méi)有單點(diǎn)的限制，服務(wù)能力可以隨服務(wù)器的增長(zhǎng)而線性增長(zhǎng)，達(dá)到幾十上百臺(tái)的規(guī)模。LSM-Tree模式的設(shè)計(jì)讓hbase的寫(xiě)入性能非常良好，單次寫(xiě)入通常在1-3ms內(nèi)即可響應(yīng)完成，且性能不隨數(shù)據(jù)量的增長(zhǎng)而下降。region（相當(dāng)于數(shù)據(jù)庫(kù)的分表）可以ms級(jí)動(dòng)態(tài)的切分和移動(dòng)，保證了負(fù)載均衡性。由于hbase上的數(shù)據(jù)模型是按rowkey排序存儲(chǔ)的，而讀取時(shí)會(huì)一次讀取連續(xù)的整塊數(shù)據(jù)做為cache，因此良好的rowkey設(shè)計(jì)可以讓批量讀取變得十分容易，甚至只需要１次io就能獲取幾十上百條用戶想要的數(shù)據(jù)。最后，淘寶大部分工程師是java背景的同學(xué)，因此hbase的api對(duì)于他們來(lái)說(shuō)非常容易上手，培訓(xùn)成本相對(duì)較低。

當(dāng)然也必須指出，在大數(shù)據(jù)量的背景下銀彈是不存在的，hbase本身也有不適合的場(chǎng)景。比如，索引只支持主索引（或看成主組合索引），又比如服務(wù)是單點(diǎn)的，單臺(tái)機(jī)器宕機(jī)后在master恢復(fù)它期間它所負(fù)責(zé)的部分?jǐn)?shù)據(jù)將無(wú)法服務(wù)等。這就要求在選型上需要對(duì)自己的應(yīng)用系統(tǒng)有足夠了解。

3 應(yīng)用情況

我們從2011年3月開(kāi)始研究hbase如何用于在線服務(wù)。盡管之前在一淘搜索中己經(jīng)有了幾十節(jié)點(diǎn)的離線服務(wù)。這是因?yàn)閔base早期版本的目標(biāo)就是一個(gè)海量數(shù)據(jù)中的離線服務(wù)。2009年9月發(fā)布的0.20.0版本是一個(gè)里程碑，online應(yīng)用正式成為了hbase的目標(biāo)，為此hbase引入了zookeeper來(lái)做為backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一個(gè)里程碑，基本上我們今天看到的各大網(wǎng)站，如facebook/ebay/yahoo內(nèi)所使用于生產(chǎn)的hbase都是基于這一個(gè)版本(fb所采用的0.89版本結(jié)構(gòu)與0.90.x相近)。bloomfilter等諸多屬性加入了進(jìn)來(lái)，性能也有極大提升?；诖?#xff0c;淘寶也選用了0.90.x分支作為線上版本的基礎(chǔ)。

第一個(gè)上線的應(yīng)用是數(shù)據(jù)魔方中的prom。prom原先是基于redis構(gòu)建的，因?yàn)閿?shù)據(jù)量持續(xù)增大以及需求的變化，因此我們用hbase重構(gòu)了它的存儲(chǔ)層。準(zhǔn)確的說(shuō)prom更適合0.92版本的hbase，因?yàn)樗粌H需要高速的在線讀寫(xiě)，更需要count/group by等復(fù)雜應(yīng)用。但由于當(dāng)時(shí)0.92版本尚未成熟，因此我們自己?jiǎn)为?dú)實(shí)現(xiàn)了coprocessor。prom的數(shù)據(jù)導(dǎo)入是來(lái)源于云梯，因此我們每天晚上花半個(gè)小時(shí)將數(shù)據(jù)從云梯上寫(xiě)入hbase所在的hdfs，然后在web層做了一個(gè)client轉(zhuǎn)發(fā)。經(jīng)過(guò)一個(gè)月的數(shù)據(jù)比對(duì)，確認(rèn)了速度比之redis并未有明顯下降，以及數(shù)據(jù)的準(zhǔn)確性，因此得以順利上線。

第二個(gè)上線的應(yīng)用是TimeTunnel，TimeTunnel是一個(gè)高效的、可靠的、可擴(kuò)展的實(shí)時(shí)數(shù)據(jù)傳輸平臺(tái)，廣泛應(yīng)用于實(shí)時(shí)日志收集、數(shù)據(jù)實(shí)時(shí)監(jiān)控、廣告效果實(shí)時(shí)反饋、數(shù)據(jù)庫(kù)實(shí)時(shí)同步等領(lǐng)域。它與prom相比的特點(diǎn)是增加了在線寫(xiě)。動(dòng)態(tài)的數(shù)據(jù)增加使hbase上compact/balance/split/recovery等諸多特性受到了極大的挑戰(zhàn)。TT的寫(xiě)入量大約一天20TB，讀的量約為此的1.5倍，我們?yōu)榇藴?zhǔn)備了20臺(tái)regionserver的集群，當(dāng)然底層的hdfs是公用的，數(shù)量更為龐大（下文會(huì)提到）。每天TT會(huì)為不同的業(yè)務(wù)在hbase上建不同的表，然后往該表上寫(xiě)入數(shù)據(jù)，即使我們將region的大小上限設(shè)為1GB，最大的幾個(gè)業(yè)務(wù)也會(huì)達(dá)到數(shù)千個(gè)region這樣的規(guī)模，可以說(shuō)每一分鐘都會(huì)有數(shù)次split。在TT的上線過(guò)程中，我們修復(fù)了hbase很多關(guān)于split方面的bug，有好幾個(gè)commit到了hbase社區(qū)，同時(shí)也將社區(qū)一些最新的patch打在了我們的版本上。split相關(guān)的bug應(yīng)該說(shuō)是hbase中會(huì)導(dǎo)致數(shù)據(jù)丟失最大的風(fēng)險(xiǎn)之一，這一點(diǎn)對(duì)于每個(gè)想使用hbase的開(kāi)發(fā)者來(lái)說(shuō)必須牢記。hbase由于采用了LSM-Tree模型，從架構(gòu)原理上來(lái)說(shuō)數(shù)據(jù)幾乎沒(méi)有丟失的可能，但是在實(shí)際使用中不小心謹(jǐn)慎就有丟失風(fēng)險(xiǎn)。原因后面會(huì)單獨(dú)強(qiáng)調(diào)。TT在預(yù)發(fā)過(guò)程中我們分別因?yàn)镸eta表?yè)p壞以及split方面的bug曾經(jīng)丟失過(guò)數(shù)據(jù)，因此也單獨(dú)寫(xiě)了meta表恢復(fù)工具，確保今后不發(fā)生類(lèi)似問(wèn)題(hbase-0.90.5以后的版本都增加了類(lèi)似工具)。另外，由于我們存放TT的機(jī)房并不穩(wěn)定，發(fā)生過(guò)很多次宕機(jī)事故，甚至發(fā)生過(guò)假死現(xiàn)象。因此我們也著手修改了一些patch，以提高宕機(jī)恢復(fù)時(shí)間，以及增強(qiáng)了監(jiān)控的強(qiáng)度。

CTU以及會(huì)員中心項(xiàng)目是兩個(gè)對(duì)在線要求比較高的項(xiàng)目，在這兩個(gè)項(xiàng)目中我們特別對(duì)hbase的慢響應(yīng)問(wèn)題進(jìn)行了研究。hbase的慢響應(yīng)現(xiàn)在一般歸納為四類(lèi)原因：網(wǎng)絡(luò)原因、gc問(wèn)題、命中率以及client的反序列化問(wèn)題。我們現(xiàn)在對(duì)它們做了一些解決方案(后面會(huì)有介紹)，以更好地對(duì)慢響應(yīng)有控制力。

和Facebook類(lèi)似，我們也使用了hbase做為實(shí)時(shí)計(jì)算類(lèi)項(xiàng)目的存儲(chǔ)層。目前對(duì)內(nèi)部己經(jīng)上線了部分實(shí)時(shí)項(xiàng)目，比如實(shí)時(shí)頁(yè)面點(diǎn)擊系統(tǒng)，galaxy實(shí)時(shí)交易推薦以及直播間等內(nèi)部項(xiàng)目，用戶則是散布到公司內(nèi)各部門(mén)的運(yùn)營(yíng)小二們。與facebook的puma不同的是淘寶使用了多種方式做實(shí)時(shí)計(jì)算層，比如galaxy是使用類(lèi)似affa的actor模式處理交易數(shù)據(jù)，同時(shí)關(guān)聯(lián)商品表等維度表計(jì)算排行(TopN)，而實(shí)時(shí)頁(yè)面點(diǎn)擊系統(tǒng)則是基于twitter開(kāi)源的storm進(jìn)行開(kāi)發(fā)，后臺(tái)通過(guò)TT獲取實(shí)時(shí)的日志數(shù)據(jù)，計(jì)算流將中間結(jié)果以及動(dòng)態(tài)維表持久化到hbase上，比如我們將rowkey設(shè)計(jì)為url+userid，并讀出實(shí)時(shí)的數(shù)據(jù)，從而實(shí)現(xiàn)實(shí)時(shí)計(jì)算各個(gè)維度上的uv。

最后要特別提一下歷史交易訂單項(xiàng)目。這個(gè)項(xiàng)目實(shí)際上也是一個(gè)重構(gòu)項(xiàng)目，目的是從以前的solr+bdb的方案上遷移到hbase上來(lái)。由于它關(guān)系到己買(mǎi)到頁(yè)面，用戶使用頻率非常高，重要程度接近核心應(yīng)用，對(duì)數(shù)據(jù)丟失以及服務(wù)中斷是零容忍。它對(duì)compact做了優(yōu)化，避免大數(shù)據(jù)量的compact在服務(wù)時(shí)間內(nèi)發(fā)生。新增了定制的filter來(lái)實(shí)現(xiàn)分頁(yè)查詢(xún)，rowkey上對(duì)應(yīng)用進(jìn)行了巧妙的設(shè)計(jì)以避免了冗余數(shù)據(jù)的傳輸以及90%以上的讀轉(zhuǎn)化成了順序讀。目前該集群存儲(chǔ)了超過(guò)百億的訂單數(shù)據(jù)以及數(shù)千億的索引數(shù)據(jù)，線上故障率為0。

隨著業(yè)務(wù)的發(fā)展，目前我們定制的hbase集群己經(jīng)應(yīng)用到了線上超過(guò)二十個(gè)應(yīng)用，數(shù)百臺(tái)服務(wù)器上。包括淘寶首頁(yè)的商品實(shí)時(shí)推薦、廣泛用于賣(mài)家的實(shí)時(shí)量子統(tǒng)計(jì)等應(yīng)用，并且還有繼續(xù)增多以及向核心應(yīng)用靠近的趨勢(shì)。

4 部署、運(yùn)維和監(jiān)控

Facebook之前曾經(jīng)透露過(guò)Facebook的hbase架構(gòu)，可以說(shuō)是非常不錯(cuò)的。如他們將message服務(wù)的hbase集群按用戶分為數(shù)個(gè)集群，每個(gè)集群100臺(tái)服務(wù)器，擁有一臺(tái)namenode以及分為５個(gè)機(jī)架，每個(gè)機(jī)架上一臺(tái)zookeeper。可以說(shuō)對(duì)于大數(shù)據(jù)量的服務(wù)這是一種優(yōu)良的架構(gòu)。對(duì)于淘寶來(lái)說(shuō)，由于數(shù)據(jù)量遠(yuǎn)沒(méi)有那么大，應(yīng)用也沒(méi)有那么核心，因此我們采用公用hdfs以及zookeeper集群的架構(gòu)。每個(gè)hdfs集群盡量不超過(guò)100臺(tái)規(guī)模（這是為了盡量限制namenode單點(diǎn)問(wèn)題）。在其上架設(shè)數(shù)個(gè)hbase集群，每個(gè)集群一個(gè)master以及一個(gè)backupmaster。公用hdfs的好處是可以盡量減少compact的影響，以及均攤掉硬盤(pán)的成本，因?yàn)榭傆屑簩?duì)磁盤(pán)空間要求高，也總有集群對(duì)磁盤(pán)空間要求低，混合在一起用從成本上是比較合算的。zookeeper集群公用，每個(gè)hbase集群在zk上分屬不同的根節(jié)點(diǎn)。通過(guò)zk的權(quán)限機(jī)制來(lái)保證hbase集群的相互獨(dú)立。zk的公用原因則僅僅是為了運(yùn)維方便。

由于是在線應(yīng)用，運(yùn)維和監(jiān)控就變得更加重要，由于之前的經(jīng)驗(yàn)接近0，因此很難招到專(zhuān)門(mén)的hbase運(yùn)維人員。我們的開(kāi)發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)從一開(kāi)始就很重視該問(wèn)題，很早就開(kāi)始自行培養(yǎng)。以下講一些我們的運(yùn)維和監(jiān)控經(jīng)驗(yàn)。

我們定制的hbase很重要的一部分功能就是增加監(jiān)控。hbase本身可以發(fā)送ganglia監(jiān)控?cái)?shù)據(jù)，只是監(jiān)控項(xiàng)遠(yuǎn)遠(yuǎn)不夠，并且ganglia的展示方式并不直觀和突出。因此一方面我們?cè)诖a中侵入式地增加了很多監(jiān)控點(diǎn)，比如compact/split/balance/flush隊(duì)列以及各個(gè)階段的耗時(shí)、讀寫(xiě)各個(gè)階段的響應(yīng)時(shí)間、讀寫(xiě)次數(shù)、region的open/close，以及具體到表和region級(jí)別的讀寫(xiě)次數(shù)等等。仍然將它們通過(guò)socket的方式發(fā)送到ganglia中，ganglia會(huì)把它們記錄到rrd文件中，rrd文件的特點(diǎn)是歷史數(shù)據(jù)的精度會(huì)越來(lái)越低，因此我們自己編寫(xiě)程序從rrd中讀出相應(yīng)的數(shù)據(jù)并持久化到其它地方，然后自己用js實(shí)現(xiàn)了一套監(jiān)控界面，將我們關(guān)心的數(shù)據(jù)以趨勢(shì)圖、餅圖等各種方式重點(diǎn)匯總和顯示出來(lái)，并且可以無(wú)精度損失地查看任意歷史數(shù)據(jù)。在顯示的同時(shí)會(huì)把部分非常重要的數(shù)據(jù)，如讀寫(xiě)次數(shù)、響應(yīng)時(shí)間等寫(xiě)入數(shù)據(jù)庫(kù)，實(shí)現(xiàn)波動(dòng)報(bào)警等自定義的報(bào)警。經(jīng)過(guò)以上措施，保證了我們總是能先于用戶發(fā)現(xiàn)集群的問(wèn)題并及時(shí)修復(fù)。我們利用redis高效的排序算法實(shí)時(shí)地將每個(gè)region的讀寫(xiě)次數(shù)進(jìn)行排序，能夠在高負(fù)載的情況下找到具體請(qǐng)求次數(shù)排名較高的那些region，并把它們移到空閑的regionserver上去。在高峰期我們能對(duì)上百臺(tái)機(jī)器的數(shù)十萬(wàn)個(gè)region進(jìn)行實(shí)時(shí)排序。

為了隔離應(yīng)用的影響，我們?cè)诖a層面實(shí)現(xiàn)了可以檢查不同client過(guò)來(lái)的連接，并且切斷某些client的連接，以在發(fā)生故障時(shí)，將故障隔離在某個(gè)應(yīng)用內(nèi)部而不擴(kuò)大化。mapreduce的應(yīng)用也會(huì)控制在低峰期運(yùn)行，比如在白天我們會(huì)關(guān)閉jobtracker等。

此外，為了保障服務(wù)從結(jié)果上的可用，我們也會(huì)定期跑讀寫(xiě)測(cè)試、建表測(cè)試、hbck等命令。hbck是一個(gè)非常有用的工具，不過(guò)要注意它也是一個(gè)很重的工操作，因此盡量減少hbck的調(diào)用次數(shù)，盡量不要并行運(yùn)行hbck服務(wù)。在0.90.4以前的hbck會(huì)有一些機(jī)率使hbase宕機(jī)。另外為了確保hdfs的安全性，需要定期運(yùn)行fsck等以檢查hdfs的狀態(tài)，如block的replica數(shù)量等。
我們會(huì)每天根蹤所有線上服務(wù)器的日志，將錯(cuò)誤日志全部找出來(lái)并且郵件給開(kāi)發(fā)人員，以查明每一次error以上的問(wèn)題原因和fix。直至錯(cuò)誤降低為0。另外每一次的hbck結(jié)果如果有問(wèn)題也會(huì)郵件給開(kāi)發(fā)人員以處理掉。盡管并不是每一次error都會(huì)引發(fā)問(wèn)題，甚至大部分error都只是分布式系統(tǒng)中的正?，F(xiàn)象，但明白它們問(wèn)題的原因是非常重要的。

5 測(cè)試與發(fā)布

因?yàn)槭俏粗南到y(tǒng)，我們從一開(kāi)始就非常注重測(cè)試。測(cè)試從一開(kāi)始就分為性能測(cè)試和功能測(cè)試。性能測(cè)試主要是注意基準(zhǔn)測(cè)試，分很多場(chǎng)景，比如不同混合讀寫(xiě)比例，不同k/v大小，不同列族數(shù)，不同命中率，是否做presharding等等。每次運(yùn)行都會(huì)持續(xù)數(shù)小時(shí)以得到準(zhǔn)確的結(jié)果。因此我們寫(xiě)了一套自動(dòng)化系統(tǒng)，從web上選擇不同的場(chǎng)景，后臺(tái)會(huì)自動(dòng)將測(cè)試參數(shù)傳到各臺(tái)服務(wù)器上去執(zhí)行。由于是測(cè)試分布式系統(tǒng)，因此client也必須是分布式的。

我們判斷測(cè)試是否準(zhǔn)確的依據(jù)是同一個(gè)場(chǎng)景跑多次，是否數(shù)據(jù)，以及運(yùn)行曲線達(dá)到99%以上的重合度，這個(gè)工作非常煩瑣，以至于消耗了很多時(shí)間，但后來(lái)的事實(shí)證明它非常有意義。因?yàn)槲覀儗?duì)它建立了100%的信任，這非常重要，比如后期我們的改進(jìn)哪怕只提高2%的性能也能被準(zhǔn)確捕捉到，又比如某次代碼修改使compact隊(duì)列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。

功能測(cè)試上則主要是接口測(cè)試和異常測(cè)試。接口測(cè)試一般作用不是很明顯，因?yàn)閔base本身的單元測(cè)試己經(jīng)使這部分被覆蓋到了。但異常測(cè)試非常重要，我們絕大部分bug修改都是在異常測(cè)試中發(fā)現(xiàn)的，這幫助我們?nèi)サ袅撕芏嗌a(chǎn)環(huán)境中可能存在的不穩(wěn)定因素，我們也提交了十幾個(gè)相應(yīng)的patch到社區(qū)，并受到了重視和commit。分布式系統(tǒng)設(shè)計(jì)的難點(diǎn)和復(fù)雜度都在異常處理上，我們必須認(rèn)為系統(tǒng)在通訊的任何時(shí)候都是不可靠的。某些難以復(fù)現(xiàn)的問(wèn)題我們會(huì)通過(guò)查看代碼大體定位到問(wèn)題以后，在代碼層面強(qiáng)行拋出異常來(lái)復(fù)現(xiàn)它。事實(shí)證明這非常有用。

為了方便和快速定位問(wèn)題，我們?cè)O(shè)計(jì)了一套日志收集和處理的程序，以方便地從每臺(tái)服務(wù)器上抓取相應(yīng)的日志并按一定規(guī)律匯總。這非常重要，避免浪費(fèi)大量的時(shí)間到登錄不同的服務(wù)器以尋找一個(gè)bug的線索。

由于hbase社區(qū)在不停發(fā)展，以及線上或測(cè)試環(huán)境發(fā)現(xiàn)的新的bug，我們需要制定一套有規(guī)律的發(fā)布模式。它既要避免頻繁的發(fā)布引起的不穩(wěn)定，又要避免長(zhǎng)期不發(fā)布導(dǎo)致生產(chǎn)版本離開(kāi)發(fā)版本越來(lái)越遠(yuǎn)或是隱藏的bug爆發(fā)。我們強(qiáng)行規(guī)定每?jī)芍軓膬?nèi)部trunk上release一個(gè)版本，該版本必須通過(guò)所有的測(cè)試包括回歸測(cè)試，并且在release后在一個(gè)小型的集群上24小時(shí)不受甘擾不停地運(yùn)行。每個(gè)月會(huì)有一次發(fā)布，發(fā)布時(shí)采用最新release的版本，并且將現(xiàn)有的集群按重要性分級(jí)發(fā)布，以確保重要應(yīng)用不受新版本的潛在bug影響。事實(shí)證明自從我們引入這套發(fā)布機(jī)制后，由發(fā)布帶來(lái)的不穩(wěn)定因素大大下降了，并且線上版本也能保持不落后太多。

6 改進(jìn)和優(yōu)化

Facebook是一家非常值得尊敬的公司，他們毫無(wú)保留地對(duì)外公布了對(duì)hbase的所有改造，并且將他們內(nèi)部實(shí)際使用的版本開(kāi)源到了社區(qū)。facebook線上應(yīng)用的一個(gè)重要特點(diǎn)是他們關(guān)閉了split，以降低split帶來(lái)的風(fēng)險(xiǎn)。與facebook不同，淘寶的業(yè)務(wù)數(shù)據(jù)量相對(duì)沒(méi)有如此龐大，并且由于應(yīng)用類(lèi)型非常豐富，我們并們并沒(méi)有要求用戶強(qiáng)行選擇關(guān)閉split，而是盡量去修改split中可能存在的bug。到目前為止，雖然我們并不能說(shuō)完全解決了這個(gè)問(wèn)題，但是從0.90.2中暴露出來(lái)的諸多跟split以及宕機(jī)相關(guān)的可能引發(fā)的bug我們的測(cè)試環(huán)境上己經(jīng)被修復(fù)到接近了0，也為社區(qū)提交了10數(shù)個(gè)穩(wěn)定性相關(guān)的patch，比較重要的有以下幾個(gè)：

• https://issues.apache.org/jira/browse/HBASE-4562
• https://issues.apache.org/jira/browse/HBASE-4563
• https://issues.apache.org/jira/browse/HBASE-5152
• https://issues.apache.org/jira/browse/HBASE-5100
• https://issues.apache.org/jira/browse/HBASE-4880
• https://issues.apache.org/jira/browse/HBASE-4878
• https://issues.apache.org/jira/browse/HBASE-4899

還有其它一些，我們主要將patch提交到0.92版本，社區(qū)會(huì)有commitor幫助我們backport回0.90版本。所以社區(qū)從0.90.2一直到0.90.6一共發(fā)布了5個(gè)bugfix版本后，0.90.6版本其實(shí)己經(jīng)比較穩(wěn)定了。建議生產(chǎn)環(huán)境可以考慮這個(gè)版本。

split這是一個(gè)很重的事務(wù)，它有一個(gè)嚴(yán)重的問(wèn)題就是會(huì)修改meta表（當(dāng)然宕機(jī)恢復(fù)時(shí)也有這個(gè)問(wèn)題）。如果在此期間發(fā)生異常，很有可能meta表、rs內(nèi)存、master內(nèi)存以及hdfs上的文件會(huì)發(fā)生不一致，導(dǎo)致之后region重新分配時(shí)發(fā)生錯(cuò)誤。其中一個(gè)錯(cuò)誤就是有可能同一個(gè)region被兩個(gè)以上的regionserver所服務(wù)，那么就可能出現(xiàn)這一個(gè)region所服務(wù)的數(shù)據(jù)會(huì)隨機(jī)分別寫(xiě)到多臺(tái)rs上，讀取的時(shí)候也會(huì)分別讀取，導(dǎo)致數(shù)據(jù)丟失。想要恢復(fù)原狀，必須刪除掉其中一個(gè)rs上的region，這就導(dǎo)致了不得不主動(dòng)刪掉數(shù)據(jù)，從而引發(fā)數(shù)據(jù)丟失。

前面說(shuō)到慢響應(yīng)的問(wèn)題歸納為網(wǎng)絡(luò)原因、gc問(wèn)題、命中率以及client的反序列化問(wèn)題。網(wǎng)絡(luò)原因一般是網(wǎng)絡(luò)不穩(wěn)定引起的，不過(guò)也有可能是tcp參數(shù)設(shè)置問(wèn)題，必須保證盡量減少包的延遲，如nodelay需要設(shè)置為true等，這些問(wèn)題我們通過(guò)tcpdump等一系列工具專(zhuān)門(mén)定位過(guò)，證明tcp參數(shù)對(duì)包的組裝確實(shí)會(huì)造成慢連接。gc要根據(jù)應(yīng)用的類(lèi)型來(lái)，一般在讀比較多的應(yīng)用中新生代不能設(shè)置得太小。命中率極大影響了響應(yīng)的時(shí)間，我們會(huì)盡量將version數(shù)設(shè)為１以增加緩存的容量，良好的balance也能幫助充分應(yīng)用好每臺(tái)機(jī)器的命中率。我們?yōu)榇嗽O(shè)計(jì)了表級(jí)別的balance。

由于hbase服務(wù)是單點(diǎn)的，即宕機(jī)一臺(tái)，則該臺(tái)機(jī)器所服務(wù)的數(shù)據(jù)在恢復(fù)前是無(wú)法讀寫(xiě)的。宕機(jī)恢復(fù)速度決定了我們服務(wù)的可用率。為此主要做了幾點(diǎn)優(yōu)化。首先是將zk的宕機(jī)發(fā)現(xiàn)時(shí)間盡量縮短到1分鐘，其次改進(jìn)了master恢復(fù)日志為并行恢復(fù)，大大提高了master恢復(fù)日志的速度，然后我們修改了openhandler中可能出現(xiàn)的一些超時(shí)異常，以及死鎖，去掉了日志中可能發(fā)生的open…too long等異常。原生的hbase在宕機(jī)恢復(fù)時(shí)有可能發(fā)生10幾分鐘甚至半小時(shí)無(wú)法重啟的問(wèn)題己經(jīng)被修復(fù)掉了。另外，hdfs層面我們將socket.timeout時(shí)間以及重試時(shí)間也縮短了，以降低datanode宕機(jī)引起的長(zhǎng)時(shí)間block現(xiàn)象。

hbase本身讀寫(xiě)層面的優(yōu)化我們目前并沒(méi)有做太多的工作，唯一打的patch是region增加時(shí)寫(xiě)性能?chē)?yán)重下降的問(wèn)題。因?yàn)橛捎趆base本身良好的性能，我們通過(guò)大量測(cè)試找到了各種應(yīng)用場(chǎng)景中比較優(yōu)良的參數(shù)并應(yīng)用于生產(chǎn)環(huán)境后，都基本滿足需求。不過(guò)這是我們接下來(lái)的重要工作。

7 將來(lái)計(jì)劃

我們目前維護(hù)著淘寶內(nèi)基于社區(qū)0.90.x而定制的hbase版本。接下來(lái)除繼續(xù)fix它的bug外，會(huì)維護(hù)基于0.92.x修改的版本。之所以這樣，是因?yàn)?.92.x和0.90.x的兼容性并不是非常好，而且0.92.x修改掉的代碼非常多，粗略統(tǒng)計(jì)會(huì)超過(guò)30%。0.92中有我們非?？粗氐囊恍┨匦?。

• 0.92版本改進(jìn)了hfile為hfileV2，v2版本的特點(diǎn)是將索引以及bloomfilter進(jìn)行了大幅改造，以支持單個(gè)大hfile文件。現(xiàn)有的HFile在文件大到一定程度時(shí)，index會(huì)占用大量的內(nèi)存，并且加載文件的速度會(huì)因此下降非常多。而如果HFile不增大的話，region就無(wú)法擴(kuò)大，從而導(dǎo)致region數(shù)量非常多。這是我們想盡量避免的事。
• 0.92版本改進(jìn)了通訊層協(xié)議，在通訊層中增加了length，這非常重要，它讓我們可以寫(xiě)出nio的客戶端，使反序列化不再成為影響client性能的地方。
• 0.92版本增加了coprocessor特性，這支持了少量想要在rs上進(jìn)行count等的應(yīng)用。
• 還有其它很多優(yōu)化，比如改進(jìn)了balance算法、改進(jìn)了compact算法、改進(jìn)了scan算法、compact變?yōu)镃F級(jí)別、動(dòng)態(tài)做ddl等等特性。

除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不錯(cuò)的特性，0.94是一個(gè)性能優(yōu)化版本。它做了很多革命性工作，比如去掉root表，比如HLog進(jìn)行壓縮，replication上支持多個(gè)slave集群，等等。
我們自己也有一些優(yōu)化，比如自行實(shí)現(xiàn)的二級(jí)索引、backup策略等都會(huì)在內(nèi)部版本上實(shí)現(xiàn)。

另外值得一提的是hdfs層面的優(yōu)化也非常重要，hadoop-1.0.0以及cloudera-3u3的改進(jìn)對(duì)hbase非常有幫助，比如本地化讀、checksum的改進(jìn)、datanode的keepalive設(shè)置、namenode的HA策略等。我們有一支優(yōu)秀的hdfs團(tuán)隊(duì)來(lái)支持我們的hdfs層面工作，比如定位以及fix一些hdfs層面的bug,幫助提供一些hdfs上參數(shù)的建議，以及幫助實(shí)現(xiàn)namenode的HA等。最新的測(cè)試表明，3u3的checksum+本地化讀可以將隨機(jī)讀性能提升至少一倍。

我們正在做的一件有意義的事是實(shí)時(shí)監(jiān)控和調(diào)整regionserver的負(fù)載，能夠動(dòng)態(tài)地將負(fù)載不足的集群上的服務(wù)器挪到負(fù)載較高的集群中，而整個(gè)過(guò)程對(duì)用戶完全透明。

總的來(lái)說(shuō)，我們的策略是盡量和社區(qū)合作，以推動(dòng)hbase在整個(gè)apache生態(tài)鏈以及業(yè)界的發(fā)展，使其能更穩(wěn)定地部署到更多的應(yīng)用中去，以降低使用門(mén)檻以及使用成本。

總結(jié)

以上是生活随笔為你收集整理的HBase在淘宝的应用和优化小结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。