当前位置: 首页 > news >正文

实时数仓与维表时态Join实战

  • 下单用户是新客还是老客
  • 用户当前的等级、城市、渠道
  • 商品所属品类、类目层级

这些信息通常存放在维度表(维表)中,例如 MySQL 的dim_userdim_product等。我们希望在实时计算时,能把「事实流」和「维表」在时间维度上正确地关联起来,构建一张带有完整业务属性的明细宽表

这就是维表时态 Join(Temporal Table Join)要解决的问题。

本文我们就以「订单事实流 + 用户维表」为例,完成一个从 Kafka 到 MySQL 的简易实时数仓 Demo,并重点理解 Flink SQL 中维表时态 Join 的语法和注意事项。

一、业务场景与数仓目标

设想一个简化的电商业务场景:

  • Kafka 中有实时写入的orders订单事实流
  • MySQL 中维护一张dim_user用户维表,包含用户等级、所属城市、注册渠道等信息

我们想要在 Flink 中构建一张「订单明细宽表」,字段大致包括:

  • 订单信息:订单号、下单用户、下单金额、下单时间
  • 用户属性:用户昵称、等级、城市、注册渠道

并且要求:

  • 当我们回看 10 分钟前的某条订单时,看到的是当时用户的等级和城市,而不是被后续变更“冲掉”的最新值

这正是时态 Join和「实时数仓」的关键:按事件发生时刻回放维度视图

二、环境前提与依赖准备

1. 基础组件

本篇默认你已经完成前几篇中的环境准备:

  • Flink 1.20.1(WSL2 Ubuntu 下部署)
  • Kafka 集群已启动,且能正常写入 / 读取 Topic
  • Flink SQL Client 可以正常连接集群

在此基础上,我们还需要:

  • 一套可访问的 MySQL(本地或远程均可)
  • Flink 的 JDBC Connector JAR 包

2. 安装 Flink JDBC Connector

和 Kafka 一样,JDBC 连接器也需要以 JAR 包形式放到 Flink 的lib目录中。

以 Flink 1.20.x 对应的flink-connector-jdbc为例:

  1. 确认 Flink 安装目录(假设为/opt/flink):

    export FLINK_HOME=/opt/flink
  2. 下载 JDBC Connector JAR 到 Flink 的lib目录:

    cd $FLINK_HOME/lib wget https://repo1.maven.org/maven2/org/apache/flink/flink-connector-jdbc/3.3.0-1.20/flink-connector-jdbc-3.3.0-1.20.jar
  3. 如果你使用的是独立集群或远程集群,需要重启 Flink 集群,让新 JAR 在 JobManager/TaskManager 上生效:

    cd $FLINK_HOME bin/stop-cluster.sh bin/start-cluster.sh
  4. 重启 Flink SQL Client,使用新 Connector:

    cd $FLINK_HOME bin/sql-client.sh

如果你在 Windows + WSL2 上部署,只需在 WSL2 内执行上述命令即可;或者手动下载 JAR 后拷贝到lib目录,步骤完全一致。

三、准备 MySQL 用户维度表 dim_user

首先在 MySQL 中准备一张简单的用户维度表,用来存用户的基础属性。

在 MySQL 中执行:

CREATE DATABASE IF NOT EXISTS realtime_dwh; USE realtime_dwh; CREATE TABLE dim_user ( user_id VARCHAR(32) PRIMARY KEY, user_name VARCHAR(64), user_level VARCHAR(16), city VARCHAR(64), register_time DATETIME ); INSERT INTO dim_user (user_id, user_name, user_level, city, register_time) VALUES ('u_1', '张三', 'VIP1', '北京', '2025-12-01 10:00:00'), ('u_2', '李四', 'VIP2', '上海', '2025-12-05 11:00:00'), ('u_3', '王五', 'VIP1', '广州', '2025-12-10 12:00:00');

为了演示「时态」效果,你可以在后续实验中手动更新某个用户的等级或城市,例如:

UPDATE dim_user SET user_level = 'VIP3' WHERE user_id = 'u_2';

这样我们在 Flink 里做时态 Join 时,就能观察“变更前后”的区别。

四、在 Flink 中注册事实流与维表

接下来回到 Flink SQL Client,把 Kafka 中的订单事实流和 MySQL 中的维表都注册成 Flink 表。

1. Kafka 订单事实表 orders

和上一篇双流 JOIN 类似,我们假设 Kafka 中有一个ordersTopic,写入订单事实数据。

在 Flink SQL Client 中执行:

