实时数仓实践系列 | NO.1『宽表处理』

一、实时数仓和离线数仓

由于离线数仓每天凌晨拉去线上生成数据库(凌晨请求较少，减少线上库压力)，导致数据是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次。可以解决无论哪个消息先到达，只需要根据业务进行判断是否符合条件，进行处理即可。在处理的过程中对每个消息进行幂等处理即可，保证消息不会重复计算。这样既能保证不用讨论消息的先后顺序，又可以保证处理所有的消息，使计算逻辑准确无误。

四、总结语

实时数据仓库在保证时效性的同时，难免处理方案不像离线数据那样简单，但如果为了时效性，做一些处理也是在所难免的，毕竟大家更希望看到的是当前的用户量是多少，当前销售额是多少，而不是昨天的。

本文分享自微信公众号 - 暴走大数据（zhouqiantanxi）