企业官网建设流程全解析

做Flink开发这几年，Table API/SQL 的窗口问题我前后回答了不下几十次。很多人刚开始接触 flink table windows（Group Windows / Over Windows）时，最常犯的错就是把这两类窗口混为一谈，或者只知道 SQL 里有个TUMBLE函数就到处套。这篇笔记我想系统地把 Flink Table/SQL 的 Group Windows 和 Over Windows 讲透，从原理、API 写法、SQL 写法，到实际业务场景里的选择依据，最后附上我踩过的坑。内容主要来源于一个模拟订单统计的实时数仓项目，代码也都是实际跑过、验证过的，你可以直接照着改。

这篇东西适合两类人：一类是刚开始学 Flink SQL，写过SELECT count(*) FROM ... GROUP BY ...但还没搞清楚窗口怎么用的新手；另一类是已经上了实时数仓，却老是遇到"窗口不输出""窗口结果不对""Over 窗口太慢"这类问题的工程师。我会尽量把这些坑背后的机制也讲清楚，而不是只给个解决办法。

1. 窗口：流计算里绕不开的那道坎

先聊点基础认知。批处理面对的数据是有限的，比如一张 MySQL 表、一个 Hive 分区，数据都在那里，你怎么跑结果都是确定的。但到了流处理这里，数据是一条一条落下来的，你永远不知道下一秒还有多少条，也不知道会不会有迟到的旧数据。用一个不太严谨的说法：批处理是食堂开饭，菜全上齐了才开吃；流处理是流水线自助餐，菜一道道往外端，你还得边接菜边算账。

窗口就是来解决这个问题的。既然无法等全部数据到齐，那就按一定规则把数据流切成一块块有边界的数据集，再分别计算。Flink Table/SQL 里最常用的就是两类窗口——Group Windows和Over Windows。它们看待数据的方式很不一样：

• Group Windows（分组窗口）：固定把数据流按照时间或数量切成多个互不重叠（也可以是重叠滑动的）的数据块，然后对每个块做聚合。输出的结果是"每个窗口一个汇总值"，比如"每分钟商品销量""每小时订单 GMV"。
• Over Windows（Over 窗口）：更像 SQL 标准里的开窗函数，它以当前行为基准，向前圈出一定范围，然后在这个范围内做累加、求平均等聚合。输出结果是"每条记录后面跟一个聚合值"，比如"每个用户最近 10 笔订单累计金额""当前订单之前 1 小时内的订单总额"。

这两种窗口在实际业务里都极其常见。搞懂它们的区别，很多实时统计需求的实现路径就清楚了：要按固定时间块汇报规模，用 Group；要算移动平均、逐行累计、排名，用 Over。

1.1 流式数据的"无限"和"乱序"

这里必须把两个基本矛盾说透。

第一个矛盾是无限。一条实时订单流理论上永远不结束，你不可能"等数据全到了再算"，所以必须人为设定时间边界。比如回答"过去 5 分钟卖了多少""过去 1 小时支付金额多少"，这个"过去多久"就是窗口。

第二个矛盾是乱序。虽然业务时间戳看着是连续的，但网络抖动、上游重试、数据源并发写入，都会让事件时间戳不单调递增。我见过最典型的现象是：订单支付时间 10:14 分的数据，可能 10:17 分才进到计算引擎。如果引擎按到达顺序去切窗口，10:14 这条就会被分到 10:15~10:20 的窗口里，结果就错了。

Flink 对这两个问题的回答也很简单：用时间属性来确定业务时钟，用Watermark（水位线）来划定"数据完整性"的边界。

比如建表语句里写：

WATERMARK FOR order_ts AS order_ts - INTERVAL '5' SECOND

意思是：最多容忍 5 秒的乱序。当引擎看到一条10:15:00的事件后，它默认10:14:55以及更早的数据已经差不多到齐了，可以放心推进窗口计算了。这个容忍度直接影响窗口结果的质量和延迟——设大了，窗口结果更准但更慢；设小了，出数快但是可能漏掉晚到的数据。

