企业官网建设流程全解析

去年我带的一个实时指标项目里，出现过一次特别抓狂的问题：一段很普通的 Flink Table API 窗口 SQL，在测试环境用一份有界数据跑，结果完全正确；可一接到线上的无界数据流，窗口要么迟迟不触发，要么下游收到的结果跟预想对不上。排查了大半天，最后发现根子不在并行度、不在数据倾斜，而在于我对"有界"和"无界"这两类输入下的窗口语义理解得不够透。

这篇文章就专门讲 Flink Table API / SQL 里有界窗口和无界窗口的使用逻辑。不只写语法，我会把窗口触发背后的时间语义、水位线、迟到数据、批模式行为这些关键点串起来讲，适合正在用 Flink 做实时数仓、实时指标统计，或者从 DataStream 切到 Table API 的开发者参考。你应该已经熟悉基础 SQL，但对窗口细节还时不时踩坑。

1. 先把"有界"和"无界"的含义落在 Flink 窗口上

1.1 动态表：一张会持续增长的表

Flink Table API 里，数据流和表的关系有一点绕：流不是静态表，而是"动态表"。

直白点说，你把 Kafka Topic 里不断到达的数据注册成一张表，这张表的行会随着新数据到达而持续增加。你把一个文件目录注册成表，读完之后这份数据就固定了，不会再有新行产生。

有界数据在 Flink 中的形态，就是这批数据有明确的结束边界；无界数据则是"永远不知道什么时候结束"的流。这个区别直接决定了窗口算子的运行方式。

我记得有次跟人聊需求，对方说"我加了 TUMBLE 窗口，批和流应该都一样吧"。实际上差别非常大：批处理下，数据已经全部到齐，窗口的起点终点是确定的，可以按排序后的数据一次性聚合；流处理下，数据还在源源不断来，窗口必须靠水位线判断"到这个时间点了，把窗口里的数据聚合并输出，然后继续等下一个窗口"。前者是"算完拉倒"，后者是"永远在赶路"。

1.2 窗口本身是有界的，但数据流性质不会变

这里容易混淆一个概念：窗口是有界的，但数据流是有限还是无限，跟是否开窗没关系。

每个窗口算子都会划定一个有限的时间范围，比如 1 分钟滚动窗口，看似把无界流拆成了一个个有界的小块。但底层逻辑没变：上游数据仍然无界，窗口算子本身仍然要维持状态、不断等待新数据、不断判断水位线。

Flink 内部区分一批数据到底有没有边界，主要看你的 source 连接器和运行模式。比如：

• Kafka Source，默认被视为无界数据源，数据不断进来，没有结束标志。
• 文件 Source、JDBC Source 这类有明确读取范围的，默认被视为有界数据源，读完了就结束。
• 如果设置了execution.runtime-mode: BATCH，Flink 会在批模式下处理有界数据源，用批处理引擎的调度方式执行；设置为STREAMING，则按流模式处理。

我刚接触 Table API 时以为窗口能"制造有界"，后来才发现窗口只能"在有界或无界的数据之上划分计算范围"，不能改变数据流的有限/无限属性。

1.3 批流一体：同样的窗口 SQL，两套执行逻辑

Flink 1.12 之后把流批一体作为重点方向，同一套 SQL 在 BATCH 和 STREAMING 模式下的物理执行计划会不同。

一个典型的差异是窗口触发。流模式下，窗口不会因为"数据到了 N 条"就触发，只有等到水位线越过窗口结束时间才触发。批模式下，Flink 可以拿到全量数据，先按时间排序，再在排序过程中切分窗口，不需要水位线，也不会因为某条数据迟到导致窗口结果缺失。

所以你会看到这样的现象：相同一段 TUMBLE 窗口 SQL，在流模式接 Kafka 需要专门设计水位线；在批模式接 Hive 表或文件，直接跑就能输出完整结果。不是说流模式有 bug，而是两套执行逻辑本来就不同。

