网易视频云技术分享HBase优化实战

名称
数量Βιβλιοθήκη 备注服务器数量17
配置不同，HBase、HDFS 都部署在这些机器上
表数量
30+
只有部分表的数据量比较大，其他基本没多少数据
Region 数量
600+
基本上都是数据量较大的表划分的 region 较多
请求量
50000+
服务器请求分布极其不均匀
应用反应经常会过段时间出现数据写入缓慢，导致应用端数据堆积现象，是否可以通过增加机器数 量来解决？
其实，那个时候，我们本身对 HBase 也不是很熟悉，对 HBase 的了解，也仅仅在做过一些测试， 了解一些性能，对内部结构，实现原理之类的基本上都不怎么清楚。于是刚开始几天，各种问题，每天 晚上拉着一男一起摸索，顺利的时候，晚上 8，9 点就可以暂时搞定线上问题，更多的时候基本要到 22 点甚至更晚(可能那个时候流量也下去了)，通过不断的摸索，慢慢了解 HBase 在使用上的一些限制，也 就能逐渐解决这一系列过程中发现的问题。后面挑几个相对比较重要，效果较为明显的改进点，做下简 单介绍。
调优 首先根据目前 17 台机器，50000+的 QPS，并且观察磁盘的 I/O 利用率和 CPU 利用率都相当低来 判断：当前的请求数量根本没有达到系统的性能瓶颈，不需要新增机器来提高性能。如果不是硬件资源 问题，那么性能的瓶颈究竟是什么？ Rowkey 设计问题 现象 打开 HBase 的 Web 端，发现 HBase 下面各个 RegionServer 的请求数量非常不均匀，第一个想到 的就是 HBase 的热点问题，具体到某个具体表上的请求分布如下： HBase 表请求分布
背景 Datastream 一直以来在使用 HBase 分流日志，每天的数据量很大，日均大概在 80 亿条，10TB 的数据。对于像 Datastream 这种数据量巨大、对写入要求非常高，并且没有复杂查询需求的日志系统 来说，选用 HBase 作为其数据存储平台，无疑是一个非常不错的选择。 HBase 是一个相对较复杂的分布式系统，并发写入的性能非常高。然而，分布式系统从结构上来讲， 也相对较复杂，模块繁多，各个模块之间也很容易出现一些问题，所以对像 HBase 这样的大型分布式系 统来说，优化系统运行，及时解决系统运行过程中出现的问题也变得至关重要。正所谓：“你”若安好， 便是晴天；“你”若有恙，我便没有星期天。 历史现状 HBase 交接到我们团队手上时，已经在线上运行有一大段时间了，期间也偶尔听到过系统不稳定的、 时常会出现一些问题的言论，但我们认为：一个能被大型互联网公司广泛采用的系统(包括 Facebook， twitter，淘宝，小米等)，其在性能和可用性上是毋庸置疑的，何况像 Facebook 这种公司，是在经过严 格选型后，放弃了自己开发的 Cassandra 系统，用 HBase 取而代之。既然这样，那么，HBase 的不稳 定、经常出问题一定有些其他的原因，我们所要做的，就是找出这些 HBase 的不稳定因素，还 HBase 一个“清白”。“查案”之前，先来简单回顾一下我们接手 HBase 时的现状(我们运维着好几个 HBase 集群，这里主要介绍问题最多那个集群的调优)：
解决的方法可以让 SA 释放些空间出来便于数据写入。当然，最直接有效的就是把 HDFS 的预留空 间调整至 100G 以上，我们也正是这样做的，通过调整后，异常不再出现，HBase 层面的 slow log 也 没有再出现。同时我们也开启了 HDFS 层面的 balance，使数据自动在各个服务器之间保持平衡。
网易视频云技术分享：HBase 优化实战
网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，提供稳定流 畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的 PAAS 服务，在线教育、远程医 疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。现在，网 易视频云的技术专家给大家分享一则技术文：HBase 优化实战。
WARN - (responseTooSlow): {“processingtimemsrpc version=1, client version=29, methodsFingerPrintstarttimems”:1440239670790, “queuetimems”:42081, “class”:” HRegionServer”, “responsesize”:0, “method”:”multi”}
资源分配不均匀，造成部分机器压力较大，部分机器负载较低，并且部分 Region 过大过热，导致 请求相对较集中。
解决 迁移部分老的 RegionServer 上的 region 到新加入的机器上，使每个 RegionServer 的负载均匀。 通过 split 切分部分较大 region，均匀分布热点 region 到各个 RegionServer 上。 HBase region 请求分布 对比前后两张截图我们可以看到，Region 总数量从 1336 增加到了 1426，而增加的这 90 个 region 就是通过 split 切分大的 region 得到的。而对 region 重新分布后，整个 HBase 的性能有了大幅度提高。 建议 Region 迁移的时候不能简单开启自动 balance，因为 balance 主要的问题是不会根据表来进行 balance，HBase 的自动 balance 只会根据每个 RegionServer 上的 Region 数量来进行 balance，所 以自动 balance 可能会造成同张表的 region 会被集中迁移到同一个台 RegionServer 上，这样就达不 到分布式的效果。 基本上，新增 RegionServer 后的 region 调整，可以手工进行，尽量使表的 Region 都平均分配到 各个 RegionServer 上，另外一点，新增的 RegionServer 机器，配置最好与前面的一致，否则资源无 法更好利用。 对于过大，过热的 region，可以通过切分的方法生成多个小 region 后均匀分布(注意：region 切 分会触发 major compact 操作，会带来较大的 I/O 请求，请务必在业务低峰期进行) HDFS 写入超时 现象 HBase 写入缓慢，查看 HBase 日志，经常有慢日志如下：
并且伴有 HDFS 创建 block 异常如下： INFO – Exception in createBlockOutputStream (HdfsProtoUtil.java:171) $DataStreamer.createBlockOutputStream(DFSOutputStream.java:1105) $DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1039) $DataStreamer.run(DFSOutputStream.java:487) 一般地，HBase 客户端的写入到 RegionServer 下某个 region 的 memstore 后就返回，除了网络 外，其他都是内存操作，应该不会有长达 30 多秒的延迟，外加 HDFS 层抛出的异常，我们怀疑很可能 跟底层数据存储有关。 原因 定位到可能是 HDFS 层出现了问题，那就先从底层开始排查，发现该台机器上 10 块盘的空间利用 率都已经达到 100%。按理说，作为一个成熟的分布式文件系统，对于部分数据盘满的情况，应该有其 应对措施。的确，HDFS 本身可以设置数据盘预留空间，如果部分数据盘的预留空间小于该值时，HDFS 会自动把数据写入到另外的空盘上面，那么我们这个又是什么情况？ 最终通过多方面的沟通确认，发现了主要原因：我们这批机器，在上线前 SA 已经经过处理，每块 盘默认预留 100G 空间，所以当通过 df 命令查看盘使用率为 100%时，其实盘还有 100G 的预留空间， 而 HDFS 层面我们配置的预留空间是 50G，那么问题就来了：HDFS 认为盘还有 100G 空间，并且多于 50G 的预留，所以数据可以写入本地盘，但是系统层面却禁止了该写入操作，从而导致数据写入异常。 解决
网络问题，联系机房解决，机房的反馈也验证了我们的想法：由于 HBase 的机器后面进行了扩展， 后面加入的机器有一台跟其他机器不在同一个交换机下，而这台机器正是我们找出的有较大 ping 延时 这台，整个 HBase 物理结构如下：
HBase 物理拓扑结构 跟机房协调，调整机器位置，使所有的 HBase 机器都位于同一个交换机下，问题迎刃而解。 建议 对于分布式大流量的系统，除了系统本身，物理机的部署和流量规划也相当重要，尽量使集群中所 有的机器位于相同的交换机下(有容灾需求的应用除外)，集群较大，需要跨交换机部署时，也要充分考 虑交换机的出口流量是否够用，网络硬件上的瓶颈诊断起来相对更为困难。 JVM 参数调整 解决了网络上面的不稳定因素，HBase 的性能又得到进一步的提高，随之也带来了另外的问题。 现象 根据应用反应，HBase 会阶段性出现性能下降，导致应用数据写入缓慢，造成应用端的数据堆积， 这又是怎么回事？经过一系列改善后 HBase 的系统较之以前有了大幅度增长，怎么还会出现数据堆积的 问题？为什么会阶段性出现？ HBase 流量统计 从上图看，HBase 平均流量 QPS 基本能达到 12w，但是每过一段时间，流量就会下降到接近零点， 同时这段时间，应用会反应数据堆积。 原因 这个问题定位相对还是比较简单，结合 HBase 的日志，很容易找到问题所在： – We slept 41662ms instead of 3000ms, this is likely due to a long garbage collecting pause and it’s usually bad
建议 磁盘满了导致的问题很难预料，HDFS 可能会导致部分数据写入异常，MySQL 可能会出现直接宕机 等等，所以最好的办法就是：不要使盘的利用率达到 100%。 网络拓扑 现象 通过 rowkey 调整，HDFS 数据 balance 等操作后，HBase 的确稳定了许多，在很长一段时间都没 有出现写入缓慢问题，整体的性能也上涨了很多。但时常会隔一段时间出现些 slow log，虽然对整体的 性能影响不大，但性能上的抖动还是很明显。 原因 由于该问题不经常出现，对系统的诊断带来不小的麻烦，排查了 HBase 层和 HDFS 层，几乎一无 所获，因为在大多数情况下，系统的吞吐量都是正常的。通过脚本收集 RegionServer 所在服务器的系 统资源信息，也看不出问题所在，最后怀疑到系统的物理拓扑上，HBase 集群的最大特点是数据量巨大， 在做一些操作时，很容易把物理机的千兆网卡都吃满，这样如果网络拓扑结构存在问题，HBase 的所有 机器没有部署在同一个交换机上，上层交换机的进出口流量也有可能存在瓶颈。网络测试还是挺简单的， 直接 ping 就可以，我们得到以下结果：共 17 台机器，只有其中一台的延迟存在问题，如下： 网络延迟测试：Ping 结果 同一个局域网内的机器，延迟达到了毫秒级别，这个延迟是比较致命的，因为分布式存储系统 HDFS 本身对网络有要求，HDFS 默认 3 副本存在不同的机器上，如果其中某台机器的网络存在问题，这样就 会影响到该机器上保存副本的写入，拖慢整个 HDFS 的写入速度。 解决