知无不言代立冬：大家都在关注hbase到底是怎样的？ -欧洲杯足彩官网

1顶
0踩

知无不言代立冬：大家都在关注hbase到底是怎样的？

2016-11-04 13:37 by 副主编 mengyidan1988 评论(1) 有10292人浏览

hbase mongodb

声明：iteye资讯文章的欧洲杯足彩官网的版权属于iteye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

【编者按】hbase作为hadoop家族的重要一员，其不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是，它基于列的而不是基于行的模式。

为了帮助大家更加系统全面地学习hbase知识，我们csdn知识库特邀请了知名的社区专家代立冬老师，绘制了hbase知识图谱，根据知识点挑选优质内容呈现给大家

引用

代立冬，csdn知识库特邀编辑，csdn社区专家。信柏信息科技有限公司架构师，专注于数据平台的规划、集群调优、数据安全、数据仓库构建以及线上trouble shooting，个人博客

hbase知识库即将发布，抢先占座地址

代立冬

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;

然后具体性能优化可分为服务端和客户端，服务端和客户端我列几个代表性的(详细请参见)

服务端：

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付出如此大的力气去做这个知识体系建设，实属难得。我刚好在学习深度学习，现在知识库里面列出了深度学习体系的知识点，并且每个知识点有不少精选的文章，我会着重找下相关的最新的业界进展，顺便看下有没有相关开放的数据集，另外我也会搜集整理成自己的知识体系。

推荐阅读：

分享到：

1
顶

0
踩

评论共 1 条请登录后发表评论

1 楼 2018-01-31 10:46

发表评论

您还没有登录,请您登录后再发表评论

知无不言 代立冬：大家都在关注hbase到底是怎样的？ -欧洲杯足彩官网

1顶0踩