讀寫過程
讀請求過程：
（1） 客戶端通過zookeeper以及root表和meta表找到目標數據所在的regionserver
（2）聯繫regionserver查詢目標數據
（3）regionserver定位到目標數據所在的region，發出查詢請求
（4）region先在memstore中查找，命中則返回
（5）如果在memstore中找不到，則在storefile中掃描（可能會掃描到很多的storefile—-bloomfilter布隆過濾器）
補充：布隆過濾器參數類型有2種：
Row、row+col
2、寫請求過程：
（1）client向region server提交寫請求
（2）region server找到目標region
（3）region檢查數據是否與schema一致
（4）如果客戶端沒有指定版本，則獲取當前系統時間作爲數據版本
（5）將更新寫入WAL log
（6）將更新寫入Memstore
（7）判斷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帶有內存中索引，合併的過程還是比較快