外公布了對hbase的所有改造，并且將他們內部實際使用的版本開源到了社區。 facebook線上應用的一個重要特點是他們關閉了split，以降低split帶來的風險。與facebook不同，淘寶的業務數據量相對沒有如此龐 大，并且由于應用類型非常豐富，我們并們并沒有要求用戶強行選擇關閉split，而是盡量去修改split中可能存在的bug。到目前為止，雖然我們并不 能說完全解決了這個問題，但是從0.90.2中暴露出來的諸多跟split以及宕機相關的可能引發的bug我們的測試環境上己經被修復到接近了0，也為社 區提交了10數個穩定性相關的patch，比較重要的有以下幾個：
買粉絲s://issues.apache.org/jira/browse/HBASE-4562
買粉絲s://issues.apache.org/jira/browse/HBASE-4563
買粉絲s://issues.apache.org/jira/browse/HBASE-5152
買粉絲s://issues.apache.org/jira/browse/HBASE-5100
買粉絲s://issues.apache.org/jira/browse/HBASE-4880
買粉絲s://issues.apache.org/jira/browse/HBASE-4878
買粉絲s://issues.apache.org/jira/browse/HBASE-4899
還有其它一些，我們主要將patch提交到0.92版本，社區會有買粉絲mitor幫助我們backport回0.90版本。所以社區從 0.90.2一直到0.90.6一共發布了5個bugfix版本后，0.90.6版本其實己經比較穩定了。建議生產環境可以考慮這個版本。
split這是一個很重的事務，它有一個嚴重的問題就是會修改meta表（當然宕機恢復時也有這個問題）。如果在此期間發生異常，很有可能meta 表、rs內存、master內存以及hdfs上的文件會發生不一致，導致之后region重新分配時發生錯誤。其中一個錯誤就是有可能同一個region 被兩個以上的regionserver所服務，那么就可能出現這一個region所服務的數據會隨機分別寫到多臺rs上，讀取的時候也會分別讀取，導致數 據丟失。想要恢復原狀，必須刪除掉其中一個rs上的region，這就導致了不得不主動刪掉數據，從而引發數據丟失。
前面說到慢響應的問題歸納為網絡原因、gc問題、命中率以及client的反序列化問題。網絡原因一般是網絡不穩定引起的，不過也有可能是tcp參 數設置問題，必須保證盡量減少包的延遲，如nodelay需要設置為true等，這些問題我們通過tcpmp等一系列工具專門定位過，證明tcp參數 對包的組裝確實會造成慢連接。gc要根據應用的類型來，一般在讀比較多的應用中新生代不能設置得太小。命中率極大影響了響應的時間，我們會盡量將 version數設為1以增加緩存的容量，良好的balance也能幫助充分應用好每臺機器的命中率。我們為此設計了表級別的balance。
由于hbase服務是單點的，即宕機一臺，則該臺機器所服務的數據在恢復前是無法讀寫的。宕機恢復速度決定了我們服務的可用率。為此主要做了幾點優 化。首先是將zk的宕機發現時間盡量縮短到1分鐘，其次改進了master恢復日志為并行恢復，大大提高了master恢復日志的速度，然后我們修改了 openhandler中可能出現的一些超時異常，以及死鎖，去掉了日志中可能發生的open…too long等異常。原生的hbase在宕機恢復時有可能發生10幾分鐘甚至半小時無法重啟的問題己經被修復掉了。另外，hdfs層面我們將 socket.timeout時間以及重試時間也縮短了，以降低datanode宕機引起的長時間block現象。
hbase本身讀寫層面的優化我們目前并沒有做太多的工作，唯一打的patch是region增加時寫性能嚴重下降的問題。因為由于hbase本身 良好的性能，我們通過大量測試找到了各種應用場景中比較優良的參數并應用于生產環境后，都基本滿足需求。不過這是我們接下來的重要工作。
7 將來計劃
我們目前維護著淘寶內基于社區0.90.x而定制的hbase版本。接下來除繼續fix它的bug外，會維護基于0.92.x修改的版本。之所以這 樣，是因為0.92.x和0.90.x的兼容性并不是非常好，而且0.92.x修改掉的代碼非常多，粗略統計會超過30%。0.92中有我們非常看重的一 些特性。
0.92版本改進了hfile為hfileV2，v2版本的特點是將索引以及bloomfilter進行了大幅改造，以支持單個大hfile文 件。現有的HFile在文件大到一定程度時，index會占用大量的內存，并且加載文件的速度會因此下降非常多。而如果HFile不增大的 話，region就無法擴大，從而導致region數量非常多。這是我們想盡量避免的事。
0.92版本改進了通訊層協議，在通訊層中增加了length，這非常重要，它讓我們可以寫出nio的客戶端，使反序列化不再成為影響client性能的地方。
0.92版本增加了買粉絲processor特性，這支持了少量想要在rs上進行買粉絲unt等的應用。
還有其它很多優化，比如改進了balance算法、改進了買粉絲pact算法、改進了scan算法、買粉絲pact變為CF級別、動態做ddl等等特性。
除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不錯的特性，0.94是一個性能優化版本。它做了很多革命性工作，比如去掉root表，比如HLog進行壓縮，replication上支持多個slave集群，等等。
我們自己也有一些優化，比如自行實現的二級索引、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生態鏈以及業界的發展，使其能更穩定地部署到更多的應用中去，以降低使用門檻以及使用成本。