调试与优化:一次数据中心看板 T+1 改 T+0 优化过程
推荐阅读:我总结了72份面试题,累计3170页,斩获了30+互联网公司offer(含BATJM)2020首战告捷,这份Java面试神技Plus版,让我成功拿到了阿里、京东、字节跳动等大厂offer膜拜!阿里内部都在强推的K8S(kubernetes)学习指南,不能再详细了背景团队目前在做一个用户数据看板(下面简称看板),基本覆盖用户的所有行为数据,并生成分析数据,用户行为数据来源于多个数据源(餐饮
推荐阅读:
背景
团队目前在做一个用户数据看板(下面简称看板),基本覆盖用户的所有行为数据,并生成分析数据,用户行为数据来源于多个数据源(餐饮、生活日用、充值消费、交通出行、通讯物流、交通出行、医疗保健、住房物业、运动健康…),基于对大量数据的任意请求、排序和统计,没有办法对原生表(原生多表查询相对复杂)直接进行数据采用,所以我们在当日的凌晨获取前一天数据,并将数据做成Json对象保存在Mongo数据库中。
所以看板最初采用得是T+1的策略,这样就减少了实时数据计算的过程,另一方面能够保证数据的准确性。但是目前很多人反馈,希望能够实时的获取到看板最新的数据,而且每月月底会有消费数据核对,消费数据按照看板统计得出并核对,如果等到第二天(也就是次月1号)再输出数据报表,这种体验就太差了。
优化方案
针对看板的原型需求和数据呈现形式,形成了类似 (数据(Mongo)服务 - 接口服务 - 前端展示页面)的架构模式,以T+1的策略提供数据,
来保障用户可以高效的浏览到自己的行为数据结构,并给出具体得数据分析和建议。
原有流程:通过设计开发控制台调度服务,并部署到中心服务器上,调度配置每天凌晨一点做服务启动,会根据用户新增和修改的日志做数据增量。
优化目标:改成每次用户行为数据的修改、删除和保存都采用消息队列形式实时的通知到服务去消费,服务消费之后立刻把Mongo的行为数据做好。
T+0 服务概要设计
核心功能实现设计
1、用户行为数据保存后实时发送MQ消息通知,解耦行为数据保存和看板数据生产的强关联。
2、开发独立服务消费MQ,同步聚合看板数据、输出用户行为数据报表,并推送通知消息给用户进行查看。
数据服务生成流程
时序图/流程图说明
1、原有是独立服务每天凌晨进行数据计算,改成每次用户行为完成修改之后发送MQ
2、服务端程序监听MQ,消费到数据,则调用调度服务进行处理
3、调度服务根据配置好的调度规则,进行控制台服务启动,并将对应的数据增量拉取到内存中,进行数据的筛选、排序、整合,合并成目标mongo文档,并保存到mongo集群中
4、调度服务数据处理完成之后,同步聚合看板数据、输出用户行为数据报表,并推送通知消息给用户进行查看。
数据聚合过程说明
所有的用户行为模块都遵循这个规则,最后实现数据T+0 实时聚合的目标
更多推荐
所有评论(0)