【三个臭皮匠】日志处理系统之Hbase优化历程

 

三个臭皮匠【参与人】: 振远、光鑫和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左右 参看 : kafka消费延时解决实战【意想不到的消费逻辑优化】
自身日志打印	将自身日志打印关闭
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    欢迎讨论问题

在每次收到阅读者添加微信并开始交流讨论，心理是无比的激动。