4. 流处理特征计算
在离线特征工程中，我们通常面对的是已经落库、边界清晰的历史数据；而流处理特征计算面对的是持续到达、可能乱序、可能迟到的事件流。要在这种环境下产出与离线口径一致、可供在线推理使用的特征，核心不在于“把批处理代码搬到流引擎”，而在于理解流处理架构、时间语义与窗口机制如何共同决定特征的正确性。
一、核心原理：流处理架构与时间语义
流处理架构通常由数据源、消息队列、计算引擎、状态存储与特征输出五部分组成。数据源产生事件，消息队列（如 Kafka）承担缓冲与解耦，计算引擎（Flink、Spark Streaming）负责有状态计算，状态后端保存中间聚合结果，最终特征写入 Feature Store 或在线存储供模型调用。
其中最关键的概念是事件时间与水位线。事件时间指事件真实发生的时间，由业务数据携带；处理时间指引擎处理该事件的系统时间。两者往往存在偏差，因为网络延迟、重试、分区消费速度不同都会导致事件乱序到达。水位线是引擎对“事件时间进展”的估计：当水位线推进到 T，表示引擎认为时间戳小于 T 的事件已基本到齐，可以触发窗口计算。
滑动窗口则定义了特征聚合的时间范围与更新频率。例如“过去 5 分钟、每 30 秒更新一次”的点击率特征，窗口长度 5 分钟，滑动步长 30 秒。窗口越长，特征越平滑但越滞后；步长越小，特征越新鲜但计算与存储压力越大。
二、方法流程：Flink 实时特征聚合的典型实现
以 Flink DataStream API 为例，实时特征聚合通常遵循“接入—提取时间—开窗—聚合—输出”的流程。下面是一个按用户统计过去 5 分钟点击次数的核心代码骨架：
DataStream<ClickEvent> stream = env
.addSource(new FlinkKafkaConsumer<>("click_topic", schema, props));
SingleOutputStreamOperator<ClickEvent> withTs = stream
.assignTimestampsAndWatermarks(
WatermarkStrategy.<ClickEvent>forBoundedOutOfOrderness(Duration.ofSeconds(5))
.withTimestampAssigner((e, ts) -> e.getEventTime())
);
SingleOutputStreamOperator<UserFeature> features = withTs
.keyBy(ClickEvent::getUserId)
.window(SlidingEventTimeWindows.of(Time.minutes(5), Time.seconds(30)))
.aggregate(new ClickCountAgg(), new FeatureWindowFunction());
features.addSink(new FeatureStoreSink());关键参数包括：forBoundedOutOfOrderness 设定允许迟到时间，SlidingEventTimeWindows 定义窗口长度与步长，aggregate 使用增量聚合减少状态压力。若业务允许迟到数据修正结果，可配合 allowedLateness 与侧输出流实现“先输出近似值，再回撤修正”。
| 机制 | 作用 | 典型参数 | 代价 |
|---|---|---|---|
| 事件时间 | 按业务发生时间计算，保证口径一致 | timestampAssigner | 需处理乱序 |
| 水位线 | 估计数据完整性，触发窗口 | outOfOrderness=5s | 延迟与完整性权衡 |
| 滑动窗口 | 定义聚合范围与更新频率 | length=5min, slide=30s | 状态与计算放大 |
| allowedLateness | 允许迟到数据更新结果 | lateness=1min | 状态保留更久 |
三、案例场景：电商实时点击率特征
某电商推荐场景需要“用户过去 5 分钟点击率”作为在线特征。数据流为曝光事件与点击事件，二者通过 requestId 关联。实现时按 userId 分组，使用滑动窗口分别统计曝光数与点击数，再计算比值写入 Feature Store。若直接使用处理时间，遇到 Kafka 分区积压时，特征会整体后移，导致线上模型看到的“过去 5 分钟”实际是“过去 8 分钟”，与离线训练口径不一致。改用水位线后，特征时间语义与离线对齐，AUC 提升约 1.2 个百分点。
四、误区与复盘
- 误区一：水位线越大越好。过大的 outOfOrderness 会显著增加延迟，且状态膨胀。应根据实际乱序分布设定，例如 P99 延迟加缓冲。
- 误区二：滑动步长越小特征越准。步长过小会导致窗口数量激增，状态与下游写入压力成倍上升，需结合 Feature Store 的写入能力评估。
- 误区三：忽略迟到数据。若不允许迟到更新，促销、秒杀等场景下特征会系统性偏低。应配置 allowedLateness 或侧输出流补偿。
- 误区四：流批特征各写一套逻辑。建议将窗口定义、聚合函数抽象为共享配置，避免线上线下口径漂移。
掌握事件时间、水位线与滑动窗口的协同机制，是构建可靠实时特征的基础。只有在时间语义正确的前提下，Flink 或 Spark Streaming 的聚合结果才能真正与离线特征对齐，并为 Feature Store 提供可信的在线特征输入。