hbasesplit源碼

① hbase 源碼 什麼語言開發的

是用java開發的，hbase包含兩個核心服務，一個是HMaster，一個是HRegionServer，在hbase部署的伺服器上調用jps命令能查看到這兩個進程。

② hbase 中HRegion 手動分裂無效

對於一個曾經運維過幾百個節點的HBase集群的運維人員，並且Request每秒在5w以上，一定遇到過如下類似的問題。
ZooKeeper服務在不停地報警指示在zookeeper的unassigned路徑由一些節點在會一直存在，而且它的版本在不斷增加。此時，HRegionServer和HMaster都會列印大量log，而且會持續給ZooKeeper帶來壓力，另外整個HBase集群沒有報告出現任何Region offline的現象。如果你也是遇到同樣的問題，那麼請繼續看本文的內容。
背景：
注冊到zookeeper的unassgined路徑下的節點，是處於Transition狀態的Region，這主要有如下幾種：
public enum State {
OFFLINE, // region is in an offline state
PENDING_OPEN, // sent rpc to server to open but has not begun
OPENING, // server has begun to open but not yet done
OPEN, // server opened region and updated meta
PENDING_CLOSE, // sent rpc to server to close but has not begun
CLOSING, // server has begun to close but not yet done
CLOSED, // server closed region and updated meta
SPLITTING, // server started split of a region
SPLIT // server completed split of a region
}
幾個常見場景：
1）在一個RegionServer下線，在進行了log split之後，它上面的Region需要遷移到其它RegionServer的時候，會首先將其放入PENDING_OPEN的Region放入unassigned路徑下。
2）在Region進行split時，會有Region經歷SPLITTING -〉SPLIT的過程，對於SPLIT的操作，下面將努力還原這個過程。
HRegionServer有兩種方式觸發split操作：
1）用戶直接通過API指定splitkey，然後進行Region Split
2）HRegionServer上CompactionSplitThread被觸發。
無論哪種方式，最後的核心處理邏輯都是類似的，都是由SplitTransction來進行。
核心操作的步驟為：
1）創建兩個子女Region。此時，Parent Region的信息被創建在unassgined路徑下，狀態為SPLITTING，此時該Region處於Off-line。
2）讓兩個子女Region上線。在first region 和 second Region上線的選擇中，https://issues.apache.org/jira/browse/HBASE-4335 給出了一個小小的trick，讓second Region先上線。
orignal Region：[starkey， endkey） example {a, b ,c}
first Region : [startkey，midkey) example {a}
second Region: [midkey， endkey） example {b, c}
如果讓first Region 先於 second Region上線，那麼根據Get(key)查找離key最匹配的Region的區間時，會根據startkey進行匹配，由於second Region還沒上線，則get(c)最後直接會在first Region中查找，找不到該值，直接返回null，而如果second Region先於first Region上線，則get(a)仍然會找到original Region，從而觸發客戶端的retry。
3）結束整個split操作工作。這一步相當於打掃衛生的工作，然而就是這步操作，出現了一個問題。
SplitTransaction將parent region的狀態由SPLITTING 轉換成SPLIT，這是在提醒HMaster端的AssignmentManager，你可以回收這個parent region了。
AssignmentManager由nodeChanged發現了SPLIT的event之後，立刻就開始清理工作，它通過ExecutorThreadPool提交了SplitRegionHandler，接下來它的順序就特別重要了：
1）它會清空在AssignmentManager內存中該Parent Region記錄的狀態；
2）然後刪除unassigned節點的內容。注意這個步驟是time-consuming過程。
同時，在SplitTransaction內，如果在sleep 100 ms之後，會醒來，如果發現AssignmentManager沒有處理該路徑，會重新創建一個新的version，狀態仍然是SPLIT。可怕的事情是，如果ZooKeeper是順序執行這個操作，如果某個時序上，AssignmentManager刪除了該路徑，而此時，HRegionServer上SplitTransaction又正好更新該ZNode，就悲劇了。
此時，AssignmentManager由於內存已經清空了該數據，不再認定該Region是正常的Region，所以，就會報出Warning，而SplitTransaction只是100ms反復更新znode。分布式交互的死循環即將開始。

對於該bug，深層次原因在於，對於zookeeper上一個node的創建與修改都是加鎖的，而且是time-consuming的過程。如果在HMaster節點和HRegionServer節點高並發，多線程調度情況下，很容易出現上述的狀態。
基於此，我的解決方案是：
增加HRegionServer上SplitTransaction的sleep的時間，可以由100ms改成4000ms，讓等待時間足夠長，同時保留之前循環檢查來比避免ZK的event丟失問題。
hbase-0.92.1 SplitTransaction.java
412 Thread.sleep(100); => Thread.sleep(4000);

注意，由於分裂的Region已經上線，修改該時間，不會帶來性能上的影響。只是確保HMaster的AssignmentManager 可以更好進行相應的操作。

③ hbase splits 如何定位到哪個分區

1.取樣，先隨機生成一定數量的rowkey,將取樣數據按升序排序放到一個集合里
2.根據預分區的region個數，對整個集合平均分割，即是相關的splitKeys.
3.HBaseAdmin.createTable(HTableDescriptor tableDescriptor,byte[][] splitkeys)可以指定預分區的splitKey，即是指定region間的rowkey臨界值.

④ hbase預分區與region切割的關系

一張表預分區N個，那就是一開始就設定了N個region；
hbase.hregion.max.filesize 設定的region大小，超過了就會split，就會增加一個region，對預分區沒什麼影響。
一張表假如不預分區，那麼數據超過region最大值才會拆分，比如你1天10G數據，設定5G才split，兩天內寫數據都寫在一個region里，沒有分布式效果，改region就是熱點。
預設分區一般配合rowkey設計解決熱點，例如預分區5個，rowkey可設置前最A、B、C、D、E，程序裡面隨機的加其中的一個前綴，那麼就會隨機插入到各個region中，但是一般又會和業務系統需求有些矛盾。例如rowkey按時間戳字元串加鹽，那麼就只有一各個region scan再合起來統計會比較快，直接scan 「A20181111」到「D20181128」很慢很麻，還有按用戶ID、手機號等等做rowkey加鹽或者hash散列可能都會在設計上有熱點和業務需求的矛盾點。

⑤ hbase源代碼 純java開發的嗎

是的，純java開發的nosql

⑥ 關於hbase的問題，開啟hbase後一會hmaster和hregionserver就沒了

一、通常向HBase批量導入數據有三種常用方式
1、使用HBase提供的TableOutputFormat，原理是通過一個Maprece作業將數據導入HBase
2、還有一種方式就是使用HBase原生Client API（put）
3、前兩種方式因為須要頻繁的與數據所存儲的RegionServer通信。一次性入庫大量數據時，特別佔用資源，所以都不是很有效。因為HBase在HDFS中是以HFile文件結構存儲的，所以高效便捷的方法就是直接生成HFile文件然後使用Bulk Load方法，即HBase提供的HFileOutputFormat類。
二、Bulk Load基本原理
Bulk Load處理由兩個主要步驟組成：
1、生成HFile文件
Bulk Load的第一步會執行一個Maprece作業，其中使用到了HFileOutputFormat輸出HBase數據文件：StoreFile。
HFileOutputFormat的作用在於使得輸出的HFile文件能夠適應單個region。使用TotalOrderPartitioner類將map輸出結果分區到各個不同的key區間中，每一個key區間都相應著HBase表的region。
2、導入HBase表
第二步使用completebulkload工具將第一步的結果文件依次交給負責文件相應region的RegionServer，並將文件move到region在HDFS上的存儲文件夾中。一旦完畢。將數據開放給clients。
假設在bulk load准備導入或在准備導入與完畢導入的臨界點上發現region的邊界已經改變，completebulkload工具會自己主動split數據文件到新的邊界上。可是這個過程並非最佳實踐，所以用戶在使用時須要最小化准備導入與導入集群間的延時，特別是當其它client在同一時候使用其它工具向同一張表導入數據。
Bulk Load常遇到的一個ERROR:」java.io.IOException: Retry attempted 10 times without completing, ling out」
錯誤解析：
我們使用的Hbase1.0.2版本下，如果Hfile文件 跨越多個region，bulkload會自動地將Hfile文件split，但是對於每次retry只會將指定的Hfile文件split一次。但是在hbase-site.xml配置文件里有個參數hbase.bulkload.retries.number控制了hbase對一個hfile最多plit多少次。這個參數默認是10，如果某個hfile跨越的region數超過10個就會報上述Exception。
解決方案：
將hbase.bulkload.retries.number這個參數設置為更大的值，比如目標表的region數量或者將這個參數設置成0，0表示不斷重試直到成功。設置之後問題解決。

⑦ 如何使用Java API操作Hbase

1. HBaseConfiguration是每一個hbase client都會使用到的對象，它代表的是HBase配置信息。它有兩種構造方式：
public HBaseConfiguration()
public HBaseConfiguration(final Configuration c)
2. HBaseAdmin來創建表。HBaseAdmin負責表的META信息處理。HBaseAdmin提供了createTable這個方法：
public void createTable(HTableDescriptor desc)
3. addFamily方法增加family
public void addFamily(final HColumnDescriptor family)
4. 刪除表
刪除表也是通過HBaseAdmin來操作，刪除表之前首先要disable表。
disableTable和deleteTable分別用來disable和delete表。
5. 查詢數據
單條查詢是通過rowkey在table中查詢某一行的數據。HTable提供了get方法來完成單條查詢。
批量查詢是通過制定一段rowkey的范圍來查詢。HTable提供了個getScanner方法來完成批量查詢。
public Result get(final Get get)
public ResultScanner getScanner(final Scan scan)
6. 插入數據 HTable通過put方法來插入數據。
public void put(final Put put) throws IOException
public void put(final List puts) throws IOException
7. 切分表
HBaseAdmin提供split方法來將table 進行split.
public void split(final String tableNameOrRegionName)

⑧ 淘寶為什麼使用HBase及如何優化的

1 前言
hbase是從hadoop中 分離出來的apache頂級開源項目。由於它很好地用java實現了google的bigtable系統大部分特性，因此在數據量猛增的今天非常受到歡 迎。對於淘寶而言，隨著市場規模的擴大，產品與技術的發展，業務數據量越來越大，對海量數據的高效插入和讀取變得越來越重要。由於淘寶擁有也許是國內最大 的單一hadoop集群(雲梯)，因此對hadoop系列的產品有比較深入的了解，也就自然希望使用hbase來做這樣一種海量數據讀寫服務。本篇文章將 對淘寶最近一年來在online應用上使用和優化hbase的情況做一次小結。

2 原因
為什麼要使用hbase？
淘寶在2011年之前所有的後端持久化存儲基本上都是在mysql上進行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由於開源，並且生態系統良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業務的需求。

但是由於業務的多樣化發展，有越來越多的業務系統的需求開始發生了變化。一般來說有以下幾類變化：

a) 數據量變得越來越多，事實上現在淘寶幾乎任何一個與用戶相關的在線業務的數據量都在億級別，每日系統調用次數從億到百億都有，且歷史數據不能輕易刪除。這需要有一個海量分布式文件系統，能對TB級甚至PB級別的數據提供在線服務
b) 數據量的增長很快且不一定能准確預計，大多數應用系統從上線起在一段時間內數據量都呈很快的上升趨勢，因此從成本的角度考慮對系統水平擴展能力有比較強烈的需求，且不希望存在單點制約
c) 只需要簡單的kv讀取，沒有復雜的join等需求。但對系統的並發能力以及吞吐量、響應延時有非常高的需求，並且希望系統能夠保持強一致性
d) 通常系統的寫入非常頻繁，尤其是大量系統依賴於實時的日誌分析
e) 希望能夠快速讀取批量數據
f ) schema靈活多變，可能經常更新列屬性或新增列
g) 希望能夠方便使用，有良好且語義清晰的java介面

