考察点
这道题出自京东大数据开发一面，是两个小问的组合：先枚举算子体系，再深入窗口。面试官想确认你有真实的 Flink 开发手感——算子能按功能归类讲而不是零散背诵，窗口能讲清四种窗口类型的语义差别和适用场景，最好带出 keyBy 与窗口的关系、事件时间触发这些细节。追问常往"滑动窗口的状态膨胀问题"、"会话窗口在日志分析里怎么用"、"process function 能做什么"走。
参考答案
算子按功能分类
Flink DataStream 的算子可以分五类来记。
转换类：map（一进一出）、flatMap（一进零到多出，解析 JSON、拆分行常用）、filter。这三个是最基础的无状态转换。
KeyBy：逻辑上按 key 把流分区，是所有 keyed 聚合和窗口的前提。要点：keyBy 本身不产生物理算子，它是一次 hash 重分区（网络 shuffle）；key 选得不好（高基数字段或倾斜 key）直接决定后面所有算子的命运。
聚合类：reduce、sum/min/max、aggregate，以及更通用的 KeyedProcessFunction。这些是滚动聚合——每来一条更新一次结果流，不是窗口。注意 reduce 要求输入输出同类型，aggregate 可以不同类型（增量累加器模式）。
窗口类：window() + 各种 WindowFunction，这是第二个问题的重点，下面展开。
底层通用类：process / KeyedProcessFunction，能访问定时器（event time 和 processing time 两种 timer）、状态、侧输出，是所有高级算子的基石——窗口、聚合底层都是它实现的。遇到现成算子表达不了的逻辑（复杂超时控制、多条件分流）就下钻到 process function。
另外还有关联类算子值得一提：union（多流合并，类型需一致）、connect（双流连接，类型可不同，配合 CoProcessFunction 做规则引擎）、join/coGroup（窗口内双流 join）、interval join（事件时间区间 join，风控场景常用）。
窗口的四种类型
滚动窗口（Tumbling Window）：固定长度、不重叠、首尾相接。window(TumblingEventTimeWindows.of(Time.minutes(5)))，每条数据属于且只属于一个窗口。典型场景：每 5 分钟的订单量统计。资源最省，一个时刻每个 key 只有一个活跃窗口。
滑动窗口（Sliding Window）：固定窗口长度 + 滑动步长，步长小于窗口长度时窗口重叠，一条数据属于多个窗口。SlidingEventTimeWindows.of(Time.hours(1), Time.minutes(5))：每小时的数据，每 5 分钟更新一次——"最近 1 小时 GMV"大屏指标的标准写法。代价要说清：一条数据被复制到窗口长度/步长个窗口里（这个例子是 12 个），状态和计算量同倍数膨胀，步长越小越贵。
会话窗口（Session Window）：没有固定长度，以活动间隙（gap）切分。EventTimeSessionWindows.withGap(Time.minutes(30))：同一用户 30 分钟内有新事件就延续会话，超过 30 分钟静默则窗口关闭。典型场景是用户行为 session 分析——一次"逛 App"的行为聚合。特点：窗口长度不定、触发时间不定，且窗口会 merge（两个会话因新数据连成一片时合并），实现上比前两种复杂。
全局窗口（Global Window）：不自动切分，所有数据进同一个窗口，触发时机完全由自定义 Trigger 控制。GlobalWindows + 自定义 trigger 可以实现"每满 1000 条触发一次"、"计数和时间混合触发"这类非标需求。一般配合自定义 trigger 和 evictor 使用，用不好状态会无限增长，要手动 purge。
窗口计算的两个层次
分配窗口之后是计算函数，分两档。增量聚合：ReduceFunction、AggregateFunction，来一条算一条，窗口状态只有一个累加器，内存 O(1)，性能最好，能用就用。全量窗口：ProcessWindowFunction，把窗口内所有数据攒着，触发时一次性给你迭代器，能做排序、取 topN 这类需要全量数据的逻辑，代价是状态随窗口内数据量线性增长。实战技巧是两者组合：aggregate(AggregateFunction, ProcessWindowFunction)，增量聚合出结果后 Process 只拿到聚合值，可以补充窗口元信息（开始结束时间）同时保持 O(1) 状态——这是生产代码的标准写法。
触发与迟到
事件时间窗口靠 watermark 触发：watermark 越过窗口结束时间就计算。迟到的数据三层处理（watermark 容忍、allowedLateness、侧输出流）是另一个专题，但答题时要提一句窗口和 watermark 的联动，显得体系完整。另外 early firing / late firing 可以用自定义 trigger 做：比如窗口没到结束时间但每满 1 分钟先吐一次中间结果，大屏类需求常用。
常见踩坑
带过两个实战点收尾。一是 keyBy + 窗口的状态是按 (key, window) 存的，高基数 key（比如 user_id 亿级）加滑动窗口会让状态爆炸，必须配 TTL 或先预聚合。二是 windowAll（不 keyBy 的全局窗口）并行度是 1，全量数据挤一个 task，大流量场景禁用——要用就先 keyBy 做局部窗口再二次汇总。
可能的追问
- 滚动聚合（sum）和滚动窗口加 sum 有什么区别？前者每条输入都产出一个累计结果，是持续更新的流；后者窗口触发才产出一次。看下游要"实时跳动"还是"周期快照"。
- 会话窗口的 merge 是怎么回事？初始每个事件自成一个候选窗口，gap 内出现新事件把相邻窗口连起来时触发窗口合并，已注册的状态和定时器一起迁移，实现成本高但语义正确。
- 窗口状态怎么清理？窗口触发后默认清理（purging），allowedLateness 会推迟清理；超过容忍期的靠 state TTL 兜底，防止异常场景状态泄漏。