三个臭皮匠【参与人】: 振远、光鑫和me
一、背景
日志收集并入hbase
1、框架
2、日志量
每日产生数十亿条日志,其中有15%~20%为有效日志,hbase高峰期有效日志的写入QPS为25万/秒。
3、日志过滤
80%的日志需要过滤掉【由于特殊性,无法将需要的日志生成到一个指定文件,这里不做过多讨论】
4、机器部署
4台机器,kafka80个partition
5、业务目标
二、一图看懂数据性能
1. 第一版【典型问题:消费逻辑慢】
因为数据量大,hbase集群扛不住,hbase meta所在服务器CPU低,一直影响着这个项目的正常运行。其它的如日志延时、丢数据暂时还不算焦点问题。
a)存在问题
版本 | 存在问题 | 服务器配置 | 典型问题 |
1.0 | 数据延时很大
| 4台服务器 每台20个线程 | 数据消费速度慢,从全量日志中过滤出不足20%的有效数据慢。 |
每日都有数据积压 | hbase为一张表 | ||
持续数据积压量达到15亿条【1500M条】 |
b)解决方案:【参看如下连接】
优化项 | 优化点 |
后端逻辑 | 逻辑优化, 优化前1万条数据处理时间为上千ms 优化后1万条数据处理时间为20ms左右 |
自身日志打印 | 将自身日志打印关闭 |
hbase表拆分 | 将之前的单表拆分为日表 |
日志系统日志丢失优化 | 参看 : 日志并发写入造成脏数据 |
c)优化后效果
考察项 | 描述 |
kafka消费堆积 | 消费堆积基本被消除了 |
hbase写入耗时 | 从之前的每批次耗时300~400ms,最好1.5s,降至100ms以内 |
服务器配置 | 之前4台服务器处理,有严重积压,hbase服务器CPU扛不住,现在只上线2台服务器,8个小时内将1500M条积压的数据消费完毕。之后高峰期积压量也是50M以内,而且高峰期之后很快就消耗掉了。 |
尝试过修改 hbase client的缓存,现在使用的是默认的5M,修改hbase client对写入性能没有提升。
尝试过修改每次请求中写入数据的数量,当前默认的是一个请求,批量写入100条数据,这个也是一个权衡,经过测试100还是比较合理的数值。
2.第二版【典型问题:数据延时】
a)数据延时1小时
由于大家都是小白,之前没过多考虑kafka的数据出入平衡问题,单纯的以为在上一步优化之后,基本就没有延时了。
之后在看日志时,发现日志延时在1小时以上。
b)解决方案:
将kafka的出入量放开,kafka的延时基本被消除掉了。
3.第三版【典型问题:hbase集群压力大】
随着第二版kafka放开了吞吐量之后,kafka内部基本没有延时,峰值压力都打到了hbase,hbase的压力CPU idle 很低。
a)存在问题:
版本 | 存在问题 | 服务器配置 | 典型问题 |
3.0 | hbase集群压力大 | 4台服务器。每台10个线程 | meta请求频繁 |
meta所在服务器的CPU idle在业务高峰期时,CPU跌到20% | 排查了客户端内存设置 | ||
hbase的其它服务器CPU基本正常 | 排查了写入setAutoFlush(false)设置 | ||
排查了writeToWAL(false)设置 |
b)解决方案
优化项 | 优化点 |
hbase配置优化 | 对region数量进行限制,将hbase主库的表只保留7天的 |
c)优化效果
考察项 | 描述 |
hbase写入耗时 | 每批次写入耗时在40ms以内,即使是高峰期,耗时基本也在40ms以内。 |
服务器配置 | 4台服务器,每台10个进程。 |
日志入hbase延时 | 高峰期,kafka还有几M的数据积压 |
单条日志的延时已经降到秒级了 | 高峰期日志处理延时为十几秒、非高峰期日志延迟为5秒以内 |
4.第四版【典型问题:CPU跌底】
a)存在问题
版本 | 存在问题 | 服务器配置 | 典型问题 |
4.0 | 高峰期kafka内还有几M的数据积压 | 4台服务器。每台10个线程 | 精益求精,想进一步将kafka积压消除 |
meta所在服务器的CPU idle在业务高峰期时,CPU idle在25% | 消除积压,也是为即将到来的每日都在增长的业务量做准备。 | ||
为月底【20多天之后】业务目标配套做服务 |
b)解决方案:
优化项 | 优化点 |
增加日志处理线程数 | 将"日志处理“服务器的线程数,从之前的每台10个线程,提升为每台20个线程。 一共部署4台服务器 |
c)优化效果:
考察项 | 描述 |
hbase写入耗时 | 高峰期每批次写入耗时从之前的40ms以内,变为1秒。非高峰期耗时增长不大。 |
日志入hbase延时 | 高峰期,kafka无任何数据积压 |
单条日志的延时已经降到秒级了 | 高峰期日志处理延时为2秒以内【目标终于达成了】 |
上线2天后,突然在一个非业务高峰期,meta所在服务器的每秒写入QPS为25万/秒,CPU idle 跌至10%附近。幸运的CPU idle很快就恢复至30%以上。有点惊心动魄。
5.第五版【典型问题:不再玩心跳】
a)存在问题
版本 | 存在问题 | 服务器配置 | 典型问题 |
5.0 | 任何时段,kafka无积压 | 4台服务器。每台20个线程 | hbase meta 所在服务器稳定性高优解决 |
日志消费延时已经在2秒以内了 |
kafka已经没有消费积压,这也意味着kafka没有了缓冲,即kafka也失去了削峰的作用,hbase想抗住瞬间的写入高峰有点困难,只要QPS稍微增加至30万/秒以上,估计hbase meta所在的那台服务器就宕机了。 | ||
开始考虑hbase meta表所在服务器的稳定性为主 | 为月底【20多天之后】业务目标配套做服务 |
b)解决方案:
优化项 | 优化点 |
牺牲数据准确性 确保低延时和高峰期的CPU不被击穿 | 使用主库写入,备库读取的方案,据测算,备库有1.5/10000的数据丢失率。 持续提升主库的写入速度,主库只保留2天的数据,即两张表,备库保留长时间的表。 |
预警备案 : 当后续的hbase meta所在服务器再次扛不住的时候,需要将数据处理的服务器单台线程数设置为10,否则还是设置为20. |
c)预警备案 :
v1 : 当前还是追求高的写入速度和日志处理的低延时,保留4台server,每台server 20个线程。
v2 : 如果v1版之后数据量变大,而hbase meta 所在服务器 CPU idle很低,则考虑将数据处理服务器的线程数从20调整为10.
v3 : 如果在v2版的基础上,日志整体延时超过2分钟,则需要重新搭建一套hbase的集群。
d)优化效果:
考察项 | 描述 |
hbase写入耗时 | 高峰期每批次写入耗时150ms左右。非高峰期写入耗时很少。 |
hbase meta 服务器CPU | meta所在服务器高峰期CPU idle最低为45%,比之前的10%【个例】和以往以来的25%要好很多。非高峰时段CPU idle为95%左右。 |
单条日志的延时已经降到秒级了 | 高峰期日志处理延时为2秒以内【目标终于达成了】 |
6.第六版
a)当前效果
b)指标权衡
最终的矛盾变为低延时、丢数据、CPU保障、业务增长支撑几个方面的权衡。
kafka 按分钟的数据积压量
kafka按小时的数据积压量
hbase集群的CPU idle,高峰期CPU idle最低也在45%
三、总结
1. 三个小白,非常无助的情况下,每天面对CPU的压力,想尽好多办法,最终完成了任务目标。【hbase meta所在服务器的CPU一直是最头疼的问题,也是整个环节最致命的问题,项目上线后就一下很低,而且被迫停止了一段时间】
2. 日志入库整体延时严格控制在了秒级,准确来讲,高峰期延迟也控制在了2秒以内。
3.数据丢失,从各个环节控制,现在丢失率已经控制到了比较小的比例。
4.后续考虑长期支撑大的业务量,牺牲了一部分数据丢失率,换取了hbase集群的支撑数据能力。
5. 边学边解决问题也是挺刺激的事情。
6. 现在可以不用长时间盯着看消费积压和CPU了。终于可以歇一口气了。
持续追求,权衡平衡
作者:杨考 微信 : devin_cn_hd_09_16 欢迎讨论问题
在每次收到阅读者添加微信并开始交流讨论,心理是无比的激动。