Blink/Flink 实践案例中的知识点整理

---

实践案例的知识点整理

实践案例部分在内部文档中有更多的案例，但是内容很重复，学习过程中经常看到一样的内容，我认为在这部分的阅读过程中不需要像我一样把所有的案例都读一遍，只需要看我下面整理的问题就可以了，难度并不大。推荐的方法是详细看一下我整理的在实际案例中遇到问题的解决方法，然后再略读实践案例的内容。

---

确定最终付款交易时间和订单确定时间

首先根据订单编号做分组，因为同一个编号订单会有多次业务操作(例如下单、付款、发货)，会在Binlog日志中形成多条同一订单编号的订单流水记录。使用MAX(dts_paytime)获取同一编号的最后一次操作数据库最终付款交易时间。

CREATE VIEW new_paytime AS
SELECT 
    dts_ordercodeofsys, 
    MAX(dts_paytime) AS dts_paytime
FROM orders_real
GROUP BY dts_ordercodeofsys

MIN(gmt_create) gmt_create,-- ‘创建时间’
MAX(gmt_modified) gmt_modified,-- ‘修改时间’

MIN(gmt_create)是指的订单的第一笔订单的创建时间，MAX(gmt_modified)是指的最后一比订单的时间。根据订单的业务逻辑我们可以用MAX和MIN来取相应的值。

---

如何判断有效订单

数据库日志会获取所有的数据记录的变更，而每个订单是有状态的。如列表所示：

dts_record_id: 这条增量日志的唯一标识，唯一递增。如果变更类型为 update，那么增量更新会被拆分成 2 条，一条 Insert，一条 Delete。这两条记录具有相同的 record_id。
dts_instance_id: 这条增量日志所对应的数据库的 server id。
dts_db_name: 这条增量更新日志更新的表所在的数据库库名。
dts_table_name:这条增量更新日志更新的表。
dts_operation_flag: 标示这条增量日志的操作类型。取值包括:
I : insert 操作
D : delete 操作
U : update 操作

dts_utc_timestamp: 这条增量日志的操作时间戳，为这个更新操作记录 binlog 的时间戳。这个时间戳为 UTC 时间。
dts_before_flag: 表示这条增量日志后面带的各个 column 值是否更新前的值。取值包括：Y 和 N。当后面的 column 为更新前的值时，dts_before_flag＝Y, 当后面的 column 值为更新后的值时，dts_before_flag=N.
dts_after_flag：表示这条增量日志后面带的各个 column 值是否更新后的值。取值包括：Y 和 N。 当后面的 column 为更新前的值时，dts_after_flag=N，当后面的 column 值为更新后的值时，dts_after_flag=Y.

对于不同的操作类型，增量日志中的 dts_before_flag 和 dts_after_flag 定义如下：

1. 操作类型为：insert
   当操作类型为 insert 时，后面的所有 column 值为新插入的记录值，即为更新后的值。所以 before_flag＝N, after_flag=Y

2. 操作类型为：update
当操作类型为 update 时，会将 update 操作拆为 2 条增量日志。这两条增量日志的 dts_record_id ,dts_operation_flag 及 dts_utc_timestamp 相同。
第一条日志记录了更新前的值，所以 dts_before_flag=Y, dts_after_flag=N
第二条日志记录了更新后的值，所以 dts_before_flag=N, dts_after_flag=Y

3. 操作类型为：delete
当操作类型为 delete 时，后面的所有 column 值为被删除的记录值，即为更新前的值。所以 dts_before_flag＝Y, dts_after_flag=N

CREATE VIEW new_orderdetail AS
SELECT 
dts_ordercodeofsys, 
dts_skuname, 
dts_skucode,