发现spark实时任务延迟。
看了spark监控页面，处理延迟了30s+
进入该批次任务查看延迟详情，初步确定是访问hbase导致延迟。
先登上cloudera界面查看hbase监控:告警折线图显示在延迟的时间点发生过事件，但是没有详细信息，能够看刷新队列稍大，但是不明显，需要登上regionServer上查看详细日志。
日志表明和zookeeper有过断连，因为这个断连导致WAL日志同步延迟，以及下面的RpcServer请求（应该就是我们实时任务的调用）延迟较大。但是找不
到导致和zookeeper断连的原因，此时顺手百度了下，网友遇到过因GC time过长导致regionServer回应zookeeper超时，zookeeper将regionServer断连的场景。但是看了下
cloudera监控界面，Gc时间和没有发生突增的现象，压缩队列也正常，因此排除了这种可能性。
只能到zookeeper Server端日志中看下有没有有用的信息，根据regionServer中建立连接的zookeeper ip到对应的zookeeper上查看日志，根据regionServer ip 端口，时间找到
对应日志片段，但是没有找到发现问题的日志，但是发现本次重连后的sessionid没有变。后来想想不对，重连后的zookeeper一定是经过重新筛选后的节点，上次断连肯定发生在另外几台zookeeper节点上，由于hbase日志已经冲掉了上次连接的zookeeper节点ip，并且zookeeper info级别日志没有打印心跳。还好发现本次重新连接的sessionId没变，拿着sessionId 到另外几台上，运气不错，试第二台的时候就找到了：
| WARN org.apache.zookeeper.server.persistence.FileTxnLog: fsync-ing the write ahead log in SyncThread:2 took 31038ms which will adversely effect operation latency. See the ZooKeeper troubleshooting guide |
|---|
结合日志上下文，刚好在延迟这段时间没有日志打印，write ahead log耗时31038刚好31s，这段时间zookeeper没有处理任何服务，因此导致了hbase发现服务器没有回应并
关闭了连接，重新尝试连接。
write ahead log阻塞一般是因为和其他服务或模块争抢磁盘资源，导致相互影响，写入性能下降。
如此就能说得通了，需要首先吧数据目录和事务日志磁盘路径拆开，并尽量减少dataLogDir和其他服务之间争抢磁盘。