从零开始学Flink：Flink SQL四大Join解析

在上一篇 《从零开始学Flink：实时数仓与维表时态Join实战》 中，我们通过引入 Hive Catalog，解决了 Flink SQL 元数据管理的痛点。
今天，我们将目光聚焦于实时数仓建设中最核心、也最容易“踩坑”的环节——多流关联（Join）。
作为一名大数据工程师，你可能经常面临这样的灵魂拷问：

• "为什么我的双流 Join 跑着跑着就 OOM 了？"
  
• "为什么订单和支付数据都有，但 Join 出来的结果却是空的？"
  
• "我想关联订单发生那一刻的用户等级，而不是现在的等级，怎么搞？"
  

本文将基于 Flink 1.20+ 版本，结合真实的电商场景，深入剖析 Regular Join、Interval Join、Temporal Join 和 Lookup Join 的原理、应用场景及生产级优化策略。
环境准备

为了复现本文的实战案例，请确保你已配置好 Hive Catalog 环境（参考前文），并切换到 ods 库：

1. USE CATALOG myhive;
2. USE ods;
3. -- 确保 orders 和 payments 表已存在
4. SHOW TABLES;

复制代码

一、Regular Joins (常规 Join)：最灵活但也最危险

这是最符合 SQL 标准的 Join 方式，语法与传统离线 Hive SQL 几乎一致。
1.1 场景：全量订单支付关联

业务需求很简单：查询每个订单的支付详情，不限制支付时间（哪怕支付比订单晚了一个月）。
实战 SQL

1. -- 1. 准备测试数据
2. INSERT INTO orders VALUES
3. ('o_001', 'u_1', 50.00, TO_TIMESTAMP_LTZ(1773024000000, 3)), -- 02:40:00
4. ('o_002', 'u_2', 80.00, TO_TIMESTAMP_LTZ(1773027600000, 3)); -- 03:40:00
6. INSERT INTO payments VALUES
7. ('p_001', 'o_001', 50.00, 'WECHAT', TO_TIMESTAMP_LTZ(1773024600000, 3)), -- 02:50:00
8. ('p_002', 'o_002', 80.00, 'ALIPAY', TO_TIMESTAMP_LTZ(1773031200000, 3)); -- 04:40:00
10. -- 2. 执行关联查询
11. SELECT
12.   o.order_id,
13.   o.order_amount,
14.   p.pay_amount,
15.   p.pay_method
16. FROM orders AS o
17. INNER JOIN payments AS p
18. ON o.order_id = p.order_id;

复制代码

1.2 生产避坑指南

Regular Join 的核心机制是 Hash Join。为了保证“无论数据来得早晚都能关联上”，Flink 必须在 State 中 永久保存 左右两张流的所有历史数据。
⚠️ 风险提示：State 爆炸
如果不加限制，State 会随着时间无限膨胀，最终撑爆内存（OOM）或导致 Checkpoint 超时。

<strong>
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！