1.2 三种时间属性，先确定用哪个钟表

Flink 里跟窗口直接挂钩的时间属性有三个，很多新手在建表时根本不区分，结果窗口结果跟直觉完全对不上。

在 Table API/SQL 里，如果要用 Event Time 做窗口，必须在 CREATE TABLE 语句里给时间字段声明WATERMARK。如果你只定义了一个普通TIMESTAMP(3)字段，没有声明 watermark，那它只能当普通业务字段用，不能作为窗口的时钟。

Processing Time 的验证方式是：建表时直接ts AS PROCTIME()，然后窗口按系统时间切，特点是引擎收到数据就开始算，不需要等水位线。缺点也明显——同样的代码换台机器、换个时间跑，结果完全不一样，没法做数据回溯和校准。

1.3 窗口的种类：Group 家族和 Over 家族

Flink 1.13 以后，官方文档习惯把窗口分成两类：Group Windows（窗口表值函数 + 窗口聚合）和Over Windows（Over 聚合）。

Group Windows 家族里有：

• TUMBLE：翻滚窗口，固定大小，窗口之间互不重叠。
• HOP：滑动窗口，固定大小，窗口按固定步长向前移动，可以重叠。
• SESSION：会话窗口，按数据之间的静默间隔划分，数据连续来就属于同一个窗口，超过 gap 没新数据就关闭窗口。
• CUMULATE：累计窗口，从一个起点开始，按固定步长逐步扩大窗口，直到最大窗口周期。

Over Windows 家族则主要通过ROWS BETWEEN ... AND CURRENT ROW或RANGE BETWEEN ... AND CURRENT ROW来描述范围。它在 SQL 标准里非常常见。

后面我会分别把这两类讲透，并且给你可直接跑的 SQL 和 Table API 写法。

2. Group Windows：把无限流切成有限块再聚合

Group Windows 是默认。你想要的是"每一个时间段的统计结果"，而不是"每来一条数据就更新一次累计值"，那基本就是 Group Windows。

这里用 SQL TVF 写法为主，但也会展示老的 Group Window Aggregation 写法——因为很多线上任务用的还是老写法，你在公司里翻历史任务大概率会看到。

2.1 翻滚窗口 TUMBLE：最简单也最常用

TUMBLE 的中文意思就是翻滚，窗口大小固定且不重叠。比如1 小时的翻滚窗口，数据只会落进 10:00~11:00、11:00~12:00 这样的区间，每条数据只属于一个窗口。

它的语义可以用一句话记：固定间隔切一刀，每个数据只落一个窗口。

SQL 标准写法（Flink 1.13 后推荐 TVF）：

SELECT user_id, window_start, window_end, SUM(amount) AS total_amount FROM TABLE( TUMBLE(TABLE order_tab, DESCRIPTOR(order_ts), INTERVAL '1' HOUR) ) GROUP BY user_id, window_start, window_end;

TVF 的写法里，TUMBLE(TABLE order_tab, DESCRIPTOR(order_ts), INTERVAL '1' HOUR)会生成三列隐含字段：window_start、window_end、window_time。这时候GROUP BY必须带上window_start和window_end，否则 SQL 会直接报错。很多新人都在这被卡过一次。

老的写法则是这样：

SELECT user_id, TUMBLE_START(order_ts, INTERVAL '1' HOUR) AS window_start, TUMBLE_END(order_ts, INTERVAL '1' HOUR) AS window_end, SUM(amount) AS total_amount FROM order_tab GROUP BY user_id, TUMBLE(order_ts, INTERVAL '1' HOUR);

两种写法区别不大，但 TVF 支持后续跟JOIN、TopN、Grouping Sets等更多操作，灵活性高不少。我建议新任务一律用 TVF 写法。

