一、概况
集群环境如下表：
| 集群 | 机器 | 存储 | 内存 | CPU | 每日数据 | ||||
| HW大数据平台 | 160台 | 6PB | 10TB | 8000 | 10亿 |
数据存储在kafka中，130个分区，采用sparkstreaming将数据清洗后，通过phoneix批量写入hbase。
二、kafka原因排查
sparkstreaming拉取kafka的时候，卡死在这一步，如下图所示：
sparkstreaming读取kafka的数据采用Direct 模式读取kafka数据，检查点在客户端维护offset，任务运行不是很稳定，偶尔会出现延迟几分钟。
- 推测执行
- kafka客户端版本
- offset跳跃
三、hbase原因排查
hbase写入慢的时候，查看线程堆栈，发现卡在这一步，如图所示：
- 写热点
- hbase的处理线程数
- hbase的memstore大小
- hbase的flush、合并、split
- 代码频繁创建连接
四、规律搜集
上述问题排查了已经一个月了，各种办法都试过了，期间kafka端的阻塞已经解决了，写入hbase慢。各种百度，以及hbase的原理也看了一遍又一遍，大数据平台上的监控也一直盯着看，也没有解决写入慢的问题。
到这一步基本可以确定是hbase写入延迟导致sparkstreaming任务延迟越来越高。
10s钟一个批次的任务，5*26个处理core，基本从下午4点半到第二天早上9点半都很快，在3s中左右处理完成，期间虽然写入有波动，但是基本都可以很快平稳，但是9点半以后基本每个批次都要10s以上，sparkstreaming延迟越来越高，每个批次写入的数量和之前并无变化，也没有数据倾斜。
因为sparkstreaming的日志都比较散，很艰难的发现了。
#1, waiting for 2 actions to finish on table: WIFI_MAC_FAST_QUERY
Left over 2 task(s) are processed on server(s): [xlhd-b1805-hbase41,21302,1568195573413]
客户端写等待，这不是很正常嘛，可能是服务端内部活动，导致的吧？唉，于是想收集一下，看看是不是写等待多的时候，导致sparkstreaming，这怎么统计？？？？。
幸好，现场之前基于elk做过日志搜集，采用扩展logback的插件，将数据直接从服务接引到es，并且成功集成了sparkstreaming，tomcat，springboot等框架，于是将o.a.h.h.c.AsyncProcess类打的日志采集到es，去寻找规律。
上图真是来的太及时了，搜集了sparkstreaming散开的日志，聚合在一起，发现写等待还是比较大的，但是最重要的发现是写等待的regionserver居然都是hbase41这个节点，难道有热点写，去大数据平台查看，没有发生热点写，每个regionserver的请求很平稳，于是登陆这台机器进行一通linux命令，top，iostat，sar，ifconfig，ping等，发现丢包，哈哈。
-
于是将该节点的regionserver停掉，发现基本每个批次3s左右都可以处理完，通知运维去机房解决网络问题。
转载：https://blog.csdn.net/weixin_36647532/article/details/101026923