HBase最佳实践——读性能优化策略

任何系统都会有各类各样的问题，有些是系统自己设计问题，有些倒是使用姿式问题。HBase也同样，在真实生产线上你们或多或少都会遇到不少问题，有些是HBase还须要完善的，有些是咱们确实对它了解太少。总结起来，你们遇到的主要问题无非是Full GC异常致使宕机问题、RIT问题、写吞吐量过低以及读延迟较大。

Full GC问题以前在一些文章里面已经讲过它的前因后果，主要的解决方案目前主要有两方面须要注意，一方面须要查看GC日志确认是哪一种Full GC，根据Full GC类型对JVM参数进行调优，另外一方面须要确认是否开启了BucketCache的offheap模式，建议使用LRUBlockCache的童鞋尽快转移到BucketCache来。固然咱们仍是很期待官方2.0.0版本发布的更多offheap模块。

RIT问题，我相信更可能是由于咱们对其不了解，具体原理能够戳 这里 ，解决方案目前有两个，优先是使用官方提供的HBCK进行修复(HBCK本人一直想拿出来分享，可是目前案例还很少，等后面有更多案例的话再拿出来讲)，使用以后仍是解决不了的话就须要手动修复文件或者元数据表。而对于写吞吐量过低以及读延迟太大的优化问题，笔者也和不少朋友进行过探讨，这篇文章就以读延迟优化为核心内容展开，具体分析HBase进行读延迟优化的那些套路，以及这些套路以后的具体原理。但愿你们在看完以后可以结合这些套路剖析本身的系统。

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

1. 仅有某业务延迟较大，集群其余业务都正常；

2. 整个集群全部业务都反映延迟较大；

3. 某个业务起来以后集群其余部分业务延迟较大。

这三种场景是表象，一般某业务反应延迟异常，首先须要明确具体是哪一种场景，而后针对性解决问题。下图是对读优化思路的一点总结，主要分为四个方面：客户端优化、服务器端优化、列族设计优化以及HDFS相关优化，下面每个小点都会按照场景分类，文章最后进行概括总结。下面分别进行详细讲解：

HBase读优化

HBase客户端优化

和大多数系统同样，客户端做为业务读写的入口，姿式使用不正确一般会致使 本业务读延迟较高 实际上存在一些使用姿式的推荐用法，这里通常须要关注四个问题：

1. scan缓存是否设置合理?

优化原理：在解释这个问题以前，首先须要解释什么是scan缓存，一般来说一次scan会返回大量数据，所以客户端发起一次scan请求，实际并不会一次就将全部数据加载到本地，而是分红屡次RPC请求进行加载，这样设计一方面是由于大量数据请求可能会致使网络带宽严重消耗进而影响其余业务，另外一方面也有可能由于数据量太大致使本地客户端发生OOM。在这样的设计体系下用户会首先加载一部分数据到本地，而后遍历处理，再加载下一部分数据到本地处理，如此往复，直至全部数据都加载完成。数据加载到本地就存放在scan缓存中，默认100条数据大小。

一般状况下，默认的scan缓存设置就能够正常工做的。可是在一些大scan(一次scan可能须要查询几万甚至几十万行数据)来讲，每次请求100条数据意味着一次scan须要几百甚至几千次RPC请求，这种交互的代价无疑是很大的。所以能够考虑将scan缓存设置增大，好比设为500或者1000就可能更加合适。笔者以前作过一次试验，在一次scan扫描10w+条数据量的条件下，将scan缓存从100增长到1000，能够有效下降scan请求的整体延迟，延迟基本下降了25%左右。欢迎加入大数据学习交流分享群： 658558542   一块儿吹水交流学习（☛点击便可加入群聊）

优化建议：大scan场景下将scan缓存从100增大到500或者1000，用以减小RPC次数。

2. get请求是否可使用批量请求?

优化原理：HBase分别提供了单条get以及批量get的API接口，使用批量get接口能够减小客户端到RegionServer之间的RPC链接数，提升读取性能。另外须要注意的是，批量get请求要么成功返回全部请求数据，要么抛出异常。

优化建议：使用批量get进行读取请求。

3. 请求是否能够显示指定列族或者列?

优化原理：HBase是典型的列族数据库，意味着同一列族的数据存储在一块儿，不一样列族的数据分开存储在不一样的目录下。若是一个表有多个列族，只是根据Rowkey而不指定列族进行检索的话不一样列族的数据须要独立进行检索，性能必然会比指定列族的查询差不少，不少状况下甚至会有2倍～3倍的性能损失。

优化建议：能够指定列族或者列进行精确查找的尽可能指定查找。

4. 离线批量读取请求是否设置禁止缓存?