2.2 滑动窗口 HOP：叠加计算带来的额外成本

HOP 窗口有两个参数：滑动步长（slide）和窗口大小（size）。每过一个滑动步长，就生成一个新窗口，窗口大小固定。比如窗口大小 1 小时、滑动步长 10 分钟，那 10:00、10:10、10:20 都会生成一个长度为 1 小时的窗口，一条数据可能同时属于多个窗口。

用 SQL 写就是：

SELECT user_id, window_start, window_end, SUM(amount) AS total_amount FROM TABLE( HOP(TABLE order_tab, DESCRIPTOR(order_ts), INTERVAL '10' MINUTE, INTERVAL '1' HOUR) ) GROUP BY user_id, window_start, window_end;

注意第三个参数是滑动步长，第四个参数才是窗口大小。我见过有人把这两个参数写反的，结果统计出来的数据"半小时更新一次，窗口 10 分钟"，逻辑乱成一团。

HOP 窗口有个隐藏成本：重叠窗口意味着数据会被复制多份进入多个窗口，状态和计算量都会放大。比如窗口 1 小时、滑动 5 分钟，理论上最多有 12 个窗口同时存在，每条数据就要被处理 12 次。所以做 HOP 窗口之前一定想清楚：是不是真的需要每 5 分钟看一次过去 1 小时的数据？如果业务只是"从整点开始每 10 分钟出一次最近 1 小时累计值"，那也要接受底层计算量接近 6 倍的事实。

2.3 会话窗口 SESSION：用静默划分业务边界

SESSION 窗口很有意思，它不按固定长度切窗口，而是按没有新数据超过 gap 时间来切。比如设置 gap 为 30 分钟：用户 10:00 下单、10:10 下单、10:25 下单，这些订单在同一个会话窗口里；如果下一单是 11:20，中间空了 55 分钟，10:25 那个会话窗口就关闭，11:20 的这一单属于新窗口。

SQL 写法：

SELECT user_id, window_start, window_end, SUM(amount) AS session_gmv FROM TABLE( SESSION(TABLE order_tab, DESCRIPTOR(order_ts), INTERVAL '30' MINUTE) ) GROUP BY user_id, window_start, window_end;

会话窗口非常适合"用户一次访问/一次连续操作"这类语义：连续行为归到同一会话，长时间不活跃就断开。但我必须提醒一点：会话窗口什么时候关闭，依赖"多久没有新数据"这个判断。在事件时间语义下，Watermark 不推进，会话窗口就永远不关闭。我见过典型的例子：某个上游数据源突然停了 40 分钟，如果 gap 是 30 分钟，窗口应该关了，但因为 Watermark 没有后续数据推进，结果一直不落表。

解决思路是给查询设置table.exec.source.idle-timeout，并配合合理的 Watermark 延迟；同时在源表处尽量保证有一个低频的"心跳数据"持续发送，让 Watermark 能继续前进。

2.4 累计窗口 CUMULATE：增量汇报的好帮手

CUMULATE 是相对晚出现的窗口。它的场景很明确：你想每 10 分钟出一次"从今天 0 点开始到现在的累计值"，但这种累计不能直接用一个大的 TUMBLE 窗口做，因为那样要等一天结束才出结果。也不能用普通的 HOP，因为 HOP 的每个窗口都是独立 1 小时，不是累计。

CUMULATE 可以做到：窗口起点固定，每过一个 step 就扩展一次，最终到达最大 size。比如从 0 点开始，每 10 分钟累计一次，最大 1 天。这样 10:00 出 0~10 点的结果，10:10 出 0~10:10 的结果。

SQL：

SELECT user_id, window_start, window_end, SUM(amount) AS daily_acc_amt FROM TABLE( CUMULATE(TABLE order_tab, DESCRIPTOR(order_ts), INTERVAL '10' MINUTE, INTERVAL '1' DAY) ) GROUP BY user_id, window_start, window_end;

