這裏先大概記錄下Hbase數據的讀寫交互流程，後面研究了Hbase源碼有了深入體會再繼續敘述詳細的讀寫原理實現。
讀數據流程
HBase讀數據是比寫數據更加複雜的操作流程，這主要基於兩個方面的原因：一是整個HBase存儲引擎基於LSM-Like樹實現，因此一次範圍查詢可能會涉及多個分片、多塊緩存甚至多個數據存儲文件；二是HBase中更新操作以及刪除操作實現都很簡單，更新操作並沒有更新原有數據，而是使用時間戳屬性實現了多版本。刪除操作也並沒有真正刪除原有數據，只是插入了一條打上”deleted”標籤的數據，而真正的數據刪除發生在系統合併文件的時候。很顯然，這種方式大大簡化了數據更新、刪除流程，但是讀取過程需要根據版本進行過濾，同時對已經標記刪除的數據也要進行過濾。
客戶羣發送讀數據請求：
1、客戶端首先會根據配置文件中zk地址連接zk，並讀取meta-region-server節點信息，該節點信息存儲了HBase元數據（hbase:meta）表所在的RegionServer地址以及訪問端口等信息
2、zk返回hbase:meta所在RegionServer的訪問信息客戶端
3、客戶端請求元數據meta表所在RegionServer
4、返回元數據表給客戶端，並將該元數據表加載到本地並進行緩存，然後在表中確定待檢索rowkey所在的RegionServer信息
5、客戶端根據數據所在RegionServer的訪問信息，向該RegionServer發送真正的數據讀取請求
6、服務器端接收到該請求之後，先查詢內存MemStore中是否有符合的數據，如果沒有再去StoreFile文件中查詢，查到數據則返回結果給客戶端
注：META 表是 HBase 中一張特殊的表，它保存了所有 Region 的位置信息，META 表自己的位置信息則存儲在 ZooKeeper 上。
讀數據流程圖如下：
寫數據流程
客戶端發起put寫數據請求：
1、客戶端首先會根據配置文件中zk地址連接zk，並讀取meta-region-server節點信息，該節點信息存儲了HBase元數據（hbase:meta）表所在的RegionServer地址以及訪問端口等信息
2、zk返回hbase:meta所在RegionServer的訪問信息客戶端
3、客戶端請求元數據meta表所在RegionServer
4、返回元數據表給客戶端，並將該元數據表加載到本地並進行緩存，然後在表中確定待檢索rowkey所在的RegionServer信息
5、客戶端根據數據所在RegionServer的訪問信息，向該RegionServer發送真正的數據寫請求
6、先將數據寫入HLog日誌文件。HBase使用WAL機制保證數據可靠性，即首先寫日誌再寫緩存，即使發生宕機，也可以通過恢復HLog還原出原始數據。
7、再將數據寫入MemStore緩存。HBase中每列族都會對應一個store，用來存儲該列數據，每個store都會有個memstore用於緩存寫入數據。HBase並不會直接將數據落盤，而是先寫入緩存，等緩存滿足一定大小之後再一起落到HFile。
寫入數據流程圖如下：
從上面的讀寫數據交互來看，可以得出以下幾點：
1、由於客戶端會將hbase:meta元數據表緩存在本地，因此上述步驟中前四步只會在客戶端第一次請求的時候發生，之後所有請求都直接從緩存中加載元數據。如果集羣發生某些變化導致hbase:meta元數據更改，客戶端再根據本地元數據表請求的時候就會發生異常，此時客戶端需要重新加載一份最新的元數據表到本地。
2、客戶端只需要配置zookeeper的訪問地址以及根目錄，就可以進行正常的讀寫請求，不需要配置集羣的RegionServer地址列表。
3、Hbase數據的讀寫交互只涉及到Zookeeper、RegionServer服務（zk上存儲了元數據meta表的所在的RegionServer信息，meta表又存儲了其他region數據），Master服務並沒有參與，master僅僅維護者table和region的元數據信息，負載很低。