一、概述动态表Dynamic Table和连续查询Continuous Query是 Flink Table API / SQL 实现流批统一与标准关系代数语义的两大核心理论基础。其核心思想将无限、无界的流式数据映射为一张随时间不断变化的逻辑表让用户可以直接使用标准 SQL 对流数据进行查询、聚合、关联等操作完美对齐批处理的 SQL 使用习惯。整套机制分为三层核心能力动态输入表技术将实时输入数据流映射为 SQL 可识别的动态输入表连续查询技术在动态表上执行持续计算映射标准 SQL 运算语义动态输出表技术将计算后的动态结果表反向转换为可输出的数据流。二、动态表Dynamic Table2.1 产生背景传统大数据计算存在明显的流批割裂认知批处理操作静态有限表数据集固定查询一次性执行完成流处理处理无界事件流数据逐条持续到达无固定数据集。Flink 打破流批边界提出核心理论流 动态表的 Changelog变更日志流是动态表的实时变更记录动态表是流数据的高层逻辑抽象。双视角对照理解视角数据表现形式流视角(Alice, 1),(Bob, 1),(Alice, 1)… 逐条变更数据流表视角一张不断更新、追加数据的动态数据表可随时查询快照基于该设计同一条 SQL 语句可同时适配批处理静态表和流处理动态表真正实现 Flink 流批一体。2.2 动态表详解动态表是 Flink 对流式无界数据的逻辑表抽象核心特性如下随时间持续变化支持行的插入、更新、删除操作任意时间点都可像静态批表一样执行 SQL 查询表初始为空新流事件到达即触发表数据变更所有表的变更最终以Changelog 流的形式对外输出。三、连续查询Continuous Query3.1 定义连续查询是作用于动态表的流式 SQL 查询区别于批处理的一次性查询它是永不停止的增量计算任务除非手动停止作业。核心链路输入动态表 → 连续查询计算 → 输出动态表Changelog 流3.2 核心特性增量计算不重复计算全量数据仅根据新输入数据增量更新状态和结果每一次输出都是最新的中间结果状态驱动聚合、分组、连接等算子会维护状态例如GROUP BY会为每个 Key 单独维护聚合结果完善的时间语义原生支持事件时间、处理时间支持滚动、滑动、会话等多种窗口类型。3.3 实战案例小时级用户点击统计业务场景实时统计每小时每个用户的页面点击次数基于用户点击流数据计算。SQL 语句SELECT user_id, COUNT(*) AS click_cnt, TUMBLE_START(ts, INTERVAL 1 HOUR) AS w_start FROM clicks GROUP BY user_id, TUMBLE(ts, INTERVAL 1 HOUR);执行过程输入层clicks动态表持续接收用户点击流不断追加新数据计算层连续查询按user_id 1 小时滚动窗口分组为每个(user_id, window)组合维护 count 聚合状态输出层窗口水位线超过窗口结束时间后触发窗口计算输出最终结果。输出结果示例I (Alice, 5, 2024-06-01 10:00) -- 窗口 [10:00, 11:00) 最终结果插入 I (Bob, 3, 2024-06-01 10:00)该结果可直接写入 Kafka、Paimon、Hudi 等存储供下游实时消费。若开启窗口早期触发会产生-U/U更新消息。3.4 动态表两大更新模式Flink 根据 SQL 查询是否产生更新、删除操作将动态表输出流分为两类类型名称消息类型触发条件Append-only Stream仅追加流只有I插入消息无 GROUP BY、无 JOIN、无 DISTINCT、无窗口仅数据追加Changelog Stream更新流包含I/-U/U/-D全量变更消息包含聚合、连接、去重、窗口等会更新历史结果的操作四、Changelog 变更日志机制Changelog 是 Flink Table/SQL 流处理的核心底层机制所有算子之间的数据流转本质都是传递 Changelog 变更日志是动态表和连续查询得以实现的基础。4.1 定义Changelog 类似于 MySQL Binlog是一套描述动态表数据变更的流式数据模型每条消息对应表的一次变更操作。Flink 内部通过RowKind枚举定义四种变更类型Changelog 类型枚举值含义使用场景IINSERT插入新行新数据首次写入结果表-UUPDATE_BEFORE更新前旧值数据更新时标记需要替换的旧数据可优化省略UUPDATE_AFTER更新后新值数据更新后的最新结果-DDELETE删除行历史数据需要删除、撤回4.2 引入 Changelog 的必要性传统批表是静态快照而 Flink 动态表是持续变化的无法直接传递全量快照。因此 Flink 引入 Changelog 机制流转表、表转流的核心桥梁算子之间仅传递增量变更而非全量数据保证流式计算高效性所有算子消费 Changelog、产出新 Changelog形成完整流式计算链路。4.3 Changelog 流转原理Flink Table 层所有算子聚合、JOIN、窗口、去重的底层数据结构为Row RowKind// 代码层面构建带变更类型的数据RowrowRow.withKind(RowKind.INSERT,1001,Jack);// 控制台输出I[1001, Jack]数据传输时可序列化为 JSON、Avro 等格式内存计算阶段无需序列化性能优异。Flink WebUI 中 DAG 算子之间的链路本质就是 Changelog 流传输通道。4.4 Changelog 三大编码方式核心概念区分Changelog 语义描述表发生了什么变化插入/更新/删除编码方式Flink 用何种消息组合物理实现这种变更语义。Flink 提供三种标准化编码方式适配不同业务场景性能和规则差异显著编码方式编码规则核心特点是否需要主键状态开销Append-only仅使用I所有数据均为插入最简单、零开销、最高效无更新删除操作否无Retract撤回流更新 -D删旧值 I插新值不使用-U/U通用性最强无需主键更新需两条消息网络开销翻倍否全量缓存状态Upsert更新插入流首次写入I更新直接U删除-D省略-U更新仅一条消息高效依赖主键覆盖旧数据是主键索引状态生产选择建议有明确主键、需要更新结果优先Upsert高效、适配主流存储无主键、不确定数据规则使用Retract通用兼容纯追加数据、无更新删除使用Append-only性能最优。补充Flink 默认优化省略-U仅审计、精准溯源场景可强制开启全量 ChangelogtableEnv.toChangelogStream(table,ChangelogMode.all()).print();4.5 特殊 Changelog 变体场景4.5.1 Full Changelog完整变更日志特点完整输出I/-U/U/-D四种消息触发场景复杂多层查询、自定义 UDF、手动强制开启用途数据审计、精准溯源、问题调试。4.5.2 Windowed Changelog窗口变更日志特点窗口支持早期触发时会产生多次中间更新消息规则仅窗口结束触发 →I开启早期触发 → 先-U/U迭代更新最终输出I本质Upsert/Retract 模式在窗口语义下的特殊表现。4.5.3 Temporal Join Changelog时态连接变更日志特点维表数据更新时会撤回旧 JOIN 结果、插入新结果消息模式固定为-D I属于 Retract 流场景原因维表更新会导致整条关联结果失效无法通过主键 Upsert 实现。4.6 Retract vs Upsert 核心对比两者最大差异是UPDATE 操作的编码方式直接决定作业性能与 Sink 适配性Retract一次更新 2 条消息删旧插新网络、存储、序列化开销翻倍Upsert一次更新 1 条U消息性能翻倍生产首选。Upsert 完美适配主流更新型存储MySQL/PostgreSQL对应INSERT ... ON DUPLICATE KEY UPDATERedis/HBase主键 PUT 覆盖Upsert-Kafka日志压缩保留 Key 最新值ClickHouse主键更新语义。五、Changelog 与 Sink 适配Sink 必须精准识别上游 Changelog 语义否则会出现数据重复、丢失、不一致问题。不同 Sink 对变更消息的支持能力差异极大。5.1 主流 Sink 能力对比Sink 类型是否支持完整 Changelog核心适用场景精准一次支持Upsert-Kafka✅ 完全支持实时聚合结果、维度表、实时大屏✅ 事务开启即可普通 Kafka✅ 原样输出调试、Flink 作业间数据中转✅ 支持Hudi✅ 支持删除需配置实时数据湖、CDC 入湖✅ 完全支持JDBC/File/Hive❌ 不支持更新删除语义静态数据初始化、日志归档⚠️ 需自定义实现Print/Blackhole✅ 支持调试输出开发测试、日志打印❌ 不支持5.2 核心 Sink 实战案例5.2.1 Upsert-Kafka生产首选核心要求必须定义主键自动根据 Key 覆盖旧数据忽略无用-U消息。CREATE TABLE user_clicks_sink ( user_id STRING, total_clicks BIGINT, PRIMARY KEY (user_id) NOT ENFORCED -- 必须声明主键触发Upsert模式 ) WITH ( connector upsert-kafka, topic user-clicks-result, properties.bootstrap.servers kafka:9092, key.format json, value.format json ); -- 写入聚合结果自动处理更新覆盖 INSERT INTO user_clicks_sink SELECT user_id, COUNT(*) FROM clicks GROUP BY user_id;5.2.2 普通 Kafka仅调试/中转原样输出完整 Changelog保留rowkind字段下游需自行解析变更语义。CREATE TABLE debug_sink ( user_id STRING, cnt BIGINT ) WITH ( connector kafka, topic debug-changelog, format json -- 输出包含rowkind的完整变更数据 ); INSERT INTO debug_sink SELECT user_id, COUNT(*) FROM clicks GROUP BY user_id;输出 JSON 示例{rowkind:I,fields:[Alice,1]}{rowkind:-U,fields:[Alice,1]}{rowkind:U,fields:[Alice,2]}5.3 生产环境最佳实践聚合、窗口、去重结果优先使用upsert-kafka / Hudi规避复杂 Changelog 解析禁止将带更新删除的 Changelog 写入普通 Kafka、HDFS 等不支持更新的系统Upsert 类 Sink 必须显式定义PRIMARY KEY开发调试使用toChangelogStream().print()观察真实变更类型需要精准一次语义时开启sink.semantic EXACTLY_ONCE。六、FlinkSQL 完整处理流程一条流式 FlinkSQL 的完整执行链路分为三步完美串联流、动态表、连续查询、Changelog 四大核心能力6.1 第一步输入流 → 动态表将无界输入流映射为逻辑动态表流中每条数据默认是I追加操作构建 Append-only 初始动态表。该表为逻辑抽象无物化存储。6.2 第二步动态表 → 连续查询计算在动态表上执行 SQL 连续查询基于状态增量计算生成新的动态结果表。根据 SQL 逻辑不同产生 Append-only 或 Update 类型 Changelog。6.3 第三步结果动态表 → 输出流将计算后的动态结果表通过三种编码方式Append/Retract/Upsert转换为可输出的 Changelog 数据流写入外部 Sink。七、全文总结流批一体核心流是动态表的 Changelog动态表是流的逻辑抽象实现流批 SQL 统一语义连续查询核心增量计算、状态驱动、持续运行输出动态变更结果Changelog 核心四种 RowKind 定义表变更三种编码方式适配不同场景生产最优解无更新用 Append有主键更新用 Upsert无主键更新用 RetractSink 适配核心聚合结果优先 Upsert-Kafka/Hudi杜绝 Changelog 与 Sink 语义不匹配。