Hadoop之Hbase从学习入门到精通2.doc
《Hadoop之Hbase从学习入门到精通2.doc》由会员分享,可在线阅读,更多相关《Hadoop之Hbase从学习入门到精通2.doc(77页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、|一、 HBase 性能调优我们经常看到一些文章吹嘘某产品如何如何快,如何如何强,而自己测试时却不如描述的一些数据。其实原因可能在于你还不是真正理解其内部结构,对于其性能调优方法不够了解。本文转自 TaoBao 的 Ken Wu 同学的博客,是目前看到比较完整的 HBase 调优文章。原文链接: HBase 性能调优因 官方 Book Performance Tuning 部分章节没有按配置项进行索引,不能达到快速查阅的效果。所以我以配置项驱动,重新整理了原文,并补充一些自己的理解,如有错误,欢迎指正。配置优化zookeeper.session.timeout默认值:3 分钟(180000ms
2、)说明:RegionServer 与 Zookeeper 间的连接超时时间。当超时时间到后,ReigonServer 会被 Zookeeper 从 RS 集群清单中移除,HMaster 收到移除通知后,会对这台 server 负责的 regions 重新 balance,让其他存活的 RegionServer接管.调优:这个 timeout 决定了 RegionServer 是否能够及时的 failover。设置成1 分钟或更低,可以减少因等待超时而被延长的 failover 时间。不过需要注意的是,对于一些 Online 应用,RegionServer 从宕机到恢复时间本身就很短的(网络闪断
3、,crash 等故障,运维可快速介入),如果调低timeout 时间,反而会得不偿失。因为当 ReigonServer 被正式从 RS 集群中移除时,HMaster 就开始做 balance 了(让其他 RS 根据故障机器记录的 WAL 日志进行恢复)。当故障的 RS 在人工介入恢复后,这个 balance 动作是毫无意义的,反而会使负载不均匀,给 RS 带来更多负担。特别是那些固定分配 regions 的场景。hbase.regionserver.handler.count默认值:10说明:RegionServer 的请求处理 IO 线程数。调优:这个参数的调优与内存息息相关。|较少的 IO
4、 线程,适用于处理单次请求内存消耗较高的 Big PUT 场景(大容量单次 PUT 或设置了较大 cache 的 scan,均属于 Big PUT)或 ReigonServer 的内存比较紧张的场景。较多的 IO 线程,适用于单次请求内存消耗低,TPS 要求非常高的场景。设置该值的时候,以监控内存为主要参考。这里需要注意的是如果 server 的 region 数量很少,大量的请求都落在一个region 上,因快速充满 memstore 触发 flush 导致的读写锁会影响全局 TPS,不是 IO 线程数越高越好。压测时,开启 Enabling RPC-level logging,可以同时监控
5、每次请求的内存消耗和 GC 的状况,最后通过多次压测结果来合理调节 IO 线程数。这里是一个案例 Hadoop and HBase Optimization for Read Intensive Search Applications,作者在 SSD 的机器上设置 IO 线程数为 100,仅供参考。hbase.hregion.max.filesize默认值:256M说明:在当前 ReigonServer 上单个 Reigon 的最大存储空间,单个 Region 超过该值时,这个 Region 会被自动 split 成更小的 region。调优:小 region 对 split 和 compac
6、tion 友好,因为拆分 region 或 compact小 region 里的 storefile 速度很快,内存占用低。缺点是 split 和compaction 会很频繁。特别是数量较多的小 region 不停地 split, compaction,会导致集群响应时间波动很大,region 数量太多不仅给管理上带来麻烦,甚至会引发一些 Hbase 的bug。一般 512 以下的都算小 region。大 region,则不太适合经常 split 和 compaction,因为做一次 compact 和split 会产生较长时间的停顿,对应用的读写性能冲击非常大。此外,大region 意味着
7、较大的 storefile,compaction 时对内存也是一个挑战。当然,大 region 也有其用武之地。如果你的应用场景中,某个时间点的访问量较低,那么在此时做 compact 和 split,既能顺利完成 split 和 compaction,又能保证绝大多数时间平稳的读写性能。既然 split 和 compaction 如此影响性能,有没有办法去掉?compaction 是无法避免的,split 倒是可以从自动调整为手动。只要通过将这个参数值调大到某个很难达到的值,比如 100G,就可以间接禁用自动 split(RegionServer 不会对未到达 100G 的 region 做
8、 split)。再配合 RegionSplitter 这个工具,在需要 split 时,手动 split。|手动 split 在灵活性和稳定性上比起自动 split 要高很多,相反,管理成本增加不多,比较推荐 online 实时系统使用。内存方面,小 region 在设置 memstore 的大小值上比较灵活,大 region 则过大过小都不行,过大会导致 flush 时 app 的 IO wait 增高,过小则因 store file过多影响读性能。hbase.regionserver.global.memstore.upperLimit/lowerLimit默认值:0.4/0.35uppe
9、rlimit 说明:hbase.hregion.memstore.flush.size 这个参数的作用是 当单个 memstore 达到指定值时,flush 该 memstore。但是,一台ReigonServer 可能有成百上千个 memstore,每个 memstore 也许未达到flush.size,jvm 的 heap 就不够用了。该参数就是为了限制 memstores 占用的总内存。当 ReigonServer 内所有的 memstore 所占用的内存总和达到 heap 的 40%时,HBase 会强制 block 所有的更新并 flush 这些 memstore 以释放所有 mem
10、store占用的内存。lowerLimit 说明: 同 upperLimit,只不过当全局 memstore 的内存达到 35%时,它不会 flush 所有的 memstore,它会找一些内存占用较大的 memstore,做个别flush,当然更新还是会被 block。lowerLimit 算是一个在全局 flush 导致性能暴跌前的补救措施。为什么说是性能暴跌?可以想象一下,如果 memstore 需要在一段较长的时间内做全量 flush,且这段时间内无法接受任何读写请求,对HBase 集群的性能影响是很大的。调优:这是一个 Heap 内存保护参数,默认值已经能适用大多数场景。它的调整一般是
11、为了配合某些专属优化,比如读密集型应用,将读缓存开大,降低该值,腾出更多内存给其他模块使用。这个参数会给使用者带来什么影响?比如,10G 内存,100 个 region,每个 memstore 64M,假设每个 region 只有一个 memstore,那么当 100 个 memstore 平均占用到 50%左右时,就会达到lowerLimit 的限制。假设此时,其他 memstore 同样有很多的写请求进来。在那些大的 region 未 flush 完,就可能又超过了 upperlimit,则所有 region 都会被 block,开始触发全局 flush。不过,除了你的内存非常小或你的应用
12、场景里大多数都是读,我觉得不需要去调这个参数。hfile.block.cache.size默认值:0.2|说明:storefile 的读缓存占用 Heap 的大小百分比,0.2 表示 20%。该值直接影响数据读的性能。调优:当然是越大越好,如果读比写少,开到 0.4-0.5 也没问题。如果读写较均衡,0.3 左右。如果写比读多,果断默认吧。设置这个值的时候,你同时要参考 hbase.regionserver.global.memstore.upperLimit ,该值是 memstore占 heap 的最大百分比,两个参数一个影响读,一个影响写。如果两值加起来超过 80-90%,会有 OOM
13、的风险,谨慎设置。hbase.hstore.blockingStoreFiles默认值:7说明:在 compaction 时,如果一个 Store(Coulmn Family)内有超过 7 个storefile 需要合并,则 block 所有的写请求,进行 flush,限制 storefile 数量增长过快。调优:block 写请求会影响当前 region 的性能,将值设为单个 region 可以支撑的最大 store file 数量会是个不错的选择,即允许 comapction 时,memstore 继续生成 storefile。最大 storefile 数量可通过 region size/
14、memstore size 来计算。如果你将 region size 设为无限大,那么你需要预估一个 region 可能产生的最大 storefile 数。hbase.hregion.memstore.block.multiplier默认值:2说明:当一个 region 里的 memstore 超过单个 memstore.size 两倍的大小时,block 该 region 的所有请求,进行 flush,释放内存。虽然我们设置了memstore 的总大小,比如 64M,但想象一下,在最后 63.9M 的时候,我 Put 了一个 100M 的数据,此时 memstore 的大小会瞬间暴涨到超过预
15、期的memstore.size。这个参数的作用是当 memstore 的大小增至超过memstore.size 时,block 所有请求,遏制风险进一步扩大。调优: 这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景(不包括异常)不会出现突发写或写的量可控,那么保持默认值即可。如果正常情况下,你的写请求量就会经常暴长到正常的几倍,那么你应该调大这个倍数并调整其他参数值,比如 hfile.block.cache.size 和hbase.regionserver.global.memstore.upperLimit/lowerLimit,以预留更多内存,防止 HBase server OO
16、M。其他启用 LZO 压缩|LZO 对比 Hbase 默认的 GZip,前者性能较高,后者压缩比较高,具体参见Using LZO Compression。对于想提高 HBase 读写性能的开发者,采用 LZO 是比较好的选择。对于非常在乎存储空间的开发者,则建议保持默认。不要在一张表里定义太多的 Column FamilyHbase 目前不能良好的处理超过包含 2-3 个 CF 的表。因为某个 CF 在 flush 发生时,它邻近的 CF 也会因关联效应被触发 flush,最终导致系统产生更多 IO。批量导入在批量导入数据到 Hbase 前,你可以通过预先创建 regions,来平衡数据的负载
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Hadoop Hbase 学习 入门 精通
限制150内