以上需求綜合在一起，我們認為hbase是一種比較適合的選擇。首先它的數據由hdfs天然地做了數據冗餘，雲梯三年的穩定運行，數據100%可靠 己經證明了hdfs集群的安全性，以及服務於海量數據的能力。其次hbase本身的數據讀寫服務沒有單點的限制，服務能力可以隨伺服器的增長而線性增長， 達到幾十上百台的規模。LSM-Tree模式的設計讓hbase的寫入性能非常良好，單次寫入通常在1-3ms內即可響應完成，且性能不隨數據量的增長而 下降。

region（相當於資料庫的分表）可以ms級動態的切分和移動，保證了負載均衡性。由於hbase上的數據模型是按rowkey排序存儲的，而讀 取時會一次讀取連續的整塊數據做為cache，因此良好的rowkey設計可以讓批量讀取變得十分容易，甚至只需要1次io就能獲取幾十上百條用戶想要的 數據。最後，淘寶大部分工程師是java背景的同學，因此hbase的api對於他們來說非常容易上手，培訓成本相對較低。

當然也必須指出，在大數據量的背景下銀彈是不存在的，hbase本身也有不適合的場景。比如，索引只支持主索引（或看成主組合索引），又比如服務是 單點的，單台機器宕機後在master恢復它期間它所負責的部分數據將無法服務等。這就要求在選型上需要對自己的應用系統有足夠了解。

