主要任务

从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 **字典表

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

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

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

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

（2）与字典表通过内连接关联。

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

图解

代码编写

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主题

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 主题

bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092  --topic dwd_trade_order_refund

开始启动