【三个臭皮匠】日志处理系统之Hbase优化历程
三个臭皮匠【参与人】: aa、bb和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 欢迎讨论问题
在每次收到阅读者添加微信并开始交流讨论，心理是无比的激动。