寫流程

1. 向zookeeper發起請求，從ROOT表中獲得META所在的region，再根據table，namespace，rowkey，去meta表中找到目標數據對應的region信息以及regionserver

2. 把數據分別寫到HLog和MemStore上一份，若MemStore中的數據有丟失，則可在HLog上恢復

3. 當memstore數據達到閾值（默認是64M），將數據刷到硬盤，將內存中的數據刪除同時刪除Hlog中的歷史數據。

4. 當多個StoreFile文件達到一定的大小后，會觸發Compact合并操作，合并為一個StoreFile，這里同時進行版本的合并和數據刪除。

5. 當Compact后，逐步形成越來越大的StoreFIle后，會觸發Split操作，把當前的StoreFile分成兩個，這里相當于把一個大的region分割成兩個region

6. 當hregionser宕機后，將hregionserver上的hlog拆分，然后分配給不同的hregionserver加載，修改.META.

讀流程

1. 首先用MemStoreScanner搜索MemStore里是否有所查的rowKey（這一步在內存中，很快），

2. 同時也會用Bloom Block通過一定算法過濾掉大部分一定不包含所查rowKey的HFile，

3. 上面提到在RegionServer啟動的時候就會把Trailer，和Load-on-open-section里的block先后加載到內存，所以接下來會查Trailer，因為它記錄了每個HFile的偏移量，可以快速排除掉剩下的部分HFile。

4. 經過上面兩步，剩下的就是很少一部分的HFile了，就需要根據Index Block索引數據（這部分的Block已經在內存）快速查找rowkey所在的block的位置；

5. 找到block的位置后，檢查這個block是否在blockCache中，在則直接去取，如果不在的話把這個block加載到blockCache進行緩存，

6. 最后掃描這些讀到內存中的Block（可能有多個，因為有多版本），找到對應rowKey返回需要的版本。

熟悉了HBase的讀寫流程后（尤其是寫流程），了解lsm tree就會變得容易很多了。Log-Structured Merge-Tree中文翻譯是日志結構合并樹。那我們就從日志結構與合并樹這兩個方面來講。

日志結構

我們知道磁盤隨機讀寫性能是比順序讀寫慢至少3個數量級的，日志的特點是它是順序追加寫的，可以保證非常好的寫操作性能，但是從日志文件中讀一些數據將會比寫操作需要更多的時間，需要倒序掃描，直接找到所需的內容。
因此日志適用的場景非常有限：

1. 數據是被整體訪問，像大部分數據庫的WAL(write-ahead log)、HDFS

2. 記錄了文件明確的偏移量，比如Kafka

為了為更復雜的讀場景（比如按key或者range）提供高效的性能，人們發明了幾種方式：

二分查找: 將文件數據有序保存，使用二分查找來完成特定key的查找。

哈希：用哈希將數據分割為不同的bucket

B+樹：使用B+樹 或者 ISAM 等方法，可以減少外部文件的讀取

外部文件： 將數據保存為日志，并創建一個hash或者查找樹映射相應的文件。

所有的方法都可以有效的提高了讀操作的性能（最少提供了O(log(n)) )，但是，卻丟失了日志文件超好的寫性能。上面這些方法，都強加了總體的結構信息在數據上，數據被按照特定的方式放置，所以可以很快的找到特定的數據，但是卻對寫操作不友善，讓寫操作性能下降。更糟糕的是，當我們需要更新hash或者B+樹的結構時，需要同時更新文件系統中特定的部分，這就是上面說的比較慢的隨機讀寫操作。這種隨機的操作要盡量減少。

此時，LSM 被發明了， LSM 使用一種不同于上述四種的方法，保持了日志文件寫性能，以及微小的讀操作性能損失。本質上就是通過把隨機寫的數據寫到內存，然后定期flush到磁盤，對于磁盤來說，讓所有的操作順序化，而不是隨機讀寫。

合并樹

LSM樹原理把一棵大樹拆分成N棵小樹，它首先寫入內存中即是小樹，隨著小樹越來越大，會flush到磁盤中，磁盤中的樹定期可以做merge操作，合并成一棵大樹，以優化讀性能。
lsm tree，理論上，可以是內存中樹的一部分和磁盤中第一層樹做merge，對于磁盤中的樹直接做update操作有可能會破壞物理block的連續性，但是實際應用中，一般lsm有多層，當磁盤中的小樹合并成一個大樹的時候，可以重新排好順序，使得block連續，優化讀性能。
hbase在實現中，是把整個內存在一定閾值后，flush到disk中，形成一個file，這個file的存儲也就是一個小的B+樹，因為hbase一般是部署在hdfs上，hdfs不支持對文件的update操作，所以hbase這么整體內存flush，而不是和磁盤中的小樹merge update，這個設計也就能講通了。內存flush到磁盤上的小樹，定期也會合并成一個大樹。整體上hbase就是用了lsm tree的思路。