flink- Interval Joins

1. 实验用数据

俩列： op固定值：

每隔5s往kafka 写一条数据

2. 实验用sql

select a.op , a.ts, b.ts  from source_table a  left join  source_table b on  a.op=b.op  and  a.ts between b.ts -INTERVAL '6' second  and  b.ts +INTERVAL '0' second 

3. 实验结果

+----+--------------------------------+-------------------------+-------------------------+
| op |                             op |                      ts |                     ts0 |
+----+--------------------------------+-------------------------+-------------------------+
| +I |                   10.10.28.240 | 2024-04-19 17:21:09.242 | 2024-04-19 17:21:09.242 |
| +I |                   10.10.28.240 | 2024-04-19 17:21:09.242 | 2024-04-19 17:21:14.251 |
| +I |                   10.10.28.240 | 2024-04-19 17:21:14.251 | 2024-04-19 17:21:14.251 |
| +I |                   10.10.28.240 | 2024-04-19 17:21:19.252 |                  (NULL) |
| -D |                   10.10.28.240 | 2024-04-19 17:21:19.252 |                  (NULL) |
| +I |                   10.10.28.240 | 2024-04-19 17:21:19.252 | 2024-04-19 17:21:19.252 |
| +I |                   10.10.28.240 | 2024-04-19 17:21:14.251 | 2024-04-19 17:21:19.252 |
| +I |                   10.10.28.240 | 2024-04-19 17:21:24.267 |                  (NULL) |
| -D |                   10.10.28.240 | 2024-04-19 17:21:24.267 |                  (NULL) |
| +I |                   10.10.28.240 | 2024-04-19 17:21:19.252 | 2024-04-19 17:21:24.267 |
| +I |                   10.10.28.240 | 2024-04-19 17:21:24.267 | 2024-04-19 17:21:24.267 |

每5s 一条数据， 根据关联条件， a表的数据应该和b表 本条数据+下一条数据关联。

看返回结果， 符合预期。

但是会出现 -D的回撤流数据。

原因： 左表的数据快于右表的数据到了， 不等待立刻下发一条关联不成功的数据。

          等右表数据到了， 发现之前下发的关联不成功的数据是不合理的，应该回撤， 然后再下发一条关联成功的数据。

          等右表第二条数据到达时，再下发一条关联成功的记录。

Regular Joins   原理一样，只是少了一个关联条件。

4. 和回撤流关联

select  a.op,b.regdate  from source_table a  left join dim   as b on a.op=b.ipv4 

dim 是 cdc，  值从119  改成 120.

5.和回撤流关联结果

+----+--------------------------------+-------------+
| op |                             op |     regdate |
+----+--------------------------------+-------------+
| +I |                   10.10.28.240 |         119 |
| +I |                   10.10.28.240 |         119 |
| -U |                   10.10.28.240 |         119 |
| -U |                   10.10.28.240 |         119 |
| +I |                   10.10.28.240 |      (NULL) |
| +I |                   10.10.28.240 |      (NULL) |
| -D |                   10.10.28.240 |      (NULL) |
| -D |                   10.10.28.240 |      (NULL) |
| +I |                   10.10.28.240 |         120 |
| +I |                   10.10.28.240 |         120 |
| +I |                   10.10.28.240 |         120 |

右表数据变更生成回撤数据后， 之前正常发送的数据都会被回撤。

然后根据最新值继续下发。

中间为什么有 2对4条  null的数据呢。

6. Temporal Joins

select  a.op,b.regdate  from source_table a  left join dim  for system_time as of a.`ts`  as b on a.op=b.ipv4

7. Temporal Joins  结果

+----+--------------------------------+-------------+
| op |                             op |     regdate |
+----+--------------------------------+-------------+
| +I |                   10.10.28.240 |         120 |
| +I |                   10.10.28.240 |         120 |
| +I |                   10.10.28.240 |         121 |
| +I |                   10.10.28.240 |         121 |
| +I |                   10.10.28.240 |         121 |
| +I |                   10.10.28.240 |         121 |

 左表和右表 某个时刻的快照关联。   

虽然dim 中是包含回撤流的， 但是关联时关心的是这个时刻的快照，不收回撤数据影响。

7.1  状态管理

  Temporal Joins 左表必须有时间属性，干啥，应该是用来判断右表过期。右表状态不是用ttl管理的。

7.2 结果固定

基于事件时间， 静态数据的 Temporal Joins 的连接结果是固定的。

但是如果右表发生了变动， 第一次跑的结果和第二次跑的结果就可能不一致吧。（人懒了，没找数据验证)

例子： 订单 汇率

11 点给了 11 点的汇率是7   

13点给了 12 点的汇率是8.

第一次跑的时候， 12-13 点的订单的汇率是几呢， 应该是7。 

第二次再跑的时候，12-13 点订单的汇率应该是8 。

基于事件时间， 静态数据的 Temporal Joins 的连接结果是固定的。 一定是基于静态数据。

 

8. Lookup Join

一般会把数据进行缓存， 当找不到对应值时，再去mysql表查询。

所以特别不适用 流表的维度值比 mysql的值多的情况， 没法缓存，只能不停地去mysql查询

9. table function  join