从零开始学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 库：

USE CATALOG myhive;
USE ods;
-- 确保 orders 和 payments 表已存在
SHOW TABLES;

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

这是最符合 SQL 标准的 Join 方式，语法与传统离线 Hive SQL 几乎一致。

1.1 场景：全量订单支付关联

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

实战 SQL

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