目錄
0. 前言
Hbase在大數據領域中起着重要角色，在處理海量數據時候能達到秒級響應，很多公司都有自己的Hbase集羣，在存儲處理數據方面有着明顯的優勢。本文從Hbase的基本概念及架構原理進行深入解讀，旨在幫助讀者能從整體上認識Hbase，並對Hbase基本架構原理有個深入瞭解。
通過本文你可以獲取如下幾方面知識：
- （1）Hbase是什麼
- （2）Hbase與關係型數據庫之間的區別
- （3）Hbase的特點
- （4）Hbase架構及原理
- （5）Hbase讀寫流程
- （6）storefile合併過程
- （7）region切分過程
1. 初識Hbase
1.1 Hbase的定義
HBase 是一種分佈式、可擴展、支持海量數據存儲的 NoSQL 數據庫。一句話概括爲：hbase是hadoop的數據庫，是構建在hadoop之上的分佈式數據庫。邏輯上，HBase 的數據模型同關係型數據庫很類似，數據存儲在一張表中，有行有列。但從 HBase 的底層物理存儲結構（K-V）來看，HBase 更像是一個 multi-dimensional map(可以理解爲多維map結構)。
1.2 Hbase的邏輯結構
如上圖所示反映了Hbase邏輯結構，如字段name下的小眼睛數據是如何被定位的呢？首先每一條數據都有一個rowkey,rowkey類似於mysql表中的主鍵具有唯一性。其次有一個列族（列簇）這裏我們就叫爲列族吧，正確的應該是列簇，但是呢很多程序員也都這麼叫，錯誤的叫的多了也便是正確的了，（哈哈，所以說這個世界上在人類所能認知的範圍內，真理還是掌握在大多數人手中，因爲少數人服從多數人。），列族其實就是列的集合，一個列族對應物理存儲上一個文件夾。爲什麼要設計列族這個概念呢？我想可能是對錶的一種切分吧，當一個列族所能容納字段越來越多的時候，此時表越來越寬就需要對錶進行縱向切分，便有了列族的概念。當表的記錄數越來越多的時候，表變得越來越高（高表），此時就需要對錶進行橫向切分，橫向切分後得到的切片就是region，所以列族是對錶的垂直切分，region是對錶的橫向切分。 一張表一條數據實際上是K-V結構，只不過這個key是多維的。
1.3 Hbase物理存儲結構
由上圖可以看出，對比關係型數據庫中表結構，一條數據被當成了多條記錄存儲，每一個value值前面都對應rowkey->column family->column qualifier->timestamp作爲一個key,不同數據的版本需要timestamp進行標記，從上面也可以看出hbase存儲相對於關係型數據庫結構化表來講，數據存在一定膨脹，因此在使用時候需要進行壓縮。在表中我們也可以看到Type類型，他標記着這條數據操作行爲，put爲插入數據，delete爲刪除數據。
1.4 Hbase數據模型
（1）Name Space
Name Space命名空間，類似於關係型數據庫中的數據庫的概念(database),每個命名空間下有多張表。HBase有兩個自帶的命名空間，分別是 hbase 和 default，hbase 中存放的是 HBase 內置的表，default 表是用戶默認使用的命名空間。
（2）Region
類似於關係型數據庫的表概念。不同的是，HBase 定義表時只需要聲明列族即可，不需要聲明具體的列（與關係型數據庫最主要的一個區別）。這意味着，往 HBase 寫入數據時，字段可以動態、按需指定。因此，和關係型數據庫相比，HBase 能夠輕鬆應對字段變更的場景。
（3） Row
HBase 表中的每行數據都由一個 RowKey 和多個 Column（列）組成，數據是按照 RowKey的字典順序存儲的，並且查詢數據時只能根據 RowKey 進行檢索，所以 RowKey 的設計十分重要。
（4） Column
HBase 中的每個列都由 Column Family(列族)和 Column Qualifier（列限定符）進行限定，例如 info：name，info：age。建表時，只需指明列族，而列限定符無需預先定義，也就是定義一個hbase表時候只需要指定列族即可，不像關係型數據庫建表時候字段類型是固定的，這也說明了Hbase的靈活性。
（5） Time Stamp
用於標識數據的不同版本（version），每條數據寫入時，如果不指定時間戳，系統會自動爲其加上該字段，其值爲寫入 HBase 的時間。
（6） Cell
由{rowkey, column Family：column Qualifier, time Stamp} 唯一確定的單元。cell 中的數據是沒有類型的，全部是字節碼形式存貯。
2 Hbase與關係型數據庫之間的對比
| Hbase | RDBMS | |
| 結構上 | 數據庫以region的形式存在 | 數據庫以表的形式存在 |
| 構建在HDFS之上 | 支持FAT、NTFS、EXT、文件系統 | |
| 使用WAL（Write-Ahead Logs）存儲日誌 | 使用Commit log存儲日誌 | |
| 藉助Zookeeper系統 | 參考系統是座標系統 | |
| 使用行鍵（row key） | 使用主鍵（PK） | |
| 支持分片 | 支持分區 | |
| 使用行、列、列族和單元格 | 使用行、列、單元格 | |
| 功能上 | 支持向外擴展 | 支持向上擴展 |
| 使用API和MapReduce來訪問HBase表數據 | 使用SQL查詢 | |
| 面向列，即每一列都是一個連續的單元 | 面向行，即每一行都是一個連續單元 | |
| 數據總量不依賴具體某臺機器，而取決於機器數量 | 數據總量依賴於服務器配置 | |
| HBase不支持ACID（Atomicity、Consistency、Isolation、Durability） | 支持ACID | |
| 適合結構化數據和非結構化數據 | 適合結構化數據 | |
| 一般都是分佈式的 | 傳統關係型數據庫一般都是中心化的 | |
| HBase不支持事務 | 支持事務 | |
| 不支持Join | 支持Join |
3 Hbase的優勢
（1）橫向擴展
HBase支持橫向擴展，也就是說如果現有服務器硬件性能出現瓶頸，不需要停現有的集羣提升硬件配置，而只需要在現有的正在運行的集羣中添加新的機器節點即可，而且新的RegionServer一旦建立完畢，集羣會開始重新調整。
（2）列式存儲
HBase是面向列存儲的，每個列都單獨存儲，所以在HBase中列是連續存儲的，而行不是。並且列可以動態增加，列爲空時就不存儲數據,節省存儲空間，RDBMS的行有多少列是固定的，若某一列爲null時就浪費了存儲空間。HBase爲null的列不會被存儲，這樣既節省了空間又提高了讀性能。
（3）半結構化或非結構化數據
Hbase支持半結構化或非結構化的數據存儲，對於數據結構字段不夠確定或雜亂無章非常難按一個概念去進行抽取的數據適合用HBase，因爲HBase支持動態添加列。
（4）高併發、隨機讀寫
HBase採用LSMT（log-structured merge-tree）架構進行設計，這種架構會週期性地將小文件合併成大文件以減少磁盤訪問同時減少NameNode壓力。本質上解決了HDFS不能隨機讀寫的問題，在寫入（插入）數據方面具有很大優勢，特別在PB級以上數據優勢明顯，適用於插入比查詢操作更頻繁的情況，寫比查詢更高效。（強調寫的能力）
（5）自動切分
HBase表是由分佈在多個RegionServer中的region組成的，這些RegionServer又分佈在不同的DataNode上，如果一個region增長到了一個閾值，爲了負載均衡和減少IO，HBase可以自動或手動干預的將region切分爲更小的region，也稱之爲subregion。
（6）自動故障處理和負載均衡
HBase運行在HDFS上，所以HBase中的數據以多副本形式存放，數據也服從分佈式存放，數據的恢復也可以得到保障。另外，HMaster和RegionServer也是多副本的。
4 Hbase基本架構及原理
圖1反映了Hbase集羣間各個服務角色之間的關係，其服務之間的關係及作用如下描述：
（1）架構角色
1）Region Server（RS）
Region Server 爲 Region 的管理者，其實現類爲 HRegionServer，主要作用如下:
- 對於數據的操作：get, put, delete；
- 對於 Region 的操作：splitRegion、compactRegion。
總結：RS其實實現的是類似於關係型數據庫中的DML操作，實現對數據的管理
2）Master
Master 是所有 Region Server 的管理者，其實現類爲 HMaster，主要作用如下：
- 對於表的操作：create, delete, alter.(類似於關係型數據庫的DDL操作，實現的是對錶的管理)；
- 對於RegionServer的操作：分配regions到每個RegionServer；監控每個RegionServer的狀態；負載均衡和故障轉移；發 現失效的RegionSercer重新爲他們分配自己負責的region。
- hdfs上的垃圾文件回收（標記爲刪除的且經過major compact的文件）
3）zookeeper
HBase 通過 Zookeeper 來做 Master 的高可用、RegionServer 的監控、元數據的入口以及集羣配置的維護等工作。
- 負責Master高可用時候切換工作
- 降低Master的負擔，承擔Master部分工作
4）HDFS
HDFS 爲 HBase 提供最終的底層數據存儲服務，同時爲 HBase 提供高可用的支持，底層的最終存儲是構建在HDFS之上的，這也是爲什麼Hbase是hadoop的數據庫的緣由
圖2反映了Hbase的架構原理圖，其原理如下所示：
1）Storefile
保存實際數據的物理文件，StoreFile以 HFile 的形式存儲在 HDFS 上。每個 Store 會有一個或多個 StoreFile（HFile），數據在每個 StoreFile 中都是有序的。HFile可以理解爲一種文件格式，與orc,txt等是一樣的概念，只不過是以key,value的形式存儲。
2）MemStore
寫緩存，由於HFile中數據要求是有序的，所以數據是先存儲在MemStore中，排好序後，等到達刷寫時機纔會刷寫到Hflie,每次刷寫都會形成一個新的HFile
3) WAL
由於數據要經 MemStore 排序後才能刷寫到 HFile，但把數據保存在內存中會有很高的概率導致數據丟失，爲了解決這個問題，數據 會先寫在一個叫做 Write-Ahead logfile 的文件中，然後再寫入 MemStore 中。所以在系統出現故障的時候，數據可以通過這個日誌文件重建。WAL類似於Mysql的binlog，用來做災難恢復。Hlog記錄所有數據的變更，一旦數據修改，就可以從Hlog恢復，每個HRegionSever維護一個HLog.
疑問，爲什麼是HRegionSever維護一個HLog，而不是HRgeion維護一個HLog?
解釋：這樣不同region(不同表)的日誌會混在一起，這樣做的目的不斷追加單個文件相對於同時寫多個文件而言，可以減少磁盤的尋址次數，可以提高對table的寫性能。
缺點：如果一臺HRegionSever下線了，爲了恢復其上的region，需要將HRegionSever上的log進行拆分，然後分發到其他HRegionSever進行恢復。
4) HRegion
HRegion也就是我們所說的Region, 一個Table由一個或者多個Region組成，一個Region中可以看成是Table按行切分且有序的數據塊，每個Region都有自身的StartKey、EndKey。一個Region由一個或者多個Store組成，每個Store存儲該Table對應Region中一個列簇的數據，相同列簇的列存儲在同一個Store中。同一個Table的Region會分佈在集羣中不同的RegionServer上以實現讀寫請求的負載均衡。故，一個RegionServer中將會存儲來自不同Table的N多個Region。
Store、Region與Table的關係可以表述如下：多個Store（列簇）組成Region，多個Region（行數據塊）組成完整的Table。
其中，Store由Memstore（內存）、StoreFile（磁盤）兩部分組成。
5. Hbase寫入數據的流程
5.1 寫入流程分析
寫入流程具體如下圖所示：
寫流程：
1）Client 先訪問 zookeeper，獲取 hbase:meta 表位於哪個 Region Server。
2）訪問對應的 Region Server，獲取 hbase:meta 表，根據讀請求的 namespace:table/rowkey，
查詢出目標數據位於哪個 Region Server 中的哪個 Region 中。並將該 table 的 region 信息以
及 meta 表的位置信息緩存在客戶端的 meta cache，方便下次訪問。
3）與目標 Region Server 進行通訊；
4）將數分別寫入HLog和MemStore中，數據會在MemStore 進行排序（若MemStore中數據有丟失，則可以從HLog中進行恢復）；
5）向客戶端發送 ack；（當寫入到內存時就可立即返回，代表寫入成功，這也是Hbase，I/O高性能的保證）
6）當MemStore 的數據達到一定閾值後，將數據刷寫到StoreFile文件。
7）當多個StoreFile文件達到一定大小後會觸發Compact操作，合併爲一個StoreFile,這裏同時進行版本的合併（更新）及數據的刪除
8）當Compact後會逐步形成越來越大的StoreFile,此時會觸發Split操作，把當前的StoreFile進行分割，相當於一個大的Region進行分割的過程，大的Region分割成兩個。
Hbase的操作其實只有兩個查詢和寫入（增加），其他的更新和刪除數據都是在Compact階段完成的，所以用戶的寫操作只需要到內存即可立即返回，從而保證I/O的高性能。
老版本寫的時候需要先找-Root-表，-Root-是存放meta表的元信息，爲什麼新版本取消了這一步操作呢？
- -ROOT-：記錄.META.表的Region信息。
- hbase:meta：記錄用戶表的Region信息。
- 其中-ROOT-表本身只會有一個region，這樣保證了只需要三次跳轉，就能定位到任意region
從0.96版本以後，三層架構被改爲二層架構，-ROOT-表被去掉了，同時zk中的/hbase/root-region-server也被去掉了。直接把.META.表所在的RegionServer信息存儲到了zk中的/hbase/meta-region-server去了。再後來引入了namespace，.META.表這樣彆扭的名字被修改成了hbase:meta。
原因可能是Hbase根據用戶使用的實際需求，大部分用戶存不了這麼多數據量而取消掉。最開始設計時候，Hbase
考慮到meta表有可能分裂造成找不到meta表信息，於是採用-Root-表來存放meta表的元信息，但是實際中用戶根
本就存不了那麼多數據致使meta表分裂。試想meta表存放元信息，默認10G分裂，我們可以簡單的估算一下，假設
meta表中一條數據爲1K（實際上應該比這小很多，爲了估算方便暫時取1K），1K對應10G，那麼等到分裂時，10G
的meta表元信息對應數據量大概爲：1024*1024*10*10=104857600G=100PB。實際而言大部分公司使用來看是到
不了這個數據量的，因而Hbase根據實際使用需求取消掉了-Root-表。
5.2 刷寫時機分析
1.memstroe級別的限制：當Region中任意一個MemStore的大小達到了上限，會觸發memstore的刷寫。(木桶原理)
一個store（列簇）對應一個memstore，一個region中包含多個列簇，也就是說一個region中可能包含多個memstore
刷寫閾值：
hbase.hregion.memstore.flush.size（默認值128M），
2.Region級別限制：當Region中所有Memstore的大小總和達到了上限，會觸發memstore刷寫。
當memstore的大小達到了如下參數值時
hbase.hregion.memstore.flush.size（默認值128M）* hbase.hregion.memstore.block.multiplier（默認值4）時
也就是128*4=512MB的時候，那麼除了觸發 MemStore 刷寫之外，HBase 還會在刷寫的時候同時阻塞所有寫入該 Store 的寫請求！這時候如果你往對應的 Store 寫數據，會出現 RegionTooBusyException 異常。會阻止繼續往該memstore寫數據。
3.Region Server級別限制：當一個Region Server中所有Memstore的大小總和達到了上限，會觸發部分Memstore刷寫。
當RegionServer中memstore的總大小達到
java_heapsize
* hbase.regionserver.global.memstore.size（默認值0.4）
* hbase.regionserver.global.memstore.size.lower.limit（默認值0.95），
Flush順序是按照Memstore由大到小執行，先Flush Memstore最大的Region，再執行次大的，直至總體Memstore內存使用量低於閾值:
hbase.regionserver.global.memstore.lowerLimit ＊ hbase_heapsize，默認 38%的JVM內存使用量。
0.4*0.95=0.38
需要注意的是，如果達到了 RegionServer 級別的 Flush，那麼當前 RegionServer 的所有寫操作將會被阻塞，而且這個阻塞可能會持續到分鐘級別。
4. HBase定期刷寫MemStore:當到達自動刷寫的時間，也會觸發memstore flush。自動刷新的時間間隔由該屬性進行配置
hbase.regionserver.optionalcacheflushinterval（默認1小時）。
爲避免所有的MemStore在同一時間都進行flush導致的問題，定期自動刷寫會有 0 ~ 5 分鐘的延遲
5.HLog級別的限制：當WAL文件的數量超過hbase.regionserver.max.logs，region會按照時間順序依次進行刷寫，直到WAL文件數量減小到hbase.regionserver.max.log以下（該屬性名已經廢棄，現無需手動設置，最大值爲32）。
6.手動執行flush：用戶可以通過shell命令 flush ‘tablename’或者flush ‘region name’分別對一個表或者一個Region進行flush。
Shell 中通過執行 flush 命令：
hbase> flush 'TABLENAME'
hbase> flush 'REGIONNAME'
hbase> flush 'ENCODED_REGIONNAME'
hbase> flush 'REGION_SERVER_NAME'
調用可以調用 Admin 接口提供的方法：
void flush(TableName tableName) throws IOException;
void flushRegion(byte[] regionName) throws IOException;
void flushRegionServer(ServerName serverName) throws IOException;
Memstore Flush對業務讀寫的影響：
影響甚微：
正常情況下，大部分Memstore Flush操作都不會對業務讀寫產生太大影響，比如這幾種場景：
HBase定期刷新Memstore、手動執行flush操作、觸發Memstore級別限制、觸發HLog數量限制以及觸發Region級
別限制等，這幾種場景只會阻塞對應Region上的寫請求，阻塞時間很短，毫秒級別。
影響較大：
然而一旦觸發Region Server級別限制導致flush，就會對用戶請求產生較大的影響。會阻塞所有落在該Region
Server上的更新操作，阻塞時間很長，甚至可以達到分鐘級別。一般情況下Region Server級別限制很難觸發，
但在一些極端情況下也不排除有觸發的可能
5.3 合併過程分析
由於memstore每次刷寫都會生成一個新的HFile，且同一個字段的不同版本（timestamp）和不同類型（Put/Delete）有可能會分佈在不同的HFile中，因此查詢時需要遍歷所有的HFile。爲了減少HFile的個數，以及清理掉過期和刪除的數據，會進行StoreFile Compaction。
Compaction分爲兩種，分別是Minor Compaction和Major Compaction。Minor Compaction會將臨近的若干個較小的HFile合併成一個較大的HFile，但不會清理過期和刪除的數據。Major Compaction會將一個Store下的所有的HFile合併成一個大HFile，並且會清理掉過期和刪除的數據。
5.4 Region切分分析
默認情況下，每個Table起初只有一個Region，隨着數據的不斷寫入，Region會自動進行拆分。剛拆分時，兩個子Region都位於當前的Region Server，但處於負載均衡的考慮，HMaster有可能會將某個Region轉移給其他的Region Server。Hbase的Region切分策略主要有以下幾個策略
Region Split時機：
1. ConstantSizeRegionSplitPolicy：0.94版本前默認切分策略。當1個region中的某個Store下所有StoreFile的總大小超過
hbase.hregion.max.filesize
該Region就會進行拆分（0.94版本之前）。
這個是比較容易產生誤解的切分策略，從字面意思來看，當region大小大於某個閾（hbase.hregion.max.filesize）之後就會觸發切分，實際上並不是這樣，真正實現中這個閾值是對於某個store來說的，即一個region中最大store的大小大於設置閾值之後纔會觸發切分。另外一個大家比較關心的問題是這裏所說的store大小是壓縮後的文件總大小還是未壓縮文件總大小，實際實現中store大小爲壓縮後的文件大小（採用壓縮的場景）。
ConstantSizeRegionSplitPolicy相對來來說最容易想到，但是在生產線上這種切分策略卻有相當大的弊端：切分策略對於大表和小表沒有明顯的區分。閾值（hbase.hregion.max.filesize，默認10G）設置較大對大表比較友好，但是小表就有可能不會觸發分裂，極端情況下可能就1個，這對業務來說並不是什麼好事。如果設置較小則對小表友好，但一個大表就會在整個集羣產生大量的region，這對於集羣的管理、資源使用、failover來說都不是一件好事。
2. IncreasingToUpperBoundRegionSplitPolicy : 0.94版本~2.0版本默認切分策略。當1個region中的某個Store下所有StoreFile的總大小超過如下參數值時
Min(R^2 * "hbase.hregion.memstore.flush.size",hbase.hregion.max.filesize")
該Region就會進行拆分，其中R爲當前Region Server中屬於該Region(table)的個數（0.94版本~2.0版本）。
這種切分策略很好的彌補了ConstantSizeRegionSplitPolicy的短板，能夠自適應大表和小表。而且在大集羣條件下對於很多大表來說表現很優秀，但並不完美，這種策略下很多小表會在大集羣中產生大量小region，分散在整個集羣中。而且在發生region遷移時也可能會觸發region分裂。
從這個算是我們可以得出flushsize爲128M、maxFileSize爲10G的情況下，可以計算出Region的分裂情況如下：
第一次拆分大小爲：min(10G，1*1*128M)=128M
第二次拆分大小爲：min(10G，3*3*128M)=1152M
第三次拆分大小爲：min(10G，5*5*128M)=3200M
第四次拆分大小爲：min(10G，7*7*128M)=6272M
第五次拆分大小爲：min(10G，9*9*128M)=10G
第五次拆分大小爲：min(10G，11*11*128M)=10G
從上面的計算我們可以看到這種策略能夠自適應大表和小表，但是這種策略會導致小表產生比較多的小region，對於小表還是不是很完美。
3. SteppingSplitPolicy: 2.0版本默認切分策略。這種切分策略的切分閾值又發生了變化，相比 IncreasingToUpperBoundRegionSplitPolicy簡單了一些，依然和待分裂region所屬表在當前regionserver上的region個數有關係。
如果region個數等於1，切分閾值爲flush size * 2，否則爲MaxRegionFileSize
If(region=1) {flush size * 2}
else {MaxRegionFileSize}
假設flushSize爲128M，MaxRegionFileSize爲10G,則
第一次拆分大小爲：2*128M=256M
第二次拆分大小爲：10G
這種切分策略對於大集羣中的大表、小表會比IncreasingToUpperBoundRegionSplitPolicy更加友好，小表不會再產生大量的小region，而是適可而止。
4.其他策略：另外，還有一些其他分裂策略，比如使用DisableSplitPolicy:可以禁止region發生分裂；而KeyPrefixRegionSplitPolicy，DelimitedKeyPrefixRegionSplitPolicy對於切分策略依然依據默認切分策略，但對於切分點有自己的看法，比如KeyPrefixRegionSplitPolicy要求必須讓相同的PrefixKey待在一個region中。在用法上，一般情況下使用默認切分策略即可，也可以在cf級別設置region切分策略，命令爲：
create ’table’, {NAME => ‘cf’, SPLIT_POLICY => ‘org.apache.hadoop.hbase.regionserver. ConstantSizeRegionSplitPolicy'}
5.5 meta存儲位置尋找
hbase:meta表，記錄了集羣中所有存儲region的位置信息。
如何尋找這張表呢？首先得知道這張表儲存在哪個機器上？
我們知道meta存儲在zookeeper中，所以我們需要先連接到zookeeper的客戶端進行查看
步驟1：先進入zookeeper的客戶端
進入zk的bin目錄下執行如下命令
./zkCli.sh -server bigdata1:2181
進去後連接狀態如下：
執行ls /命令查看其下面的目錄
目錄下有個hbase-unsecure是我們需要找的目錄
查看該目錄 ls /hbase-unsecure
有個meta-region-server是我們需要尋找的表。
查看該表中的內容：
get /hbase-unsecure/meta-region-server
可以看到該表存儲在bigdata4機器上。
通過在hbase中,scan 'hbase:meta'就可以看到哪個表示哪些服務器在維護。
6. Hbase讀流程分析
1）Client先訪問zookeeper，獲取hbase:meta表位於哪個Region Server。
2）訪問對應的Region Server，獲取hbase:meta表，根據讀請求的namespace:table/rowkey，查詢出目標數據位於哪個Region Server中的哪個Region中。並將該table的region信息以及meta表的位置信息緩存在客戶端的meta cache，方便下次訪問。
3）與目標Region Server進行通訊；
4）分別在Block Cache（讀緩存），MemStore和Store File（HFile）中查詢目標數據，並將查到的所有數據進行合併。此處所有數據是指同一條數據的不同版本（time stamp）或者不同的類型（Put/Delete）。
5） 將從文件中查詢到的數據塊（Block，HFile數據存儲單元，默認大小爲64KB）緩存到Block Cache。
6）將合併後的最終結果返回給客戶端。
7 小結
本文對HBase的基本概念、原理架構進行了深入分析，並對其讀寫流程、Flush機制、切分機制、合併機制進行了研究。通過本文你可以對HBase相關的基本原理概念流程有一定的認識。
參考鏈接：
https://yq.aliyun.com/articles/727443?spm=a2c4e.11163080.searchblog.129.48782ec1QqNAj4
http://hbasefly.com/2016/03/23/hbase-memstore-flush/