CREATE TABLE orders ( order_id STRING, user_id STRING, order_amount DECIMAL(10, 2), order_time TIMESTAMP_LTZ(3), WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND, proc_time AS PROCTIME() ) WITH ( 'connector' = 'kafka', 'topic' = 'orders', 'properties.bootstrap.servers' = '127.0.0.1:9092', 'properties.group.id' = 'flink-orders-dim', 'scan.startup.mode' = 'earliest-offset', 'format' = 'json', 'json.timestamp-format.standard' = 'ISO-8601' );

你可以沿用上一篇中 Kafka 造数的方式,用kafka-console-producer.sh发送 JSON 订单数据,只需要保证字段名一致。

2. MySQL 用户维表 dim_user(JDBC Lookup 表)

然后把刚才在 MySQL 中建好的dim_user注册为 Flink 的 JDBC 表:

CREATE TABLE dim_user ( user_id STRING, user_name STRING, user_level STRING, city STRING, register_time TIMESTAMP(3), PRIMARY KEY (user_id) NOT ENFORCED ) WITH ( 'connector' = 'jdbc', 'url' = 'jdbc:mysql://127.0.0.1:3306/realtime_dwh', 'table-name' = 'dim_user', 'driver' = 'com.mysql.cj.jdbc.Driver', 'username' = 'root', 'password' = '1qaz@WSX' );

注意几点:

  • PRIMARY KEY (user_id) NOT ENFORCED告诉 Flink 这是一张以user_id为主键的表,是做时态 Join 的前提
  • 这里使用的是典型的 JDBC Lookup 模式,Flink 会在 Join 时按需去 MySQL 查维度信息

在生产环境中,你可以把 MySQL 作为维度存储,或者通过 CDC 把维表变更同步到 Kafka,构造成 changelog 流,这些都可以和 Temporal Join 结合使用。

五、维表时态 Join:把订单打上用户维度

有了订单事实表orders和维度表dim_user,就可以通过时态 Join 来构建订单明细宽表。

1. 基础时态 Join 语法

Flink SQL 中的 Temporal Table Join 对于 JDBC 这类外部维表,通常采用「处理时间(Processing Time)」语义来做 Lookup Join,典型写法如下:

SELECT o.order_id, o.user_id, d.user_name, d.user_level, d.city, o.order_amount, o.order_time FROM orders AS o LEFT JOIN dim_user FOR SYSTEM_TIME AS OF o.proc_time AS d ON o.user_id = d.user_id;


这里有几个关键点:

  • proc_time AS PROCTIME()是在orders上定义的处理时间字段
  • FOR SYSTEM_TIME AS OF o.proc_time表示“以 Flink 处理这条订单记录的当前时间,去查维表的一个快照”,这是 JDBC Lookup 支持的典型用法
  • Join 条件依然是user_id等值关联
  • 使用LEFT JOIN可以保留找不到维度的订单,并用空值来表示“维度缺失”

在 SQL Client 中执行这段查询,会看到实时流式刷新的结果,每一行订单都带上了对应的用户属性。

2. 验证时态效果:修改维表再观察 Join

为了验证这是“时态 Join”而不是“始终查最新维度”,可以按下面步骤操作:

  1. 先往 Kafka 的ordersTopic 写入几条订单数据,例如用户u_2下单的记录

  2. 观察 Flink SQL 中 Join 后的结果,此时u_2的等级是VIP2

  3. 回到 MySQL,执行:

    UPDATE dim_user SET user_level = 'VIP3' WHERE user_id = 'u_2';
  4. 再写入一批新的订单,仍然是用户u_2

bin/kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092 --topic orders

在命令行中输入一条 JSON 数据(按回车发送一条):

{"order_id":"o_3","user_id":"u_2","order_amount":200.00,"order_time":"2026-02-19T14:42:00Z"}


这时你会看到:

  • 变更前的订单,维度字段仍然显示VIP2
  • 变更后的订单,维度字段变成了VIP3

这就说明 Flink 的时态 Join 确实是“按订单发生时刻去回放维度视图”的,而不是简单查当前最新值。

六、把结果写回 Kafka 或 MySQL,形成实时数仓明细层

在真实项目中,我们不会只在 SQL Client 里SELECT一下就结束,而是要把 Join 后的订单明细宽表,写回到下游存储,形成实时数仓的一个层级。

例如,可以把结果写回 Kafka,作为 DWD 层的订单宽表:

CREATE TABLE dwd_order_user_wide ( order_id STRING, user_id STRING, user_name STRING, user_level STRING, city STRING, order_amount DECIMAL(10, 2), order_time TIMESTAMP_LTZ(3), WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'dwd_order_user_wide', 'properties.bootstrap.servers' = '127.0.0.1:9092', 'properties.group.id' = 'flink-dwd-order-wide', 'scan.startup.mode' = 'earliest-offset', 'format' = 'json', 'json.timestamp-format.standard' = 'ISO-8601' ); INSERT INTO dwd_order_user_wide SELECT o.order_id, o.user_id, d.user_name, d.user_level, d.city, o.order_amount, o.order_time FROM orders AS o LEFT JOIN dim_user FOR SYSTEM_TIME AS OF o.proc_time AS d ON o.user_id = d.user_id;

