region定位
系統如何找到某個row key (或者某個 row key range)所在的region
bigtable 使用三層類似b+樹的結構來儲存region位置。
第一層是儲存zookeeper裡面的檔案，它持有root region的位置。
第二層root region是.meta.表的第乙個region其中儲存了.meta.z表其它region的位置。通過root region，我們就可以訪問.meta.表的資料。
.meta.是第三層，它是乙個特殊的表，儲存了hbase中所有資料表的region 位置資訊。
說明：1 root region永遠不會被split，保證了最需要三次跳轉，就能定位到任意region 。
2.meta.表每行儲存乙個region的位置資訊，row key 採用表名+表的最後一樣編碼而成。
3 為了加快訪問，.meta.表的全部region都儲存在記憶體中。
假設，.meta.表的一行在記憶體中大約占用1kb。並且每個region限制為128mb。
那麼上面的三層結構可以儲存的region數目為：
(128mb/1kb) * (128mb/1kb) = = 2(34)個region
4 client會將查詢過的位置資訊儲存快取起來，快取不會主動失效，因此如果client上的快取全部失效，則需要進行6次網路來回，才能定位到正確的region(其中三次用來發現快取失效，另外三次用來獲取位置資訊)。
讀寫過程
上文提到，hbase使用memstore和storefile儲存對錶的更新。
資料在更新時首先寫入log(wal log)和記憶體(memstore)中，memstore中的資料是排序的，當memstore累計到一定閾值時，就會建立乙個新的memstore，並 且將老的memstore新增到flush佇列，由單獨的執行緒flush到磁碟上，成為乙個storefile。於此同時，系統會在zookeeper中 記錄乙個redo point，表示這個時刻之前的變更已經持久化了。(minor compact)
當系統出現意外時，可能導致記憶體(memstore)中的資料丟失，此時使用log(wal log)來恢復checkpoint之後的資料。
前面提到過storefile是唯讀的，一旦建立後就不可以再修改。因此hbase的更 新其實是不斷追加的操作。當乙個store中的storefile達到一定的閾值後，就會進行一次合併(major compact),將對同乙個key的修改合併到一起，形成乙個大的storefile，當storefile的大小達到一定閾值後，又會對 storefile進行split，等分為兩個storefile。
由於對錶的更新是不斷追加的，處理讀請求時，需要訪問store中全部的 storefile和memstore，將他們的按照row key進行合併，由於storefile和memstore都是經過排序的，並且storefile帶有記憶體中索引，合併的過程還是比較快。
寫請求處理過程
1 client向region server提交寫請求
2 region server找到目標region
3 region檢查資料是否與schema一致
4 如果客戶端沒有指定版本，則獲取當前系統時間作為資料版本
5 將更新寫入wal log
6 將更新寫入memstore
7 判斷memstore的是否需要flush為store檔案。
region分配
任何時刻，乙個region只能分配給乙個region server。master記錄了當前有哪些可用的region server。以及當前哪些region分配給了哪些region server，哪些region還沒有分配。當存在未分配的region，並且有乙個region server上有可用空間時，master就給這個region server傳送乙個裝載請求，把region分配給這個region server。region server得到請求後，就開始對此region提供服務。
region server上線
master使用zookeeper來跟蹤region server狀態。當某個region server啟動時，會首先在zookeeper上的server目錄下建立代表自己的檔案，並獲得該檔案的獨佔鎖。由於master訂閱了server 目錄上的變更訊息，當server目錄下的檔案出現新增或刪除操作時，master可以得到來自zookeeper的實時通知。因此一旦region server上線，master能馬上得到訊息。
region server下線
當region server下線時，它和zookeeper的會話斷開，zookeeper而自動釋放代表這台server的檔案上的獨佔鎖。而master不斷輪詢 server目錄下檔案的鎖狀態。如果master發現某個region server丟失了它自己的獨佔鎖，(或者master連續幾次和region server通訊都無法成功),master就是嘗試去獲取代表這個region server的讀寫鎖，一旦獲取成功，就可以確定：
1 region server和zookeeper之間的網路斷開了。
2 region server掛了。
的其中一種情況發生了，無論哪種情況，region server都無法繼續為它的region提供服務了，此時master會刪除server目錄下代表這台region server的檔案，並將這台region server的region分配給其它還活著的同志。
如果網路短暫出現問題導致region server丟失了它的鎖，那麼region server重新連線到zookeeper之後，只要代表它的檔案還在，它就會不斷嘗試獲取這個檔案上的鎖，一旦獲取到了，就可以繼續提供服務。
master上線
master啟動進行以下步驟:
1 從zookeeper上獲取唯一乙個**master的鎖，用來阻止其它master成為master。
2 掃瞄zookeeper上的server目錄，獲得當前可用的region server列表。
3 和2中的每個region server通訊，獲得當前已分配的region和region server的對應關係。
4 掃瞄.meta.region的集合，計算得到當前還未分配的region，將他們放入待分配region列表。
master下線
由於master只維護表和region的元資料，而不參與表資料io的過 程，master下線僅導致所有元資料的修改被凍結(無法建立刪除表，無法修改表的schema，無法進行region的負載均衡，無法處理region 上下線，無法進行region的合併，唯一例外的是region的split可以正常進行，因為只有region server參與)，表的資料讀寫還可以正常進行。因此master下線短時間內對整個hbase集群沒有影響。從上線過程可以看到，master儲存的 資訊全是可以冗餘資訊（都可以從系統其它地方收集到或者計算出來），因此，一般hbase集群中總是有乙個master在提供服務，還有乙個以上 的』master』在等待時機搶占它的位置。
HBase 表名及設計規則
表名設計規則一般為 彙總層標識 資料域 主維度 時間維度 例如 dws trd slr dtr,表示彙總層交易資料，根據賣家 slr 主維度 0點截止當日 dtr 進行統計彙總。這樣做的好處是，所有主維度相同的資料都放在一張物理表中，避免表數量過多，難以維護。另外，可以從表名上直觀地看到儲存的是什麼...
HBase變更表名以及meta表修復
表名變更 1.停止表繼續插入 hbase shell disable tablename 2。製作快照 hbase shell snapshot tablename tablesnapshot 3.轉殖快照為新的名字 hbase shell clone snapshot tablesnapshot ...
HBase中批量修改
先隨便寫寫.做個隨筆記錄 使用rest連線操作hbase.是微軟提供的 microsoft.hbase.client 類庫.版本是0.4.1.0 一直知道 client.storecellsasync 方法是可以新增也可以覆蓋已有資料.其實不是這麼簡單.機緣巧合下測試發現修改一次只能修改100條資料...