3 應用情況
我們從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集群己經應用到了線上超過二十個應用，數百台伺服器上。包括淘寶首頁的商品實時推薦、廣泛用於賣家的實時量子統計等應用，並且還有繼續增多以及向核心應用靠近的趨勢。

4 部署、運維和監控
Facebook之前曾經透露過Facebook的hbase架構，可以說是非常不錯的。如他們將message服務的hbase集群按用戶分為數 個集群，每個集群100台伺服器，擁有一台namenode以及分為5個機架，每個機架上一台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的連接，以在發生故障時，將故障隔離在某個應用內部而不擴大化。maprece的應用也會控制在低峰期運行，比如在白天我們會關閉jobtracker等。

此外，為了保障服務從結果上的可用，我們也會定期跑讀寫測試、建表測試、hbck等命令。hbck是一個非常有用的工具，不過要注意它也是一個很重 的工操作，因此盡量減少hbck的調用次數，盡量不要並行運行hbck服務。在0.90.4以前的hbck會有一些機率使hbase宕機。另外為了確保 hdfs的安全性，需要定期運行fsck等以檢查hdfs的狀態，如block的replica數量等。

我們會每天根蹤所有線上伺服器的日誌，將錯誤日誌全部找出來並且郵件給開發人員，以查明每一次error以上的問題原因和fix。直至錯誤降低為0。另外 每一次的hbck結果如果有問題也會郵件給開發人員以處理掉。盡管並不是每一次error都會引發問題，甚至大部分error都只是分布式系統中的正常現 象，但明白它們問題的原因是非常重要的。

