设为首页 加入收藏

TOP

【三个臭皮匠】日志处理系统之Hbase优化历程
2019-03-15 01:42:05 】 浏览:26
Tags:三个臭皮匠 日志 理系统 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 欢迎讨论问题

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


编程开发网
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇HBase启动HMaster几秒后又死掉的.. 下一篇Hbase 错误记录及修改方法

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容:

array(4) { ["type"]=> int(8) ["message"]=> string(24) "Undefined variable: jobs" ["file"]=> string(32) "/mnt/wp/cppentry/do/bencandy.php" ["line"]=> int(214) }