日志处理相关

数据处理是一项细活,每步相关问题都值得梳理清楚

日志处理流:

日志格式->写日志文件->读日志文件->数据队列->流处理入库->离线分析->报表API查询->可视化


日志格式:

写日志文件:

数据队列:

流处理入库

离线分析

报表API查询

初始公司,人手少,开始阶段忙于写业务,就 make it work, make it right and make it fast三点来看,都做到了但是不健壮,一方面与建设者的经验,眼光和能力有关,另一个方面,基础架构的复杂与业务的体量大小这中间的trade-off,衡量不好,后续改造成本负担不小;

过程记录:

数据流量大的日志在入库时 势必会对数据库产生比大压力,虽然目前日志是先存放到文件中,再从文件解析后入库,存在可能因为日志解析后入库导致的日志文件消耗过慢,从而由日志文件切割产生日志数据遗漏问题,解决方法是可以在数据库前加一个消息队列如kafka来缓和压力:一方面可以加快 日志解析速度,另一方面可以减缓数据库的入库压力。

日志收集:
使用filebeat持续监控日志文件读取数据推向下一个数据点;

另个一个是数据的聚合问题:
机器人对话服务中每一通对话由多个QA组成, 每一条日志保存了一组QA,目前一条日志 作为一条row存放于MySQL表chat中(MyISAM存储引擎); web界面显示是以一通对话组合显示,所以要把 每一通对话的多个QA聚合起来;想了以下方法:
a. 使用即聚合返回 一个是给前端提供的api 中用group by 查询; 优点是简单,不折腾,缺点: 数据量大后,比如100万条后,查询明显感觉很慢
b. 离线聚合 把chat表中的数据按sessionID聚合后 存放于merge_chat表中;优点: 能不小程序解决a.中查询慢的问题;折腾的地方是, 每一通对话聚合结束的标志不明确,解决方法是:

c. 优先从聚合表中 但优先从merge_chat表中取数据,merge_chat表中没数据时,从chat表中拿所需要的数据进行聚合后,存入聚合表中;考虑到分页情况, chat表只保留一条session数据并且有标志显示数据已经聚合; 优点: 用到时才聚合,省cpu; 缺点: 要处理好 两张表的数据一致性关系。 这个算是a和b的折中方法
d. 日志存放ES或者MongoDB 用非关系型(文档)数据库,日志这种结构不定的数据,应对随时可能要增加一些指标项的情况, 修改起来要不方便不少;

2019-05-12