这个窗口在做实时大屏的"当日累计 GMV/当日累计活跃用户"时非常好用。注意它要求第一个参数 step 必须能被第二个参数 size 整除，否则会报参数检查错误。

2.5 Table API 里的 Group Windows 写法

Table API 并不常用，但如果你在用 Java/Scala 写 DataStream 与 Table 混合的程序，难免会遇到。以下以 Java 为例。

翻滚窗口：

Table result = tableEnv.from("order_tab") .window(Tumble.over(lit(1).hour()).on($("order_ts")).as("w")) .groupBy($("w"), $("user_id")) .select( $("w").start().as("window_start"), $("w").end().as("window_end"), $("user_id"), $("amount").sum().as("total_amount") );

滑动窗口：

Table result = tableEnv.from("order_tab") .window(Hop.over(lit(1).hour()).every(lit(10).minute()).on($("order_ts")).as("w")) .groupBy($("w"), $("user_id")) .select($("w").start().as("window_start"), $("w").end().as("window_end"), $("user_id"), $("amount").sum().as("total_amount"));

会话窗口：

Table result = tableEnv.from("order_tab") .window(Session.withGap(lit(30).minute()).on($("order_ts")).as("w")) .groupBy($("w"), $("user_id")) .select($("w").start().as("window_start"), $("w").end().as("window_end"), $("user_id"), $("amount").sum().as("total_amount"));

Table API 的.as("w")是把窗口别名固定下来，后面groupBy($("w"))和.select($("w").start(), ...)都会用到这个别名。这样写能跑通，但老实说，对于团队协作和可维护性，纯 SQL 更香，Table API 通常只用于需要和 DataStream API 深度集成的情况。

3. Over Windows：为每一行算一个"范围"快照

Over Windows 和 Group Windows 最大的不同在于：它是逐行计算，输出行数和输入行数一一对应。每来一条记录，它都会看你当前行"前面"的 N 行或某段时间内的所有行，然后在这个范围内执行聚合函数，结果作为当前行的新列输出。

如果你写过标准的 SQL：SUM(...) OVER (PARTITION BY ... ORDER BY ...)，那你已经写过 Over Window 了。Flink SQL 的 Over Windows 只是把它搬到流上，并绑定时间属性和 Watermark 机制。

3.1 Over 窗口的三要素

一个 Over 窗口必须明确三件事：

1. 分区（PARTITION BY）：把数据按什么维度分组。没有 PARTITION BY 就全局排序计算，流式场景下基本会出问题，所以实际几乎都要指定。
2. 排序（ORDER BY）：窗口内的数据按什么顺序排。在流上通常按时间字段排序，这样才能定义"当前行之前的范围"。
3. 范围（ROWS 或 RANGE）：往前看多少。可以是固定行数，也可以是固定时间范围，还可以是UNBOUNDED PRECEDING表示从分区开始到当前行。

用 SQL 写就是：

SELECT order_id, user_id, amount, SUM(amount) OVER ( PARTITION BY user_id ORDER BY order_ts ROWS BETWEEN 9 PRECEDING AND CURRENT ROW ) AS last_10_orders_amt FROM order_tab;

这段 SQL 的意思非常直白：对每个user_id，按照order_ts升序排列，对当前行和它之前的 9 行做SUM(amount)。这就是"每个用户最近 10 笔订单累计金额"。

3.2 ROWS 与 RANGE：按行还是按时间

这是 Over 窗口里最容易让人迷糊的地方，也是面试高频题。

ROWS 按行数圈范围。ROWS BETWEEN 9 PRECEDING AND CURRENT ROW表示当前行往前数 9 行，加上当前行一共 10 行参与聚合。它不关心时间间隔，哪怕这 10 行跨越了 7 天，也会算在一起。

RANGE 按时间范围圈数据。它要求 ORDER BY 的字段必须是时间类型，比如：