这样,下游的实时应用或 BI 查询就可以直接订阅dwd_order_user_wide这个 Topic,拿到已经打好用户标签的订单明细数据。

你也可以把结果同步到 MySQL、ClickHouse 等分析型数据库中,构建实时明细表,为报表和可视化提供数据。

七、小结与下一步建议

通过这篇文章,我们完成了这样一件事:

  • 在 Kafka 中维护订单事实流orders
  • 在 MySQL 中维护用户维度表dim_user
  • 使用 Flink SQL 的 JDBC Connector 把 MySQL 注册为维表
  • 利用FOR SYSTEM_TIME AS OF语法做维表时态 Join
  • 将 Join 结果写回 Kafka,形成实时数仓中的一张订单明细宽表

这背后有几个非常重要的实时数仓设计理念:

  • 事实流是不断追加的事件序列,维表是相对缓慢变更的业务视图
  • 时态 Join 让你能够“按事件发生的时间点”,回看当时的维度快照
  • 实时数仓的 DWD 层,往往就是「事实表 + 多个维表时态 Join」后形成的明细宽表

在后续的文章中,我们可以继续沿着这个方向深入:

  • 在一个任务里同时关联多张维表,构建更宽的明细表
  • 引入 CDC,把维表变更实时同步到 Kafka,再在 Flink 中构建 changelog 维表
  • 把实时数仓的明细层、汇总层(DWS)、指标主题层(ADS)串起来,做一个端到端的实时数仓小项目

如果你已经跑通了本文的 Demo,不妨试着自己设计一张商品维表dim_product,再给订单打上商品品类维度,体验一下“事实 + 多维表时态 Join”在 Flink SQL 里的完整味道。

http://www.cnnetsun.cn/news/1676885.html

相关文章:

  • 04 月 03 日 AI 每日参考:中外厂商密集发新模型,智元发布周将启
  • 2026届毕业生推荐的五大AI科研神器实测分析
  • Blender场景教程:秘密实验室
  • 如何彻底解决Mac滚动方向混乱:Scroll Reverser完整配置指南
  • 3.30作业
  • 剑指offer-14、链表中倒数第k个结点
  • 2026 Java后端面试“三剑客”:集合、JUC、Redis 高频考点解析
  • 【初中地生会考练习系统】一个类似驾考宝典的初中地理生物会考在线练习系统,支持题库管理、错题本、顺序练习、模拟考试等功能
  • 软件开发常见骗局有哪些?
  • 什么是数据标准管理?怎么进行数据标准管理?
  • 09_语义网之行业应用与企业实践
  • T113的Linux系统调试记录(二)T113 的Linux 编译过程详解
  • 全球辅助动力装置(APU):稳增6.0%,2032年剑指106.47亿美元
  • 我的 Nexent 实操手记:零代码搭建「旅行规划师」智能体
  • 2026届最火的降重复率工具实际效果
  • 我发现了一个超级好用快速生成er图的工具
  • 2026年计算机科学论文降AI工具推荐:代码说明和算法描述怎么处理
  • 从一次线上文件泄露事件说起:深度复盘KKFileView配置踩坑与最佳实践
  • 所有下载都一定要直接从个人服务器直接下载--------因为个人宽带的上传速度一点也不慢
  • python web框架streamlit
  • 告别模糊边界!用DeepLabv3+在Cityscapes数据集上实现像素级街景分割(附PyTorch实战代码)
  • 从‘正在加载’到‘用户体验’:用Qt QProgressDialog打造更友好的长时间任务交互(附模态/非模态选择指南)
  • 番茄小说下载器:为离线阅读爱好者打造的全能工具
  • **AI仿真人剧企业2025推荐,沉浸式交互体验与多场景商业落地解析**据中国信通院2025数字内容与人工智能融合应用白皮书显示,2025年国内AI仿真人剧市场规模预计突破120亿元,但能提供完整
  • 2025最权威的降重复率方案实际效果
  • 如何快速部署DeepQA:10分钟搭建你的第一个AI聊天机器人
  • java常见面试题杂记
  • SEO 关键字优化与内容营销的结合方法是什么
  • 解决Telegraf Kafka插件与Kafka 4.0兼容性问题:从报错到修复全指南
  • Extism终极指南:如何用WebAssembly框架构建可扩展应用