Hbase读写过程
?
1、讀請求過程
- 客戶端通過zookeeper以及root表和meta表找到目標數據所在的regionserver
- 聯系regionserver查詢目標數據
- regionserver定位到目標數據所在的region，發出查詢請求
- region先在memstore中查找，命中則返回
- 如果在memstore中找不到，則在storefile中掃描（可能會掃描到很多的storefile—-bloomfilter布隆過濾器）
補充：布隆過濾器參數類型有2種：?
Row、row+col
2、寫請求過程：
- client向region server提交寫請求
- region server找到目標region
- region檢查數據是否與schema一致
- 如果客戶端沒有指定版本，則獲取當前系統時間作為數據版本
- 將更新寫入WAL log
- 將更新寫入Memstore
- 判斷Memstore的是否需要flush為StoreFile文件。
細節描述：?
hbase使用MemStore和StoreFile存儲對表的更新。?
數據在更新時首先寫入Log(WAL log)和內存(MemStore)中，MemStore中的數據是排序的，當MemStore累計到一定閾值時，就會創建一個新的MemStore，并且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成為一個StoreFile。于此同時，系統會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了。
當系統出現意外時，可能導致內存(MemStore)中的數據丟失，此時使用Log(WAL log)來恢復checkpoint之后的數據。
StoreFile是只讀的，一旦創建后就不可以再修改。因此Hbase的更新其實是不斷追加的操作。當一個Store中的StoreFile達到一定的閾值后，就會進行一次合并(minor_compact, major_compact),將對同一個key的修改合并到一起，形成一個大的StoreFile，當StoreFile的大小達到一定閾值后，又會對 StoreFile進行split，等分為兩個StoreFile。
由于對表的更新是不斷追加的，compact時，需要訪問Store中全部的 StoreFile和MemStore，將他們按row key進行合并，由于StoreFile和MemStore都是經過排序的，并且StoreFile帶有內存中索引，合并的過程還是比較快。
總結
