Hbase架构与原理
HBase是Apache Hadoop中的一個子項目，Hbase依托于Hadoop的HDFS作為最基本存儲基礎單元，通過使用hadoop的DFS工具就可以看到這些這些數據存儲文件夾的結構,還可以通過Map/Reduce的框架(算法)對HBase進行操作
一、?? hbase架構
?1.概述。
HBase是Apache Hadoop的數據庫，能夠對大型數據提供隨機、實時的讀寫訪問。HBase的目標是存儲并處理大型的數據。HBase是一個開源的，分布式的，多版本的，面向列的存儲模型。它存儲的是松散型數據。
上圖是hadoop的生態系統描述，hadoop所有應用都是構建于hdfs（它提供高可靠的底層存儲支持，幾乎已經成為分布式文件存儲系統事實上的工業標準）之上的分布式列存儲系統，主要用于海量結構化數據存儲。
HBase是一種NoSQL數據庫. NoSQL是一個通用詞表示數據庫不是RDBMS ，后者支持 SQL 作為主要訪問手段。有許多種 NoSQL 數據庫: BerkeleyDB 是本地 NoSQL 數據庫例子, 而 HBase 是大型分布式數據庫。 技術上來說, HBase 更像是"數據存儲(Data Store)" 多于 "數據庫(Data Base)"。因為缺少很多RDBMS特性, 如列類型，第二索引，觸發器，高級查詢語言等
然而, HBase 有許多特征同時支持線性化和模塊化擴充。 HBase 集群通過增加RegionServers進行擴充。 它可以放在普通的服務器中。例如，如果集群從10個擴充到20個RegionServer，存儲空間和處理容量都同時翻倍。 RDBMS 也能很好擴充， 但僅對一個點 - 特別是對一個單獨數據庫服務器的大小 - 同時，為了更好的性能，需要特殊的硬件和存儲設備。Hbase特性：
強一致性讀寫: HBase 不是 "最終一致性(eventually consistent)" 數據存儲. 這讓它很適合高速計數聚合類任務。
自動分片(Automatic sharding):HBase 表通過region分布在集群中。數據增長時，region會自動分割并重新分布。
RegionServer 自動故障轉移
Hadoop/HDFS 集成: HBase 支持本機外HDFS 作為它的分布式文件系統。
MapReduce: HBase 通過MapReduce支持大并發處理， HBase 可以同時做源和目標.
Java 客戶端 API: HBase 支持易于使用的 Java API 進行編程訪問.
Thrift/REST API:HBase 也支持Thrift和 REST 作為非Java 前端.
Block Cache 和 Bloom Filters: 對于大容量查詢優化， HBase支持 Block Cache 和 Bloom Filters。
運維管理: HBase提供內置網頁用于運維視角和JMX 度量.
前文提到Hbase是一個列式存儲的數據庫，那么什么是列式存儲，它與傳統的RDBMS采用的行式存儲又有什么區別？列存儲不同于傳統的關系型數據庫，其數據在表中是按行存儲的，列方式所帶來的重要好處之一就是，由于查詢中的選擇規則是通過列來定義的，因此整個數據庫是自動索引化的。按列存儲每個字段的數據聚集存儲，在查詢只需要少數幾個字段的時候，能大大減少讀取的數據量，一個字段的數據聚集存儲，那就更容易為這種聚集存儲設計更好的壓縮/解壓算法。這張圖講述了傳統的行存儲和列存儲的區別：
?2.hbase架構
注：準確的說位于上圖下半部分的組建應該是hdfs而非hadoop，hbase并不依賴于hadoop，但是它構建于hdfs之上。
Zookeeper：
Zookeeper Quorum存儲-ROOT-表地址、HMaster地址
HRegionServer把自己以Ephedral方式注冊到Zookeeper中，HMaster隨時感知各個HRegionServer的健康狀況
Zookeeper避免HMaster單點問題
HMaster：
HMaster沒有單點問題，HBase中可以啟動多個HMaster，通過Zookeeper的MasterElection機制保證總有一個Master在運行
主要負責Table和Region的管理工作：
1 管理用戶對表的增刪改查操作
2 管理HRegionServer的負載均衡，調整Region分布
3 Region Split后，負責新Region的分布
4 在HRegionServer停機后，負責失效HRegionServer上Region遷移
HRegionServer：
HBase中最核心的模塊，主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據
HRegionServer管理一些列HRegion對象；
每個HRegion對應Table中一個Region，HRegion由多個HStore組成；
每個HStore對應Table中一個Column Family的存儲；
Column Family就是一個集中的存儲單元，故將具有相同IO特性的Column放在一個Column Family會更高效
HStore：
HBase存儲的核心。由MemStore和StoreFile組成。
MemStore是Sorted Memory Buffer。用戶寫入數據的流程：
Client寫入 -> 存入MemStore，一直到MemStore滿 -> Flush成一個StoreFile，直至增長到一定閾值 -> 出發Compact合并操作 -> 多個StoreFile合并成一個StoreFile，同時進行版本合并和數據刪除 -> 當StoreFiles Compact后，逐步形成越來越大的StoreFile ->單個StoreFile大小超過一定閾值后，觸發Split操作，把當前Region Split成2個Region，Region會下線，新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer 上，使得原先1個Region的壓力得以分流到2個Region上
由此過程可知，HBase只是增加數據，所有的更新和刪除操作，都是在Compact階段做的，所以，用戶寫操作只需要進入到內存即可立即返回，從而保證I/O高性能。
HLog
引入HLog原因：
在分布式系統環境中，無法避免系統出錯或者宕機，一旦HRegionServer意外退出，MemStore中的內存數據就會丟失，引入HLog就是防止這種情況
工作機制：
每 個HRegionServer中都會有一個HLog對象，HLog是一個實現Write Ahead Log的類，每次用戶操作寫入Memstore的同時，也會寫一份數據到HLog文件，HLog文件定期會滾動出新，并刪除舊的文件(已持久化到 StoreFile中的數據)。當HRegionServer意外終止后，HMaster會通過Zookeeper感知，HMaster首先處理遺留的 HLog文件，將不同region的log數據拆分，分別放到相應region目錄下，然后再將失效的region重新分配，領取到這些region的 HRegionServer在Load Region的過程中，會發現有歷史HLog需要處理，因此會Replay HLog中的數據到MemStore中，然后flush到StoreFiles，完成數據恢復。
HBase存儲格式
HBase中的所有數據文件都存儲在Hadoop HDFS文件系統上，格式主要有兩種：
1 HFile HBase中KeyValue數據的存儲格式，HFile是Hadoop的二進制格式文件，實際上StoreFile就是對HFile做了輕量級包裝，即StoreFile底層就是HFile
2 HLog File，HBase中WAL（Write Ahead Log） 的存儲格式，物理上是Hadoop的Sequence File
HFile
HFile文件不定長，長度固定的塊只有兩個：Trailer和FileInfo
Trailer中指針指向其他數據塊的起始點
File Info中記錄了文件的一些Meta信息，例如：AVG_KEY_LEN,AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等
Data Index和Meta Index塊記錄了每個Data塊和Meta塊的起始點
Data Block是HBase I/O的基本單元，為了提高效率，HRegionServer中有基于LRU的Block Cache機制
每個Data塊的大小可以在創建一個Table的時候通過參數指定，大號的Block有利于順序Scan，小號Block利于隨機查詢
每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成, Magic內容就是一些隨機數字，目的是防止數據損壞
HFile里面的每個KeyValue對就是一個簡單的byte數組。這個byte數組里面包含了很多項，并且有固定的結構。
KeyLength和ValueLength：兩個固定的長度，分別代表Key和Value的長度
Key部分：Row Length是固定長度的數值，表示RowKey的長度，Row 就是RowKey
Column Family Length是固定長度的數值，表示Family的長度
接著就是Column Family，再接著是Qualifier，然后是兩個固定長度的數值，表示Time Stamp和Key Type（Put/Delete）
Value部分沒有這么復雜的結構，就是純粹的二進制數據
HLog文件就是一個普通的Hadoop Sequence File，Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬信息，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是“寫入時間”，sequence number的起始值為0，或者是最近一次存入文件系統中sequence number。
HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue
?3.什么時候應該使用hbase
在學習一門新技術的時候首先需要明白，我們到底應該在什么時候使用它，然后才是怎么去使用它，Hbase并不適合所有問題。
首先，確信有足夠多數據，如果有上億或上千億行數據，HBase是很好的備選。如果只有上千或上百萬行，則用傳統的RDBMS可能是更好的選擇。因為所有數據可以在一兩個節點保存，集群其他節點可能閑置。
其次，確信可以不依賴所有RDBMS的額外特性 (e.g., 列數據類型, 第二索引,事物,高級查詢語言等.) 一個建立在RDBMS上應用，如不能僅通過改變一個JDBC驅動移植到HBase。相對于移植， 需考慮從RDBMS 到 HBase是一次完全的重新設計。
第三， 確信你有足夠硬件。甚至 HDFS 在小于5個數據節點時，干不好什么事情 (根據如HDFS 塊復制具有缺省值 3), 還要加上一個NameNode.
HBase 能在單獨的筆記本上運行良好。但這應僅當成開發配置。
4.目錄表（.meta.和-root-）
-ROOT- 保存 .META. 表存在哪里的蹤跡. -ROOT- 表結構如下:
Key:
.META. region key (.META.,,1)
Values:
info:regioninfo?(序列化.META.的?HRegionInfo?實例 )
info:server?( 保存 .META.的RegionServer的server:port)
info:serverstartcode?( 保存 .META.的RegionServer進程的啟動時間)
.META. 保存系統中所有region列表。 .META.表結構如下:
Key:
Region key 格式 ([table],[region start key],[region id])
Values:
info:regioninfo?(序列化.META.的?HRegionInfo?實例 )
info:server?( 保存 .META.的RegionServer的server:port)
info:serverstartcode?( 保存 .META.的RegionServer進程的啟動時間)
以上是官網文檔對于.meta.和-root-的描述，簡而言之，-root-中存儲了.meta.的位置，而在.meta.中保存了具體數據（region）的存儲位置。如圖：
Zookeeper中記錄了-ROOT-表的location
客戶端訪問數據的流程：
Client -> Zookeeper -> -ROOT- -> .META.-> 用戶數據表
多次網絡操作，不過client端有cache緩存
a.????啟動時序
1.啟動時主服務器調用AssignmentManager.
2.AssignmentManager?在META中查找已經存在的區域分配。
3.如果區域分配還有效(如 RegionServer 還在線)，那么分配繼續保持。
4.如果區域分配失效，LoadBalancerFactory?被調用來分配區域。?DefaultLoadBalancer?將隨機分配區域到RegionServer.
5.META 隨RegionServer 分配更新(如果需要) ， RegionServer 啟動區域開啟代碼(RegionServer 啟動時進程)
b.故障轉移
當regionServer故障退出時：
1.區域立即不可獲取，因為區域服務器退出。
2.主服務器會檢測到區域服務器退出。
3.區域分配會失效并被重新分配，如同啟動時序。
5.預寫日志（wal）
每個RegionServer會將更新(Puts, Deletes)先記錄到預寫日志中(WAL)，然后將其更新在Store的MemStore里面。這樣就保證了HBase的寫的可靠性。如果沒有WAL,當RegionServer宕掉的時候，MemStore還沒有flush，StoreFile還沒有保存，數據就會丟失。HLog?是HBase的一個WAL實現，一個RegionServer有一個HLog實例。
WAL 保存在HDFS 的?/hbase/.logs/?里面，每個region一個文件。
二、?? 數據模型
1.概念視圖
以bigTable論文中的例子來說明，有一個名為webtable的表，包含兩個列族：contents和anchor.在這個例子里面，anchor有兩個列 (anchor:cssnsi.com,anchor:my.look.ca)，contents僅有一列(contents:html)
Row Key | Time Stamp | ColumnFamily?contents | ColumnFamily?anchor |
"com.cnn.www" | t9 | ? | anchor:cnnsi.com?= "CNN" |
"com.cnn.www" | t8 | ? | anchor:my.look.ca?= "CNN.com" |
"com.cnn.www" | t6 | contents:html?= "<html>..." | ? |
"com.cnn.www" | t5 | contents:html?= "<html>..." | ? |
"com.cnn.www" | t3 | contents:html?= "<html>..." | ? |
RowKey：行鍵，是表中每條記錄的“主鍵”，方便快速查找，Rowkey的設計非常重要。
Column Family：列族，擁有一個名稱(string)，包含一個或者多個相關列
Column：屬于某一個columnfamily，每條記錄可動態添加
Version Number：類型為Long，默認值是系統時間戳，可由用戶自定義
Value(Cell)：一個cell由familyName:columnName唯一定義
2.物理視圖
盡管在概念視圖里，表可以被看成是一個稀疏的行的集合。但在物理上，它的是區分列族 存儲的。新的columns可以不經過聲明直接加入一個列族.
Row Key | Time Stamp | Column Family?anchor |
"com.cnn.www" | t9 | anchor:cnnsi.com?= "CNN" |
"com.cnn.www" | t8 | anchor:my.look.ca?= "CNN.com" |
?
Row Key | Time Stamp | ColumnFamily "contents:" |
"com.cnn.www" | t6 | contents:html?= "<html>..." |
"com.cnn.www" | t5 | contents:html?= "<html>..." |
"com.cnn.www" | t3 | contents:html?= "<html>..." |
值得注意的是在上面的概念視圖中空白cell在物理上是不存儲的，因為根本沒有必要存儲。因此若一個請求為要獲取t8時間的contents:html，他的結果就是空。相似的，若請求為獲取t9時間的anchor:my.look.ca，結果也是空。但是，如果不指明時間，將會返回最新時間的行，每個最新的都會返回。例如，如果請求為獲取行鍵為"com.cnn.www"，沒有指明時間戳的話，活動的結果是t6下的contents:html，t9下的anchor:cnnsi.com和t8下anchor:my.look.ca。
對于hbase我一直有一個疑問，在hbase提供了修改和刪除的接口，但是hdfs本身很難實現修改和刪除（可以將文件塊從hdfs中下載，進行修改再上傳），那么hbase是如何實現快速的刪除與修改呢？實際上在HBase中，修改和刪除數據都是增加1個新版本的數據（時間戳為最新），舊版本的數據并沒有發生變化，而實際上的修改和刪除是在Hfile的合并階段實現的。
三、?? Hbase優化
1.??? 預先分區
默認情況下，在創建?HBase?表的時候會自動創建一個?Region?分區，當導入數據的時候，所有的?HBase?客戶端都向這一個?Region?寫數據，直到這個?Region?足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先創建一些空的?Regions，這樣當數據寫入?HBase?時，會按照?Region?分區情況，在集群內做數據的負載均衡。
2.??? Rowkey優化
HBase?中?Rowkey?是按照字典序存儲，因此，設計?Rowkey?時，要充分利用排序特點，將經常一起讀取的數據存儲到一塊，將最近可能會被訪問的數據放在一塊。
此外，Rowkey?若是遞增的生成，建議不要使用正序直接寫入?Rowkey，而是采用?reverse?的方式反轉Rowkey，使得?Rowkey?大致均衡分布，這樣設計有個好處是能將?RegionServer?的負載均衡，否則容易產生所有新數據都在一個?RegionServer?上堆積的現象，這一點還可以結合?table?的預切分一起設計。
3.??? 減少列族數量
不要在一張表里定義太多的?ColumnFamily。目前?Hbase?并不能很好的處理超過?2~3?個?ColumnFamily?的表。因為某個?ColumnFamily?在?flush?的時候，它鄰近的?ColumnFamily?也會因關聯效應被觸發?flush，最終導致系統產生更多的?I/O。
4.??? 緩存策略
創建表的時候，可以通過?HColumnDescriptor.setInMemory(true)?將表放到?RegionServer?的緩存中，保證在讀取的時候被?cache?命中。
5.??? 設置存儲生命期
創建表的時候，可以通過?HColumnDescriptor.setTimeToLive(int timeToLive)?設置表中數據的存儲生命期，過期數據將自動被刪除。
6.??? 硬盤配置
每臺?RegionServer?管理?10~1000?個?Regions，每個?Region?在?1~2G，則每臺?Server?最少要?10G，最大要1000*2G=2TB，考慮?3?備份，則要?6TB。方案一是用?3?塊?2TB?硬盤，二是用?12?塊?500G?硬盤，帶寬足夠時，后者能提供更大的吞吐率，更細粒度的冗余備份，更快速的單盤故障恢復。
7.??? 分配合適的內存給RegionServer服務
在不影響其他服務的情況下，越大越好。例如在?HBase?的?conf?目錄下的?hbase-env.sh?的最后添加?export HBASE_REGIONSERVER_OPTS="-Xmx16000m$HBASE_REGIONSERVER_OPTS”
其中?16000m?為分配給?RegionServer?的內存大小。
8.??? 寫數據的備份數
備份數與讀性能成正比，與寫性能成反比，且備份數影響高可用性。有兩種配置方式，一種是將?hdfs-site.xml拷貝到?hbase?的?conf?目錄下，然后在其中添加或修改配置項?dfs.replication?的值為要設置的備份數，這種修改對所有的?HBase?用戶表都生效，另外一種方式，是改寫?HBase?代碼，讓?HBase?支持針對列族設置備份數，在創建表時，設置列族備份數，默認為?3，此種備份數只對設置的列族生效。
9.??? WAL（預寫日志）
可設置開關，表示?HBase?在寫數據前用不用先寫日志，默認是打開，關掉會提高性能，但是如果系統出現故障(負責插入的?RegionServer?掛掉)，數據可能會丟失。配置?WAL?在調用?JavaAPI?寫入時，設置?Put?實例的WAL，調用?Put.setWriteToWAL(boolean)。
10. 批量寫
HBase?的?Put?支持單條插入，也支持批量插入，一般來說批量寫更快，節省來回的網絡開銷。在客戶端調用JavaAPI?時，先將批量的?Put?放入一個?Put?列表，然后調用?HTable?的?Put(Put?列表)?函數來批量寫。
11. 客戶端一次從服務器拉取的數量
通過配置一次拉去的較大的數據量可以減少客戶端獲取數據的時間，但是它會占用客戶端內存。有三個地方可進行配置：
1）在?HBase?的?conf?配置文件中進行配置?hbase.client.scanner.caching；
2）通過調用?HTable.setScannerCaching(intscannerCaching)?進行配置；
3）通過調用?Scan.setCaching(intcaching)?進行配置。三者的優先級越來越高。
12. RegionServer的請求處理I/O線程數
較少的?IO?線程適用于處理單次請求內存消耗較高的?Big Put?場景?(大容量單次?Put?或設置了較大?cache?的Scan，均屬于?Big Put)?或?ReigonServer?的內存比較緊張的場景。
較多的?IO?線程，適用于單次請求內存消耗低，TPS?要求?(每秒事務處理量?(TransactionPerSecond))?非常高的場景。設置該值的時候，以監控內存為主要參考。
在?hbase-site.xml?配置文件中配置項為?hbase.regionserver.handler.count。
13. Region的大小設置
配置項為?hbase.hregion.max.filesize，所屬配置文件為?hbase-site.xml.，默認大小?256M。
在當前?ReigonServer?上單個?Reigon?的最大存儲空間，單個?Region?超過該值時，這個?Region?會被自動?split成更小的?Region。小?Region?對?split?和?compaction?友好，因為拆分?Region?或?compact?小?Region?里的StoreFile?速度很快，內存占用低。缺點是?split?和?compaction?會很頻繁，特別是數量較多的小?Region?不停地split, compaction，會導致集群響應時間波動很大，Region?數量太多不僅給管理上帶來麻煩，甚至會引發一些Hbase?的?bug。一般?512M?以下的都算小?Region。大?Region?則不太適合經常?split?和?compaction，因為做一次?compact?和?split?會產生較長時間的停頓，對應用的讀寫性能沖擊非常大。
此外，大?Region?意味著較大的?StoreFile，compaction?時對內存也是一個挑戰。如果你的應用場景中，某個時間點的訪問量較低，那么在此時做?compact?和?split，既能順利完成?split?和?compaction，又能保證絕大多數時間平穩的讀寫性能。compaction?是無法避免的，split?可以從自動調整為手動。只要通過將這個參數值調大到某個很難達到的值，比如?100G，就可以間接禁用自動?split(RegionServer?不會對未到達?100G?的?Region?做split)。再配合?RegionSplitter?這個工具，在需要?split?時，手動?split。手動?split?在靈活性和穩定性上比起自動split?要高很多，而且管理成本增加不多，比較推薦?online?實時系統使用。內存方面，小?Region?在設置memstore?的大小值上比較靈活，大?Region?則過大過小都不行，過大會導致?flush?時?app?的?IO wait?增高，過小則因?StoreFile?過多影響讀性能。
14. 操作系統參數
Linux系統最大可打開文件數一般默認的參數值是1024,如果你不進行修改并發量上來的時候會出現“Too Many Open Files”的錯誤，導致整個HBase不可運行，你可以用ulimit -n 命令進行修改，或者修改/etc/security/limits.conf和/proc/sys/fs/file-max 的參數，具體如何修改可以去Google 關鍵字 “linux limits.conf ”
15. Jvm配置
修改 hbase-env.sh 文件中的配置參數，根據你的機器硬件和當前操作系統的JVM(32/64位)配置適當的參數
HBASE_HEAPSIZE 4000 HBase使用的 JVM 堆的大小
HBASE_OPTS "‐server ‐XX:+UseConcMarkSweepGC"JVM GC 選項
HBASE_MANAGES_ZKfalse 是否使用Zookeeper進行分布式管理
16. 持久化
重啟操作系統后HBase中數據全無，你可以不做任何修改的情況下，創建一張表，寫一條數據進行，然后將機器重啟，重啟后你再進入HBase的shell中使用 list 命令查看當前所存在的表，一個都沒有了。是不是很杯具？沒有關系你可以在hbase/conf/hbase-default.xml中設置hbase.rootdir的值，來設置文件的保存位置指定一個文件夾，例如：<value>file:///you/hbase-data/path</value>，你建立的HBase中的表和數據就直接寫到了你的磁盤上，同樣你也可以指定你的分布式文件系統HDFS的路徑例如:hdfs://NAMENODE_SERVER:PORT/HBASE_ROOTDIR，這樣就寫到了你的分布式文件系統上了。
17. 緩沖區大小
hbase.client.write.buffer
這個參數可以設置寫入數據緩沖區的大小，當客戶端和服務器端傳輸數據，服務器為了提高系統運行性能開辟一個寫的緩沖區來處理它，這個參數設置如果設置的大了，將會對系統的內存有一定的要求，直接影響系統的性能。
18. 掃描目錄表
hbase.master.meta.thread.rescanfrequency
定義多長時間HMaster對系統表 root 和 meta 掃描一次，這個參數可以設置的長一些，降低系統的能耗。
19. split/compaction時間間隔
hbase.regionserver.thread.splitcompactcheckfrequency
這個參數是表示多久去RegionServer服務器運行一次split/compaction的時間間隔，當然split之前會先進行一個compact操作.這個compact操作可能是minorcompact也可能是major compact.compact后,會從所有的Store下的所有StoreFile文件最大的那個取midkey.這個midkey可能并不處于全部數據的mid中.一個row-key的下面的數據可能會跨不同的HRegion。
20. 緩存在JVM堆中分配的百分比
hfile.block.cache.size
指定HFile/StoreFile 緩存在JVM堆中分配的百分比，默認值是0.2，意思就是20%，而如果你設置成0，就表示對該選項屏蔽。
21. ZooKeeper客戶端同時訪問的并發連接數
hbase.zookeeper.property.maxClientCnxns
這項配置的選項就是從zookeeper中來的，表示ZooKeeper客戶端同時訪問的并發連接數，ZooKeeper對于HBase來說就是一個入口這個參數的值可以適當放大些。
22. memstores占用堆的大小參數配置
hbase.regionserver.global.memstore.upperLimit
在RegionServer中所有memstores占用堆的大小參數配置，默認值是0.4，表示40%，如果設置為0，就是對選項進行屏蔽。
23. Memstore中緩存寫入大小
hbase.hregion.memstore.flush.size
Memstore中緩存的內容超過配置的范圍后將會寫到磁盤上，例如：刪除操作是先寫入MemStore里做個標記，指示那個value, column 或 family等下是要刪除的，HBase會定期對存儲文件做一個major compaction，在那時HBase會把MemStore刷入一個新的HFile存儲文件中。如果在一定時間范圍內沒有做major compaction，而Memstore中超出的范圍就寫入磁盤上了。
總結
以上是生活随笔為你收集整理的Hbase架构与原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一致性Hash(Consistent H
- 下一篇： docker之Dockerfile指令介