HBASE的读延迟分析及其优化

 

一 HBASE的概述

1. 1. HBASE的简介

HBASE的起源与Google的论文的BigTable论文的,现在是Apache的*项目之一。HBAS不同于是一般的关系型的数据库，它是一个的非结构化的数据存储的数据库，而且和redis这个类按照key-value的存储数据形式的非结构化数据库的有点不同是，hbase是基于列进行存储的接近实时的数据库。

 

1. 1. HBASE的结构和功能

Hbase的结构：

1. 数据库存储是基于region进行分布式存储数据；
2. 支持HDFS文件系统进行存储数据；
3. 支持数据分片的操作；
4. 数据结构的组成：由行，列族，列和单元格组成；

 

   Hbase的功能：

1. 支持向外扩展（本质是因为HDFS的原因）；
2. 可以使用API和MR来访问Hbase的表格的数据；
3. 可以存储结构化和非结构化的数据；
4. 不支持事务和join的操作；
5. 底层的数据存储数据结构为二进制数据，可以存储各种数据类型；

 

1. 1. 基于Hadoop的Hbase的架构

 

Hbase的架构图

Hbase中内置Zookeeper来进行监管的集群中的master和regionserver，主要来保证的几个方面，一个方面是Zookeeper的通知机制和节点的特性来保证集群只有一个活跃的HMaster节点和HMaster节点的高可用，另一个方面实时监控HRegionserver的上线和下线信息并通知给HMaster,最后一个方面是存储Hbase的schema和table的元信息；

Hbase的RegionServer的架构图参考如下，每一个每个RegionServer维护一个HLog和多个HFiles以及其对应的MemStore。RegionServer运行于DataNode上，数量可以与DatNode数量一致，底层采用HDFS进行存储。

RegionServer架构图

 

二 HBASE的读性能延迟分析

2.1 HBASE的问题

   但是Hbase有很多的优点比如存储非结构化数据，维护多个数据的版本，但是在实际的使用的当中的也是存在很多的问题，其中大家遇见的最多的问题是写的吞吐量太低了，读延迟延迟比较大以及一些集群的问题包括Full GC导致集群宕机的问题等；

在官方的测试的当中总记录数为10亿，分为128个region，均匀分布在4台region server上；查询操作执行2千万次；查询请求分布遵从zipfian分布，结果如图：

 

   但是在实际的环境当中因为各个的原因存在我们读延迟比较大，下面我们通过几个方面来进行分析读延迟的产生的原因。

 

2.2 读延迟大的分析

2.2.1 读延迟的场景概述

读请求延迟较大通常存在三种场景，分别为：

第一种. 仅有部分业务延迟较大，集群其他读取业务数据都正常，

第二种：整个集群所有业务读延迟的反映延迟较大；

第三种. 某个业务起来之后集群其他部分业务延迟较大；

无论存在哪种情况的产生的读延迟的，首先我们需要了解是什么原因产生的读延迟，比如是因为rowkey设置的不合理，还是region的数量还是Hfile的小文件太多等引起，然后进行针对性解决问题。

本次的讨论的这3种情况通过客户端端优化，服务端优化，列族优化和HDFS优化这3个方面进行分析和讨论。

 

2.2.2 随机读的延迟慢分析和解决

首先我们先讨论集群的随机读的延迟慢的现象，整个集群的读延迟的如果都比较高的话，我们的优化的思路主要从服务端进行优化和HDFS的进行优化，因为是整个集群的读延迟比较高可能是我们的集群的配置不合理或者是HFile的小文件比较多。

HBase的服务端优化主要可以考虑方面：

