• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

开发技术 开发技术 2个月前 (11-28) 16次浏览

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

 前言:老刘目前为明年校招而努力,写文章主要是想用大白话把自己复习的大数据知识点详细解释出来,拒绝资料上的生搬硬套,做到有自己的理解!

01 HBase知识点

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

第6点:HRegionServer架构

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

为什么要了解HRegionServer的架构呢?因为HBase集群中数据的存储和HRegionServer有着非常大的关系,只有搞清楚了它的架构,才能理清楚数据存储的逻辑。

那就让老刘好好介绍下HRegionServer架构。

StoreFile

在HRegionServer架构图中,StoreFile是保存实际数据的物理文件,StoreFile是以HFile的形式存储在HDFS上,每个Store会有一个或多个StoreFile,并且数据在每个StoreFile中都是有序的。为什么是有序的,会在MEMStore中介绍。

对于HFile是什么,老刘目前只能理解为它是StoreFile存在HDFS上的存储格式,也就是说StoreFile是以HFile这种形式存储在HDFS上。

MemStore

它是写缓存的意思。由于HFile是要求数据是有序的,要按照存储在HDFS上的数据需要按照rowkey排序,所以数据先存储在MemStore中,排好序后,达到阈值后才会flush到StoreFile中,每次flush生成一个新的StoreFIle。

那MemStore是如何将数据排序的呢?

很多机构的教学资料都没讲,老刘查了很多资料后,老刘只有一个相对较浅的理解,实现MemStore模型的数据结构是SkipList跳表,跳表它可以实现高效的查询、插入、删除操作。因为跳表本质上是由有序链表构成的,很多KV数据库都会使用跳表实现有序数据集合。所以呢,数据传入MemStore后,会利用跳表实现这些数据的有序。

WAL

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

BlockCache

它是读缓存的意思。每次查询出来的数据会先缓存在BlockCache中,方便下次查询数据。


 

第7点:HBase读数据流程

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

首先要说的是,在HBase中只有一张meta表(元数据表),此表只有一个region表,该region数据保存在一个HRegionServer上。

还记得HBase的第一篇文章说的ZooKeeper的作用吗,ZooKeeper里面保存了HBase的元数据meta。再想想我们要读取数据,是不是相当于去学校访问一个老师,是不是要先在校门口登记,搞清楚这个老师在学校哪个部门、哪个办公室之类的。

所以呢,HBase读数据流程如下:

1、HBase读取数据首先要与zk进行连接,从zk找到meta表的region位置,就是查找meta表存储在哪个HRegionServer,得到消息后,客户端就会立马与这个HRegionServer建立连接,然后读取meta表中的数据,这个meta表中的信息有:HBase集群有哪些表、每个表有哪些Region、都保存在哪些RegionServer上以及存储了所有用户表的Region信息。

2、我们根据要查询的namespace(命名空间,相当于关系型数据库数据库名称)、表名和rowkey信息。找到写入数据对应的Region信息。

3、然后找到这个Region对应的RegionServer,然后发送请求。

4、现在就可以查找并定位到对应的Region了。

5、我们会先从MemStore中查找数据,如果没有,就会再从BlockCache上读取,如果BlockCache中也没有找到,那就会从最后的StoreFile中读取,从StoreFile中读取到数据之后,并不是直接把结果数据返回到客户端,而是把数据先写入到BlockCache中,目的是为了加快后续的查询;然后在返回结果给客户端。


 

第8点:HBase写数据流程

 大白话详解大数据HBase核心知识点,老刘真的很用心(2)

1、客户端首先会从zk找到meta表的region位置,然后读到meta表中的数据,meta表中存储了用户表的region信息。

2、根据我们根据要写入数据的namespace(命名空间,相当于关系型数据库数据库名称)、表名和rowkey信息。找到写入数据对应的Region信息。

3、然后找到这个Region对应的RegionServer,然后发送请求。

4、现在就可以把数据顺序写入(追加)到WAL。

5、将数据写入对应的MemStore,数据会在MemStore进行排序

6、达到MemStore的刷写时机后,将数据刷写到StoreHFile中。