SUM(amount) OVER ( PARTITION BY user_id ORDER BY order_ts RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW )

这个聚合会把分区内、时间上落在 [当前行时间 - 1 小时, 当前行时间] 的所有行都加进去。注意：RANGE 不是"只看当前行往前 N 行"，而是看"时间窗口范围内落到分区里的所有行"。同一时间戳有多条记录时，RANGE 会把它们都纳入，所以行数可能多于直觉。

实际工作中，做"最近 N 单累计金额"用 ROWS；做"最近 N 分钟累计支付金额"用 RANGE。这个选择题我几乎每周都会碰到。

3.3 SQL 里的 Over 完整示例

在流上使用 Over 窗口时，需要注意隐含的触发条件：如果 ORDER BY 用的是 Event Time 字段，那么当且仅当 Watermark 越过某条记录的 Event Time 后，这条记录才会被实际计算并输出。这一点和 Group Windows 类似，都是为了保证排序正确性。

举两个完整例子。

按 ROWS，统计每个用户最近 5 笔订单的平均金额：

SELECT order_id, user_id, order_ts, amount, AVG(amount) OVER ( PARTITION BY user_id ORDER BY order_ts ROWS BETWEEN 5 PRECEDING AND CURRENT ROW ) AS avg_5_orders FROM order_tab;

按 RANGE，统计每个用户当前订单之前 10 分钟内的累计订单金额：

SELECT order_id, user_id, order_ts, amount, SUM(amount) OVER ( PARTITION BY user_id ORDER BY order_ts RANGE BETWEEN INTERVAL '10' MINUTE PRECEDING AND CURRENT ROW ) AS sum_10min_window FROM order_tab;

这里我再强调一个细节：如果 ORDER BY 列是TIMESTAMP(3)，RANGE 的INTERVAL '10' MINUTE会精确比较时间。如果数据里有两个相同时间戳的订单，RANGE 会把它们都算进窗口，ROWS 则只按物理顺序取行数。具体用哪个，取决于业务定义。

3.4 Table API 里的 Over 写法

Over 窗口的 Table API 写法通常长这样：

Table result = tableEnv.from("order_tab") .window(Over .partitionBy($("user_id")) .orderBy($("order_ts")) .preceding(9) .as("w")) .select( $("order_id"), $("user_id"), $("order_ts"), $("amount"), $("amount").sum().over($("w")).as("last_10_orders_amt") );

如果是时间范围，就把.preceding(9)换成.preceding(lit(1).hour())，这代表向前 1 小时。lit(1).hour()是 Table API 里构造时间间隔的标准写法。

注意，Table API 的 Over 窗口在 select 阶段是通过聚合函数.over($("w"))来使用的，不是普通聚合函数的写法，很多从 SQL 转过来的朋友会漏掉.over($("w"))那段，结果编译报错。

3.5 Group 窗口还是 Over 窗口，怎么选

这是个老生常谈的问题，但每次都很关键。我习惯用结果形态来区分：

• 如果业务报表的粒度是"分钟/小时/天的汇总值"，一行代表一个时间段，用 Group Windows。
• 如果业务需要在原始记录上"附带累计值、移动平均、排名、LAG/LEAD"，或者下游要根据当前行做决策，用 Over Windows。

举个实际例子：实时大屏要"每 5 分钟更新一次的当日 GMV"，这是 Group 的 CUMULATE 或 TUMBLE；但风控要"判断当前订单金额是否超过该用户最近 30 天平均金额的 3 倍"，这是典型 Over 窗口（向前取 30 天所有订单算AVG）。

还有一个经验：Over 窗口的状态成本通常比 Group 窗口高。尤其是UNBOUNDED PRECEDING的 RANGE 窗口，需要在状态里为每个 key 保存自分区开始以来的全部相关数据，数据量大时必须格外谨慎。

4. 实战：订单流的窗口统计一条龙