优化原理：一般离线批量读取数据会进行一次性全表扫描，一方面数据量很大，另外一方面请求只会执行一次。这种场景下若是使用scan默认设置，就会将数据从HDFS加载出来以后放到缓存。可想而知，大量数据进入缓存必将其余实时业务热点数据挤出，其余业务不得不从HDFS加载，进而会形成明显的读延迟毛刺欢迎加入大数据学习交流分享群： 658558542   一块儿吹水交流学习（☛点击便可加入群聊）

优化建议：离线批量读取请求设置禁用缓存，scan.setBlockCache(false)。

HBase服务器端优化

通常服务端端问题一旦致使业务读请求延迟较大的话，一般是集群级别的，即整个集群的业务都会反映读延迟较大。能够从4个方面入手：

1. 读请求是否均衡?

优化原理：极端状况下假如全部的读请求都落在一台RegionServer的某几个Region上，这一方面不能发挥整个集群的并发处理能力，另外一方面势必形成此台RegionServer资源严重消耗(好比IO耗尽、handler耗尽等)，落在该台RegionServer上的其余业务会所以受到很大的波及。可见，读请求不均衡不只会形成自己业务性能不好，还会严重影响其余业务。固然，写请求不均衡也会形成相似的问题，可见负载不均衡是HBase的大忌。

观察确认：观察全部RegionServer的读请求QPS曲线，确认是否存在读请求不均衡现象。

优化建议：RowKey必须进行散列化处理(好比MD5散列)，同时建表必须进行预分区处理。

2. BlockCache是否设置合理?

优化原理：BlockCache做为读缓存，对于读性能来讲相当重要。默认状况下BlockCache和Memstore的配置相对比较均衡(各占40%)，能够根据集群业务进行修正，好比读多写少业务能够将BlockCache占比调大。另外一方面，BlockCache的策略选择也很重要，不一样策略对读性能来讲影响并非很大，可是对GC的影响却至关显著，尤为BucketCache的offheap模式下GC表现很优越。另外，HBase 2.0对offheap的改造(HBASE-11425)将会使HBase的读性能获得2～4倍的提高，同时GC表现会更好!

观察确认：观察全部RegionServer的缓存未命中率、配置文件相关配置项一级GC日志，确认BlockCache是否能够优化。

优化建议：JVM内存配置量 < 20G，BlockCache策略选择LRUBlockCache;不然选择BucketCache策略的offheap模式;期待HBase 2.0的到来!

3. HFile文件是否太多?

优化原理：HBase读取数据一般首先会到Memstore和BlockCache中检索(读取最近写入数据&热点数据)，若是查找不到就会到文件中检索。HBase的类LSM结构会致使每一个store包含多数HFile文件，文件越多，检索所需的IO次数必然越多，读取延迟也就越高。文件数量一般取决于Compaction的执行策略，通常和两个配置参数有关：hbase.hstore.compactionThreshold和hbase.hstore.compaction.max.size，前者表示一个store中的文件数超过多少就应该进行合并，后者表示参数合并的文件大小最大是多少，超过此大小的文件不能参与合并。这两个参数不能设置太’松’(前者不能设置太大，后者不能设置过小)，致使Compaction合并文件的实际效果不明显，进而不少文件得不到合并。这样就会致使HFile文件数变多。

观察确认：观察RegionServer级别以及Region级别的storefile数，确认HFile文件是否过多。

优化建议：hbase.hstore.compactionThreshold设置不能太大，默认是3个;设置须要根据Region大小肯定，一般能够简单的认为hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold。

4. Compaction是否消耗系统资源过多?

优化原理：Compaction是将小文件合并为大文件，提升后续业务随机读性能，可是也会带来IO放大以及带宽消耗问题(数据远程读取以及三副本写入都会消耗系统带宽)。正常配置状况下Minor Compaction并不会带来很大的系统资源消耗，除非由于配置不合理致使Minor Compaction太过频繁，或者Region设置太大状况下发生Major Compaction。

观察确认：观察系统IO资源以及带宽资源使用状况，再观察Compaction队列长度，确认是否因为Compaction致使系统资源消耗过多。

优化建议：

(1)Minor Compaction设置：hbase.hstore.compactionThreshold设置不能过小，又不能设置太大，所以建议设置为5～6;hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold。

(2)Major Compaction设置：大Region读延迟敏感业务( 100G以上)一般不建议开启自动Major Compaction，手动低峰期触发。小Region或者延迟不敏感业务能够开启Major Compaction，但建议限制流量;

(3)期待更多的优秀Compaction策略，相似于stripe-compaction尽早提供稳定服务。

HBase列族设计优化

HBase列族设计对读性能影响也相当重要，其特色是只影响单个业务，并不会对整个集群产生太大影响。列族设计主要从两个方面检查：

1. Bloomfilter是否设置?是否设置合理?

