HBase的读写流程以及优化方法
本篇内容主要讲解“HBase的读写流程以及优化方法”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“HBase的读写流程以及优化方法”吧!
站在用户的角度思考问题,与客户深入沟通,找到元江县网站设计与元江县网站推广的解决方案,凭借多年的经验,让设计与互联网技术结合,创造个性化、用户体验好的作品,建站类型包括:网站设计、做网站、企业官网、英文网站、手机端网站、网站推广、域名注册、网络空间、企业邮箱。业务覆盖元江县地区。
HBase的读写流程--依赖于HBase的4大组件:分别是客户端、Zookeeper、HMaster和HRegionServer。
HBase的读写都是由客户端进行发起的。首先是读的过程:客户端根据用户提供的表名、行键去客户端里的缓存进行查询,没有查询到,就去Zookeeper进行查询。Zookeeper在HBase中用来存储ROOT表的地址。HBase中有两张重要的表,分别是ROOT表和META表,ROOT表记录META表的region信息,而META表记录的是用户表的region信息。简单来说,META表的行键是由Region所属表的表名、以及该region在表中的开始行键和时间戳组成,列族info定义了三个列,分别是regionInfo存储了region中开始结束行键,server列存储了region所在的服务器地址,serverstartcode存储了regionServer的状态。
由于META表也是一张普通的HBASE表,因此当META表的数据越来越多的时候,也会分裂成多个meta region,每个meta region也会被不同的regionServer管理。因此就需要有一张表存储meta region的信息,这张表就是ROOT表,ROOT表只存储了一个region信息,那就是meta region。按照这个过程,理论上还需要一张表存储ROOT表的信息,但是这样就会产生无穷无尽的表存储类似的信息,针对于这种情况,因此HBase的开发人员认为ROOT表数据量不会很大,因此不会数据分裂,所以就不需要其他表存储ROOT表的region信息了。
客户端通过Zookeeper获得了ROOT表的地址,通过RPC连接到ROOT表所在的RegionServer,根据ROOT表查询META表,然后根据用户所提供的表名和行键,组成一个XXXXXXX(),通过这个行键去META表查询,拿到info列族中的regionInfo和server列的值之后,根据server列的值,客户端与RegionServer建立连接,将regionInfo列的数据提交给RegionServer。
RegionServer接收客户端的查询请求之后,首先创建RegionScanner对象,通过该对象定位到HRegion,然后HRegin对象创建StoreScanner,通过StoreScanner定位到HStore,HStore对象创建1个MemStoreScanner对象,这个对象负责去MemStore查询有没有相关数据,有则返回,没有就创建多个StoreFileScanner对象,每个对象否则去不同的HFile中查询数据,如果找到了则返回,如果没有就返回null。
HBase写的过程:当客户端进行put操作时,数据会自动保存到HRegion上,在HRegionServer中,找到对应要写入的HRegion之后,数据会写入到HLog中并同时写入到HStore的MemStore内存中,会在内存中按照行键对数据进行排序,当内存中的数据达到一定阈值后,会触发flush操作。Flush操作主要就是把MemStore内存中的数据写入到StoreFile中,当HDFS中的StoreFile个数达到一定的阈值后,会触发compact(合并)操作,将HDFS中所有的StoreFile合并成一个新的SotreFile,在合并的时候会按照行键进行排序,并且会进行版本合并和数据删除。当StoreFile通过不断的合并操作后,StoreFile文件会变得越来越大,当这个StoreFile达到一定的阈值后,会触发Split(切分)操作,同时把当前region拆分成两个新的region,原有的region会下线,新的两个region会被HMaster分配到相应的HRegionServer上,使得原来一个Region的压力得以分流到两个Region上,其实,HBase只是增加数据,更新和删除操作都是compact阶段做的,所以,客户端写入成功的标志是HLog和MemStore中都有数据。
先写HLog,但是如果显示MemSotre也是没问题的,因为MemStore的MVCC(多版本并发控制)不会向前滚动,这些变化在更新MVCC之前,Scan是无法看到的,所以在写入HLog之前,即使MemStore有数据,客户端也查询不到。
HBASE的优化
1. 对行键、列族、列名称长度优化,HBase引入block的原因是block中包含了很多的key/value,每个key中包含rowkey、列族、列、时间戳,减少rowkey、列族、列的长度就能减少block的数量,否则会增加region server、region、索引、内存、查询范围。
2. 当进行批量处理数据时,客户端会将数据先保存到客户端的缓存中,HBASE默认是开启隐式刷写的,当关闭隐式刷写时,put的数据也会保存到客户端的缓存中,直到调用刷写命令时,才会保存到HRegion中。
3.查询优化:
*设置scan缓存。
*查询时指定列。
*使用完ResultScanner后及时关闭。
*查询时尽量使用过滤器或协处理器,减少数据量。
*将查询频率较高的数据缓存起来。例如缓存到redis中。
*使用HtableTool查询。
*使用批量读取Htable.get(List
4.写入优化:
*关闭WAL日志,如果开启了WAL日志,可以修改日志写入hdfs的时间。(存在数据丢失的风险优化)
*设置AutoFlush为false。(存在数据丢失的风险优化)
*Region预分区,两种方式,hbase自带的RegionSplitter,和自己实现,一般使用hbase自带的。
*通过HtableTool写入。
*使用批量写入Htable.put(List
5.配置方面优化:
*设置RegionServer的处理线程数量,但是需要先进行测试。
*调整BlockChche或者MemStore内存大小大小,如果读的较多则将BlockChche增大,如果写的较多则MemStore调大。但两者之和不能超过
一个RegionServer总内存大小的80%。(StoreFile的flush)
*调整StoreFile合并的数量限制,太少则合并次数频繁严重影响性能,太大会到这查询变慢。(StoreFile的compart)
*设置单个StoreFile的大小,调整分裂的性能。(StoreFile的spill)
6.行键设计:最大长度64KB
*因为hbase会的rowkey按照字节顺序由小到大排序,因此需要保持rowkey松散性,避免单调递增,防止出现region热点。
*因为hbase只对rowkey建立索引,所以要保证行键的唯一性。
*因为行键是不可变的,所以在设计之初要满足业务需求。
*因为rowkey是冗余存储,所以只要满足以上要求,行键长度尽量短。
7.列族设计:
*因为hbase底层是以列族为单位存储的,一个列族中的数据会被存放在一个磁盘文件中,所以应该将具有相同特性的列放到一个列族中。
*一个表中的列族尽量不要太多,保持到1-2个最好。
*如果是更新频繁并且只需要最获取最新数据可以设置,单元格的时间版本为1,默认为3(VERSION)
*可以设置单元格的生命周期(TTL)
*随机读较多开启布隆过滤器。
CAP原理
Consistency强一致性、availability可用性、partition tolerance分区容错性,在一个大规模的分布式服务系统中不可能同时存在。
C指的是更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致
A指的是读和写操作都能成功
P指的是节点宕机不影响服务的运行。
HBASE只支持CP
到此,相信大家对“HBase的读写流程以及优化方法”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
当前题目:HBase的读写流程以及优化方法
当前路径:http://pwwzsj.com/article/iiocgh.html