Hbase底层解析

hfile+compaction

原理

​ 用户数据写入先写WAL,再写缓存,满足一定条件后缓存数据会执行flush操作真正落盘,形成一个数据文件HFile。太多数据文件会导致数据查询IO次数增多,因此HBase尝试着不断对这些文件进行合并,这个合并过程称为Compaction

​ Compaction过程会有以下作用:

​ (1)合并文件

​ (2)清除删除、过期、多余版本的数据

​ (3)提高读写数据的效率

​ Compaction会从一个region的一个store中选择一些hfile文件进行合并,分为MinorCompaction和MajorCompaction。

  • MinorCompaction是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile,在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少并且更大的StoreFile。
  • MajorCompaction是指将所有的StoreFile合并成一个StoreFile,这个过程还会清理三类无意义数据:被删除的数据、TTL过期数据、版本号超过设定版本号的数据。

触发compaction

​ HBase中可以触发compaction的因素有很多,最常见的因素有这么三种:Memstore Flush、后台线程周期性检查、手动触发

  1. Memstore Flush: 应该说compaction操作的源头就来自flush操作,memstore flush会产生HFile文件,文件越来越多就需要compact。因此在每次执行完Flush操作之后,都会对当前Store中的文件数进行判断,一旦文件数# > ,就会触发compaction。需要说明的是,compaction都是以Store为单位进行的,而在Flush触发条件下,整个Region的所有Store都会执行compact,所以会在短时间内执行多次compaction。
  2. 后台线程周期性检查:后台线程CompactionChecker定期触发检查是否需要执行compaction,检查周期为:hbase.server.thread.wakefrequencyhbase.server.compactchecker.interval.multiplier。和flush不同的是,该线程优先检查文件数#是否大于,一旦大于就会触发compaction。如果不满足,它会接着检查是否满足major compaction条件,简单来说,如果当前store中hfile的最早更新时间早于某个值mcTime,就会触发major compaction,HBase预想通过这种机制定期删除过期数据。上文mcTime是一个浮动值,浮动区间默认为[7-70.2,7+7*0.2],其中7为hbase.hregion.majorcompaction,0.2为hbase.hregion.majorcompaction.jitter,可见默认在7天左右就会执行一次major compaction。用户如果想禁用major compaction,只需要将参数hbase.hregion.majorcompaction设为0
  3. 手动触发:一般来讲,手动触发compaction通常是为了执行major compaction,原因有三,其一是因为很多业务担心自动major compaction影响读写性能,因此会选择低峰期手动触发;其二也有可能是用户在执行完alter操作之后希望立刻生效,执行手动触发major compaction;其三是HBase管理员发现硬盘容量不够的情况下手动触发major compaction删除大量过期数据;无论哪种触发动机,一旦手动触发,HBase会不做很多自动化检查,直接执行合并。

Compaction流程

​ 一旦触发,HBase会将该Compaction交由一个独立的线程处理,该线程会执行以下操作:

  1. 首先会从对应store中选择合适的hfile文件进行合并,这一步是整个Compaction的核心,选取文件需要遵循很多条件,比如文件数不能太多、不能太少、文件大小不能太大等等,最理想的情况是,选取那些承载IO负载重、文件小的文件集,实际实现中,HBase提供了多个文件选取算法:RatioBasedCompactionPolicy、ExploringCompactionPolicy和StripeCompactionPolicy等,用户也可以通过特定接口实现自己的Compaction算法。
  2. 选出待合并的文件后,HBase会根据这些hfile文件总大小挑选对应的线程池处理。
  3. 最后对这些文件执行具体的合并操作。

Exception

​ 1. compaction操作重写文件会带来很大的带宽压力以及短时间IO压力

​ 2. 对 hbase 进行短时间大批量数据导入时,hbase 很容易触发 regionserver 的 compaction 操作,在 compaction 过程中,会获得region too busy 的 Exception。

​ org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1 action: RegionTooBusyException

​ ……

​ ……

​ 对此类Exception的处理,目前程序中所使用的方法是

  1. 使用try..catch..得到此类错误的时候让当前线程sleep一段时间,再重新导入,直至没有catch到此类错误。(办法总比困难多,希望以后有更好的处理方法)

Rowkey特性

字符串类型

​ 虽然行键在HBase中是以byte[]字节数组的形式存储的,但是建议在系统开发过程中将其数据类型设置为String类型,保证通用性;如果在开发过程中将RowKey规定为其他类型,譬如Long型,那么数据的长度将可能受限于编译环境等所规定的数据长度。

常用的行键字符串有以下几种:

纯数字字符串,譬如9559820140512;

数字+特殊分隔符,譬如95598-20140512;

数字+英文字母,譬如city20140512;

数字+英文字母+特殊分隔符,譬如city_20140512。

有明确意义

RowKey的主要作用是为了进行数据记录的唯一性标示,但是唯一性并不是其全部,具有明确意义的行键对于应用开发、数据检索等都具有特殊意义。譬如上面的数字字符串9559820140512,其实际意义是这样:95598(电网客服电话)+20140512(日期)。

行键往往由多个值组合而成,而各个值的位置顺序将影响到数据存储和检索效率,所以在设计行键时,需要对日后的业务应用开发有比较深入的了解和前瞻性预测,才能设计出可尽量高效率检索的行键。

有序性

RowKey是按照字典序存储,因此,设计RowKey时,要充分利用这个排序特点,将经常一起读取的数据存储到一块,将最近可能会被访问的数据放在一块。

举个例子:如果最近写入HBase表中的数据是最可能被访问的,可以考虑将时间戳作为RowKey的一部分,由于是字典序排序,所以可以使用Long.MAX_VALUE – timestamp作为RowKey,这样能保证新写入的数据在读取时可以被快速命中。

定长性

行键具有有序性的基础便是定长,譬如20140512080500、20140512083000,这两个日期时间形式的字符串是递增的,不管后面的秒数是多少,我们都将其设置为14位数字形式,如果我们把后面的0去除了,那么201405120805将大于20140512083,其有序性发生了变更。所以我们建议,行键一定要设计成定长的。

计数器

两种方法

  1. RMW(read-modify-write)
  2. increment

优劣比较

以前人的比较结果进行描述:

  1. 单线程环境下进行的RMW速率比increment快
  2. 多线程环境下的RMW需要对列进行加锁解锁操作,效率比increment慢

原理简述

RMW操作中的主要瓶颈在read操作,在对多列进行数据获取的情况下,效率会明显变慢,且多线程环境下,更是需要增加加锁解锁操作。

increment是hbase自带的计数器API,线程安全,操作原子性。

    原文作者:hbase
    原文地址: https://www.cnblogs.com/fengzzi/p/10033070.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