理解了这一点，后面看水位线、看迟到数据、看批模式特有行为，就不会觉得混乱了。

2. 时间属性与水位线：窗口能触发的真正前提

2.1 先选时间语义：处理时间还是事件时间

Table API 的窗口必须基于一个时间字段。这个字段有两种来源：事件时间（数据里自带的时间戳）或处理时间（Flink 算子所在机器的本地时间）。

这个选择最好在数据接入阶段就定好。我的建议是：只要业务对时间准确性有要求，比如统计某分钟的 PV、判断用户在某段时间的行为序列，优先用事件时间。因为处理时间受机器时钟、调度延迟、网络传输影响很大，同一批数据在不同时刻补齐，结果会不一样。

处理时间适合的场景是：你只关心数据到达的先后，比如实时告警、基于到达顺序做限流。注意，处理时间在批模式下基本没有意义，因为批处理时任务瞬间完成，处理时间窗口会产生无法预期的结果。

2.2 在 DDL 中定义时间属性和水位线

Table API / SQL 中，一般在创建表的 DDL 里直接声明时间属性和水位线。这段是地基，写错后面全乱。

典型的 Kafka 表定义：

CREATE TABLE user_behavior ( user_id BIGINT, item_id BIGINT, action STRING, ts TIMESTAMP(3), WATERMARK FOR ts AS ts - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'user_behavior', 'properties.bootstrap.servers' = 'localhost:9092', 'properties.group.id' = 'flink-sql-demo', 'scan.startup.mode' = 'earliest-offset', 'format' = 'json' );

这里的关键点是：

• ts字段必须是TIMESTAMP(3)类型，精度是毫秒。如果你源数据里是yyyy-MM-dd HH:mm:ss字符串，需要先转成这个类型。
• WATERMARK FOR ts AS ts - INTERVAL '5' SECOND意思是：允许数据最多迟到 5 秒，超过这个时间窗口将不再等待。
• 其中ts - INTERVAL '5' SECOND就是生成水位线的表达式。Flink 会持续观察当前已经看到的最大事件时间，并减去 5 秒，作为当前可触发窗口的"水位标记"。

2.3 时间字段类型不对，窗口永远不触发

我见过不少新手在这里踩坑：Kafka 里的ts字段是字符串，直接拿来做窗口，结果窗口一直不触发或者结果为空。

从 JSON 字符串到TIMESTAMP(3)通常得做一步转换，比如：

ts AS TO_TIMESTAMP(FROM_UNIXTIME(ts_seconds))

或使用CAST(json_ts AS TIMESTAMP(3))。总之，源的字段类型必须和窗口算子要求的一致，否则 Flink 在逻辑计划阶段就会拒绝，或者偷偷把你的字段当作不会推进的时间字段处理。

另外一个容易忽略的问题是时区。TIMESTAMP(3)本身不带时区，如果你的场景里上游事件时间戳是 UTC，而窗口的统计口径要按东八区，那 8 个小时的偏移会导致窗口切分错误。我习惯在 Flink SQL 里用TIMESTAMP_LTZ(3)配合时间戳毫秒值，并在客户端设置table.local-time-zone，避免很多诡异问题。

3. 四类窗口的实际写法与选型逻辑

3.1 基础三件套：TUMBLE、HOP、SESSION

Flink Table API / SQL 的窗口函数在 1.13 之后推荐用窗口表值函数（TVF）写法。下面给三个最常见的示例，建议直接照着往自己的 SQL 上套。

滚动窗口 TUMBLE：固定间隔，窗口之间不重叠。比如按用户每分钟统计动作数。

SELECT window_start, window_end, action, COUNT(*) AS cnt FROM TABLE( TUMBLE(TABLE user_behavior, DESCRIPTOR(ts), INTERVAL '1' MINUTE) ) GROUP BY window_start, window_end, action;

