(转载)实时数仓宽表加工解决方案

一.实时数据仓库与离线数据仓库

由于离线数据每天凌晨拉去线上生成数据库(凌晨请求较少,减少线上库压力),导致数据是T+1,而对于一些时效性要求较强的场景。比如需要看现在的用户数、GMV等等,离线方案就很难解决了。

实时数据仓库就是刚好为了满足时效性要求较高的场景下而生的,但是在做实时数据仓库中经常会遇到一些问题。离线由于表数据都同步到数据仓库中,可以进行随意关联,出一些业务想要的统计结果。但是实时数据,一般是接收线上发送的实时消息或者同步mysql的binlog消息,进行消费的。

这就会出现如果消息来自不同源头,需要对这些消息进行整合关联,不同消息的先后顺序无法保证?关联关系如果比较复杂,不像离线数仓通过sql进行关联,处理效果也会较差。(转载)实时数仓宽表加工解决方案_第1张图片

二.问题

下面是在实时数据仓库加工过程中,经常会遇到的一些问题:

1.需要关联维表信息(与离线数仓类似需要关联维表信息,但是实时数据中并没有维表信息)

2.接收多个消息,消息先后顺序无法保证(离线中数据都已经同步,不存在先后问题)

3.一条与信息相关的所有消息是否全部到达(离线可以看作是当天的快照,但实时没办法判断是否全部到达)

三、解决方案

针对上述问题、结合工作中的遇到的一些场景,做一些总结,探讨下实时宽表加工方案:

1.如何关联维表信息问题:比如说我们计算订单相关数据,需要查询部门或者收货地址的地区等等,需要关联部门相关的维表或者地址信息维表。

解决方案:将sku相关的部门信息(T+1)同步到redis、hbase中作为缓存,查询的时候可以先查询缓存中的数据,如果没有查询到再去查询线上接口,能够有效的减少线上接口的压力。(转载)实时数仓宽表加工解决方案_第2张图片

2.多个消息无法保证先后顺序问题:还拿订单场景为例,比如我们需要统计订单支付金额,涉及到下单消息、支付消息,正常情况(支付消息后来,但是没办法保证)

解决方案:将消息进行分别存储至hbase,(1)下单消息到了去查询支付消息表,找到了进行下发;没找到进行存储;(2)支付消息先到达,查询下单消息,查询到了下发;没查询到进行存储(转载)实时数仓宽表加工解决方案_第3张图片

 

3.如何判断一条与信息相关的消息是否全部到达问题:订单场景下,一个订单多个消息(下单消息A、支付消息B、取消消息C等等),怎么能保证一个订单下的所有消息都达到了呢?比如说:订单od1是不是支付了呢?是不是取消了呢?这些

解决方案:不管消息是否全部到达,进行存储至hbase,同时取出该订单相关的所有消息进行下发。

下发出来的数据:

(1)A

(2)A、B

(3)A、B、C

可以看到上述总共发了3次消息,其中A消息发了3次,B消息发了2次,C消息发了1次。可以解决无论哪个消息先到达,只需要根据业务进行判断是否符合条件,进行处理即可。在处理的过程中对每个消息进行幂等处理即可,保证消息不会重复计算。这样既能保证不用讨论消息的先后顺序,又可以保证处理所有的消息,使计算逻辑准确无误。(转载)实时数仓宽表加工解决方案_第4张图片

四、总结

实时数据仓库在保证时效性的同时,难免处理方案不像离线数据那样简单,但如果为了时效性,做一些处理也是在所难免的,毕竟大家更希望看到的是当前的用户量是多少,当前销售额是多少,而不是昨天的。
————————————————
原文转自:实时数仓宽表加工解决方案_诸葛子房的博客-CSDN博客_数仓中的宽表icon-default.png?t=M1L8https://blog.csdn.net/weixin_43291055/article/details/100112790

你可能感兴趣的:(hbase,big,data,数据仓库)