这一节我以一个模拟电商订单实时统计的场景为例，把从建表、定义 Watermark 到各类窗口计算的完整链路跑一遍。项目背景是一个"模拟订单系统"，目的是实时统计平台 GMV 和用户行为，数据源是 Kafka，Sink 先用 Print 方便验证。

4.1 建表与数据准备

先建源表。这里面最关键的是时间字段和 Watermark 声明：

CREATE TABLE source_orders ( order_id BIGINT, user_id BIGINT, product_id BIGINT, category_id BIGINT, amount DECIMAL(12, 2), order_ts TIMESTAMP(3), WATERMARK FOR order_ts AS order_ts - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'order_topic', 'properties.bootstrap.servers' = 'broker01:9092', 'properties.group.id' = 'flink_window_demo', 'format' = 'json', 'json.timestamp-format.standard' = 'ISO-8601' );

这条 DDL 里，WATERMARK FOR order_ts AS order_ts - INTERVAL '5' SECOND定义了 5 秒乱序容忍度。它意味着窗口的关闭时间会比实际窗口结束时间晚约 5 秒，换来的是对新数据更包容。

接着建一个 Print Sink 用来观察输出：

CREATE TABLE print_sink ( window_start TIMESTAMP(3), window_end TIMESTAMP(3), category_id BIGINT, total_amount DECIMAL(20, 2) ) WITH ( 'connector' = 'print' );

实际项目中 Print Sink 通常会被替换成 JDBC 或 Kafka 下游，但验证窗口逻辑时用 Print 最直观。

4.2 滚动窗口：每 5 分钟商品分类销售统计

第一个需求：统计每 5 分钟每个商品分类的销售额，用于实时监控平台交易热度。

INSERT INTO print_sink SELECT window_start, window_end, category_id, SUM(amount) AS total_amount FROM TABLE( TUMBLE(TABLE source_orders, DESCRIPTOR(order_ts), INTERVAL '5' MINUTE) ) GROUP BY window_start, window_end, category_id;

这个 SQL 里没有在源表先指定category_id的精度，所以结果默认是DECIMAL(20,2)的隐式转换，实际开发时建议在 Print Sink 里把类型写严谨。

运行后你会发现：窗口不是每条数据进来就输出，而是等到 Watermark 越过窗口结束时间后，一次性输出这个窗口的聚合结果。这正好解释了为什么 Kafka 数据源一旦不发送新数据，窗口就一直不出结果。

4.3 滑动窗口：近 1 小时 GMV 的每 10 分钟快照

第二个需求：每 10 分钟输出一次"过去 1 小时的 GMV"，用于观察持续变化趋势。

INSERT INTO print_sink SELECT window_start, window_end, SUM(amount) AS gmv FROM TABLE( HOP(TABLE source_orders, DESCRIPTOR(order_ts), INTERVAL '10' MINUTE, INTERVAL '1' HOUR) ) GROUP BY window_start, window_end;

注意这里没有category_id维度，所以 Sink 表的结构要调整，否则字段类型对不上。我实际调试过程中常犯的错就是把SELECT字段数和 Sink 字段数搞不一致，排查了十几分钟才反应过来。

HOP 窗口跑的中间过程比较有趣：同一时刻最多可能有 6 个重叠窗口，所以同一批订单会被多个窗口同时统计。如果下游需要这 6 个窗口都计算完成后才做汇总，那要注意窗口之间并不是严格同步的，它们各自由各自的 Watermark 触发。写代码时不要假设所有窗口同时出结果。

4.4 会话窗口：用户下单会话聚合

第三个需求：把用户在 30 分钟内的连续下单归为一个会话，统计每个会话的订单金额，用于分析用户购物的连贯性。

SELECT user_id, window_start, window_end, SUM(amount) AS session_gmv FROM TABLE( SESSION(TABLE source_orders, DESCRIPTOR(order_ts), INTERVAL '30' MINUTE) ) GROUP BY user_id, window_start, window_end;

