HBase系列3-Hbase进阶

一. 架构原理

image.png

  1. StoreFile
    保存实际数据的物理文件,StoreFile 以HFile 的形式存储在HDFS 上。每个Store 会有一个或多个StoreFile(HFile),数据在每个StoreFile 中都是有序的。

  2. MemStore
    写缓存,由于HFile 中的数据要求是有序的,所以数据是先存储在MemStore 中,排好序后,等到达刷写时机才会刷写到HFile,每次刷写都会形成一个新的HFile。

  3. WAL
    由于数据要经MemStore 排序后才能刷写到HFile,但把数据保存在内存中会有很高的概率导致数据丢失,为了解决这个问题,数据会先写在一个叫做Write-Ahead logfile 的文件中,然后再写入MemStore 中。所以在系统出现故障的时候,数据可以通过这个日志文件重建。

二. 写流程

image.png

写流程:
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。

三. MemStore Flush

image.png

MemStore 刷写时机:

  1. 当某个memstroe 的大小达到了hbase.hregion.memstore.flush.size(默认值128M),其所在region 的所有memstore 都会刷写。
    当memstore 的大小达到了
hbase.hregion.memstore.flush.size(默认值128M)
* hbase.hregion.memstore.block.multiplier(默认值4)

时,会阻止继续往该memstore 写数据。

  1. 当region server 中memstore 的总大小达到
java_heapsize
*hbase.regionserver.global.memstore.size(默认值0.4)
*hbase.regionserver.global.memstore.size.lower.limit(默认值0.95)

region 会按照其所有memstore 的大小顺序(由大到小)依次进行刷写。直到region server中所有memstore 的总大小减小到上述值以下。
当region server 中memstore 的总大小达到

java_heapsize*hbase.regionserver.global.memstore.size(默认值0.4)

时,会阻止继续往所有的memstore 写数据。

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

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

四. 读流程

image.png

读流程

  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. 将合并后的最终结果返回给客户端。

五. 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

六. Region Split

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

Region Split 时机:

  1. 当1 个region 中的某个Store 下所有StoreFile 的总大小超过hbase.hregion.max.filesize,该Region 就会进行拆分(0.94 版本之前)。

  2. 当1 个region 中的某个Store 下所有StoreFile 的总大小超过Min(R^2 *
    “hbase.hregion.memstore.flush.size”,hbase.hregion.max.filesize"),该Region 就会进行拆分,其中R 为当前Region Server 中属于该Table 的个数(0.94 版本之后)。
    image.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值