最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

某电商实时数仓宽表加工解决方案

[复制链接]
发表于 2019-10-20 12:26:29 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
作者简介:
目前就职于一线互联网公司,从事大数据相关工作。了解互联网、大数据,一直在努力的路上。
一、实时数据仓库与离线数据仓库
由于离线数据每天凌晨拉去线上生成数据库(凌晨请求较少,减少线上库压力),导致数据是T+1,而对于一些时效性要求较强的场景。比如需要看现在的用户数、GMV等等,离线方案就很难解决了。
实时数据仓库就是刚好为了满足时效性要求较高的场景下而生的,但是在做实时数据仓库中经常会遇到一些问题。离线由于表数据都同步到数据仓库中,可以进行随意关联,出一些业务想要的统计结果。但是实时数据,一般是接收线上发送的实时消息或者同步mysql的binlog消息,进行消费的。
这就会出现如果消息来自不同源头,需要对这些消息进行整合关联,不同消息的先后顺序无法保证?关联关系如果比较复杂,不像离线数仓通过sql进行关联,处理效果也会较差。
二、问题
下面是在实时数据仓库加工过程中,经常会遇到的一些问题:
1.需要关联维表信息(与离线数仓类似需要关联维表信息,但是实时数据中并没有维表信息)
2.接收多个消息,消息先后顺序无法保证(离线中数据都已经同步,不存在先后问题)
3.一条与信息相关的所有消息是否全部到达(离线可以看作是当天的快照,但实时没办法判断是否全部到达)
三、解决方案
针对上述问题、结合工作中的遇到的一些场景,做一些总结,探讨下实时宽表加工方案:
1.如何关联维表信息问题:比如说我们计算订单相关数据,需要查询部门或者收货地址的地区等等,需要关联部门相关的维表或者地址信息维表。
解决方案:将sku相关的部门信息(T+1)同步到redis、hbase中作为缓存,查询的时候可以先查询缓存中的数据,如果没有查询到再去查询线上接口,能够有效的减少线上接口的压力。
2.多个消息无法保证先后顺序问题:还拿订单场景为例,比如我们需要统计订单支付金额,涉及到下单消息、支付消息,正常情况(支付消息后来,但是没办法保证)
解决方案:将消息进行分别存储至hbase,
(1)下单消息到了去查询支付消息表,找到了进行下发;没找到进行存储;
(2)支付消息先到达,查询下单消息,查询到了下发;没查询到进行存储
3.如何判断一条与信息相关的消息是否全部到达问题:订单场景下,一个订单多个消息(下单消息A、支付消息B、取消消息C等等),怎么能保证一个订单下的所有消息都达到了呢?比如说:订单od1是不是支付了呢?是不是取消了呢?这些
解决方案:不管消息是否全部到达,进行存储至hbase,同时取出该订单相关的所有消息进行下发。
下发出来的数据:
(1)A
(2)A、B
(3)A、B、C
可以看到上述总共发了3次消息,其中A消息发了3次,B消息发了2次,C消息发了1次。可以解决无论哪个消息先到达,只需要根据业务进行判断是否符合条件,进行处理即可。在处理的过程中对每个消息进行幂等处理即可,保证消息不会重复计算。这样既能保证不用讨论消息的先后顺序,又可以保证处理所有的消息,使计算逻辑准确无误。
四、总结
实时数据仓库在保证时效性的同时,难免处理方案不像离线数据那样简单,但如果为了时效性,做一些处理也是在所难免的,毕竟大家更希望看到的是当前的用户量是多少,当前销售额是多少,而不是昨天的。
作者:​诸葛子房
来源:小晨说数据

楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 17:11

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表