这里有一个和 TUMBLE 不同的点：会话窗口的window_start不是某个固定整点，而是该会话的第一条数据或最后一条数据往回推算出来的。所以打印出来的窗口边界会五花八门：10:03:27~10:33:27、11:05:12~11:35:12。不要指望它和整点对齐。

另外，会话窗口的window_time（区间内最后一条数据的时间）在后续做会话 id 或者和维度表关联时非常有用，建议在 SELECT 里保留下来。

4.5 Over ROWS：每个用户最近 10 笔订单累计金额

第四个需求：在每一笔订单旁边标注该用户最近 10 笔订单的累计金额，用于用户价值分层。

SELECT order_id, user_id, order_ts, amount, SUM(amount) OVER ( PARTITION BY user_id ORDER BY order_ts ROWS BETWEEN 9 PRECEDING AND CURRENT ROW ) AS last_10_orders_amt FROM source_orders;

这个查询结果的行数和输入完全一样。如果用户订单不足 10 笔，则只对已有的行做累加，不会因为你只有 3 笔就返回 NULL。

在流上跑 Over ROWS 时，我特别注意了输出延迟：因为使用 Event Time，每条记录要被 Watermark 确认"它之前的记录已经全部到位"才会输出。也就是说，从业务时间戳到实际输出之间，至少会有一个 watermark 延迟窗口。对实时答数要求"秒级"的场景，这会成为一个隐藏的延迟来源。

4.6 Over RANGE：每个用户近 1 小时累计支付金额

第五个需求：每一笔订单旁边显示该用户最近 1 小时内的累计支付金额，常用于实时风控和优惠券核销。

SELECT order_id, user_id, order_ts, amount, SUM(amount) OVER ( PARTITION BY user_id ORDER BY order_ts RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW ) AS last_1h_amt FROM source_orders;

RANGE 窗口对状态的要求比 ROWS 高。因为时间范围是动态的，Flink 需要维护每个用户在当前行之前 1 小时内的所有订单状态。如果某用户订单特别密，或时间跨度长，状态就会持续增长。实际项目中我见过一个超高频用户账户，单 key 的状态能涨到几百 MB，最后要靠设置 state TTL 来做兜底。这个我在下一章细说。

5. 窗口实战避坑指南

这一部分是我个人最想分享的，都是真正在业务项目里踩过的坑，不是从文档里抄的。

5.1 窗口一直不触发怎么办

窗口不触发，是实时开发新人问得最多的问题。归根结底的原因通常是：Watermark 没有前进。

Watermark 来自源表或 Source 阶段。如果 Kafka Topic 突然没有新数据，数据源不产生新记录，Flink 默认就无法持续推进 Watermark，那么 Event Time 窗口就一直等。对于 TUMBLE 窗口来说，哪怕数据已经统计完了，只要窗口结束时间没被 Watermark 越过，它就不输出。

三个解决方案：

1. 合理设置 Watermark 策略，如order_ts - INTERVAL '5' SECOND。
2. 给查询增加table.exec.source.idle-timeout，让空闲分区不拖后腿：

SET 'table.exec.source.idle-timeout' = '5s';

这会标记空闲分片，Watermark 会忽略它们继续前进。要注意：如果这个值设得太小，在数据高峰期来回抖动可能导致 Watermark 被过早推高，丢失部分消息。

3. 在上游增加"心跳数据"。最稳妥的做法是源表周期注入一条低频心跳记录，保证 Watermark 能持续推进。我在监控类项目里就是这么干的，省的被两边同事反复质疑"窗口是不是坏了"。

5.2 时区带来的窗口边界错位

时间字段是TIMESTAMP(3)，窗口边界默认按 UTC 计算。我曾经在上海时间环境下统计"每日 GMV"，结果每天 0 点窗口的分界不是在本地 0 点，而是在早上 8 点。这就是时区偏移问题。

