1. Hbase原理

2. 架构原理

05. Hbase原理 - 图1

  1. StoreFile
    保存实际数据的物理文件,StoreFile以HFile的形式存储在HDFS上。每个Store会有一个或多个StoreFile(HFile),数据在每个StoreFile中都是有序的。
  2. MemStore
    写缓存,由于HFile中的数据要求是有序的,所以数据是先存储在MemStore中,排好序后,等到达刷写时机才会刷写到HFile,每次刷写都会形成一个新的HFile。
  3. WAL
    由于数据要经MemStore排序后才能刷写到HFile,但把数据保存在内存中会有很高的概率导致数据丢失,为了解决这个问题,数据会先写在一个叫做Write-Ahead logfile的文件中,然后再写入MemStore中。所以在系统出现故障的时候,数据可以通过这个日志文件重建。Hlog默认存储在HDFS上

3. 写流程

05. Hbase原理 - 图2

  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. 将数据顺序写入(追加)到WAL
  5. 将数据写入对应的MemStore,数据会在MemStore进行排序;
  6. 向客户端发送ack
  7. 等达到MemStore的刷写时机后,将数据刷写到HFile。

4. MemStore Flush(刷新时机)

05. Hbase原理 - 图3

MemStore刷写时机:

  1. 某个memstroe的大小达到了hbase.hregion.memstore.flush.size(默认值128M),其所在region的所有memstore都会刷写
    当memstore的大小达到了 hbase.hregion.memstore.flush.size(默认值128M hbase.hregion.memstore.block.multiplier(默认值4倍)时(即默认为128M4=512MB),会阻止继续往该memstore写数据。
    Hbase中不推荐创建太多了列族 由于刷写整个memstore都会刷写 而每次刷写都是在hdfs中建立新的文件 可能有store很小就被刷写了 浪费系统资源

  2. region server中memstore的总大小达到
    java_heapsize hbase.regionserver.global.memstore.size(默认值0.4) hbase.regionserver.global.memstore.size.upper.limit(默认值0.95),
    region server 会把其的所有 region 按照其所有memstore的大小顺序(由大到小)依次进行刷写。直到region server中所有memstore的总大小减小到hbase.regionserver.global.memstore.size.lower.limit(默认为空 需要配置)以下
    当region server中memstore的总大小达到java_heapsizehbase.regionserver.global.memstore.size(默认值0.4)时,*会阻止继续往所有的memstore写数据

  3. 到达自动刷写的时间,也会触发memstore flush。自动刷新的时间间隔由该属性进行配置hbase.regionserver.optionalcacheflushinterval(默认1小时)

  4. 当WAL文件的数量超过hbase.regionserver.max.logs,region会按照时间顺序依次进行刷写,直到WAL文件数量减小到hbase.regionserver.max.log以下(该属性名已经废弃,现无需手动设置,最大值为32)。

5. 读流程

05. Hbase原理 - 图4

读流程

  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)。 先看缓存 再看MemStore 再看Store file
  5. 将从文件中查询到的数据块(Block,HFile数据存储单元,默认大小为64KB缓存到Block Cache
  6. 将合并后的最终结果返回给客户端。

6. StoreFile Compaction

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

05. Hbase原理 - 图5

Compaction分为两种,分别是Minor Compaction和Major Compaction。

  1. Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile,但不会清理过期和删除的数据。
  2. Major Compaction会将一个Store下的所有的HFile合并成一个大HFile,并且清理掉过期和删除的数据。

7. Region Split

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

05. Hbase原理 - 图6

Region Split时机:

  1. 当1个region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize(默认为10737418240 十GB大小),该Region就会进行拆分(0.94版本之前)。
  2. 当1个region中的某个Store下所有StoreFile的总大小超过Min(R^3 2 “hbase.hregion.memstore.flush.size”,hbase.hregion.max.filesize”),该Region就会进行拆分,其中R为当前Region Server中属于该Table的个数(0.94版本之后)。
  3. Hbase 2.0 引入了新的split策略: 如果当前 RegionServer 上该表只有一个 Regin 按照 2 * “hbase.hregion.memstore.flush.size” 分裂,否则按照 hbase.hregion.max.filesize 分裂