前言
hbase是從 hadoop中分離出來的apache頂級開源項目。由於它很好地用java實現了google的bigtable系統大部分特性，因此在數據量猛增的今天非常受到歡迎。對於淘寶而言，隨着市場規模的擴大，產品與技術的發展，業務數據量越來越大，對海量數據的高效插入和讀取變得越來越重要。由於淘寶擁有也許是國內最大的單一hadoop集羣(雲梯)，因此對hadoop系列的產品有比較深入的瞭解，也就自然希望使用hbase來做這樣一種海量數據讀寫服務。本篇文章將對淘寶最近一年來在online應用上使用和優化hbase的情況做一次小結。
原因
爲什麼要使用hbase？
淘寶在2011年之前所有的後端持久化存儲基本上都是在mysql上進行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由於開源，並且生態系統良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業務的需求。
但是由於業務的多樣化發展，有越來越多的業務系統的需求開始發生了變化。一般來說有以下幾類變化：
當然也必須指出，在大數據量的背景下銀彈是不存在的，hbase本身也有不適合的場景。比如，索引只支持主索引（或看成主組合索引），又比如服務是單點的，單臺機器宕機後在master恢復它期間它所負責的部分數據將無法服務等。這就要求在選型上需要對自己的應用系統有足夠了解。
淘寶在2011年之前所有的後端持久化存儲基本上都是在mysql上進行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由於開源，並且生態系統良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業務的需求。
但是由於業務的多樣化發展，有越來越多的業務系統的需求開始發生了變化。一般來說有以下幾類變化：
- 數據量變得越來越多，事實上現在淘寶幾乎任何一個與用戶相關的在線業務的數據量都在億級別，每日系統調用次數從億到百億都有，且歷史數據不能輕易刪除。這需要有一個海量分佈式文件系統，能對TB級甚至PB級別的數據提供在線服務
- 數據量的增長很快且不一定能準確預計，大多數應用系統從上線起在一段時間內數據量都呈很快的上升趨勢，因此從成本的角度考慮對系統水平擴展能力有比較強烈的需求，且不希望存在單點制約
- 只需要簡單的kv讀取，沒有複雜的join等需求。但對系統的併發能力以及吞吐量、響應延時有非常高的需求，並且希望系統能夠保持強一致性
- 通常系統的寫入非常頻繁，尤其是大量系統依賴於實時的日誌分析
- 希望能夠快速讀取批量數據
- schema靈活多變，可能經常更新列屬性或新增列
- 希望能夠方便使用，有良好且語義清晰的java接口
當然也必須指出，在大數據量的背景下銀彈是不存在的，hbase本身也有不適合的場景。比如，索引只支持主索引（或看成主組合索引），又比如服務是單點的，單臺機器宕機後在master恢復它期間它所負責的部分數據將無法服務等。這就要求在選型上需要對自己的應用系統有足夠了解。
應用情況
我們從2011年3月開始研究hbase如何用於在線服務。儘管之前在一淘搜索中己經有了幾十節點的離線服務。這是因爲hbase早期版本的目標就是一個海量數據中的離線服務。2009年9月發佈的0.20.0版本是一個里程碑，online應用正式成爲了hbase的目標，爲此hbase引入了zookeeper來做爲backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一個里程碑，基本上我們今天看到的各大網站，如facebook/ebay/yahoo內所使用於生產的hbase都是基於這一個版本(fb所採用的0.89版本結構與0.90.x相近)。bloomfilter等諸多屬性加入了進來，性能也有極大提升。基於此，淘寶也選用了0.90.x分支作爲線上版本的基礎。
第一個上線的應用是數據魔方中的prom。prom原先是基於redis構建的，因爲數據量持續增大以及需求的變化，因此我們用hbase重構了它的存儲層。準確的說prom更適合0.92版本的hbase，因爲它不僅需要高速的在線讀寫，更需要count/group by等複雜應用。但由於當時0.92版本尚未成熟，因此我們自己單獨實現了coprocessor。prom的數據導入是來源於雲梯，因此我們每天晚上花半個小時將數據從雲梯上寫入hbase所在的hdfs，然後在web層做了一個client轉發。經過一個月的數據比對，確認了速度比之redis並未有明顯下降，以及數據的準確性，因此得以順利上線。
第二個上線的應用是TimeTunnel，TimeTunnel是一個高效的、可靠的、可擴展的實時數據傳輸平臺，廣泛應用於實時日誌收集、數據實時監控、廣告效果實時反饋、數據庫實時同步等領域。它與prom相比的特點是增加了在線寫。動態的數據增加使hbase上compact/balance/split/recovery等諸多特性受到了極大的挑戰。TT的寫入量大約一天20TB，讀的量約爲此的1.5倍，我們爲此準備了20臺regionserver的集羣，當然底層的hdfs是公用的，數量更爲龐大（下文會提到）。每天TT會爲不同的業務在hbase上建不同的表，然後往該表上寫入數據，即使我們將region的大小上限設爲1GB，最大的幾個業務也會達到數千個region這樣的規模，可以說每一分鐘都會有數次split。在TT的上線過程中，我們修復了hbase很多關於split方面的bug，有好幾個commit到了hbase社區，同時也將社區一些最新的patch打在了我們的版本上。split相關的bug應該說是hbase中會導致數據丟失最大的風險之一，這一點對於每個想使用hbase的開發者來說必須牢記。hbase由於採用了LSM-Tree模型，從架構原理上來說數據幾乎沒有丟失的可能，但是在實際使用中不小心謹慎就有丟失風險。原因後面會單獨強調。TT在預發過程中我們分別因爲Meta表損壞以及split方面的bug曾經丟失過數據，因此也單獨寫了meta表恢復工具，確保今後不發生類似問題(hbase-0.90.5以後的版本都增加了類似工具)。另外，由於我們存放TT的機房並不穩定，發生過很多次宕機事故，甚至發生過假死現象。因此我們也着手修改了一些patch，以提高宕機恢復時間，以及增強了監控的強度。
CTU以及會員中心項目是兩個對在線要求比較高的項目，在這兩個項目中我們特別對hbase的慢響應問題進行了研究。hbase的慢響應現在一般歸納爲四類原因：網絡原因、gc問題、命中率以及client的反序列化問題。我們現在對它們做了一些解決方案(後面會有介紹)，以更好地對慢響應有控制力。
和Facebook類似，我們也使用了hbase做爲實時計算類項目的存儲層。目前對內部己經上線了部分實時項目，比如實時頁面點擊系統，galaxy實時交易推薦以及直播間等內部項目，用戶則是散佈到公司內各部門的運營小二們。與facebook的puma不同的是淘寶使用了多種方式做實時計算層，比如galaxy是使用類似affa的actor模式處理交易數據，同時關聯商品表等維度表計算排行(TopN)，而實時頁面點擊系統則是基於twitter開源的storm進行開發，後臺通過TT獲取實時的日誌數據，計算流將中間結果以及動態維表持久化到hbase上，比如我們將rowkey設計爲url+userid，並讀出實時的數據，從而實現實時計算各個維度上的uv。
最後要特別提一下歷史交易訂單項目。這個項目實際上也是一個重構項目，目的是從以前的solr+bdb的方案上遷移到hbase上來。由於它關係到己買到頁面，用戶使用頻率非常高，重要程度接近核心應用，對數據丟失以及服務中斷是零容忍。它對compact做了優化，避免大數據量的compact在服務時間內發生。新增了定製的filter來實現分頁查詢，rowkey上對應用進行了巧妙的設計以避免了冗餘數據的傳輸以及90%以上的讀轉化成了順序讀。目前該集羣存儲了超過百億的訂單數據以及數千億的索引數據，線上故障率爲0。
隨着業務的發展，目前我們定製的hbase集羣己經應用到了線上超過二十個應用，數百臺服務器上。包括淘寶首頁的商品實時推薦、廣泛用於賣家的實時量子統計等應用，並且還有繼續增多以及向核心應用靠近的趨勢。
第一個上線的應用是數據魔方中的prom。prom原先是基於redis構建的，因爲數據量持續增大以及需求的變化，因此我們用hbase重構了它的存儲層。準確的說prom更適合0.92版本的hbase，因爲它不僅需要高速的在線讀寫，更需要count/group by等複雜應用。但由於當時0.92版本尚未成熟，因此我們自己單獨實現了coprocessor。prom的數據導入是來源於雲梯，因此我們每天晚上花半個小時將數據從雲梯上寫入hbase所在的hdfs，然後在web層做了一個client轉發。經過一個月的數據比對，確認了速度比之redis並未有明顯下降，以及數據的準確性，因此得以順利上線。
第二個上線的應用是TimeTunnel，TimeTunnel是一個高效的、可靠的、可擴展的實時數據傳輸平臺，廣泛應用於實時日誌收集、數據實時監控、廣告效果實時反饋、數據庫實時同步等領域。它與prom相比的特點是增加了在線寫。動態的數據增加使hbase上compact/balance/split/recovery等諸多特性受到了極大的挑戰。TT的寫入量大約一天20TB，讀的量約爲此的1.5倍，我們爲此準備了20臺regionserver的集羣，當然底層的hdfs是公用的，數量更爲龐大（下文會提到）。每天TT會爲不同的業務在hbase上建不同的表，然後往該表上寫入數據，即使我們將region的大小上限設爲1GB，最大的幾個業務也會達到數千個region這樣的規模，可以說每一分鐘都會有數次split。在TT的上線過程中，我們修復了hbase很多關於split方面的bug，有好幾個commit到了hbase社區，同時也將社區一些最新的patch打在了我們的版本上。split相關的bug應該說是hbase中會導致數據丟失最大的風險之一，這一點對於每個想使用hbase的開發者來說必須牢記。hbase由於採用了LSM-Tree模型，從架構原理上來說數據幾乎沒有丟失的可能，但是在實際使用中不小心謹慎就有丟失風險。原因後面會單獨強調。TT在預發過程中我們分別因爲Meta表損壞以及split方面的bug曾經丟失過數據，因此也單獨寫了meta表恢復工具，確保今後不發生類似問題(hbase-0.90.5以後的版本都增加了類似工具)。另外，由於我們存放TT的機房並不穩定，發生過很多次宕機事故，甚至發生過假死現象。因此我們也着手修改了一些patch，以提高宕機恢復時間，以及增強了監控的強度。
CTU以及會員中心項目是兩個對在線要求比較高的項目，在這兩個項目中我們特別對hbase的慢響應問題進行了研究。hbase的慢響應現在一般歸納爲四類原因：網絡原因、gc問題、命中率以及client的反序列化問題。我們現在對它們做了一些解決方案(後面會有介紹)，以更好地對慢響應有控制力。
和Facebook類似，我們也使用了hbase做爲實時計算類項目的存儲層。目前對內部己經上線了部分實時項目，比如實時頁面點擊系統，galaxy實時交易推薦以及直播間等內部項目，用戶則是散佈到公司內各部門的運營小二們。與facebook的puma不同的是淘寶使用了多種方式做實時計算層，比如galaxy是使用類似affa的actor模式處理交易數據，同時關聯商品表等維度表計算排行(TopN)，而實時頁面點擊系統則是基於twitter開源的storm進行開發，後臺通過TT獲取實時的日誌數據，計算流將中間結果以及動態維表持久化到hbase上，比如我們將rowkey設計爲url+userid，並讀出實時的數據，從而實現實時計算各個維度上的uv。
最後要特別提一下歷史交易訂單項目。這個項目實際上也是一個重構項目，目的是從以前的solr+bdb的方案上遷移到hbase上來。由於它關係到己買到頁面，用戶使用頻率非常高，重要程度接近核心應用，對數據丟失以及服務中斷是零容忍。它對compact做了優化，避免大數據量的compact在服務時間內發生。新增了定製的filter來實現分頁查詢，rowkey上對應用進行了巧妙的設計以避免了冗餘數據的傳輸以及90%以上的讀轉化成了順序讀。目前該集羣存儲了超過百億的訂單數據以及數千億的索引數據，線上故障率爲0。
隨着業務的發展，目前我們定製的hbase集羣己經應用到了線上超過二十個應用，數百臺服務器上。包括淘寶首頁的商品實時推薦、廣泛用於賣家的實時量子統計等應用，並且還有繼續增多以及向核心應用靠近的趨勢。
部署、運維和監控
Facebook之前曾經透露過Facebook的hbase架構，可以說是非常不錯的。如他們將message服務的hbase集羣按用戶分爲數個集羣，每個集羣100臺服務器，擁有一臺namenode以及分爲５個機架，每個機架上一臺zookeeper。可以說對於大數據量的服務這是一種優良的架構。對於淘寶來說，由於數據量遠沒有那麼大，應用也沒有那麼核心，因此我們採用公用hdfs以及zookeeper集羣的架構。每個hdfs集羣儘量不超過100臺規模（這是爲了儘量限制namenode單點問題）。在其上架設數個hbase集羣，每個集羣一個master以及一個backupmaster。公用hdfs的好處是可以儘量減少compact的影響，以及均攤掉硬盤的成本，因爲總有集羣對磁盤空間要求高，也總有集羣對磁盤空間要求低，混合在一起用從成本上是比較合算的。zookeeper集羣公用，每個hbase集羣在zk上分屬不同的根節點。通過zk的權限機制來保證hbase集羣的相互獨立。zk的公用原因則僅僅是爲了運維方便。
由於是在線應用，運維和監控就變得更加重要，由於之前的經驗接近0，因此很難招到專門的hbase運維人員。我們的開發團隊和運維團隊從一開始就很重視該問題，很早就開始自行培養。以下講一些我們的運維和監控經驗。
我們定製的hbase很重要的一部分功能就是增加監控。hbase本身可以發送ganglia監控數據，只是監控項遠遠不夠，並且ganglia的展示方式並不直觀和突出。因此一方面我們在代碼中侵入式地增加了很多監控點，比如compact/split/balance/flush隊列以及各個階段的耗時、讀寫各個階段的響應時間、讀寫次數、region的open/close，以及具體到表和region級別的讀寫次數等等。仍然將它們通過socket的方式發送到ganglia中，ganglia會把它們記錄到rrd文件中，rrd文件的特點是歷史數據的精度會越來越低，因此我們自己編寫程序從rrd中讀出相應的數據並持久化到其它地方，然後自己用js實現了一套監控界面，將我們關心的數據以趨勢圖、餅圖等各種方式重點彙總和顯示出來，並且可以無精度損失地查看任意歷史數據。在顯示的同時會把部分非常重要的數據，如讀寫次數、響應時間等寫入數據庫，實現波動報警等自定義的報警。經過以上措施，保證了我們總是能先於用戶發現集羣的問題並及時修復。我們利用redis高效的排序算法實時地將每個region的讀寫次數進行排序，能夠在高負載的情況下找到具體請求次數排名較高的那些region，並把它們移到空閒的regionserver上去。在高峯期我們能對上百臺機器的數十萬個region進行實時排序。
爲了隔離應用的影響，我們在代碼層面實現了可以檢查不同client過來的連接，並且切斷某些client的連接，以在發生故障時，將故障隔離在某個應用內部而不擴大化。mapreduce的應用也會控制在低峯期運行，比如在白天我們會關閉jobtracker等。
此外，爲了保障服務從結果上的可用，我們也會定期跑讀寫測試、建表測試、hbck等命令。hbck是一個非常有用的工具，不過要注意它也是一個很重的工操作，因此儘量減少hbck的調用次數，儘量不要並行運行hbck服務。在0.90.4以前的hbck會有一些機率使hbase宕機。另外爲了確保hdfs的安全性，需要定期運行fsck等以檢查hdfs的狀態，如block的replica數量等。
我們會每天根蹤所有線上服務器的日誌，將錯誤日誌全部找出來並且郵件給開發人員，以查明每一次error以上的問題原因和fix。直至錯誤降低爲0。另外每一次的hbck結果如果有問題也會郵件給開發人員以處理掉。儘管並不是每一次error都會引發問題，甚至大部分error都只是分佈式系統中的正常現象，但明白它們問題的原因是非常重要的。
由於是在線應用，運維和監控就變得更加重要，由於之前的經驗接近0，因此很難招到專門的hbase運維人員。我們的開發團隊和運維團隊從一開始就很重視該問題，很早就開始自行培養。以下講一些我們的運維和監控經驗。
我們定製的hbase很重要的一部分功能就是增加監控。hbase本身可以發送ganglia監控數據，只是監控項遠遠不夠，並且ganglia的展示方式並不直觀和突出。因此一方面我們在代碼中侵入式地增加了很多監控點，比如compact/split/balance/flush隊列以及各個階段的耗時、讀寫各個階段的響應時間、讀寫次數、region的open/close，以及具體到表和region級別的讀寫次數等等。仍然將它們通過socket的方式發送到ganglia中，ganglia會把它們記錄到rrd文件中，rrd文件的特點是歷史數據的精度會越來越低，因此我們自己編寫程序從rrd中讀出相應的數據並持久化到其它地方，然後自己用js實現了一套監控界面，將我們關心的數據以趨勢圖、餅圖等各種方式重點彙總和顯示出來，並且可以無精度損失地查看任意歷史數據。在顯示的同時會把部分非常重要的數據，如讀寫次數、響應時間等寫入數據庫，實現波動報警等自定義的報警。經過以上措施，保證了我們總是能先於用戶發現集羣的問題並及時修復。我們利用redis高效的排序算法實時地將每個region的讀寫次數進行排序，能夠在高負載的情況下找到具體請求次數排名較高的那些region，並把它們移到空閒的regionserver上去。在高峯期我們能對上百臺機器的數十萬個region進行實時排序。
爲了隔離應用的影響，我們在代碼層面實現了可以檢查不同client過來的連接，並且切斷某些client的連接，以在發生故障時，將故障隔離在某個應用內部而不擴大化。mapreduce的應用也會控制在低峯期運行，比如在白天我們會關閉jobtracker等。
此外，爲了保障服務從結果上的可用，我們也會定期跑讀寫測試、建表測試、hbck等命令。hbck是一個非常有用的工具，不過要注意它也是一個很重的工操作，因此儘量減少hbck的調用次數，儘量不要並行運行hbck服務。在0.90.4以前的hbck會有一些機率使hbase宕機。另外爲了確保hdfs的安全性，需要定期運行fsck等以檢查hdfs的狀態，如block的replica數量等。
我們會每天根蹤所有線上服務器的日誌，將錯誤日誌全部找出來並且郵件給開發人員，以查明每一次error以上的問題原因和fix。直至錯誤降低爲0。另外每一次的hbck結果如果有問題也會郵件給開發人員以處理掉。儘管並不是每一次error都會引發問題，甚至大部分error都只是分佈式系統中的正常現象，但明白它們問題的原因是非常重要的。
測試與發佈
因爲是未知的系統，我們從一開始就非常注重測試。測試從一開始就分爲性能測試和功能測試。性能測試主要是注意基準測試，分很多場景，比如不同混合讀寫比例，不同k/v大小，不同列族數，不同命中率，是否做presharding等等。每次運行都會持續數小時以得到準確的結果。因此我們寫了一套自動化系統，從web上選擇不同的場景，後臺會自動將測試參數傳到各臺服務器上去執行。由於是測試分佈式系統，因此client也必須是分佈式的。
我們判斷測試是否準確的依據是同一個場景跑多次，是否數據，以及運行曲線達到99%以上的重合度，這個工作非常煩瑣，以至於消耗了很多時間，但後來的事實證明它非常有意義。因爲我們對它建立了100%的信任，這非常重要，比如後期我們的改進哪怕只提高2%的性能也能被準確捕捉到，又比如某次代碼修改使compact隊列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。
功能測試上則主要是接口測試和異常測試。接口測試一般作用不是很明顯，因爲hbase本身的單元測試己經使這部分被覆蓋到了。但異常測試非常重要，我們絕大部分bug修改都是在異常測試中發現的，這幫助我們去掉了很多生產環境中可能存在的不穩定因素，我們也提交了十幾個相應的patch到社區，並受到了重視和commit。分佈式系統設計的難點和複雜度都在異常處理上，我們必須認爲系統在通訊的任何時候都是不可靠的。某些難以復現的問題我們會通過查看代碼大體定位到問題以後，在代碼層面強行拋出異常來複現它。事實證明這非常有用。
爲了方便和快速定位問題，我們設計了一套日誌收集和處理的程序，以方便地從每臺服務器上抓取相應的日誌並按一定規律彙總。這非常重要，避免浪費大量的時間到登錄不同的服務器以尋找一個bug的線索。
由於hbase社區在不停發展，以及線上或測試環境發現的新的bug，我們需要制定一套有規律的發佈模式。它既要避免頻繁的發佈引起的不穩定，又要避免長期不發佈導致生產版本離開發版本越來越遠或是隱藏的bug爆發。我們強行規定每兩週從內部trunk上release一個版本，該版本必須通過所有的測試包括迴歸測試，並且在release後在一個小型的集羣上24小時不受甘擾不停地運行。每個月會有一次發佈，發佈時採用最新release的版本，並且將現有的集羣按重要性分級發佈，以確保重要應用不受新版本的潛在bug影響。事實證明自從我們引入這套發佈機制後，由發佈帶來的不穩定因素大大下降了，並且線上版本也能保持不落後太多。
我們判斷測試是否準確的依據是同一個場景跑多次，是否數據，以及運行曲線達到99%以上的重合度，這個工作非常煩瑣，以至於消耗了很多時間，但後來的事實證明它非常有意義。因爲我們對它建立了100%的信任，這非常重要，比如後期我們的改進哪怕只提高2%的性能也能被準確捕捉到，又比如某次代碼修改使compact隊列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。
功能測試上則主要是接口測試和異常測試。接口測試一般作用不是很明顯，因爲hbase本身的單元測試己經使這部分被覆蓋到了。但異常測試非常重要，我們絕大部分bug修改都是在異常測試中發現的，這幫助我們去掉了很多生產環境中可能存在的不穩定因素，我們也提交了十幾個相應的patch到社區，並受到了重視和commit。分佈式系統設計的難點和複雜度都在異常處理上，我們必須認爲系統在通訊的任何時候都是不可靠的。某些難以復現的問題我們會通過查看代碼大體定位到問題以後，在代碼層面強行拋出異常來複現它。事實證明這非常有用。
爲了方便和快速定位問題，我們設計了一套日誌收集和處理的程序，以方便地從每臺服務器上抓取相應的日誌並按一定規律彙總。這非常重要，避免浪費大量的時間到登錄不同的服務器以尋找一個bug的線索。
由於hbase社區在不停發展，以及線上或測試環境發現的新的bug，我們需要制定一套有規律的發佈模式。它既要避免頻繁的發佈引起的不穩定，又要避免長期不發佈導致生產版本離開發版本越來越遠或是隱藏的bug爆發。我們強行規定每兩週從內部trunk上release一個版本，該版本必須通過所有的測試包括迴歸測試，並且在release後在一個小型的集羣上24小時不受甘擾不停地運行。每個月會有一次發佈，發佈時採用最新release的版本，並且將現有的集羣按重要性分級發佈，以確保重要應用不受新版本的潛在bug影響。事實證明自從我們引入這套發佈機制後，由發佈帶來的不穩定因素大大下降了，並且線上版本也能保持不落後太多。
改進和優化
Facebook是一家非常值得尊敬的公司，他們毫無保留地對外公佈了對hbase的所有改造，並且將他們內部實際使用的版本開源到了社區。facebook線上應用的一個重要特點是他們關閉了split，以降低split帶來的風險。與facebook不同，淘寶的業務數據量相對沒有如此龐大，並且由於應用類型非常豐富，我們並們並沒有要求用戶強行選擇關閉split，而是儘量去修改split中可能存在的bug。到目前爲止，雖然我們並不能說完全解決了這個問題，但是從0.90.2中暴露出來的諸多跟split以及宕機相關的可能引發的bug我們的測試環境上己經被修復到接近了0，也爲社區提交了10數個穩定性相關的patch，比較重要的有以下幾個：
split這是一個很重的事務，它有一個嚴重的問題就是會修改meta表（當然宕機恢復時也有這個問題）。如果在此期間發生異常，很有可能meta表、rs內存、master內存以及hdfs上的文件會發生不一致，導致之後region重新分配時發生錯誤。其中一個錯誤就是有可能同一個region被兩個以上的regionserver所服務，那麼就可能出現這一個region所服務的數據會隨機分別寫到多臺rs上，讀取的時候也會分別讀取，導致數據丟失。想要恢復原狀，必須刪除掉其中一個rs上的region，這就導致了不得不主動刪掉數據，從而引發數據丟失。
前面說到慢響應的問題歸納爲網絡原因、gc問題、命中率以及client的反序列化問題。網絡原因一般是網絡不穩定引起的，不過也有可能是tcp參數設置問題，必須保證儘量減少包的延遲，如nodelay需要設置爲true等，這些問題我們通過tcpdump等一系列工具專門定位過，證明tcp參數對包的組裝確實會造成慢連接。gc要根據應用的類型來，一般在讀比較多的應用中新生代不能設置得太小。命中率極大影響了響應的時間，我們會盡量將version數設爲１以增加緩存的容量，良好的balance也能幫助充分應用好每臺機器的命中率。我們爲此設計了表級別的balance。
由於hbase服務是單點的，即宕機一臺，則該臺機器所服務的數據在恢復前是無法讀寫的。宕機恢復速度決定了我們服務的可用率。爲此主要做了幾點優化。首先是將zk的宕機發現時間儘量縮短到1分鐘，其次改進了master恢復日誌爲並行恢復，大大提高了master恢復日誌的速度，然後我們修改了openhandler中可能出現的一些超時異常，以及死鎖，去掉了日誌中可能發生的open…too long等異常。原生的hbase在宕機恢復時有可能發生10幾分鐘甚至半小時無法重啓的問題己經被修復掉了。另外，hdfs層面我們將socket.timeout時間以及重試時間也縮短了，以降低datanode宕機引起的長時間block現象。
hbase本身讀寫層面的優化我們目前並沒有做太多的工作，唯一打的patch是region增加時寫性能嚴重下降的問題。因爲由於hbase本身良好的性能，我們通過大量測試找到了各種應用場景中比較優良的參數並應用於生產環境後，都基本滿足需求。不過這是我們接下來的重要工作。
- 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
split這是一個很重的事務，它有一個嚴重的問題就是會修改meta表（當然宕機恢復時也有這個問題）。如果在此期間發生異常，很有可能meta表、rs內存、master內存以及hdfs上的文件會發生不一致，導致之後region重新分配時發生錯誤。其中一個錯誤就是有可能同一個region被兩個以上的regionserver所服務，那麼就可能出現這一個region所服務的數據會隨機分別寫到多臺rs上，讀取的時候也會分別讀取，導致數據丟失。想要恢復原狀，必須刪除掉其中一個rs上的region，這就導致了不得不主動刪掉數據，從而引發數據丟失。
前面說到慢響應的問題歸納爲網絡原因、gc問題、命中率以及client的反序列化問題。網絡原因一般是網絡不穩定引起的，不過也有可能是tcp參數設置問題，必須保證儘量減少包的延遲，如nodelay需要設置爲true等，這些問題我們通過tcpdump等一系列工具專門定位過，證明tcp參數對包的組裝確實會造成慢連接。gc要根據應用的類型來，一般在讀比較多的應用中新生代不能設置得太小。命中率極大影響了響應的時間，我們會盡量將version數設爲１以增加緩存的容量，良好的balance也能幫助充分應用好每臺機器的命中率。我們爲此設計了表級別的balance。
由於hbase服務是單點的，即宕機一臺，則該臺機器所服務的數據在恢復前是無法讀寫的。宕機恢復速度決定了我們服務的可用率。爲此主要做了幾點優化。首先是將zk的宕機發現時間儘量縮短到1分鐘，其次改進了master恢復日誌爲並行恢復，大大提高了master恢復日誌的速度，然後我們修改了openhandler中可能出現的一些超時異常，以及死鎖，去掉了日誌中可能發生的open…too long等異常。原生的hbase在宕機恢復時有可能發生10幾分鐘甚至半小時無法重啓的問題己經被修復掉了。另外，hdfs層面我們將socket.timeout時間以及重試時間也縮短了，以降低datanode宕機引起的長時間block現象。
hbase本身讀寫層面的優化我們目前並沒有做太多的工作，唯一打的patch是region增加時寫性能嚴重下降的問題。因爲由於hbase本身良好的性能，我們通過大量測試找到了各種應用場景中比較優良的參數並應用於生產環境後，都基本滿足需求。不過這是我們接下來的重要工作。
將來計劃
我們目前維護着淘寶內基於社區0.90.x而定製的hbase版本。接下來除繼續fix它的bug外，會維護基於0.92.x修改的版本。之所以這樣，是因爲0.92.x和0.90.x的兼容性並不是非常好，而且0.92.x修改掉的代碼非常多，粗略統計會超過30%。0.92中有我們非常看重的一些特性。
我們自己也有一些優化，比如自行實現的二級索引、backup策略等都會在內部版本上實現。
另外值得一提的是hdfs層面的優化也非常重要，hadoop-1.0.0以及cloudera-3u3的改進對hbase非常有幫助，比如本地化讀、checksum的改進、datanode的keepalive設置、namenode的HA策略等。我們有一支優秀的hdfs團隊來支持我們的hdfs層面工作，比如定位以及fix一些hdfs層面的bug,幫助提供一些hdfs上參數的建議，以及幫助實現namenode的HA等。最新的測試表明，3u3的checksum+本地化讀可以將隨機讀性能提升至少一倍。
我們正在做的一件有意義的事是實時監控和調整regionserver的負載，能夠動態地將負載不足的集羣上的服務器挪到負載較高的集羣中，而整個過程對用戶完全透明。
總的來說，我們的策略是儘量和社區合作，以推動hbase在整個apache生態鏈以及業界的發展，使其能更穩定地部署到更多的應用中去，以降低使用門檻以及使用成本。
- 0.92版本改進了hfile爲hfileV2，v2版本的特點是將索引以及bloomfilter進行了大幅改造，以支持單個大hfile文件。現有的HFile在文件大到一定程度時，index會佔用大量的內存，並且加載文件的速度會因此下降非常多。而如果HFile不增大的話，region就無法擴大，從而導致region數量非常多。這是我們想盡量避免的事。
- 0.92版本改進了通訊層協議，在通訊層中增加了length，這非常重要，它讓我們可以寫出nio的客戶端，使反序列化不再成爲影響client性能的地方。
- 0.92版本增加了coprocessor特性，這支持了少量想要在rs上進行count等的應用。
- 還有其它很多優化，比如改進了balance算法、改進了compact算法、改進了scan算法、compact變爲CF級別、動態做ddl等等特性。
我們自己也有一些優化，比如自行實現的二級索引、backup策略等都會在內部版本上實現。
另外值得一提的是hdfs層面的優化也非常重要，hadoop-1.0.0以及cloudera-3u3的改進對hbase非常有幫助，比如本地化讀、checksum的改進、datanode的keepalive設置、namenode的HA策略等。我們有一支優秀的hdfs團隊來支持我們的hdfs層面工作，比如定位以及fix一些hdfs層面的bug,幫助提供一些hdfs上參數的建議，以及幫助實現namenode的HA等。最新的測試表明，3u3的checksum+本地化讀可以將隨機讀性能提升至少一倍。
我們正在做的一件有意義的事是實時監控和調整regionserver的負載，能夠動態地將負載不足的集羣上的服務器挪到負載較高的集羣中，而整個過程對用戶完全透明。
總的來說，我們的策略是儘量和社區合作，以推動hbase在整個apache生態鏈以及業界的發展，使其能更穩定地部署到更多的應用中去，以降低使用門檻以及使用成本。
