一、背景
日志收集并入hbase
1、框架
2、日志量
每日产生数十亿条日志,其中有15%~20%为有效日志,高峰期有效日志的写入QPS为25万/秒。
3、日志过滤
80%的日志需要过滤掉【由于特殊性,无法将需要的日志生成到一个指定文件,这里不做过多讨论】
4、机器部署
4台机器,每台20个线程,kafka80个partition
5、日志处理延迟情况
6、问题:
如上可以看到,每日的日志处理都有严重的积压,现在数据量一直在上涨,而且10倍的涨幅是近期就会发生的事情,不能单纯的通过扩充机器数量来解决问题
二、问题分析
1、罪魁祸首就是日志不能定制,需要过滤掉80%的不需要的日志量,耗时严重【这个无法解决】
2、日志处理程序日志打印过多,每条日志耗时1ms,打印量也是N千万条
3、关键字过滤没有太好的方法,关键字在日志的中间位置,而且位置不确定。并非开头位置、非固定位置
4、hbase服务器写入CPU消耗很多
5、hbase的写入耗时,每100条,耗时从200ms~1300ms都有
6、增加partition不是解决问题的正常思维
7、增加服务器不是解决问题的正常思维
三、【第一次优化】问题解决
1、为了能快速看到结果,将日志处理的业务日志全部删除了
2、关键字过滤逻辑
a)之前的过滤逻辑
b)修改之后的过滤逻辑
单条日志的长度大于2000字符,少于5000字符
通过分析,发现关键字 "LEOPARD" 稳定出现在日志的 500~1000字节处
如上两种方法大家可以尝试一下。每1万处理耗时,前者是4000ms左右,后者是18ms左右
四、效果
1、考虑hbase服务器压力,只使用2台服务器进行日志处理,另外2台服务器没有启用
2、上线9小时后,堆积的1300万条日志消耗完了,同时业务实时产生的日志也消耗完了。
3、高峰期LAG数量是7千条,而且很快就消耗掉了。
五、之后对hbase的业务表进行了拆分
拆分hbase表,主要是因对hbase服务器写入压力问题
同时也能缓解批量写入hbase时,耗时差异很大的问题,等后续有数据了再更新。
六、总结
编码时,一定要注意代码的效率。尤其是消费类型的业务,一定要提高消费的能力。