主要任务

从Kafka 读取业务数据,筛选退单表数据,筛选满足条件的订单表数据,建立MySQL-Lookup 字典表,关联三张表获得退单明细宽表。(退单需求)

思路分析

1**)设置 **ttl

用户执行一次退单操作时,order_refund_info 会插入多条数据,同时order_info 表的条对应数据会发生修改,所以两张表不存在业务上的时间滞后问题,因此仅考虑可能的乱序即可,ttl 设置为5s。

2**)筛选退单表数据**

退单业务过程最细粒度的操作为一个订单中一个SKU 的退单操作,退单表粒度与最细粒度相同,将其作为主表

3**)筛选订单表数据并转化为流**

获取province_id。退单操作发生时,订单表的 order_status 字段值会由1002(已支付)更新为1005(退款中)。订单表中的数据要满足三个条件:

(1)order_status 为1005(退款中);

(2)操作类型为 update;

(3)更新的字段为 order_status。

该字段发生变化时,变更数据中old 字段下order_status 的值不为null(为 1002)。

4**)建立MySQL-Lookup **字典表

  1. 获取退款类型名称和退款原因类型名称。

5**)关联这几张表获得退单明细宽表,写入Kafka **退单明细主题

  1. 退单信息表order_refund_info 的粒度为退单业务过程的最细粒度,将其作为主表。

(1)对单信息表与订单表的退单数据完全对应,不存在独有数据,通过内连接关联。

(2)与字典表通过内连接关联。

第二步是否从订单表中筛选退单数据并不影响查询结果,提前对数据进行过滤是为了减少数据量,减少性能消耗。下文同理,不再赘述。

图解

实时数仓(二十)DWD层-交易域退单事务事实表 - 图1

代码编写

https://gitee.com/luan_hao/gmall-flink/blob/master/gmall-realtime/src/main/java/com/apache/gmall/app/dwd/db/DwdTradeOrderRefund.java

测试

创建dwd_trade_order_refund主题

  1. bin/kafka-topics.sh --zookeeper hadoop102:2181,hadoop103:2181,hadoop104:2181/kafka --create --replication-factor 1 --partitions 1 --topic dwd_trade_order_refund

消费dwd_trade_order_refund 主题

  1. bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic dwd_trade_order_refund
启动 DwdTradeOrderRefund

开始启动

实时数仓(二十)DWD层-交易域退单事务事实表 - 图2

观察消费者数据

实时数仓(二十)DWD层-交易域退单事务事实表 - 图3

有如上图数据,则测试成功