这篇文章主要介绍“HBase1.x优化本地数据举例分析”，在日常操作中，相信很多人在HBase1.x优化本地数据举例分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”HBase1.x优化本地数据举例分析”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
现象：
由于同事反应生产上在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优化本地数据举例分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
