Hbase读写优化

转载地址：http://www.iteye.com/news/31920

CSDN知识库：你是如何与计算机结缘，踏上软件开发之路的，能否跟我们分享一下。 

代立冬：我走上计算机这条路主要源于大学室友熏陶，我本身是学数学专业的，按常理毕业后应该当个教师。而我们宿舍6个室友有一半学数学，一半学计算机。经常看室友们写点小程序，觉得挺厉害，有时还听他们吹牛皮：他们班一同学写了个校园论坛云云，长期耳濡目染后，自然走上了这条道。有一段时间还常跑去听他们老师讲专业课。后来在网上找到一些商城的开源代码，有空就折腾折腾，不时添加点需求实现下，当然当时的主流还是做网站开发，SSH框架大行其道，不像现在择业方向这样广。 

CSDN知识库：HBase作为NoSQL数据库，与其他NoSQL产品有哪些区别和优势？ 

代立冬：这里拿NoSQL主要的两个代表作品做下对比（HBase和MongoDB），两者主要的区别： 

• MongoDB是文档型数据库，整个数据都存在磁盘中，HBase是列式数据库，存储时按column family保存到对应的hdfs文件中;
• MongoDB支持二级索引，而HBase本身不支持二级索引；
• MongoDB的update是update-in-place，也就是原地更新，而HBase的修改和添加都使用put，实际上HBase内部对已经存在的rowkey数据，只是将这一数据用不同的版本号保存下来而已，HBase默认的保存版本的数量是3；
• HBase根据文件的大小来控制region的分裂，在HBase内部，存储时，数据按照Row key的字典序(byte order)排序存储；MongoDB根据负载来决定shards的分裂；
• MongoDB和HBase都支持mapreduce，不过MongoDB的mapreduce支持不够强大，调试也较麻烦；
• MongoDB的读效率比写高，HBase默认适合写多读少的情况。

以我们的线上使用情况，对rowkey分布均匀的情况，HBase集群的写速度单台regionserver达到3~4w/秒，单key查询一般10ms内返回(如果使用SSD硬盘会更快)。由于我们线上每天写入70多亿条数据，当时MongoDB还没有收购WiredTiger，当时MongoDB的写入锁是个很大问题，所以我们技术选型就选的HBase。 

CSDN知识库：如何提升HBase的读写性能？  

代立冬： 首先我们需要知道影响读写性能有什么因素： 

写速度关键因素 

• table region分布均衡;
• 单台region server的region数;
• hbase.regionserver.handler.count;
• hbase.regionserver.global.memstore.upperLimit;
• hbase.hregion.memstore.block.multiplier;
• hbase.hstore.blockingStoreFiles;
• hbase.hregion.max.filesize;

读速度关键因素 

• 单台Region Server上的Region数;
• StoreFile数;
• bloomfilter;
• in-memory flag;
• blockcache设置;
• hfile.block.cache.size;

