一种通用的百亿级数据清洗方案

最近两个月,一直在和刀哥两个人重构连尚读书这边的用户行为日志系统。到本周放量完所有的数据到新系统,基本算告一个段落。

目前的业务情况,大概是有新旧两套日志系统数据,日志规模(2018.11),新日志一天产生6000万条日志,旧日志一天产生4000万条日志数据,合计1亿条上报日志,这些日志数据,都是合并上报的,根据统计,大概一条上报日志,会产生50条最终日志数据。所以最终的日志量,超过了50亿条(写这篇博客时,2019.1,已经超过70亿条)。

根据业务特点,预计的高峰期是10个小时(按40000秒计算), 100000000 / 40000 = 2500条/秒。整个系统每秒要完成 2500条上报日志的收集。然后要转化为 2500 * 50 = 125000条/秒的最终结果日志数据。晚上21 ~ 22点的最高峰,处理量还要预留x4,估计会处理10000条的收集日志数据,完成生产500000条/秒最终结果日志数据。

最终结果日志数据文件的单条大小在1 ~ 2 kbyte之间,多数为1 kbyte

最终结果日志数据,需要存储在本地硬盘+大数据的Kafka集群(9台机器)两边做容灾。

如此大规模的数据,不管是收集,清洗,本地存储,还是入库,都是非常有挑战的一项工作,更何况是重构。。。

一、旧的架构情况,使用的机器规模大概是20台机器.

注释:

1、Bear服务是这边之前的同事用Golang + Leveldb写的一个服务,可以用来接收HTTP请求传输的数据到Leveldb,然后再把对应的数据,发送到指定的HTTP 地址(转发数据)或者是发送到指定的Kafka集群,可以起到数据的缓存作用

2、之前得到的同事的反馈,都说这个Bear服务的性能很高,不存在问题

旧架构存在的问题

1、无法追踪单条数据的处理情况,因为数据没有任何的标号,导致要反查或者是顺查数据,基本没法

2、Bear只会把数据存储在Leveldb里面,外层没有日志,再加上没有源码,无法做任何修改(我也不知道为啥没源码啊)

3、之前的同事反馈说Bear的性能很高,不存在性能问题,但是我们实际观察发现,问题最大的就是这个Bear,一个是接收性能不行,另外一个就是数据转发性能不行,不管是接收HTTP数据,还是转发数据到HTTP或者Kafka集群,Bear都给不出来量,所以导致经常出现拥堵的情况,需要不停的多开Bear服务,其性能有严重的问题

4、本地没有数据,无法做数据重放。不管是收集日志,还是最终日志,我们这边完全没任何原始数据,一旦入了Kafka集群后,我们就无能为力了,无法校对数据,无法重放,无法追踪处理流程

5、因为使用Bear做数据缓存,他只支持HTTP请求的数据清洗,导致只能走php-fpm,然后他的转发性能又不行,所以导致整个系统的数据清洗能力极低

二、新的架构情况,使用的机器规模为12台 + 3 组Redis实例

优点

1、不管是收集的原始日志数据还是处理以后的最终日志数据,我们都有存储,随时可以重放

2、每条日志加了不会重复的logid,可以根据logid追踪到任何一条数据的流转过程和处理结果,并且大数据那边可以根据logid去重数据

3、不管是收集端的API日志服务器,还是Redis,还是消费服务器,都是可以任意的横向的扩展的,而且不影响任何第三方,性能可以直线上升

4、日志数据压缩,采用的是pigz的并行压缩,每天凌晨压缩前一天的日志数据文件,在目前的日志规模下,在一个小时内,可以压缩完成所有的日志,对业务和机器负载不会带来任何影响,而且数据的压缩比率,在1:20以上

5、因为采用了脚本主动拉取的模式,所以只要消费服务器足够,理论上任何数据都会在3s内被处理,达到实时效果

6、业务采用了脚本的模式,执行效率相比原来的Nginx + php-fpm的模式,性能提升了几十倍,而且因为不走HTTP协议了,所以内网的带宽使用也成倍的下降,不到原来的一半

7、因为使用了Logstash的批量提交模式,数据入Kafka的性能,提升了几十倍

8、因为启用了Logstash的永久队列,基本上保障了数据的不丢失,经过对比,和Kafka里面统计出来的数据,误差在百万分之几的级别

9、在入Logstash时,采用了失败就扔Redis队列再用另外的消费脚本入可用的其他Logstash的方式,保障说即使本地的Logstash宕机,数据依然可以正常的入Kafka集群

10、消费脚本进程,采用了supervisor来做管理,新、旧版消费日志脚本,单机各开100个脚本,主要 supervisor 需要采用 3.3以上的版本,3.3以下的版本,对于管理几百个进程,会有问题

11、各段都可以方便的知道性能瓶颈,不管是Filebeat的收集端,Redis队列端,还是Logstash端,都提供了良好的监控数据,可以即时了解系统的工作状态。

三、重构完成后,新旧系统的服务器机器负载对比

旧系统单机

新系统

消费服务器的负载
Redis负载

目前,单日清洗的数据量,已经超过70亿条,按现在的机器负载预估,这5台机器,预计处理清洗150亿条日志数据,没有任何问题。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*

code

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据