本篇内容主要讲解“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