首页 > 其他 > 详细

HBase 经验小结 (Based on 1.x)

时间:2019-06-20 01:15:04      阅读:214      评论:0      收藏:0      [点我收藏+]
  1. HBase
    1.1 存储
  • Phoenix
    Schema qualifier管理方便、偶尔的SQL查数方便
    用不到二级索引实际不必要,会有一定的性能损耗

  • 列族划分
    粗粒度划分对于schema管理及上层取数十分方便
    列划分过大容易频繁触发flush,且对于部分不需要全列数据影响查询性能

  • 预分区
    极大缓解在业务读写中Split和数据倾斜带来的开销
    有些业务场景的rowkey需要hash做适配预分区,要求不高的比如md5等

  • 压缩与编码
    压缩可能采用Snappy,冷备集群可以考虑Gzip
    编码慎用所谓推荐的prefixTree,1.x版本有bug。ref: HBASE-12959

  • 多版本存储
    利用timestamp可以做版本冗余、一致性问题缓解等事情
    注意磁盘压力,尤其是还有定期做snapshot的,archive有可能回收会比较慢

1.2 写入

  • 注意List批次大小
    适当聚合请求会加速同样数量的请求速度,减少请求IO次数
    批次太大会造成slow multi request,这类慢请求过多会影响吞吐率,后来的请求只能在客户端轮询wait

  • 写请求较多的场景注意控制compaction
    如有必要可以手动关闭major compact,在闲时手动触发
    删改请求较多的,可以适当缩小major compact的间隔,以免读性能影响

1.3 读取

  • 注意List批次大小
    适当聚合请求会加速同样数量的请求速度,减少请求IO次数
    批次太大会造成slow multi request,这类慢请求过多会影响吞吐率,后来的请求只能在客户端轮询wait
    Get所请求的字节数过大(超过数组上限)的话会无法返回,1.2.0之前的版本甚至会导致RegionServer OOM 宕机。

  • 注意Version、ttl的特殊性,区分数据的逻辑删除与物理删除
    用户视角的HBase自身一致性问题80%都是搞不清楚逻辑删除。
    逻辑删除:HBase会读到这个数据,但是在RS层根据策略不返回给用户
    物理删除:真的从HDFS删除此数据,发生于compact阶段

  • Scan的Filter
    善用Filter做下推减少返回的数据数量
    Filter也不要嵌套太复杂,使得RegionServer处理负载较重
    注意设置到Filter的qualifier首先要能取出来,因此scan如果显示设置了addColumn/addFamily,需要记得包括filter的qualifier
    注意指定qualifier是否为null,有可能导致想拿的数据没拿到;结合 filter.setFilterIfMissing 使用。

  • Scan优化
    适当设置caching,一般为100
    blockCache设为false
    只取自己关注的列
    考虑设置 hbase.mapreduce.input.autobalance = true 以解决预期Region取数不太均衡或数据倾斜的scan问题
  • BlockCache缓存配置
    强烈建议用BucketCache的offheap模式,配置计算方式参考:http://hbasefly.com/2016/04/08/hbase-blockcache-1/

1.4 GC优化

  • JDK 1.7+ && CMS优化 (netease) :
    -Xmx20g -Xms20g -Xmn512m -Xss256k
    -XX:MaxPermSize=256m -XX:SurvivorRatio=2
    -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
    -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15
    -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
    -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

  • JDK 1.8+ && G1GC (XIaomi):
    -Xmx20g -Xms20g -XX:MaxDirectMemorySize=20g
    -XX:+UseG1GC
    -XX:+UnlockExperimentalVMOptions?
    -XX:MaxGCPauseMillis=90
    -XX:G1NewSizePercent=2?
    -XX:InitiatingHeapOccupancyPercent=65?
    -XX:+ParallelRefProcEnabled
    -XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -XX:MaxTenuringThreshold=1?
    -XX:G1HeapRegionSize=32m -XX:G1MixedGCCountTarget=64 -XX:G1OldCSetRegionThresholdPercent=5
    -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime?
    -XX:+PrintHeapAtGC -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy?
    -XX:+PrintTenuringDistribution -XX:+PrintSafepointS

GC情况最后依然还需根据实际自己的情况进行调整。

1.5 监控
方案:ELK、Grafana + 时序数据库(Opentsdb)/监控系统(OpenFalcon)等
指标:JVM (GC、Heap、OffHeap等)、Compact、Split、缓存命中数、各类请求count、slow request count、集群基础监控。(注:以上监控除了JVM和集群基础,有条件的表级别和RegionServer级别都做一份)

另:记得对RegionServer做自动拉起的守护进程。

1.6 Linux

  • 关闭大页 Tuning transparent huge pages (THP) off
  • 禁止swap Set vm.swappiness = 0
  • 关闭NUMA vm.zone_reclaim_mode = 0

以上操作系统配置基本适用于持续服务的高读性能数据存储集群,包括但不仅限于HBase、ES等。

1.7 备份与容灾
数据层面目前官方版本只支持异步式的冷备。

  • Snapshot/Export 机制
    每次都是全量备份
    自行维护WAL回放(或业务重放)
  • HBase 2.0 增量备份
    利用WAL做增量备份
    不支持对备份做compact,增量太多时恢复速度需要关注
  • 主从一致性(备份本身也可能因为网络等原因失败)

1.8 部署

  • Master HA
  • Region预留足够offheap内存给BucketCache读缓存,2.x会更多的利用offheap以缓解GC

HBase 经验小结 (Based on 1.x)

原文:https://www.cnblogs.com/lhfcws/p/11055829.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!