一次spark写入hbase延时问题的排查

总结一下工作中遇到一次spark写入hbase的超时问题。

业务场景是将kafka等数据源采集上来的用户日志数据经spark汇聚到hbase，然后再读出来供排序、算法评分等业务使用。先前使用时并未出现超时问题，但最近突然就出现了写入超时，下图中是spark任务调度ui页面，可以看出多个写入任务的时延明显增长。

最一开始是怀疑hbase集群出现问题，于是查找各个regionserver上的日志，但并没有发现任何异常。接着查看客户端日志，也没有异常出现。

接着怀疑随着数据写入的增多，region中残留大量的storeFile文件，造成了写延时的增高，于是对表进行了major_compact操作，但效果并不明显，任务重启后依然延时。

那会不会是数据量增多，而并发数没有相应的提高，造成写延时提高呢。基于如上的考虑，我们对表进行了split，将表的region个数扩充到2倍，表的region增多了，实际上提高了表对请求的吞吐量。而后，又提高了spark任务的并发量。我们期待着经过上述的改造，写延时能够得到缓解，但可惜。。。涛声依旧。

继续找吧，接下来我们先后怀疑了机器间网络连接的时延，集群gc等等方面的原因，但最终证明了并非上述原因所导致。

正当我们对问题一筹莫展的时候，我们想到了会不会是业务方的写入姿势不对造成了写延时的提高。

业务方的写入程序调用的是spark包装好的API，我们在测试集群中新建了一张表，将spark的写入任务重定向到这张新表中，下面是测试表的写入结果。