在 Apache Flink 中，窗口机制是如何实现流数据按时间或数量进行分组处理的？请说明不同窗口类型（如滚动、滑动、会话、全局窗口）的适用场景，并阐述在何种业务需求下应如何选择窗口类型。
考察说明
考查对 Flink 窗口机制的理解以及根据业务场景选择合适窗口类型的能力。
回答思路
- 【回答框架 1】窗口是 Flink 将无限流切分为有限批次的核心机制，分为基于时间的窗口（处理时间、事件时间）和基于数量的窗口。窗口操作分为 keyed 和 non-keyed，通过 assigner 分配数据到窗口，再由 trigger 决定何时触发计算。
- 【回答框架 2】滚动窗口（Tumbling）：固定大小、无重叠，适合简单的周期统计，如每小时 PV。滑动窗口（Sliding）：固定大小但有重叠，适合需要更平滑统计且能容忍重复计算，如每 5 分钟统计最近 1 小时数据。
- 【回答框架 3】会话窗口（Session）：按不活跃间隙分组，适合用户行为分析，如连续操作超过 30 分钟无活动则视为一次会话。全局窗口（Global）：需自定义 trigger，适合需要手动控制触发条件的场景。
- 【回答框架 4】选择依据：若需精确时间对齐且不关心边界重叠，选滚动；若需反映趋势且能容忍延迟和重复，选滑动；若按活动间断分组，选会话；特殊需求用全局加自定义 trigger。同时需考虑事件时间与处理时间的选择，事件时间能处理乱序，但需 watermark 和允许延迟。
- 【回答框架 5】根据业务指标（如实时监控天级聚合、用户会话划分、周期性报表）和数据特征（是否乱序、延迟容忍度）综合选择，必要时使用 allowedLateness 控制迟到数据。
- 【关键点 1】滚动窗口无重叠，适合固定周期统计；滑动窗口有重叠，适合平滑统计。
- 【关键点 2】会话窗口基于不活跃间隔划分，适合用户行为分析；全局窗口需自定义触发。
- 【关键点 3】事件时间窗口需配合 watermark 处理乱序；处理时间窗口简单但无法保证准确性。
- 【关键点 4】选择窗口需结合业务需求和数据特征，并考虑延迟容忍度和计算开销。
- 【易错点 1】误将处理时间窗口用于事件时间场景，导致乱序数据统计不准确。
- 【易错点 2】忽略数据迟到问题，应设置 allowedLateness 或使用侧输出。
- 【易错点 3】过度使用滑动窗口导致计算重叠和资源浪费，需权衡窗口大小和滑动步长。