5 測試與發布
因為是未知的系統，我們從一開始就非常注重測試。測試從一開始就分為性能測試和功能測試。性能測試主要是注意基準測試，分很多場景，比如不同混合讀 寫比例，不同k/v大小，不同列族數，不同命中率，是否做presharding等等。每次運行都會持續數小時以得到准確的結果。因此我們寫了一套自動化 系統，從web上選擇不同的場景，後台會自動將測試參數傳到各台伺服器上去執行。由於是測試分布式系統，因此client也必須是分布式的。

我們判斷測試是否准確的依據是同一個場景跑多次，是否數據，以及運行曲線達到99%以上的重合度，這個工作非常煩瑣，以至於消耗了很多時間，但後來 的事實證明它非常有意義。因為我們對它建立了100%的信任，這非常重要，比如後期我們的改進哪怕只提高2%的性能也能被准確捕捉到，又比如某次代碼修改 使compact隊列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。

功能測試上則主要是介面測試和異常測試。介面測試一般作用不是很明顯，因為hbase本身的單元測試己經使這部分被覆蓋到了。但異常測試非常重要， 我們絕大部分bug修改都是在異常測試中發現的，這幫助我們去掉了很多生產環境中可能存在的不穩定因素，我們也提交了十幾個相應的patch到社區，並受 到了重視和commit。分布式系統設計的難點和復雜度都在異常處理上，我們必須認為系統在通訊的任何時候都是不可靠的。某些難以復現的問題我們會通過查 看代碼大體定位到問題以後，在代碼層面強行拋出異常來復現它。事實證明這非常有用。

