HBase写数据的异常问题以及优化
发布网友
发布时间：2022-12-07 23:56
共1个回答
热心网友
时间：2023-11-17 00:20
HBase数据写入通常会遇到两类问题，一类是写性能较差，另一类是数据根本写不进去。这两类问题的切入点也不尽相同，如下图所示：
写性能优化切入点
1. 是否需要写WAL?WAL是否需要同步写入?
优化原理：数据写入流程可以理解为一次顺序写WAL+一次写缓存，通常情况下写缓存延迟很低，因此提升写性能就只能从WAL入手。WAL机制一方面是为了确保数据即使写入缓存丢失也可以恢复，另一方面是为了集群之间异步复制。默认WAL机制开启且使用同步机制写入WAL。首先考虑业务是否需要写WAL，通常情况下大多数业务都会开启WAL机制(默认)，但是对于部分业务可能并不特别关心异常情况下部分数据的丢失，而更关心数据写入吞吐量，比如某些推荐业务，这类业务即使丢失一部分用户行为数据可能对推荐结果并不构成很大影响，但是对于写入吞吐量要求很高，不能造成数据队列阻塞。这种场景下可以考虑关闭WAL写入，写入吞吐量可以提升2x~3x。退而求其次，有些业务不能接受不写WAL，但可以接受WAL异步写入，也是可以考虑优化的，通常也会带来1x～2x的性能提升。
优化推荐：根据业务关注点在WAL机制与写入吞吐量之间做出选择
其他注意点：对于使用Increment操作的业务，WAL可以设置关闭，也可以设置异步写入，方法同Put类似。相信大多数Increment操作业务对WAL可能都不是那么敏感～
2. Put是否可以同步批量提交?
优化原理：HBase分别提供了单条put以及批量put的API接口，使用批量put接口可以减少客户端到RegionServer之间的RPC连接数，提高写入性能。另外需要注意的是，批量put请求要么全部成功返回，要么抛出异常。
优化建议：使用批量put进行写入请求
3. Put是否可以异步批量提交?
优化原理：业务如果可以接受异常情况下少量数据丢失的话，还可以使用异步批量提交的方式提交请求。提交分为两阶段执行：用户提交写请求之后，数据会写入客户端缓存，并返回用户写入成功;当客户端缓存达到阈值(默认2M)之后批量提交给RegionServer。需要注意的是，在某些情况下客户端异常的情况下缓存数据有可能丢失。
优化建议：在业务可以接受的情况下开启异步批量提交
使用方式：setAutoFlush(false)
4. Region是否太少?
优化原理：当前集群中表的Region个数如果小于RegionServer个数，即Num(Region of Table) < Num(RegionServer)，可以考虑切分Region并尽可能分布到不同RegionServer来提高系统请求并发度，如果Num(Region of Table) > Num(RegionServer)，再增加Region个数效果并不明显。
优化建议：在Num(Region of Table) < Num(RegionServer)的场景下切分部分请求负载高的Region并迁移到其他RegionServer;
5. 写入请求是否不均衡?
优化原理：另一个需要考虑的问题是写入请求是否均衡，如果不均衡，一方面会导致系统并发度较低，另一方面也有可能造成部分节点负载很高，进而影响其他业务。分布式系统中特别害怕一个节点负载很高的情况，一个节点负载很高可能会拖慢整个集群，这是因为很多业务会使用Mutli批量提交读写请求，一旦其中一部分请求落到该节点无法得到及时响应，就会导致整个批量请求超时。因此不怕节点宕掉，就怕节点奄奄一息!
优化建议：检查RowKey设计以及预分区策略，保证写入请求均衡。
6. 写入KeyValue数据是否太大?
KeyValue大小对写入性能的影响巨大，一旦遇到写入性能比较差的情况，需要考虑是否由于写入KeyValue数据太大导致。KeyValue大小对写入性能影响曲线图如下：
图中横坐标是写入的一行数据(每行数据10列)大小，左纵坐标是写入吞吐量，右坐标是写入平均延迟(ms)。可以看出随着单行数据大小不断变大，写入吞吐量急剧下降，写入延迟在100K之后急剧增大。
说到这里，有必要和大家分享两起在生产线环境因为业务KeyValue较大导致的严重问题，一起是因为大字段业务写入导致其他业务吞吐量急剧下降，另一起是因为大字段业务scan导致RegionServer宕机。
案件一：大字段写入导致其他业务吞吐量急剧下降
部分业务反馈集群写入忽然变慢、数据开始堆积的情况，查看集群表级别的数据读写QPS监控，发现问题的第一个关键点：业务A开始写入之后整个集群其他部分业务写入QPS都几乎断崖式下跌，初步怀疑黑手就是业务A。
下图是当时业务A的写入QPS(事后发现脑残忘了截取其他表QPS断崖式下跌的惨象)，但是第一感觉是QPS并不高啊，凭什么去影响别人!
于是就继续查看其他监控信息，首先确认系统资源(主要是IO)并没有到达瓶颈，其次确认了写入的均衡性，直至看到下图，才追踪到影响其他业务写入的第二个关键点：RegionServer的handler(配置150)被残暴耗尽：
对比上面两张图，是不是发现出奇的一致，那就可以基本确认是由于该业务写入导致这台RegionServer的handler被耗尽，进而其他业务拿不到handler，自然写不进去。那问题来了，为什么会这样?正常情况下handler在处理完客户端请求之后会立马释放，唯一的解释是这些请求的延迟实在太大。
试想，我们去汉堡店排队买汉堡，有150个窗口服务，正常情况下大家买一个很快，这样150个窗口可能只需要50个服务。假设忽然来了一批大汉，要定制超大汉堡，好了，所有的窗口都工作起来，而且因为大汉堡不好制作导致服务很慢，这样必然会导致其他排队的用户长时间等待，直至超时。
可回头一想这可是写请求啊，怎么会有这么大的请求延迟!和业务方沟通之后确认该表主要存储语料库文档信息，都是平均100K左右的数据，是不是已经猜到了结果，没错，就是因为这个业务KeyValue太大导致。KeyValue太大会导致HLog文件写入频繁切换、flush以及compaction频繁触发，写入性能急剧下降。
目前针对这种较大KeyValue写入性能较差的问题还没有直接的解决方案，好在社区已经意识到这个问题，在接下来即将发布的下一个大版本HBase 2.0.0版本会针对该问题进行深入优化，详见 HBase MOB ，优化后用户使用HBase存储文档、图片等二进制数据都会有极佳的性能体验。
案件二：大字段scan导致RegionServer宕机
案件现场：有段时间有个0.98集群的RegionServer经常频繁宕机，查看日志是由于”java.lang.OutOfMemoryError: Requested array size exceeds VM limit”，如下图所示：
原因分析：通过查看源码以及相关文档，确认该异常发生在scan结果数据回传给客户端时由于数据量太大导致申请的array大小超过JVM规定的最大值( Interge.Max_Value-2)。造成该异常的两种最常见原因分别是：
表列太宽(几十万列或者上百万列)，并且scan返回没有对列数量做任何*，导致一行数据就可能因为包含大量列而数据超过array大小阈值
KeyValue太大，并且scan返回没有对返回结果大小做任何*，导致返回数据结果大小超过array大小阈值
有的童鞋就要提问啦，说如果已经对返回结果大小做了*，在表列太宽的情况下是不是就可以不对列数量做*呢。这里需要澄清一下，如果不对列数据做*，数据总是一行一行返回的，即使一行数据大小大于设置的返回结果*大小，也会返回完整的一行数据。在这种情况下，如果这一行数据已经超过array大小阈值，也会触发OOM异常。
解决方案：目前针对该异常有两种解决方案，其一是升级集群到1.0，问题都解决了。其二是要求客户端访问的时候对返回结果大小做*(scan.setMaxResultSize(2*1024*1024))、并且对列数量做*(scan.setBatch(100))，当然，0.98.13版本以后也可以对返回结果大小在服务器端进行*，设置参数hbase.server.scanner.max.result.size即可
写异常问题检查点
上述几点主要针对写性能优化进行了介绍，除此之外，在一些情况下还会出现写异常，一旦发生需要考虑下面两种情况(GC引起的不做介绍)：
Memstore设置是否会触发Region级别或者RegionServer级别flush操作?
问题解析：以RegionServer级别flush进行解析，HBase设定一旦整个RegionServer上所有Memstore占用内存大小总和大于配置文件中upperlimit时，系统就会执行RegionServer级别flush，flush算法会首先按照Region大小进行排序，再按照该顺序依次进行flush，直至总Memstore大小低至lowerlimit。这种flush通常会block较长时间，在日志中会发现“ Memstore is above high water mark and block 7452 ms”，表示这次flush将会阻塞7s左右。
问题检查点：
Region规模与Memstore总大小设置是否合理?如果RegionServer上Region较多，而Memstore总大小设置的很小(JVM设置较小或者upper.limit设置较小)，就会触发RegionServer级别flush。集群规划相关内容可以参考文章《》
列族是否设置过多，通常情况下表列族建议设置在1～3个之间，最好一个。如果设置过多，会导致一个Region中包含很多Memstore，导致更容易触到高水位upperlimit
Store中HFile数量是否大于配置参数blockingStoreFile?
问题解析：对于数据写入很快的集群，还需要特别关注一个参数：hbase.hstore.blockingStoreFiles，此参数表示如果当前hstore中文件数大于该值，系统将会强制执行compaction操作进行文件合并，合并的过程会阻塞整个hstore的写入。通常情况下该场景发生在数据写入很快的情况下，在日志中可以发现” Waited 3722ms on a compaction to clean up ‘too many store files “
问题检查点：
参数设置是否合理? hbase.hstore.compactionThreshold表示启动compaction的最低阈值，该值不能太大，否则会积累太多文件，一般建议设置为5～8左右。 hbase.hstore.blockingStoreFiles默认设置为7，可以适当调大一些。
写性能还能再提高么?
上文已经从写性能优化以及写异常诊断两个方面对HBase中数据写入可能的问题进行了详细的解释，相信在0.98版本的基础上对写入来说已经是最好的解决方案了。但是有些业务可能依然觉得不够快，毕竟”更快”是所有存储系统活着的动力，那还有提高空间吗?当然，接下来简单介绍HBase之后版本对写性能优化的两点核心改进：
Utilize Flash storage for WAL(HBASE-12848)
这个特性意味着可以将WAL单独置于SSD上，这样即使在默认情况下(WALSync)，写性能也会有很大的提升。需要注意的是，该特性建立在HDFS 2.6.0+的基础上，HDFS以前版本不支持该特性。具体可以参考官方jira： https://issues.apache.org/jira/browse/HBASE-12848
Multiple WALs(HBASE-14457)
该特性也是对WAL进行改造，当前WAL设计为一个RegionServer上所有Region共享一个WAL，可以想象在写入吞吐量较高的时候必然存在资源竞争，降低整体性能。针对这个问题，社区小伙伴(阿里巴巴大神)提出Multiple WALs机制，管理员可以为每个Namespace下的所有表设置一个共享WAL，通过这种方式，写性能大约可以提升20%～40%左右。