然后具体性能优化可分为服务端和客户端，服务端和客户端我列几个代表性的(详细请参见 http://blog.csdn.net/odailidong/article/details/41794403 ) 

服务端： 

• hbase.hregion.max.filesize：默认是10G，如果任何一个column familiy里的StoreFile超过这个值, 那么这个Region会一分为二，因为Region分裂会有短暂的Region下线时间(通常在5s以内)，建议手动定时分裂，可以设置为60G；
• hbase.hregion.majorcompaction：hbase的Region主合并的间隔时间，默认为1天，建议设置为0，禁止自动的major主合并，major合并会把一个store下所有的storefile重写为一个storefile文件，还会把有删除标识的数据删除，业务低峰期major合并；
• hbase.hregion.memstore.flush.size：默认值128M，单位字节，一旦有memstore超过该值将被flush，如果regionserver的jvm内存比较充足(16G以上)，可以调整为256M；
• hbase.hstore.compaction.max：默认值为10,一次最多合并多少个storefile，避免OOM；
• hbase.hstore.blockingStoreFiles：默认为7，如果任何一个store(非.META.表里的store)的storefile的文件数大于该值，则在flush memstore前先进行split或者compact，同时把该region添加到flushQueue，延时刷新，这期间会阻塞写操作直到compact完成或者超过hbase.hstore.blockingWaitTime(默认90s)配置的时间，可以设置为30，避免memstore不及时flush。

客户端 

• hbase.client.write.buffer：默认为2M，写缓存大小，推荐设置为5M，单位是字节，当然越大占用的内存越多，此外测试过设为10M下的入库性能，反而没有5M好；
• hbase.client.pause：默认是1000(1s)，如果你希望低延时的读或者写，建议设为200，这个值通常用于失败重试，region寻找等；
• hbase.client.retries.number：默认值是10，客户端最多重试次数,可以设为11，结合上面的参数，共重试时间71s；
• hbase.ipc.client.tcpnodelay：默认是false，建议设为true，关闭消息缓冲；
• hbase.client.scanner.caching：scan缓存，默认为1，避免占用过多的client和rs的内存，一般1000以内合理，如果一条数据太大，则应该设置一个较小的值，通常是设置业务需求的一次查询的数据条数，如果是扫描数据对下次查询没有帮助，则可以设置scan的setCacheBlocks为false，避免使用缓存；
• 限定扫描范围：指定列簇或者指定要查询的列，指定startRow和endRow。通过java多线程入库和查询，并控制超时时间。

CSDN知识库：HBase的rowkey设计需要注意哪些情况，有哪些好的设计方案？  

代立冬： 整体上说rowkey设计尽量分布均匀，避免热点。常见的均匀rowkey设计可考虑逆序，加盐值打散，如果是递增数字，还可考虑使用Long.maxValue减去当前值。 

rowkey的特点： 

• 三维有序rowkey（行主键,按ascii排序）
• columnkey(columnFamily+qualifier)
• timestamp(时间戳)

举个简单例子，比如手机号分为13,15,17,18等号段，但是13开头的手机号码特别的多，这时就可以考虑逆序下是否能满足需求。rowkey的设计应具体场景具体对待。如果怎么设计，都避免不了会产生热点的问题，也不用太担心，下面这个问题是针对热点的一些处理办法。 

CSDN知识库：HBase发生数据热点问题时，应该从哪些角度分析问题？  

代立冬： 热点问题通常是某些region读取或写入压力过大，热点可以通过设置监控阀值来发现。 
在监控检测到热点region时，可以手动(自动)进行热点region split，如果发现某台region server上不少region是热点，可以考虑，move region到其它空闲的region server上，注意监控region server服务器的硬件，比如cpu、memory、io、network等指标。如果需要删除大量数据，尽量考虑设置TTL数据自动过期删除。而后可以返回来去考虑主键的设计，是否采用压缩等。 

CSDN知识库：如何基于HBase实现二级索引，开源方案中常用的有哪些，以及性能如何？  

代立冬： 这个我没有实际使用过，一些开源的二级索引通过使用协处理器去做的，但协处理器运行在region server本身的内存中，对于大型集群，不建议使用。有些替代的办法比如可以考虑结合ElasticSearch使用 

CSDN知识库：从哪些方面可以判断HBase集群是否健康？  

代立冬： 对于1个需要7*24小时在线服务的集群来说，这个通常需要有一套监控报警系统去监控HBase集群的运行状况，我们当时调研过世面上很多开源的监控，都不大满意。最后参照sematext公司的产品实现了1套自己的hbase(含hdfs)监控报警体系。 

对于Hbase健康，我主要关注以下指标： 

• zookeeper的状态、连接数(一般一台zookeeper节点上连接数不会超过200)、发送和接收数据量
• region热点，region storefile个数和size，region split失败次数情况(吃过大亏)
• region memstore大小、flush队列大小、flush耗时及大小情况。
• block cache命中率及cache大小
• region server的合并/分裂队列数，我们是每天在业务低峰时定时合并/分裂region的，所以这个值大部分时间都是0
• region server上rpc连接数，jvm内存gc情况，经jvm参数优化，对64G的jvm内存还没有出现过full gc的情况

当然还有一些指标，不一一列举了。 

CSDN知识库：介绍一些HBase的典型应用场景？  

代立冬： 个人总结的一些场景，欢迎补充： 

• 存储大量数据(TB级以上)，需要很高的写吞吐能力，在大规模数据集中随机访问(基于rowkey)，需要水平扩展能力，易维护；
• 不适合对事务要求高、多维度查询的场景。

CSDN知识库:对HBase初学者有没有什么好的建议？  

代立冬： 建议理论->实践->理论理论这样的路线，HBase的用法跟关系型数据库的用法不大一样，从关系型转过来的同学需要稍转变下思路，现在网上的关于HBase资料很多，多看，多练，对于测试集群来说，尝试把服务搞瘫痪，再尝试修复。还可以关注官方的issue列表，国内还可以加几个群，多问问群里的热心人 

CSDN知识库：你最近在研究哪些技术？谈谈自己的感受。  

代立冬： 现在数据平台整体稳定，我个人抽时间学了些深度学习方面的技术，主要是cnn、rnn。对我冲击最大的是深度学习效果在某些场景（比如分类）为何如此好，当然也有我头疼的地方，就是它现在还需要有大量的标注数据然后效果才能上去。很多传统的机器学习做法，比如复杂的验证码识别等用深度学习实现，效果很好。 

CSDN知识库：关于技术学习您有什么心得？我们上线了知识库系统化学习的方法，您会怎么应用呢？  

代立冬： 大数据时代随着很多新兴概念逐渐流行，相应的技术也会有很多，我觉得还是脚踏实地，尽量在工作中运用上所学技术，实践中积累，总结，同时多分享自己的所学知识给伙伴们，在给别人帮助同时受益可能最大的还是自己。现在在搜一些问题解决方法时，也经常能看到CSDN的身影，对CSDN付出如此大的力气去做这个知识体系建设，实属难得。我刚好在学习深度学习，现在知识库里面列出了深度学习体系的知识点，并且每个知识点有不少精选的文章，我会着重找下相关的最新的业界进展，顺便看下有没有相关开放的数据集，另外我也会搜集整理成自己的知识体系。