為了方便和快速定位問題，我們設計了一套日誌收集和處理的程序，以方便地從每台伺服器上抓取相應的日誌並按一定規律匯總。這非常重要，避免浪費大量的時間到登錄不同的伺服器以尋找一個bug的線索。

由於hbase社區在不停發展，以及線上或測試環境發現的新的bug，我們需要制定一套有規律的發布模式。它既要避免頻繁的發布引起的不穩定，又要 避免長期不發布導致生產版本離開發版本越來越遠或是隱藏的bug爆發。我們強行規定每兩周從內部trunk上release一個版本，該版本必須通過所有 的測試包括回歸測試，並且在release後在一個小型的集群上24小時不受甘擾不停地運行。每個月會有一次發布，發布時採用最新release的版本， 並且將現有的集群按重要性分級發布，以確保重要應用不受新版本的潛在bug影響。事實證明自從我們引入這套發布機制後，由發布帶來的不穩定因素大大下降 了，並且線上版本也能保持不落後太多。

6 改進和優化
Facebook是一家非常值得尊敬的公司，他們毫無保留地對外公布了對hbase的所有改造，並且將他們內部實際使用的版本開源到了社區。 facebook線上應用的一個重要特點是他們關閉了split，以降低split帶來的風險。與facebook不同，淘寶的業務數據量相對沒有如此龐 大，並且由於應用類型非常豐富，我們並們並沒有要求用戶強行選擇關閉split，而是盡量去修改split中可能存在的bug。到目前為止，雖然我們並不 能說完全解決了這個問題，但是從0.90.2中暴露出來的諸多跟split以及宕機相關的可能引發的bug我們的測試環境上己經被修復到接近了0，也為社 區提交了10數個穩定性相關的patch，比較重要的有以下幾個：

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版本，社區會有commitor幫助我們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版本增加了coprocessor特性，這支持了少量想要在rs上進行count等的應用。
還有其它很多優化，比如改進了balance演算法、改進了compact演算法、改進了scan演算法、compact變為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生態鏈以及業界的發展，使其能更穩定地部署到更多的應用中去，以降低使用門檻以及使用成本。

⑨ hbase啟動為什麼要做log split

HBase為了提高寫的性能，將數據的修改先放到memstore內存中，這樣做的缺陷是當某個region server崩潰時，其memstore中的所有修改將會丟失，因為它們還沒有被刷寫到磁碟上。為了防止這情況造成的數據丟失，HBase的做法是在修改寫入memstore之前，先將其寫入一個稱為"預寫日誌"（write-ahead-log，WAL）文件中。這樣在遇到一個region server崩潰後，可以通過回放（replay）WAL文件重新生成memstore中丟失的修改。
由於一個region server上會有多個region，並且這些region共享一個WAL文件。WAL文件中的每個修改（也叫做edit）都包含其屬於哪一個region的信息。當打開一個region時，將會replay這個region在WAL中的所有edits記錄，來重新生成數據。所以，在WAL文件中的所有edit都必須按region分組形成特定的集合，通過replay這些集合來對特定的region重新生成數據。像這樣在WAL文件中對edit 按region分組的過程就稱為Log Split。
日誌拆分（Log Split）發生在集群啟動時（由HMaster負責完成）或是在region server崩潰時（由ServerShutdownHandler負責完成），因為HBase需要保持一致性。在日誌拆分時，受影響的region將不可用，直到拆分完成，數據完全重置。

⑩ hbase0.96meta表還需要split嗎

理論上沒有上限，因為個人覺得有兩個因素會影響Hbase的表個數：內存，硬碟，這個很顯然-ROOT-表訪問限制，因為當表很多時，META.表就會很大，會發生切分，相應的-ROOT-就會變大，但是由於.META.的緩沖，對-ROOT-的影響不會很明顯綜上，理論上來說HBase的表個數沒有限制，但是表增多必然會導致響應效率降低