滚动窗口是最直观的，适合分钟级/小时级指标。它的问题也很明显：如果两个相邻窗口的数据在时间边界附近抖动，统计结果可能被切得不均匀。

滑动窗口 HOP：窗口大小 + 滑动步长，窗口可以重叠。比如每 30 秒输出一次"最近 1 分钟"的统计，适合滚动刷新大盘数据。

SELECT window_start, window_end, COUNT(*) AS total_cnt FROM TABLE( HOP(TABLE user_behavior, DESCRIPTOR(ts), INTERVAL '30' SECOND, INTERVAL '1' MINUTE) ) GROUP BY window_start, window_end;

滑动窗口需要注意的是：一条数据可能同时属于多个窗口，所以下游结果会有重复计算。你要评估业务是否接受这种"重叠窗口里的独立统计"。

会话窗口 SESSION：根据事件之间的间隔 gap 进行分组。比如用户连续操作间隔超过 15 分钟，就算新会话。

SELECT window_start, window_end, COUNT(*) AS action_cnt FROM TABLE( SESSION(TABLE user_behavior, DESCRIPTOR(ts), INTERVAL '15' MINUTE) ) GROUP BY window_start, window_end;

会话窗口适合行为分析，但状态开销最大。因为 Flink 需要持续跟踪每个 key 当前会话的边界，一旦无界流上 key 种类非常多，状态很容易膨胀。

3.2 累计窗口 CUMULATE：被低估的高频场景利器

除了上面三个经典窗口，**累计窗口（CUMULATE）**在新版本里也值得掌握。它的句法是：

SELECT window_start, window_end, COUNT(*) AS cnt FROM TABLE( CUMULATE(TABLE user_behavior, DESCRIPTOR(ts), INTERVAL '10' MINUTE, INTERVAL '1' HOUR) ) GROUP BY window_start, window_end;

意思是：以 1 小时为最大窗口，每 10 分钟滚动累计一次。如果你需要做"当天累计销售额到当前时刻"这样的实时指标，CUMULATE 比手动把多个窗口拼起来简单得多。

三类窗口的选型，我整理成一张表，项目评审时直接照这个讲：

3.3 窗口结果里如何取时间边界

使用 TVF 写法后，结果里会自动带window_start、window_end、window_time三个字段。注意：

• window_start和window_end是窗口的边界时间。
• window_time是窗口内事件时间的上界，通常等同于window_end，但精度上略有差异。
• 如果要把结果写入 Kafka，再用这个结果做下一次窗口聚合，一定要正确传递window_time，否则下游窗口的时间字段又是错的。

我踩过的一个坑是：从窗口查询里取出window_end后，自己再加工成字符串，结果发现时区不对，导致下游按小时分区写入文件时，数据全部落到了前一小时。后来统一使用CAST(window_start AS STRING)并在连接器层面配好时区，才彻底解决。

4. 无界流场景的迟到数据：从容忍到结果修正

4.1 无界流里的数据都会迟到，只是程度不同

日常经验里，离线数据不会迟到，因为它面对的是一个确定的数据集。无界流不一样，一条数据从产生到进入 Flink，中间可能经过网关、消息队列、重试，网络一抖动就延迟了。迟到是常态，不是异常。

在 Table API 里，迟到数据默认被水位线机制"挡住"。水位线表示的是"比这个时间更早的数据，以后基本不会再来了"。所以窗口触发的那一刻，如果数据还没到，就会被丢弃或者触发后又来，导致结果不完整。

4.2 水位线容忍、窗口等待与结果修正的组合

面对无界流窗口，我通常用三层策略：

第一层，水位线容忍度。在表 DDL 里把 watermark 设置为业务可接受的最大延迟，例如ts - INTERVAL '30' SECOND。容忍度越大，结果越完整，但窗口输出越滞后。

第二层，允许延迟触发后的数据更新结果。Table API 里可以在作业设置中开启延迟数据触发更新：

