3.1 架构原理

image.png

3.2 写流程

HBase是一个读比写慢的数据库

image.png
image.png

疑问： 1.如何确定具体写到哪个Region？在哪里判断的？又如何知道该Region所在的RS呢？ 答：在hbase:meta这张表中维护者各个表的region信息，包括region所在RS，region的start key和end key等。因此在上图第4步拿到meta信息后，客户端就可以判断要写的rowKey应该写入到哪个region和RS。 2.meta表可能有多个Region吗？ 答：理论上是可能的。但实际中，一个Region通常可以存储10G的内容，实践中几乎不可能出现表多到需要将meta表分Region的场景。因此当前版本的HBase默认是meta表只有一个region，且不会对meta表进行切分逻辑，ZK中只存meta表所在RS即可。

3.3 MemStore Flush

image.png

MemStore刷写时机

  1. 空间条件：RS全局或单个Region的MemStore Size达到了配置的阈值时，会执行刷写，且会刷写RS全局或当前Region中全部的MemStore。
  2. 时间条件：当在一段时间内没有任何操作时，会执行刷写。
  3. WAL Log数量条件：当WAL Log数量超过一定值时（默认32个），会执行刷写。单个WAL Log Size默认128M。

3.4 读流程

image.png

HBase查询的时候，不能只读MemStore中的数据，而是需要将当前Store下MemStore和磁盘上的StoreFile都读取出来，然后根据时间戳判断应该返回哪一个。Block Cache是StoreFile的缓存。由于需要读磁盘和判断时间戳，因此HBase读性能相比于写性能并不算优秀。

3.5 StoreFile Compaction

由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清理掉过期和删除的数据，会进行StoreFile Compaction。
Compaction分为两种，分别是Minor Compaction和Major Compaction。

  • Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据。
  • Major Compaction会将一个Store（即一个列族）下的所有HFile合并成一个大HFile，并且会清理掉过期和删除的数据。

image.png
除了Major Compaction之外，当MemStore Flush的时候，会自动删除内存中已经过期的数据，但此时不会删除“Delete”类型的数据。因为如果内存中删了“Delete”类型的数据，而磁盘上还有数据的话，则磁盘上的数据就会被认为是依然存在的。不过在Major Compaction时，会删除“Delete”类型的数据。

3.6 Region Split

默认情况下，每个Table起初只有一个Regio，随着数据的不断写入，Region会自动进行拆分。刚拆分时，两个子Region都位于当前的Region Server，但出于负载均衡的考虑，HMaster有可能会将某个Region转移给其他的Region Server。
Region自动拆分的时机：

  • 0.94版本之前：当一个region中某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize（默认10G）时，该Region就会进行拆分。
  • 0.94版本之后：当一个Region中某个Store下所有StoreFile的总大小超过Min(R^2 * hbase.hregion.memstore.flush.size, hbase.hregion.max.filesize)时，该Region就会进行拆分。其中R为当前RS中该Table的Region个数。换言之，就是拆分阈值从128M、512M、2048M直到10G，依次增大。