优化原理：Bloomfilter主要用来过滤不存在待检索RowKey或者Row-Col的HFile文件，避免无用的IO操做。它会告诉你在这个HFile文件中是否可能存在待检索的KV，若是不存在，就能够不用消耗IO打开文件进行seek。很显然，经过设置Bloomfilter能够提高随机读写的性能。

Bloomfilter取值有两个，row以及rowcol，须要根据业务来肯定具体使用哪一种。若是业务大多数随机查询仅仅使用row做为查询条件，Bloomfilter必定要设置为row，不然若是大多数随机查询使用row+cf做为查询条件，Bloomfilter须要设置为rowcol。若是不肯定业务查询类型，设置为row。

优化建议：任何业务都应该设置Bloomfilter，一般设置为row就能够，除非确认业务随机查询类型为row+cf，能够设置为rowcol。

HDFS相关优化

HDFS做为HBase最终数据存储系统，一般会使用三副本策略存储HBase数据文件以及日志文件。从HDFS的角度望上层看，HBase便是它的客户端，HBase经过调用它的客户端进行数据读写操做，所以HDFS的相关优化也会影响HBase的读写性能。这里主要关注以下三个方面：

1. Short-Circuit Local Read功能是否开启?

优化原理：当前HDFS读取数据都须要通过DataNode，客户端会向DataNode发送读取数据的请求，DataNode接受到请求以后从硬盘中将文件读出来，再经过TPC发送给客户端。Short Circuit策略容许客户端绕过DataNode直接读取本地数据。

优化建议：开启Short Circuit Local Read功能，具体配置戳这里。

2. Hedged Read功能是否开启?

优化原理：HBase数据在HDFS中通常都会存储三份，并且优先会经过Short-Circuit Local Read功能尝试本地读。可是在某些特殊状况下，有可能会出现由于磁盘问题或者网络问题引发的短期本地读取失败，为了应对这类问题，社区开发者提出了补偿重试机制 – Hedged Read。该机制基本工做原理为：客户端发起一个本地读，一旦一段时间以后尚未返回，客户端将会向其余DataNode发送相同数据的请求。哪个请求先返回，另外一个就会被丢弃。

优化建议：开启Hedged Read功能。

3. 数据本地率是否过低?

数据本地率：HDFS数据一般存储三份，假如当前RegionA处于Node1上，数据a写入的时候三副本为(Node1,Node2,Node3)，数据b写入三副本是(Node1,Node4,Node5)，数据c写入三副本(Node1,Node3,Node5)，能够看出来全部数据写入本地Node1确定会写一份，数据都在本地能够读到，所以数据本地率是100%。如今假设RegionA被迁移到了Node2上，只有数据a在该节点上，其余数据(b和c)读取只能远程跨节点读，本地率就为33%(假设a，b和c的数据大小相同)。欢迎加入大数据学习交流分享群： 658558542   一块儿吹水交流学习（☛点击便可加入群聊）

优化原理：数据本地率过低很显然会产生大量的跨网络IO请求，必然会致使读请求延迟较高，所以提升数据本地率能够有效优化随机读性能。数据本地率低的缘由通常是由于Region迁移(自动balance开启、RegionServer宕机迁移、手动迁移等),所以一方面能够经过避免Region无端迁移来保持数据本地率，另外一方面若是数据本地率很低，也能够经过执行major_compact提高数据本地率到100%。

优化建议：避免Region无端迁移，好比关闭自动balance、RS宕机及时拉起并迁回飘走的Region等;在业务低峰期执行major_compact提高数据本地率。

HBase读性能优化概括

在本文开始的时候提到读延迟较大无非三种常见的表象，单个业务慢、集群随机读慢以及某个业务随机读以后其余业务受到影响致使随机读延迟很大。了解完常见的可能致使读延迟较大的一些问题以后，咱们将这些问题进行以下归类，读者能够在看到现象以后在对应的问题列表中进行具体定位：

HBase读性能优化总结

性能优化是任何一个系统都会遇到的话题，每一个系统也都有本身的优化方式。 HBase做为分布式KV数据库，优化点又格外不一样，更多得融入了分布式特性以及存储系统优化特性。文中总结了读优化的基本突破点，有什么不对的地方还望指正，有补充的也能够一块儿探讨交流!

结语

感谢您的观看，若有不足之处，欢迎批评指正。

若是有对大数据感兴趣的小伙伴或者是从事大数据的老司机能够加群：

658558542    （☛点击便可加入群聊）

里面整理了一大份学习资料，全都是些干货，包括大数据技术入门，海量数据高级分析语言，海量数据存储分布式存储，以及海量数据分析分布式计算等部分，送给每一位大数据小伙伴，这里不止是小白汇集地，还有大牛在线解答！欢迎初学和进阶中的小伙伴一块儿进群学习交流，共同进步！

最后祝福全部遇到瓶颈的大数据程序员们突破本身，祝福你们在日后的工做与面试中一切顺利。