十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章主要介绍“HBase1.x优化本地数据举例分析”,在日常操作中,相信很多人在HBase1.x优化本地数据举例分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”HBase1.x优化本地数据举例分析”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
创新互联凭借专业的设计团队扎实的技术支持、优质高效的服务意识和丰厚的资源优势,提供专业的网站策划、成都网站设计、网站建设、外贸网站建设、网站优化、软件开发、网站改版等服务,在成都10年的网站建设设计经验,为成都1000多家中小型企业策划设计了网站。
现象:
由于同事反应生产上在HBase Shell中,通过 get ‘表’,‘rowkey’ 获取数据的时候,经常会出现,连续多次执行同一条get命令,前面N-1次可能没问题,到了第N次就卡住了,时间一长就报超时的错误。
我看了下后台日志也没有太明显的错误,其他方法都试了也没解决掉这个问题,后来好好想了下,这个集群最近一段时间通过BulkLoad方式导入了40TB左右的数据,里面肯定会有很多小的HFile和需要清理的文件。由于生产环境major compation都是关闭掉的,都是通过手动执行。
于是我百度找了个Shell批量执行脚本,晚上对所有表跑了下major compaction,大约执行了有2个多小时,第二天早上发现问题已修复,且HBase监控界面的RegionSrever数据本地化率(data locality),从原来的19%提升到了99%,于是我找了找相关的东西。
1.什么是HBase的数据本地化率?
Data Locality用来衡量region服务的数据即region的HFile位于本地的百分比。
在hadoop生产环境中, hdfs通常为设置为三个副本,假如当前RegionA处于datanode1,当数据a通过从Memstore中Flush到HFile时,三副本为(datanode1,datanode2,datanode3),数据b写入三副本是(datanode1,datanode3,datanode5),数据c写入三副本(datanode1,datanode4,datanode6),可以看出来a、b、c三份数据写入的时候肯定会在本地datanode1上写入一份,其他两份按照datanode的写入机制进行分配;数据都在本地可以读到,因此数据本地率是100%。现在假设RegionA被迁移到了datanode2上,只有数据a有一份数据在该节点上,其他数据(b和c)读取只能远程跨节点读,本地率就为33%(假设a,b和c的数据大小相同)。
2.数据本地化率低的原因
由本地化率的定义我们知道,数据本地化率低的原因肯定是region和hfile数据不在同一个节点上,会产生大量的跨网络IO请求,必然会导致读请求延迟较高,那什么时候才会导致region的迁移呢?下面是我个人的理解,可能理解的不太全面,如果后面有更深层次的问题我会给大家完善进来。
1).当数据持续写入,单个region的大小达到hbase.hregion.max.filesize(默认值10GB)会自动进行Split,假如一直向RegionA持续写入数据,当RegionA大小超过10GB,会分离成两个子RegionB、RegionC,如果我们集群开启了
2).其他情况也可能导致Region的迁移,Regionserver服务宕机,手动move使region迁移到其他节点,导致数据本地化率降低。
3.如何提升数据本地化率
1.关闭HBase的Region负债均衡(balance)
2.regionserver重启后,手动move到原来节点(如果生产region比较多,这个操作比较繁琐)
3.major compaction的时候,使得一个region拥有的所有数据都转移到region这台机子上来,从而确保本地化,major compaction时间会持续比较长,整个过程会消耗大量系统资源,对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能,改为手动在业务低峰期触发大合并。
Region拆分详解请查看我的另外一篇文章:
注意:
如果RegionServer接手了一个Region,那么大多数数据块不在本地的NameNode上,读写性能会有下降,但会在后续的Compact过程中逐渐将文件写入本地的DataNode,从而恢复Data Locality。
到此,关于“HBase1.x优化本地数据举例分析”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!