HBase读写原理与Region拆分合并
一,HBase读写原理深入
HBase读流程
meta表位于的位置信息查看>>>>
HBase写流程
- 首先从zk找到meta表的region位置,然后读取meta表中的数据,meta表中存储了用户表的region信息
- 根据namespace、表名和rowkey信息。找到写入数据对应的region信息
- 找到这个region对应的regionServer,然后发送请求
- 把数据分别写到HLog(write ahead log)和memstore各一份
- memstore达到阈值后把数据刷到磁盘,生成storeFile文件
- 删除HLog中的历史数据
HBase写流程 Flash机制
当memstore的大小超过这个值的时候,会flush到磁盘,默认为128M
当memstore中的数据时间超过1小时,会flush到磁盘
HregionServer的全局memstore的大小,超过该大小会触发flush到磁盘的操作,默认是堆大小的40%
手动flush命令: flush tableName
阻塞机制
Hbase中是周期性的检查是否满足以上标准满足则进行刷写,但是如果在下次检查到来之前,数据疯狂写入Memstore中,会出现以下问题:
会触发阻塞机制,此时无法写入数据到Memstore,数据无法写入Hbase集群。
- memstore中数据达到512MB---》可以通过调大机器内存提高阈值
计算公式:hbase.hregion.memstore.flush.size*hbase.hregion.memstore..block.multiplier hbase.hregion.memstore.flush.size刷写的阀值,默认是 134217728,即128MB。 hbase.hregion.memstore.block.multiplier是一个倍数,默认是4。
- RegionServer全部memstore达到规定值
hbase.regionserver.global.memstore.size.lower.limit是0.95, hbase.regionserver.global.memstore.size是0.4, 堆内存总共是 16G,
触发刷写的阈值是:6.08GB 、触发阻塞的阈值是:6.4GB
Compact合并机制(增加读取的性能,减少访问的file)
minor compact 小合并
触发条件:
memstore flush 在进行memstore flush前后都会进行判断是否触发compact
定期检查线程 周期性检查是否需要进行compaction操作,由参数:hbase.server.thread.wakefrequency决定,默认值是10000 millseconds
- 在将Store中多个HFile(StoreFile)合并为一个HFile (这个过程中,删除和更新的数据仅仅只是做了标记,并没有物理移除,这种合并的触发频率很高。)
- minor compact文件选择标准由以下几个参数共同决定:
<!--待合并文件数据必须大于等于下面这个值-->
<property><name>hbase.hstore.compaction.min</name><value>3</value>
</property>
<!--待合并文件数据必须小于等于下面这个值-->
<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 compact 大合并
触发条件:
##使用major_compact命令手动触发: major_compact tableName
major compaction触发时间条件:
- 合并Store中所有的HFile为一个HFile
这个过程有删除标记的数据会被真正移除,同时超过单元格maxVersion的版本记录也会被删除。合并频率比较低,默认7天执行一次,并且性能消耗非常大,建议生产关闭(设置为 0),在应用空闲时间手动触发。一般可以是手动控制进行合并,防止出现在业务高峰期。
二,Region拆分策略与预分区
Region中存储的是大量的rowkey数据 ,当Region中的数据条数过多的时候,直接影响查询效率.当Region过大的时候.HBase会拆分Region
拆分策略:
ConstantSizeRegionSplitPolicy(已遗弃)
当region大小大于某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分,一个region等分为2个region,该种拆分方式统一性的处理没有大表和小表的区分,阈值设置大不友好,设置小了又影响性能
IncreasingToUpperBoundRegionSplitPolicy
总体看和ConstantSizeRegionSplitPolicy思路相同,一个region大小大于设置阈值就会触发切分。但是这个阈值并不像 ConstantSizeRegionSplitPolicy是一个固定的值,而是会在一定条件下不断调整,调整规则和region所属表在当前regionserver上的region个数有关系.
SteppingSplitPolicy(默认策略)
如果region个数等于1, 切分阈值为flush size * 2,否则为MaxRegionFileSize。这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好,小 表不会再产生大量的小region,而是适可而止。
KeyPrefixRegionSplitPolicy
根据rowKey的前缀对数据进行分组,这里是指定rowKey的前多少位作为前缀,比如rowKey都是16位的,指定前5位是前缀,那么前5位相同的rowKey在进行region split的时候会分 到相同的region中。
DelimitedKeyPrefixRegionSplitPolicy
保证相同前缀的数据在同一个region中,例如rowKey的格式为:userid_eventtype_eventid,指定的delimiter为 _ ,则split的的时候会确保userid相同的数据在同一个 region中。
DisabledRegionSplitPolicy <不启用自动拆分, 需要指定手动拆分>
Region拆分策略可以全局统一配置,也可以为单独的表指定拆分策略。
### 全局
<property>
<name>hbase.regionserver.region.split.policy</name>
<value>org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy</value>
</property>###局部表
create 'test2', {METADATA => {'SPLIT_POLICY' =>
'org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy'}},{NAME => 'cf1'
预分区: 之前Hbase文章有提到过,新建一个table的时候默认情况下只会创建一个Region,那么在集群的情况下,只有一个RegionServer会处于使用的状态,且待拆分。这样子就会出现资源没有合理利用的问题,且说到集群自然避开不了负载均衡,这样子也就达不到负载均衡的效果了。所以在创建表之前进行预分区。
预分区作用:
- 增加数据读写效率
- 负载均衡,防止数据倾斜
- 方便集群容灾调度region 每一个region维护着startRow与endRowKey,如果加入的数据符合某个region维护的rowKey范围,则该数据交给这个region堆
调整预分区方式:(实际会切分4个Region, 0~1000, 1000~2000, 2000~3000, 3000>>)
create 'mytest2','info1','info2',SPLITS => ['1000','2000','3000']
$ 有资料上了解到文件分区的方式,但是这种方式分区后,存储数据时具体是根据何种方式存储到具体的Region中还有待日后测试,实现方式这里只贴操作图
三,Region合并
region的合并,通常情况下,是垃圾数据处理之后,为了维护数据的快速访问而去合并
Shell以外,通过org.apache.hadoop.hbase.util.Merge类合并:
hbase org.apache.hadoop.hbase.util.Merge mytest \
test1,,1595256696737.fc3eff4765709e66a8524d3c3ab42d59. \
test2,12345,1595256696737.1d53d6c1ce0c1bed269b16b6514131d0.
HBase读写原理与Region拆分合并相关推荐
- HBase读写流程、flush、文件合并、region拆分
HBase存储原理(架构) HBase依赖于Zookeeper和Hadoop的,所以在启动HBase前需要启动Zookeeper和Hadoop. HMaster用于管理整个HBase集群,即管理每个H ...
- HBase数据模型和读写原理
Hbase的数据模型和读写原理: HBase是一个开源可伸缩的分布式数据库,他根据Google Bigtable数据模型构建在hadoop的hdfs存储系统之上. HBase是一个稀疏.多维度 ...
- hbase region拆分的三种方式
我们都知道,region在数据量大到一定程度的时候,会进行拆分(最开始由一个变成二个),而拆分的方式有三种,包括预拆分.自动拆分.手动强制拆分.下面就来介绍介绍拆分的方式. 预拆分 预拆分(pre-s ...
- Hbase:原理和设计
转载自:http://www.sysdb.cn/index.php/2016/01/10/hbase_principle/ ,感谢原作者. 简介 HBase -- Hadoop Database的简称 ...
- HBase读写性能调优(一)
目录 1.HBase关键参数配置 1.1 写参数调整 1.1.1客户端调优 1.1.2 使用PutList方式提交请求 1.2 Memstore相关 1.2.1 根据 memstore 大小flush ...
- HBase数据库原理解析
文章目录 1.HBase 数据库介绍 1.1产生背景 1.2简介 1.3表结构逻辑视图 1.3.1行键(RowKey) 1.3.2列簇(Column Family) 1.3.3时间戳(TimeStam ...
- 2021年大数据HBase(十四):HBase的原理及其相关的工作机制
全网最详细的大数据HBase文章系列,强烈建议收藏加关注! 新文章都已经列出历史文章目录,帮助大家回顾前面的知识重点. 目录 系列历史文章 HBase的原理及其相关的工作机制 一.HBase的flus ...
- hbase filter原理_HBase应用|HBase在移动广告监测产品中的应用
1 HBase在Ad Tracking的应用 1.1 Ad Tracking的业务场景 Ad Tracking是TalkingData的移动广告监测产品,其核心业务模型是归因.App用户点击广告之后, ...
- 五十一、HBase的原理
上一篇文章我们介绍了如何部署HBase以及HBase常用的命令行操作,本文我们从HBase的读写流程出发来看一下HBase的原理.关注专栏<破茧成蝶--大数据篇>,查看更多相关的内容~ 目 ...
最新文章
- Python3学习笔记-数据类型和变量
- 类型参数的约束(C# 编程指南)
- Swif基础语法01
- HDU多校4 - 6992 Lawn of the Dead(线段树+模拟)
- Lucene学习总结之三:Lucene的索引文件格式(2)
- Linux Ubuntu16.04界面美化
- 一份清华大佬的代码模版,简洁易懂!
- html5boder属性,你未必知道的CSS小知识:border属性比你想象的要复杂
- [Ext JS 4] 实战之 ComboBox 和 DateField (消失之解决办法)
- java单元测试笔记
- SpringMVC之安全性(三)Twitter登入
- EXCEL怎样完整显示身份证号码
- [ASP.NET 设计模式] 用Visual Studio2010搭建一个简单的分层结构示例Step by Step —— 06 用户界面层...
- 商用密码产品认证(型号)概述
- 使用 python 脚本爬取豆瓣电影排行榜
- mysql bin_mysql-bin是什么文件?
- 关于h5使用高德地图,没有获取经纬度
- 如何在图片上写字?——text in the pic
- 通往古埃及文明的钥匙 ———— 罗塞塔石碑
- 范德堡计算机科学硕士,范德堡大学计算机科学硕士排名第58(2020年TFE Times排名)...