但是大家好好想想,如果数据不停的写入,是不是会产生很多很多StoreFile?

在HBase集群中,针对产生的很多很多StoreFile,它会把它们合并为一个大的StoreFile(这是一个小合并),最终所有的StoreFile会进行一个大合并。但是在数据不断写入过程中,Region中的数据会越来越大,此时Region就会进行拆分(一分为二),拆分过程比较耗性能,就有了预分区。老刘大致说了下HBase中为什么会有flush和compact机制、Region拆分合并以及预分区,下面就详细讲讲这些知识点。

第9点:HBase中的flush、compact机制

Flush机制

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

数据要刷写到磁盘,它是有很多刷写时机的,并不是想刷写就刷写的。

第一个是达到Memtore级别的限制,当Region中任意一个MemStore的大小达到了上限,默认是128M,就会触发MemStore刷新。这个上限的设置如下:

<property>
  <name>hbase.hregion.memstore.flush.size</name>
  <value>134217728</value>
</property>

第二个是达到Region级别的限制,当Region中所有的MemStore的大小总和达到了上限,默认是2*128M=256M,会触发MemStore刷新。这个上限的设置如下:

<property>
  <name>hbase.hregion.memstore.flush.size</name>
  <value>134217728</value>
</property>
<property>
  <name>hbase.hregion.memstore.block.multiplier</name>
  <value>2</value>
</property>

第三个是达到RegionServer级别限制,当一个RegionServer中所有MemStore的大小总和超过低水位阈值,RegionServer开始强制Flush;先Flush MemStore最大的Region,再执行次大的,依次执行;

如果写入速度大于flush写出的速度,最后导致总MemStore大小超过高水位阈值(默认为JVM内存的40%),此时RegionServer会阻塞更新并强制执行flush,直到总MemStore大小低于低水位阈值。这些阈值的设置如下:

<property>
  <name>hbase.regionserver.global.memstore.size.lower.limit</name>
  <value>0.95</value>
</property>
<property>
  <name>hbase.regionserver.global.memstore.size</name>
  <value>0.4</value>
</property>

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

第五个是定期刷新MemStore,默认周期为1小时,确保MemStroe不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush导致的问题,定期的flush操作会有20000左右的随机延时。

Compact合并机制

为什么有Compact合并机制?

hbase为了防止小文件过多,以保证查询效率,hbase需要在必要的时候将这些小的store file合并成相对较大的store file,这个过程就称之为compaction。

在hbase中主要存在两种类型的compaction合并:

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

minor compaction 小合并

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

 它会将Store中多个HFile合并为一个HFile。在这个过程中它会选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile。

对于超过了TTL(生存时间)的数据、更新的数据、删除的数据仅仅只是做了标记。并没有进行物理删除,进行一次Minor Compaction的结果是产生数量上更少并且内存上更大的StoreFile。这种合并的触发频率很高。

minor compaction触发条件由以下几个参数共同决定:

<!--表示至少需要三个满足条件的store file时,minor compaction才会启动-->
<property>
  <name>hbase.hstore.compactionThreshold</name>
  <value>3</value>
</property>

<!--表示一次minor compaction中最多选取10个store file-->
<property>
  <name>hbase.hstore.compaction.max</name>
  <value>10</value>
</property>

<!--默认值为128m,
表示文件大小小于该值的store file 一定会加入到minor compaction的store file中
-->
<property>
  <name>hbase.hstore.compaction.min.size</name>
  <value>134217728</value>
</property>

<!--默认值为LONG.MAX_VALUE,
表示文件大小大于该值的store file 一定会被minor compaction排除-->
<property>
  <name>hbase.hstore.compaction.max.size</name>
  <value>9223372036854775807</value>
</property>

major compaction 大合并

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

 将所有的StoreFile合并成一个StoreFile,在这个过程中还会清理三类无意义数据:被删除的数据、TTL过期数据、版本号超过设定版本号的数据。它的合并频率比较低,默认7天执行一次,并且性能的消耗是非常大的,一般建议生产关闭,在应用空闲时间手动触发。一般可以是手动控制进行合并,这样可以防止出现在业务高峰期。

