Hbase框架不同於一般框架，一般框架都是讀快寫慢，而Hbase恰恰相反，他的寫要更快些。
寫數據流程：
1.發出請求：
（第一次交互）客戶端通過Zookeeper的調度，通過它上面的meta表，找到meta表所在的HregionServer位置信息，返回給客戶端；
（第二次交互）客戶端再次交互上面所獲取的HregionServer，通過你要查的這張表的表名和RowKey，找到這條數據所在的表的具體位置（多個HregionServer中的具體某一個），將該HregionServer返回給客戶端；
（第三次交互）客戶端通過二所獲取的HregionServer找到所在位置，進行寫操作。到這里寫數據就完成了。
注意：老版本里zookeeper還有一個-root-表，他記錄的是.meta.表的信息，就是在最開始多了一次交互。
2.寫到內存后落盤：
數據寫入到Hregion的Memstore（內存）中，直到達到閾值（128M），進行flush操作，持久化到StoreFile；
3.“先合再分”：
在Hregion上，StoreFile文件不斷增多，到達一個閾值后（一般3-10個文件），進行Compact合並操作，合成一個StoreFile，而不斷的合並，達到一定閾值后，進行split溢寫操作，把當前Hregion分成兩個Hregion（由HregionServer負責），同時父Hregion下線，生成的兩個新的被Hmaster分配到相應的HregionServer上。寫數據完成。
由此可見，Hbase只有增添數據的操作，我們的修改和刪除都是再后續的Compact中得以實現（覆蓋原數據：根據rowkey+列簇+列全部對應后，如果全一致，就會生一個新的版本，
也就是時間戳，你下次讀對應的數據他會返回給你最新的版本），客戶端進行寫數據操作時，只要進入內存，就立刻返回，這也正是Hbase的IO高效所在原因
讀數據流程：
HBase讀取數據兩種方式：get和scan。
通常我們都是根據rowkey來查找，
- 從rowkey來找這張表table，而table從行的方向上又分為了多個region，每一個region他有一個特殊屬性：startkey - endkey，這樣就能判斷你的rowkey是否在這個region上。region里對應又有多個store（存放的是列簇）。
- 找到他所在的region便可找到他所在的regionserver，因為最終客戶端還是要和regionserver進行交互。
1.客戶端訪問Zookeeper，查找-root-表（之前我所提的“根表”），獲取.meta.表信息，它里面存的是所有表的元數據（在哪個region上），進而找到在哪一個HregionServer上維護。
2.HregionServer的內存分為Memstroe和BlockCache兩部分，前者主要用來寫數據，后者主要用來讀數據。當讀數據 請求過來時，先到Memstore中查找，找不到再去BlockCache中查，再查不到才去StoreFile上讀，讀到后把結果返回並放入到BlockCache（下次再查這條就更快了）。
這里就把memstore看成一個記憶緩存，blockcache堪稱是一個二級緩沖。
歸納下：
client >> zookeeper >> -root- >> .meta. >> Hregion >> HregionServer >> client
由此可見：
讀寫數據流程其實並不需要Hmaster的參與，這部分工作依賴於zookeeper，這時即便你的Hmaster宕掉也不影響。