FLINK SQL 数据打宽
2021-11-01 本文已影响0人
貌似很有道理呢
Regular Join
- 支持INNER JOIN, FULL JOIN, LEFT JOIN, RIGHT JOIN
- 双流 Join，任意一侧流都会触发结果的更新
- 通过 state 来存储双流已经到达的数据，state 默认永久保留，所以 Regular join 的一个问题是默认情况下 state 会持续增长，一般我们会结合 state TTL 使用。
Interval Join
- 支持INNER JOIN, FULL JOIN, LEFT JOIN, RIGHT JOIN
- 区间 Join，任意一侧流都会触发结果的更新
- state 不用存储全量的曝光数据，state 可以自动清理
- 需要明确时间区间,输出流也保持时间属性
Temporal join（时态表打宽）
SELECT * FROM FACT [LEFT] JOIN DIM FOR SYSTEM_TIME AS OF FACT.{PEOCTIME|ROWTIME} ON FACT.ID = DIM.ID，即用FACT.{PEOCTIME|ROWTIME}时间去取DIM维表中的某一个版本与FACT事实表join ，只有左流才会触发结果更新
1. lookup DB
- 维度数据的变化不会触发结果更新
- 维度数据存储在数据库中
- 适用于实时性要求较高的数据
- 一般会开启Async IO 和内存cache提升查询效率
- 吞吐较差
2. changelog版本表
- 维表watermark等待
- 维表数据存在temporal join state中
- 实时性高，精准版本关联
- FOR SYSTEM_TIME AS OF 跟一个event time，event time会等待另一个流中的watermark水位对齐，保证关联上精确版本结果。
- 吞吐较好
3. hive分区表
| Hive最新分区 | Hive最新表 |
|---|---|
| stream读，每次读一个分区 | 按batch读，每次读全部分区 |
| streaming-source.partition-include取latest | streaming-source.partition-include取all |
| 通过streaming-source.monitor-interval发现分区 | lookup.join.cache.ttl控制reload时间 |
- 自动关联hive维表最新分区
- 适用于维表更新慢场景
- 吞吐非常好
UTDF
-自定义打宽