major compaction触发时间条件(7天)

<!--默认值为7天进行一次大合并,-->
<property>
  <name>hbase.hregion.majorcompaction</name>
  <value>604800000</value>
</property>

手动触发

#使用major_compact命令
major_compact tableName

 

第10点:Region拆分

region中存储的是大量的rowkey数据,当region中的数据条数过多的时候,直接影响查询效率。当region过大的时候。hbase会拆分region,这也是Hbase的一个优点。

HBase的region split策略一共有以下几种,先说说3种。

1、ConstantSizeRegionSplitPolicy

它是0.94版本前默认切分策略。

当region的大小大于某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分,一个region会等分为2个region。但是这种切分策略却有相当大的弊端:切分策略对于大表和小表没有明显的区分。阈值设置较大对大表比较友好,但是小表就有可能不会触发分裂,极端情况下可能就1个,这对业务来说并不是什么好事。如果设置较小则对小表友好,但一个大表就会在整个集群产生大量的region,这对于集群的管理、资源使用、failover来说都不是一件好事。

2、IncreasingToUpperBoundRegionSplitPolicy

它是0.94版本~2.0版本默认切分策略。

切分策略稍微有点复杂,总体看和ConstantSizeRegionSplitPolicy思路相同,一个region大小大于设置阈值就会触发切分。但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值,而是会在一定条件下不断调整,调整规则和region所属表在当前regionserver上的region个数有关系。

3、SteppingSplitPolicy

它是2.0版本默认切分策略

这种切分策略的切分阈值又发生了变化,就是一般刚设计出来都会存在一些不合理的地方,随着慢慢的发展,设计师们逐渐完善。

相比之前的IncreasingToUpperBoundRegionSplitPolicy,它会简单一些,依然和待分裂region所属表在当前regionserver上的region个数有关系,如果region个数等于1,切分阈值为flush size * 2,否则为MaxRegionFileSize。这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好,小表不会再产生大量的小region,而是适可而止。

还有几个不讲了,老刘快记不住了。


 

第11点:Region合并

什么时候需要Region合并?

比如有一张表在拆分后,一分为二,但是在使用过程中,对这两个表进行了数据的删除,数据量变小了,为了方便管理之类的,可以把他们合并。

又比如删除了大量的数据 ,这个时候每个Region都变得很小 ,存储多个Region就浪费了 ,这个时候可以把Region合并起来,进而可以减少一些Region服务器节点 。

总之,Region合并不是为了性能,而是为了方便维护管理。


第12点:HBase表的预分区

当一个table表刚被创建的时候,HBase会默认的分配一个region给这个table。这就相当于说,在这个时候,所有的读写请求都会访问到同一个regionServer的同一个region中,这个时候就达不到负载均衡的效果了,因为集群中的其他regionServer就可能会处于比较空闲的状态。出现了一人干活,其他人看戏的现象。

解决这个问题可以用预分区,在创建table表的时候就配置好,生成多个region。

预分区原理

每一个region都维护着startRow与endRowKey,如果加入的数据符合某个region维护的rowKey范围,就会把该数据交给这个region维护。如何手动指定预分区

方式一:

create 'person','info1','info2',SPLITS => ['1000','2000','3000','4000']

就会有如下这种效果:

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

方式二:

把分区规则创建于文件中

cd /kkb/install

vim split.txt

在里面添加这样的内容:

aaa
bbb
ccc
ddd

在执行这样的命令:

create 'student','info',SPLITS_FILE => '/kkb/install/split.txt'

就会得到这样的效果:

大白话详解大数据HBase核心知识点,老刘真的很用心(2)

 02 总结

好啦,大数据HBase的第二部分知识点就总结的差不多了,内容比较多,大家需要仔细理解,争取做到用自己的话把这些知识点讲述出来。

最后,如果觉得有哪里写的不好或者有错误的地方,可以联系公众号:努力的老刘,进行交流哦!希望能够对大数据开发感兴趣的同学有帮助,希望能够得到同学们的指导。

 


喜欢 (0)