Hbase是從hadoop中分離出來的apache頂級開源項目。因為它用java實現了google的bigtable系統的大部分功能，所以在數據快速增加的今天非常受歡迎。對於淘寶來說，隨著市場規模的擴大，產品和技術的發展，業務數據量越來越大，海量數據的高效插入和讀取變得越來越重要。因為淘寶擁有或許是國內最大的單個hadoop集群(天梯)，對hadoop產品有著深刻的理解，自然希望用hbase來做這樣的海量數據讀寫服務。本文將對淘寶壹年來在線應用中hbase的使用和優化做壹個總結。
2個原因
為什麽要用hbase？
2011之前，淘寶所有的後端持久化存儲基本都是在mysql上進行的(不排除少量的Oracle/BDB/Tail/MongDB等。).mysql因為開源和良好的生態系統，有子數據庫、子表等多種解決方案，所以長期以來滿足了淘寶大量商家的需求。
但是，由於業務的多元化發展，越來越多的業務系統的要求開始發生變化。壹般來說，有以下幾種類型的變化:
a)數據量越來越多。事實上，淘寶幾乎任何與用戶相關的線上業務的數據量都在十億級別，每天的系統調用從十億到十億不等，歷史數據無法輕易刪除。這就需要壹個大規模的分布式文件系統，能夠為TB級甚至PB級的數據提供在線服務。
b)數據量快速增加，可能無法準確預測。大多數應用系統在上線後的壹段時間內都有快速上升的趨勢。所以從成本的角度來說，對系統的橫向擴展能力有很強的需求，沒有單點約束。
c)只需要簡單的kv讀數，沒有復雜的連接要求。但是對系統的並發性、吞吐量、響應延遲都有非常高的要求，希望系統能夠保持很強的壹致性。
d)通常情況下，系統寫入頻繁，尤其是大量系統依賴實時日誌分析。
e)希望快速讀取批量數據。
f)模式是靈活的，並且可以頻繁地更新列屬性或添加列。
g)希望好用，有壹個好的java接口，語義清晰。
綜合來看，我們認為hbase是更合適的選擇。首先，它的數據天然被hdfs冗余，天梯穩定運行三年，數據100%可靠，已經證明了hdfs集群的安全性和服務海量數據的能力。其次，hbase本身的數據讀寫服務並不局限於單點，服務能力可以隨著服務器的增長而線性增長，達到幾十或幾百的規模。LSM樹模式的設計使得hbase的寫性能非常好，單次寫通常可以在1-3ms內完成，並且性能不會隨著數據量的增加而下降。
區域(相當於數據庫的子表)可以在ms級動態分段和移動，保證了負載均衡。由於hbase上的數據模型是按照rowkey的順序存儲的，連續的整塊數據會作為緩存壹次性讀取，壹個好的rowkey設計可以讓批量讀取變得非常容易，甚至只需要1 io次就可以得到用戶想要的幾十條或者幾百條數據。最後，淘寶大部分工程師都是有java背景的同學，所以hbase的api對他們來說非常好用，培訓成本也比較低。
當然，也必須指出的是，大數據背景下沒有銀彈，hbase本身也有不合適的場景。比如索引只支持主索引(或者被視為主復合索引)，又比如服務是單點的，它負責的壹些數據在單機宕機後被主恢復的過程中是不會被服務的。這就要求妳在選型時需要對自己的應用系統有足夠的了解。
3應用情況
我們從2011年3月開始研究hbase如何用於線上服務。雖然之前壹個壹淘搜索已經有幾十個線下服務了。這是因為hbase早期版本的目標是海量數據中的離線服務。2009年9月0.20.0版本的發布是壹個裏程碑，在線應用正式成為hbase的目標。所以hbase引入了zookeeper作為backupmaster和regionserver的管理。版本2011 1.90.0又是壹個裏程碑。基本上我們今天看到的各大網站，比如facebook/ebay/yahoo中用於制作的hbase，都是基於這個版本(fb采用的0.89版本的結構和0.90.x版本類似)。加入了Bloomfilter等諸多屬性，性能也有了很大的提升。基於此，淘寶也選擇了0.90.x分支作為網絡版的基礎。
第壹個在線應用是數據立方體中的prom。Prom最初是基於redis構建的。由於數據量的不斷增加和需求的變化，我們用hbase對其存儲層進行了改造。準確的說，prom更適合hbase的0.92版本，因為它不僅需要高速在線讀寫，還需要count/group by等復雜的應用。但是因為當時0.92版本還不成熟，所以我們自己實現了協處理器。Prom的數據導入來自於天梯，所以我們每天晚上花半個小時把天梯的數據寫到hbase所在的hdfs，然後做壹個web層的客戶端轉發。經過壹個月的數據對比，確認redis的速度比沒有明顯下降，數據準確，可以成功上線。
第二個上線的應用是TimeTunnel，這是壹個高效、可靠、可擴展的實時數據傳輸平臺，廣泛應用於實時日誌采集、實時數據監控、廣告效果實時反饋、實時數據庫同步等領域。與prom相比，其特點是增加了在線書寫。動態數據增長對hbase上的壓縮/平衡/拆分/恢復等諸多特性提出了極大的挑戰。TT每天寫大約20TB，讀大約1.5倍那麽多。為此，我們準備了20個regionserver集群。當然，底層的hdfs是公開的，數量更大(下面會提到)。每天TT都會在hbase上為不同的服務建立不同的表，然後將數據寫入表中。即使我們把區域的大小上限設置為1GB，最大的服務也會達到上千個區域的規模，可以說每分鐘都會有好幾個拆分。在推出TT期間，我們修復了hbase中許多關於拆分的bug，並且有幾個提交到達了hbase社區。同時，我們也在我們的版本上放了壹些最新的社區補丁。與Split相關的bug應該說是hbase最大的數據丟失風險之壹，這是每壹個想使用hbase的開發者必須牢記的。由於hbase采用LSM樹模型，從架構原理上來說幾乎不存在數據丟失的可能，但在實際使用中如果不小心就有數據丟失的風險。原因後面會單獨強調。TT在預發布過程中，由於元表損壞和split中的bug導致數據丟失，所以我們還單獨編寫了壹個元表恢復工具，以保證以後不會出現類似問題(hbase-0.90.5以後的版本中已經添加了類似工具)。另外，由於我們存放TT的機房不穩定，出現過多次停機事故，甚至假死。因此，我們也開始修改壹些補丁，以改善停機恢復時間和加強監測的強度。
CTU和會員中心項目是兩個對線上要求很高的項目。在這兩個項目中，我們特別研究了hbase的慢響應。hbase響應慢現在壹般分為四種原因:網絡原因、gc問題、命中率和客戶端反序列化。我們現在對他們做了壹些解決方案(後面會介紹)來更好的控制反應慢的問題。
與臉書類似，我們也使用hbase作為實時計算項目的存儲層。目前已經推出了壹些內部實時項目，如實時頁面點擊系統、銀河實時交易推薦、直播間等，用戶都是分散在公司各處的小運營商。和facebook的puma不同，淘寶用很多方式做實時計算。比如銀河采用類似affa的actor模式處理交易數據，同時通過關聯商品表等維度表計算排名(TopN)，而實時頁面點擊系統是基於twitter開源storm開發的，通過TT在後臺獲取實時日誌數據。計算流程將中間結果和動態維度表保存到hbase。比如我們把rowkey設計成url+userid，讀取實時數據，實現uv在各個維度的實時計算。
最後，我想特別提壹下歷史交易訂單項目。這個項目其實是壹個改造項目，旨在從之前的solr+bdb方案遷移到hbase。因為與購買的頁面相關，用戶使用非常頻繁，重要性接近核心應用，對數據丟失和服務中斷零容忍。它對壓縮進行優化，以防止在服務時間內發生具有大量數據的壓縮。增加了自定義的過濾器實現分頁查詢，在rowkey上巧妙設計了應用，避免了冗余數據的傳輸和90%以上的讀取轉化為順序讀取。目前集群存儲超過百億的訂單數據和數千億的指標數據，在線故障率為0。
隨著業務的發展，我們定制的hbase集群已經應用於20多個在線應用和數百臺服務器。包括淘寶首頁的商品實時推薦、賣家廣泛使用的實時量子統計等應用，並有持續增加和接近核心應用的趨勢。
4部署、操作和監控
臉書之前透露過它的hbase架構，可以說非常不錯。比如他們把message service的hbase集群按照用戶劃分成若幹個集群，每個集群有65，438+000臺服務器，有壹個namenode，分為五個機架，每個機架有壹個zookeeper。可以說，對於數據量大的服務來說，這是壹個優秀的架構。對於淘寶來說，因為數據量遠沒有那麽大，應用也沒有那麽核心，所以我們采用的是公共hdfs和zookeeper集群的架構。每個hdfs集群盡量不要超過100個單元(這是為了盡可能限制namenode的單點問題)。在上面設置幾個hbase集群，每個集群都有壹個master和壹個backupmaster。公共hdfs的好處是可以最小化緊湊的影響，平攤硬盤的成本，因為總有對磁盤空間要求高的集群，也總有對磁盤空間要求低的集群，混合在壹起更劃算。Zookeeper集群很常見，每個hbase集群都屬於zk上不同的根節點。hbase集群的獨立性由zk的權限機制保證。zk常見的原因只是為了運維方便。
因為是線上應用，運營和監控變得更加重要。因為之前的經驗接近於零，很難招到專門的hbase運維人員。我們的開發團隊和運維團隊從壹開始就非常重視這個問題，很早就開始培養自己。下面說說我們在運營和監控方面的經驗。
我們定制的hbase功能的壹個重要部分是增加監控。Hbase本身可以發送ganglia監控數據，但是監控項目遠遠不夠，ganglia的顯示方式不夠直觀和突出。因此，壹方面，我們在代碼中有創地添加了很多監控點，比如壓縮/拆分/平衡/刷新隊列和每個階段的耗時，讀寫每個階段的響應時間，讀寫次數，區域的開/關，表級和區域級的讀寫次數。它們仍然通過socket發送給ganglia，ganglia會將它們記錄在rrd文件中。rrd文件的特點是歷史數據的準確性會越來越低，所以我們自己編寫程序從rrd中讀取相應的數據並持久化到其他地方，然後我們用js實現了壹套監控界面，重點是以趨勢圖、餅狀圖等各種方式匯總顯示我們關心的數據，可以查看任何歷史數據而不損失準確性。同時，壹些非常重要的數據，如讀寫次數、響應時間等。，將寫入數據庫實現波動報警等自定義報警。通過以上措施，保證了我們總能先於用戶發現集群問題，並及時修復。我們使用redis高效排序算法對各個區域的讀寫次數進行實時排序，可以在高負載下找到那些特定請求次數較高的區域，並將其移動到空閑的regionserver。在高峰期，我們可以對數百臺機器的數十萬個區域進行實時排序。
為了隔離應用程序的影響，我們可以在代碼級別檢查來自不同客戶端的連接，並切斷壹些客戶端的連接，從而將故障隔離在壹個應用程序內部，而不會在故障發生時將其放大。mapreduce的應用也會被控制在低峰期運行，比如我們會在白天關閉jobtracker。
另外，為了從結果上保證服務的可用性，我們還會定期運行讀寫測試、建表測試、hbck等命令。Hbck是壹個非常有用的工具，但是也是壹個繁重的工作操作，所以盡量減少hbck的調用次數，盡量不要並行運行hbck服務。0.90.4之前的Hbck會有壹些機會關閉hbase。另外，為了保證hdfs的安全性，需要定期運行fsck來檢查hdfs的狀態，比如塊的副本數量。
我們會每天跟蹤所有在線服務器的日誌，找出所有的錯誤日誌並通過郵件發給開發者，找出每個錯誤上面的問題的原因和修復方法。直到誤差減小到0。另外，如果每個hbck結果有問題，也會通過郵件發給開發者進行處理。雖然不是每壹個錯誤都會產生問題，甚至大部分錯誤只是分布式系統中的正常現象，但是了解其產生問題的原因是非常重要的。
5測試和發布
因為是未知系統，所以從壹開始就非常註重測試。測試從壹開始就分為性能測試和功能測試。性能測試主要以基準測試為主，分為很多場景，比如不同的混合讀寫比，不同的k/v大小，不同的列族，不同的命中率，是否要做預哈等等。每次運行將持續幾個小時，以獲得準確的結果。所以我們寫了壹個自動化系統，從web上選取不同的場景，後臺會自動把測試參數傳到服務器上執行。因為它測試的是分布式系統，所以客戶端也必須是分布式的。
我們判斷測試是否準確的依據是同壹個場景是否多次運行，數據和運行曲線是否達到99%以上的重合。這項工作非常繁瑣，耗費了大量的時間，但後來的事實證明它非常有意義。因為我們對它建立了100%的信任，這很重要，比如我們後期的提升哪怕只是提升2%的性能也能被準確捕捉到，再比如壹個代碼的修改在緊湊的隊列曲線上造成了壹些起伏，被我們看到了，從而發現了程序的bug，等等。
功能測試主要是接口測試和異常測試。接口測試的壹般作用並不明顯，因為hbase本身的單元測試已經涵蓋了這部分。然而，異常測試非常重要。我們大部分的bug修改都是在異常測試中發現的，這有助於我們去除生產環境中可能存在的很多不穩定因素。我們也向社區提交了十幾個相應的補丁，得到了重視和承諾。分布式系統設計的難點和復雜性在於異常處理，必須在通信的任何時候都認為系統是不可靠的。對於壹些難以重現的問題，我們會通過檢查代碼已經大致定位了問題，並在代碼層面強行拋出異常的方式來重現。事實證明這很有用。
為了方便快捷的定位問題，我們設計了壹套日誌采集處理程序，方便的從各個服務器抓取相應的日誌，並按照壹定的規則進行匯總。這對於避免浪費大量時間登錄不同的服務器來尋找bug的線索非常重要。
由於hbase社區的不斷發展，以及在線或測試環境中發現的新bug，我們需要制定壹個定期發布的模式。既要避免頻繁發布帶來的不穩定性，又要避免長期不發布導致量產版離開發版越來越遠或者隱藏的bug爆發。強制要求我們每兩周從內部主幹發布壹個版本，必須通過包括回歸測試在內的所有測試，發布後在小型集群上不間斷運行24小時。每月發布壹次，發布最新版本，現有集群按重要性順序發布，確保重要應用不受新版本潛在bug影響。事實證明，自從我們引入這個發布機制後，發布帶來的不穩定因素大大減少，網絡版也能保持不遠。
6改進和優化
臉書是壹家非常值得尊敬的公司。他們毫無保留地公布了對hbase的所有修改，並向社區開放了他們內部實際使用的版本。facebook在線應用的壹個重要特點是，他們關閉了split，以降低split帶來的風險。與facebook不同的是，淘寶的業務數據並沒有那麽龐大，而且由於應用類型豐富，我們並不要求用戶選擇強行關閉split，而是盡量修改split中可能存在的bug。到目前為止，雖然還不能說完全解決了這個問題，但是從0.90.2開始暴露出來的很多與分裂和宕機相關的bug在我們的測試環境中已經被修復到接近0，並且已經為社區提交了10的穩定性相關補丁，最重要的如下:
Mitor幫助我們回到0.90版本。所以在社區發布了從0.90.2到0.90.6五個版本的bugfix之後，0.90.6版本其實已經比較穩定了。建議生產環境可以考慮這個版本。
Split這是壹個重事務，它有壹個嚴重的問題就是會修改元表(當然它宕機的時候也有這個問題)。如果在此期間發生異常，很有可能hdfs上的元表、rs內存、主內存和文件不壹致，導致稍後重新分配區域時出錯。其中壹個錯誤是，有可能同壹個區域被兩個以上的regionserver服務，然後這個區域服務的數據可能被隨機寫入多個rs，讀取的時候會分開讀取，造成數據丟失。如果要恢復原來的狀態，就必須刪除其中壹個rs上的區域，這就導致了數據的主動刪除，從而導致數據丟失。
上面提到的響應慢的問題，歸納起來就是網絡原因，gc問題，命中率，客戶端反序列化。網絡原因壹般是網絡不穩定造成的，但也可能是tcp參數設置的問題，需要保證盡可能降低數據包延遲。比如nodelay需要設置為true等。我們通過tcpdump等壹系列工具專門定位了這些問題，證明了tcp參數確實會造成包組裝中連接緩慢。Gc應該基於應用程序的類型。壹般來說，在閱讀量比較大的應用中，新生代不能設置的太小。命中率極大地影響了響應時間。我們將嘗試將版本號設置為1，以增加緩存容量。良好的平衡性也有助於充分發揮每臺機器的命中率。為此，我們設計了壹臺臺式天平。
因為hbase服務是單點的，也就是壹臺機器宕機，這臺機器服務的數據在恢復之前是無法讀寫的。停機恢復的速度決定了我們服務的可用性。為此，進行了多項優化。首先，盡可能將zk的停機發現時間縮短到1分鐘。其次，將主服務器的恢復日誌改進為並行恢復，大大提高了主服務器恢復日誌的速度。然後，我們修改壹些openhandler中可能出現的超時異常和死鎖，刪除日誌中可能出現的open…too long等異常。修復了原hbase在10停機時可能幾分鐘甚至半小時無法重啟的問題。此外，在hdfs級別，我們縮短了socket.timeout和retry的時間，以減少datanode宕機導致的長期阻塞現象。
目前對於hbase本身讀寫水平的優化，我們還沒有做太多的工作。唯壹的補丁是區域增大時書寫性能嚴重下降。由於hbase本身的良好性能，我們通過大量的測試找到了各種應用場景下的優秀參數，並應用到生產環境中，基本滿足要求。但這是我們下壹個重要的工作。
7未來計劃
我們目前在淘寶維護基於社區0.90.x的hbase定制版。接下來除了繼續修復其bug，還會維持基於0.92.x修改的版本。之所以會這樣，是因為0.92.x和0.90.x之間的兼容性不是很好，0.92.x修改的代碼非常多，粗略統計會超過30%。0.92中有壹些我們非常看重的特性。
版本0.92將hfile改進為hfilev2，v2的特點是對索引和bloomfilter進行了很大的改造，以支持單個大型hfile文檔。當現有HFile的文件大小達到壹定程度時，索引會占用大量內存，加載文件的速度會大大降低。但是，如果HFile不增加，區域就無法擴展，導致區域數量非常大。這是我們希望盡可能避免的事情。
0.92版本改進了通信層協議，增加了通信層長度，這壹點非常重要。它允許我們編寫nio的客戶端，這樣反序列化將不再影響客戶端的性能。
0.92版增加了協處理器特性，支持少量希望依靠rs的應用。
還有很多其他的優化，比如改進balance算法，改進compact算法，改進scan算法，把compact改成CF級別，動態做ddl等等。
除了0.92版，0.94版和最新的trunk(0.96)也有很多好的特性，0.94是性能優化版。它做了很多革命性的工作，比如移除根表，比如HLog壓縮，在復制中支持多個從集群等等。
我們自己也有壹些優化，比如自己實現的二級索引和備份策略，會在內部版本中實現。
另外值得壹提的是，hdfs級別的優化也很重要。hadoop-1.0.0和cloudera-3u3的改進對hbase很有幫助，比如本地化讀取、校驗和的改進、datanode的keepalive設置、namenode的HA策略等。我們有壹個優秀的hdfs團隊來支持我們的hdfs工作，比如定位和修復壹些hdfs的bug，幫助提供壹些關於hdfs參數的建議，幫助實現namenode的HA。最新測試表明，3u3校驗和+本地化讀取至少可以使隨機讀取性能提高壹倍。
我們正在做的壹件有意義的事情是實時監控和調整regionserver的負載，可以將集群中負載不足的服務器動態移動到負載較高的集群中，整個過程對用戶完全透明。
總的來說，我們的策略是盡可能的和社區合作，推動hbase在整個apache生態系統和行業的發展，讓它更穩定的部署到更多的應用上，降低使用門檻和使用成本。