1. BlockCache的问题，因为之前Hbase之前读取的数据会缓存在Hbase，Hbase读取顺序来说因为先去MenStore查找数据，没有找到数据就会去BlockCache查找数据，所以BlockCache的设置也是比较关键的，默认的情况下BlockCache和Memstore的配置相对比较均衡，但是如果我们是读的业务比较多的，可以将BlockCache的占用的比例调大，如果Hbase的版本是2，0版本可以考虑选择BlockCache策略选择LRUBlockCache，这个模式下对GC的表现比较优越，并且可以提高Hbase的读性能提高2倍左右；
2. Hfile的问题，Hfile的文件太多，导致查找的效率比较慢，因为HBase读取数据通常首先会到Memstore和BlockCache中检索，如果查找不到就会到Hfile文件中检索。Hfile的文件越多，导致需要IO的次数就越多，延迟也就会越高，可以考量设置Compaction的执行策略，通常可以设置hbase.hstore.compactionThreshold=3，hbase.hstore.compaction.max.size=RegionSize / hbase.hstore.compactionThreshold；
3. Compaction的问题，Compaction是将小文件合并为大文件来提高读的性能，因为需要合并小文件为大文件所以占用资源和大量的IO，主要考量Major Compaction设置的问题，如果Region（几百G）太大的话，建议手动合并；

HDFS的优化主要考虑：

1. 是否开启Short Circuit Local Read，开启之后这个策略允许客户端绕过DataNode直接读取本地DataNode数据。可以有效的减少网络的传输数据的消耗；
2. 是否开启Hedged Read，这个机制主要是：客户端发起一个本地读，一旦一段时间之后还没有返回，客户端将会向其他DataNode发送相同数据的请求。哪一个请求先返回，另一个就会被丢弃，减少读延迟的时间；

 

2.2.3 某些业务慢，集群速度不慢问题

     从现象来看只是某一些业务慢，其他业务集群的读延时是合理，主要说明是我们业务上设计存在问题，我们主要可以从这个几个方面考虑：

客户端优化主要考虑：

1. Scan缓存的设置，通常我们使用Scan会返回大量的数据，因为数据太大了，不是一次请求就可以将所有的数据的加载到本地，所以我们需要发送多次的PRC的请求来获取数据，这样发送大量数据请求会产生的网络的延迟并且数据如果太大加载到本地也需要时间，所以Hbase设置的是先加载到一部分到本地，然后缓存在Scan当中，默认是100条数据，对于大数据的请求来说，这需要发送几百上千的RPC的请求，导致读延迟大，可以将scan的缓存调大，然一次发送请求加载的数据比较多，进而减少RPC发送的请求，可以将scan的缓存设置在几百到1000左右，具体看业务的数据而定。
2. GET的设置考虑，Hbase提供单条的GET请求和批量的GET的请求，建议使用批量的GET的方式，减少RPC的请求的次数。

 

 列族设计优化：

Bloomfilter的问题，Bloomfilter取值有两个，row以及rowcol，需要根据业务来确定具体使用哪种。如果业务大多数随机查询仅仅使用row作为查询条件，Bloomfilter一定要设置为row，否则如果大多数随机查询使用row+cf作为查询条件，Bloomfilter需要设置为rowcol。如果不确定业务查询类型，设置为row。

 

 

   HDFS的优化：

数据本地率太低的问题：HDFS的数据通常存储3份，如果本地数据太低2，基于需要通过网络来获取数据，会导致读延迟的时间变长，产生的原因可能是Region的迁移，可以建议关balance,也在业务低峰的采用major_compact提升数据本地率。

 

2.2.4起了某个业务导致其他业务读延迟高

这个现象说明这个业务占用的某一些资源比较多，数据分配不均匀导致数据都在几个region上，不能发挥整个集群的鬓发处理能力，优化主要考虑服务器。

 服务器的读请求：

数据分配不均匀导致数据都在几个region上，导致RegionServer资源严重消耗（，RegionServer上的其他业务会因此受到很大的波及。可见，读请求不均衡不仅会造成本身业务性能很差，还会严重影响其他业务。当然，写请求不均衡也会造成类似的问题，可见负载不均衡是HBase的大忌。 主要的处理方案是RowKey必须进行散列化处理（比如MD5散列），同时建表必须进行预分区处理

 

   本文主要讨论读延迟的产生的原因及其分析产生的原理和如何优化得思路，具体的优化情况需要我们根据业务场景产生的原因采用对应方案来进行解决问题。