SET 'table.exec.emit.early-late.enable' = 'true'; SET 'table.exec.emit.late-fast.enable' = 'true';

这个配置在不同 Flink 版本里表现不完全一样，但思路是：窗口触发后如果又有迟到数据进入，算子会输出撤销旧结果和更新新结果。此时下游 Sink 必须支持更新操作，比如 Upsert Kafka、MySQL。如果 Sink 只支持 append，会出现同一窗口输出多行，下游得自己做去重。

第三层，对丢弃数据的兜底。纯 SQL 的窗口聚合没有直接的"迟到数据侧输出"语法，但我见过两种实用做法：

• 如果必须精确处理侧输出，用 DataStream API 做sideOutputLateData，再转回 Table 继续算。
• 如果不想引入 DataStream 混合开发，可以在源表层面增加"延迟补偿任务"，把当天延迟超过窗口容忍度的数据在次日补算，用离线任务每秒补一次。

不要一开始就追求把 100% 的迟到数据都吸收进实时窗口，成本和收益不成比例。

4.3 为什么你开了水位线，结果还在跳

有个现象很常见：窗口已经触发了，下游报表里数值却过一会儿变一下。这在流式场景是正常的。窗口第一次输出基于当时已到的数据；开启结果修正后，迟到的数据来了，Flink 会发出一条-U（撤销旧值）和一条+U（插入新值），最终结果被更新。

如果你希望报表稳定，可以在下游把结果落成每天的分区表，晚到数据只更新当天的分区，而不是直接修改历史报表。这样实时和离线都能对账。

4.4 无界流上的窗口状态增长问题

无界流如果 key 特别多，窗口状态会一直累积。尤其是会话窗口，每个 key 的会话要持续维护到 gap 超时，状态量非常可观。

常用的控制手段：

SET 'table.exec.state.ttl' = '1 h';

给聚合状态设置 TTL 后，超过时间不再使用的聚合上下文会被清理，能避免无界流跑几个月状态爆炸。代价是，如果某条 key 长时间没有数据再出现，窗口结果可能会因为状态被清理而无法更新。这需要根据业务对延迟的容忍度来权衡。

5. 有界数据上的窗口：批模式行为、完整输出与坑

5.1 什么情况下你会拿到有界数据

有界数据在 Table API 里最常见的来源是：

• 读一个文件目录，例如 Hive 表对应的一组分区。
• 读 JDBC 表，数据范围固定。
• 从 Kafka 里把历史数据落成文件后再做批量重算。

判断方法很简单：Source 连接器是否有明确的结束条件。注意，同一个 Kafka Topic，如果你用 Kafka Source 直接消费，它是无界数据源；但如果你先从 Kafka 把数据抽出成文件，再让 Flink 读文件，这批数据就是有界的。

5.2 批模式下的窗口行为：不需要水位线，但也不是万能

在execution.runtime-mode: BATCH模式下，Flink 会先对数据进行排序，然后按时间顺序切分窗口。批模式下窗口不需要水位线，因为全量数据已经可见，不存在"等更晚的数据"这回事。

我实际使用中有一个重要体会：批模式窗口聚合的输出结果通常只有一组最终值，不像流模式会持续发更新消息。这反而让下游逻辑更简单，但如果你把流模式那条链路上的-U/+U逻辑强加到批模式，就会以为数据丢了。

另一种情况是：有些表看起来是有界数据，但你在 DDL 里定义的处理时间窗口会产生奇怪结果。比如文件读入后，所有行的处理时间几乎相同，处理时间窗口会集中在一个窗口里。遇到这种情况，强烈建议改用事件时间字段来做窗口。

5.3 有界数据上容易无视的并行度问题

批模式下跑窗口聚合，并行度设置不合适同样会出问题。因为批模式是排序后切窗口的，如果并行度太高，小文件特别多，下游写 Hive 可能出现成百上千个小文件；并行度太低，数据倾斜时单个 Task 要处理大量 key，拖慢整体耗时。