Flink 1.13 之后，可以通过会话参数指定本地时区：

SET 'table.local-time-zone' = 'Asia/Shanghai';

设置之后，窗口的边界计算会做本地时区转换，00:00:00的窗口就变成本地 0 点。这一点特别容易忽略，因为开发环境和生产环境如果时区配置不一致，本地测得好好的，上线就错 8 小时。

5.3 SQL 报错要求 GROUP BY 带上窗口字段

Flink 1.13 之后用 TVF 窗口时，window_start和window_end是派生列，必须在 GROUP BY 里显式出现。

报错信息长这样：

Column 'window_start' must appear in the GROUP BY clause or be used in an aggregate function

解决办法很简单：GROUP BY 后面加上window_start, window_end。如果后面还要做UNION ALL或者多级聚合，这两个字段也要一直保留下去，不然上级任务拿不到窗口维度。

5.4 状态膨胀与 Over 窗口性能优化

Over 窗口的性能瓶颈主要在状态大小和排序成本。

先说排序。ORDER BY会触发排序，通常由状态后端配合 RocksDB 落盘来做。如果某个user_id下的订单量特别大，这个分区的排序会特别慢。我的排查经验是：先看是否存在数据倾斜，用一个GROUP BY user_id, TUMBLE(...)的统计去观察单 key 数据量。如果有热点用户，考虑在PARTITION BY上增加次级维度，比如(user_id, category_id)，或者用连接键打散采样。

再说状态。RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW这种窗口，状态里会保存每个 key 在时间范围内的全部原始数据。订单频繁的用户，状态会一直膨胀。我习惯设置 state TTL：

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

这个参数对所有状态管理生效，既能避免状态无限涨，又不会影响 1 小时窗口的正常计算。生产上一定要根据窗口大小留足余量，否则可能出现"窗口还没算完，状态先被清了"的诡异现象。

5.5 迟到数据处理的核心策略

即使有 Watermark，依然会有超出容忍范围的迟到数据存在。比如 Watermark 设置ORDER_TS - 5 SECONDS，结果来了一个迟到 10 秒的数据。

处理策略分两级：

第一级：允许迟到（Allowed Lateness）。Flink 窗口聚合默认在 Watermark 越过窗口结束时间后触发计算，之后依然允许一定范围内的迟到数据更新窗口结果。SQL 里可以通过TUMBLE/...加参数？严格来说，SQL 层的窗口聚合对迟到数据的更新机制比较有限，通常依赖 Watermark 策略的重试；Table API 的window操作则可以在 DataStream API 中配合.allowedLateness(...)。所以如果你对迟到数据要求很高，建议在 DataStream API 层做。

第二级：侧输出（Side Output）。把不可接受的超迟到数据导入旁路，统一做补偿对账。这个思路在 SQL 里通过WITH和多路输出也能实现，但链路会更长。

我自己的经验是：不要在窗口聚合里无限提高ALLOWED LATE和 Watermark 容忍度，否则实时性会严重下降。更合理的方案是，给 Watermark 一个可接受的延迟（如 5~10 秒），超迟数据落旁路表，由离线任务按小时补偿合并。这样既能保证大部分实时报表按时出炉，又不丢最终数据。

聊到最后，我自己的体会是：Flink Table/SQL 的窗口设计其实已经把流式计算里 80% 的脏活、累活隐藏掉了，你只要把时间属性、Watermark、窗口类型这三个问题想清楚，90% 的实时统计需求都能靠十几行 SQL 搞定。真正拉开差距的，往往是那些文档里不会细写的东西——窗口触发机制、状态大小、时区、数据倾斜、迟到数据策略。我之前在这上面栽了很多跟头，所以希望这篇笔记能帮你少走点弯路。下次再遇到"窗口不出数，水位线不高进"这种问题，不妨先照着 5.1 节的排查思路走一遍，多半会有收获。