我一般这样调：先看数据量，单并行度处理 500MB 到 1GB 是个大致合理的范围，然后根据集群资源调整。同时打开table.optimizer.agg-phase-strategy的局部聚合/全局聚合能力，缓解 key 倾斜。

5.4 从流模式切到批模式重算历史的策略

很多团队会做"白天用流模式算实时报表，凌晨用批模式重算前一天全量数据"的双链路。此时要注意两个链路的 SQL 必须保持窗口语义一致。

比如流模式用ts - INTERVAL '5' SECOND作为水位线容忍，批模式也会基于相同的窗口边界逻辑，但不会丢弃任何数据，所以两侧结果可能对不上。通常的做法是：实时链路以"窗口触发时点的已到数据"为口径，批链路以"全量数据"为口径，两者本来就应存在一个"迟到未吸收"的差值，而不是直接划等号。

6. 窗口任务上线前，我建议你多留意的几个细节

6.1 先做小窗口验证，再放大窗口

我的习惯是：任何新的窗口 SQL，先在测试环境用 1 分钟或 5 分钟的小窗口跑通，核对窗口边界、输出行数、更新行为，确认无误后再放大到小时级、天级窗口。直接上一个大窗口任务，等结果出来再检查，往往浪费大量时间。

6.2 窗口聚合结果落 Sink 前，先确认 Sink 的能力

流模式下的窗口聚合结果默认可能包含更新和删除操作。如果你的 Sink 是 Kafka（append 模式），你看到的每条数据其实只是一个快照，多次更新会变成多行，下游消费方要有去重逻辑。如果 Sink 是 Upsert Kafka 或 MySQL，可以直接按主键更新。

我踩过最实在的坑是：窗口聚合结果写入普通 Kafka Topic，下游用 Spark 消费做统计，结果同一个窗口被统计了多次。后来在 ETL 里按window_start + key做了取最大，才算修正。

6.3 并行度不是越大越好

无界流上的窗口聚合，如果并行度开得过高，状态分散到大量并行的子任务里，数据 shuffle 增加，有时候延迟反而变高。特别是配合 MiniBatch 时，过高的并行度会导致每个子任务的 mini-batch 都攒不满，反而不触发。

一个实用的组合是：

SET 'table.exec.mini-batch.enabled' = 'true'; SET 'table.exec.mini-batch.allow-latency' = '5s'; SET 'table.exec.mini-batch.size' = '10000';

MiniBatch 能让同一批数据的中间聚合状态先合并，大大减少下游写压力，但延迟会增加 5 秒左右。不是所有实时场景都适合。

6.4 会话窗口的 gap 不是越大越好

会话窗口的 gap 设长了，能让相邻的短间隔行为合并成一个大会话；设短了，会话分裂。但 gap 有状态成本，gap 越大，每个 key 的会话状态保留时间越长。我见过一个场景，gap 设成 30 分钟，单个 key 的 session 状态在 RocksDB 里占用了大量空间，后来改到 10 分钟，配合table.exec.state.ttl，才算稳定。

6.5 时刻记住：无界流窗口是"持续修正"的

流模式下，窗口结果是随时间和数据推进不断修正的。它不像离线那样"一次算完整"，而是一个渐进准确的过程。你要做的是在业务需求和数据延迟之间找到平衡点，而不是要求一个无限等待、无限准确的无界窗口。

如果产品指标能接受"最迟 30 秒可见，偶尔有迟到补数"，就把水位线容忍度设在 30 秒附近，并让下游支持更新。如果要求"绝对不能丢数"，那就要设计好补算机制，不能只靠窗口算子硬扛。每次调窗口参数，我都在笔记里记下当时的延迟容忍和最终的口径口径，这些经验比语法本身更值钱。