想象你是一家餐厅的大厨。一位客人刚坐下就追问：“我们的菜还要等多久？”你扫一眼传菜台，最新三张小票都是同一道慢炖菜，脑中立刻算出“还需 12 分钟”，脱口而出。如果等打烊后再翻账本统计平均上菜时间，那位客人早就饿跑了。流式特征计算与服务，就是给数据世界装上这种“边接单边心算”的实时直觉。 现实世界的数据像流水一样不停涌来：每次点击、每笔交易、每条日志。流式特征能在这条水流经过的瞬间提炼出它的浓度与趋势——比如“最近 5 分钟该用户的点击次数”“这台服务器当前的错误率”，然后在毫秒级把计算结果服务给下游模型。这篇文章会拆开这套系统的七个关键部件：实时特征究竟是什么、时间窗口怎么切分、状态怎么记忆与恢复、低延迟链路如何搭建、离线在线怎么保持一致、特征如何被秒级查询、批与流如何走向统一。读完你会发现，它们拼起来正是那座“实时后厨”的完整图纸。

岗位关联

实时特征能力是 AI 从“小时级看报表”跃迁到“毫秒级做决策”的临门一脚。掌握它，你的模型才能在大促抢购、交易风控、故障告警等场景里做出立刻反应，而不是隔天才知道发生了什么。

目录
  1. 可视化演示
  2. 流式特征概念
  3. 时间窗口计算
  4. 状态管理机制
  5. 低延迟架构
  6. 特征一致性
  7. 实时特征服务
  8. 流批一体实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

事件流 （乱序到达） Watermark 低延迟服务 (Redis/KV Store) 流式特征计算的窗口模型与水位线机制，展示实时事件处理、窗口聚合和低延迟服务架构 流式特征计算的窗口模型与水位线机制，展示实时事件处理、窗口聚合和低延迟服务架构

流式特征概念

一家传统餐厅的老板习惯打烊后盘点：今天卖了多少菜、哪种食材剩多少。这些统计当然有用，可第二天开门时，它只能告诉你“昨天”发生了什么。真正让餐厅在当下赚钱的，是后厨大厨那种随时扫一眼出餐口就知道“这锅汤还要炖多久、晚高峰翻台率撑不撑得住”的实时直觉。流式特征，就是给数据世界装上的这种直觉。

在传统特征工程里，特征是“攒一批、算一批、存一批”的批处理模式：数据先进数据仓库，定时任务跑完，特征表才更新，延迟通常是小时甚至天级。流式特征正好反过来：数据一到达，就在极短时间内完成计算，结果立刻可用。打个比方，批处理是“打烊后查账本”，流式特征是“边接单边心算”。流式特征的来源也随处皆是：埋点日志、交易流水、传感器信号、服务器指标，它们共同的特点是持续产生、对延迟敏感、价值随时间快速衰减。

一个流式特征通常长这样：最近 5 分钟的成交金额、当前在线人数、某用户最近一次点击距今多少秒。它有两大性质：一是增量更新，新数据到了只改部分结果，不全局重算；二是实时可查，算完立刻写入在线特征存储，供下游模型毫秒级查询。典型形态是对一段连续数据做聚合，例如滑动平均：

就像大厨不翻旧账、只扫一眼出餐口的小票流就给出判断，流式特征的核心思想正是把“结果”从昨天搬到当下——让每一次决策都用上最新鲜的数据。

xˉt=1W∑i=0W−1xt−i\displaystyle \bar{x}_t = \frac{1}{W}\sum_{i=0}^{W-1} x_{t-i}
这个公式用大白话说：把最近 \(W\) 个数据相加，再除以 \(W\)，得到当前时刻的平滑估计值。
  1. 窗口大小 \(W\)指定要回顾多少个最近的数据点，\(W\) 越大结果越平滑、反应越迟钝。
    WW
  2. 累加求和把从 \(t-W+1\) 到 \(t\) 共 \(W\) 个数据逐一加起来，体现“把一段数据收拢成一团”。
    ∑i=0W−1xt−i\sum_{i=0}^{W-1} x_{t-i}
  3. 取平均用累加结果除以窗口大小，得到这一段的平均水平，避免数据量不同导致数值不可比。
    1W⋅∑i=0W−1xt−i\frac{1}{W} \cdot \sum_{i=0}^{W-1} x_{t-i}

时间窗口计算

厨房里有三种计时器。滚动窗口像“每五分钟响一次”的闹钟：铃一响，上一锅统计作废，重新开始计；滑动窗口像大厨手上的秒表：每隔 30 秒低头看一眼“最近 5 分钟的翻台速度”，相邻两次观察时段是重叠的；会话窗口则像一桌客人从落座到结账的完整用餐过程，中间超过 15 分钟没人点菜，就默认“这桌散了”。三种计时器，决定了“哪些数据算一波”。

实时计算里，“窗口”定义了数据集的边界。没有窗口，数据只是一串离散的点；有了窗口，才能从离散中看出趋势和规律。选择哪种窗口，本质是在平衡“新鲜度”和“稳定性”：窗口越小越灵敏，窗口越大越抗噪。

三种窗口各司其职。滚动窗口按固定时间或固定条数对齐，窗口间互不重叠，适合做每分钟库存量、每 5 分钟错误数这类周期性统计。滑动窗口按固定步长移动，步长小于窗口大小时会产生重叠，适合做持续更新的实时均值——推荐系统里“最近 30 分钟点击热度”就是典型。会话窗口按事件之间的空闲间隔动态切分，适合用户行为序列，比如把一次购物旅程从“加购→下单→支付”归成一个会话。窗口何时触发计算由触发器决定：水位线推进、事件累积数达标、或处理时钟走到边界，都会触发一次窗口结果的下发。

厨房的计时器决定了“哪些菜算一波”，窗口就是数据世界的分波器。选对了窗口，实时特征才能既跟得上节奏、又不被杂音带偏。

wint=⌊t−t0W⌋\displaystyle \mathrm{win}_t = \left\lfloor \frac{t - t_0}{W} \right\rfloor
这条式子计算某个事件落在第几个滚动窗口里，就像问“现在属于今天第几个 5 分钟”。
  1. 事件时刻 \(t\) 与起点 \(t_0\)先算出当前事件距离系统起点过了多久，这是定位窗口的坐标。
    t−t0t - t_0
  2. 除以窗口宽度 \(W\)把时长切成等长的段，看它跨越了几个窗口宽度。
    t−t0W\frac{t - t_0}{W}
  3. 向下取整 \(\lfloor \cdot \rfloor\)取整数部分作为窗口编号，保证同一段内的所有事件归属同一个窗口。
    ⌊t−t0W⌋\left\lfloor \frac{t - t_0}{W} \right\rfloor

状态管理机制

大厨手边总有一块备忘板：“三号桌已上两道凉菜”“这锅卤水已炖 40 分钟”。如果每来一道新菜都从头统计一遍，厨房早就乱了套。流式计算同样必须“记住”跨事件的关键中间量——这份记忆，就是状态。

计算可以分成两类。无状态计算只依赖当前到达的数据，比如把一条日志做格式转换；有状态计算则依赖历史信息，比如滑动平均值、用户累计点击数、会话累计金额。有状态计算是流式特征的主力，因为它天然描述“到目前为止发生了什么”。

有了状态，就有一连串工程问题要解决。状态存在哪？常见后端包括内存状态表、本地嵌入式数据库（如 RocksDB）、远端存储（如 Redis）。故障了怎么办？引擎定期把状态快照（checkpoint）写入分布式文件系统，同时保留输入日志，重启后从最近快照恢复、再重放中间事件。状态会不会撑爆内存？必须为状态设置过期时间（TTL）和清理策略，就像备忘板写满了必须擦掉，否则运行几天内存就会爆炸。一条 EWMA 递推式，恰好演示了“只记住一个数”的有状态计算：

备忘板的记忆会随时间冲淡，EWMA 的衰减系数就像“用新笔记覆盖旧笔记”的力度。状态管理做得好，流式计算才能长跑不崩、故障不丢。

St=α⋅xt+(1−α)⋅St−1\displaystyle S_t = \alpha \cdot x_t + (1-\alpha) \cdot S_{t-1}
用刚才的公式，新的平滑值 = 当前数据占一份权重 + 历史记忆占一份权重，历史越久远记忆越淡。
  1. 当前输入 \(x_t\)新到达的数据点，它携带最新信息，是状态更新的动力来源。
    xtx_t
  2. 上一时刻状态 \(S_{t-1}\)这就是“备忘板上的旧笔记”，浓缩了截至上一刻的全部历史信息。
    St−1S_{t-1}
  3. 加权融合\(\alpha\) 控制新信息权重，\((1-\alpha)\) 控制旧记忆权重；\(\alpha\) 越大越跟着最新数据走，越小越平滑。
    α⋅xt+(1−α)⋅St−1\alpha \cdot x_t + (1-\alpha) \cdot S_{t-1}

低延迟架构

餐厅能做到“点单一分钟进后厨”，靠的不是某个大厨手脚快，而是一整套事件驱动通道：扫码、小票机打印、厨师台亮灯，消息像接力棒一样往前传。流式计算要做到毫秒级，同样不能靠单机算得快，而是要靠架构把延迟从源头压下来。

低延迟的四个关键词是：事件驱动、流处理引擎、流水线优化、弹性调度。事件驱动模型让计算节点不再轮询等待——数据一到达立刻触发处理，省掉大量空转时间。流处理引擎（如 Flink、Kafka Streams）承担分布式调度和状态管理，把任务拆到多台机器并行。流水线优化则包括：减少序列化开销、本地状态缓存、算子链合并，以及用反压机制在“上游生产过快、下游消费不及”时自动减速，防止数据积压失控。资源弹性调度让集群在流量高峰时自动扩容、低谷时缩容，既保延迟又省钱。

在处理乱序事件时，引擎需要一个“进度标尺”来决定窗口到底等多久，这就是水位线（Watermark）：

水位线就像高峰时段后厨对“实际上菜完成时间”的保守估计：既不等所有菜都上齐（等不起），也不一看到小票就宣布结束（会漏单）。低延迟架构的精髓，就是在“快”与“准”之间找到那条平衡线。

Wt=max⁡(Wt−1, tevent)−Δ\displaystyle W_t = \max(W_{t-1},\ t_{event}) - \Delta
水位线估算“早于某个时刻的事件基本到齐了”，然后放心地关闭对应窗口，而不是无限期等下去。
  1. 最新事件时间 \(t_{event}\)取当前已经看到的、事件时间戳最大的那条数据，代表数据流推进到了哪里。
    teventt_{event}
  2. 取历史最大值与上一轮水位比较取较大者，保证水位单调不减，不会倒退。
    max⁡(Wt−1, tevent)\max(W_{t-1},\ t_{event})
  3. 减去迟到容忍度 \(\Delta\)留出余量，允许乱序事件在 \(\Delta\) 时间内迟到而不错过窗口计算。
    max⁡(Wt−1, tevent)−Δ\max(W_{t-1},\ t_{event}) - \Delta

特征一致性

顾客照着菜单点“微辣”，端上来却是“特辣”，下次就不来了。离线训练用的是批处理特征，在线推理用的是流式特征，两个口径必须一致——否则模型在线上遇到跟训练时分布完全不同的特征，效果会直接崩掉。这就是特征一致性问题的来源。

现实里不一致的坑非常多：离线按“支付完成时间”统计，在线按“事件到达时间”统计，对不上；离线用 24 小时窗口，在线滑窗只算了最近 10 分钟；离线缺失值填 0，在线缺失值用前值填充。任何一处口径偏差，都会让模型输入分布悄悄漂移。

业界常用的四道防线是：第一，同源同算——离线和在线链路复用同一份计算逻辑代码和参数，从根上消除实现差异；第二，特征监控——定期对比在线与离线特征的均值、方差等统计量，检测分布漂移；第三，质量校验——对具体特征值做合理性检查，比如数值是否超界、缺失率是否突增；第四，回退兜底——当在线特征偏离阈值或质量校验失败时，自动回退到备用特征或离线缓存值，宁可“旧一点”也不给模型喂脏数据。衡量偏差大小，常用相对偏差公式：

菜单要定期对菜，后厨才能不跑偏。离线在线一致性不是一次性的活，而是每时每刻的校准与守卫——模型吃到的特征，必须永远和训练时一个味道。

dev=∣Fonline−Foffline∣max⁡(∣Foffline∣, ϵ)\displaystyle \mathrm{dev} = \frac{|F_{online} - F_{offline}|}{\max(|F_{offline}|,\ \epsilon)}
相对偏差把在线和离线两个特征值之间的差距，除以离线值的绝对值做归一化，得到一个可设阈值的无量纲分数。
  1. 特征偏差 \(F_{online} - F_{offline}\)先看在线算出的特征和离线算出的特征差了多少。
    Fonline−FofflineF_{online} - F_{offline}
  2. 取绝对值 \(| \cdot |\)偏差方向不重要，偏离幅度才重要，所以取绝对值。
    ∣Fonline−Foffline∣|F_{online} - F_{offline}|
  3. 按离线值归一化除以离线特征绝对值（加小量 \(\epsilon\) 防止除零），消除量纲影响，让不同特征之间可比。
    ∣Fonline−Foffline∣max⁡(∣Foffline∣, ϵ)\frac{|F_{online} - F_{offline}|}{\max(|F_{offline}|,\ \epsilon)}

实时特征服务

顾客问“还要等多久”，服务员不是当场翻账本，而是直接报出数字。因为前台放着一张“等位时长速查表”，每 30 秒更新一次。实时特征服务就是这个速查表：特征算完只是第一步，能被毫秒级查到才是真正起作用。

实时特征服务的核心是“写一次、读百万次”：特征值由流式计算持续更新，而下游的推荐、风控、搜索服务以极高的并发读取。如果每次请求都去现场算一遍特征，延迟和计算成本都无法承受。所以业界把特征预计算好，存进专门的在线特征存储。

在线特征存储通常采用键值（KV）模型：key 是用户 ID、物品 ID 或它们的组合，value 是对应的特征向量或特征字段，底层由 Redis、HBase 或内存表承载。高并发场景下再加两层缓存：本地进程内缓存管热点，分布式缓存管共享，把高频特征就近放在离应用最近的地方。特征路由则用一致性哈希把不同的 key 分片到不同节点，避免某个热点 key 把单机打爆。特征的更新采用“新值覆盖旧值”的版本控制，保证查询端永远读到完整一致的最新特征。缓存效果用一个指标衡量：

服务员记性越好，顾客等答案的时间越短。实时特征服务就是把“算得快”变成“查得快”，让模型在每一毫秒都能拿到最新鲜的判断依据。

H=NhitNhit+Nmiss\displaystyle H = \frac{N_{hit}}{N_{hit} + N_{miss}}
命中率 = 缓存直接命中的次数 ÷ 总查询次数。它越高，说明越多的请求不需要穿透到后端存储，延迟就越低。
  1. 命中次数 \(N_{hit}\)请求在缓存里直接找到特征值的次数，这是最快路径。
    NhitN_{hit}
  2. 总查询次数 \(N_{hit} + N_{miss}\)命中的加上没命中的，才是用户真正发起的全部请求。
    Nhit+NmissN_{hit} + N_{miss}
  3. 求比值 \(H\)命中占比越高，平均查询延迟越低，后端存储压力也越小。
    NhitNhit+Nmiss\frac{N_{hit}}{N_{hit} + N_{miss}}

流批一体实践

大餐厅通常有两套厨政：中央厨房批量备菜的“批”，和现炒现上的“流”。如果两套体系各用各的菜谱，标准就会打架：中央厨房的卤蛋是咸的，现炒档口的卤蛋是甜的，顾客吃一次就记住了。流批一体，就是让两套体系共用同一份菜谱。

早期的流批分离确实吃过这个亏：离线一条代码算特征，实时又写一套，两套逻辑维护成本翻倍，结果还经常对不上。于是业界演化出两种整合思路。Lambda 架构保留两条链路——批处理保证全量准确，流处理保证实时新鲜，最终把两路结果合并输出。Kappa 架构则更进一步：只用一套流引擎，历史数据也当作“流”重新灌入引擎回放计算，需要修 Bug 或加指标时，从源头重放一遍即可，不再维护两套代码。

工程实践上，流批同源是共同底线：同一份数据进入同一个处理框架，离线抽样计算和在线流式计算共享同一套算子逻辑与参数配置。版本管理也随之升级：特征版本号、计算逻辑版本号、模型版本号三者绑定，一旦发现新版本特征有问题，可以整条链路一键回滚。两条链路的输出最终要融合，一个简单的加权模型如下：

好的厨房，让中央厨房和现炒档口用同一本菜谱、同一套验收标准。流批一体不只是架构选型，更是对“一份数据、一种口径、一个版本”的坚持。

Ffinal=λ⋅Fbatch+(1−λ)⋅Fstream\displaystyle F_{final} = \lambda \cdot F_{batch} + (1-\lambda) \cdot F_{stream}
最终特征 = 批结果的权重 + 流结果的权重，\(\lambda\) 决定你更相信“大盘准确”还是“即时新鲜”。
  1. 批结果 \(F_{batch}\)全量离线计算出的特征，准确但更新慢，适合做长期基准。
    FbatchF_{batch}
  2. 流结果 \(F_{stream}\)实时增量计算出的特征，新鲜但可能受窗口和延迟影响，适合做短期波动感知。
    FstreamF_{stream}
  3. 加权求和\(\lambda\) 从 0 到 1 调节信任比例；极端时等于只用批或只用流，一般取中间值让两者互补。
    λ⋅Fbatch+(1−λ)⋅Fstream\lambda \cdot F_{batch} + (1-\lambda) \cdot F_{stream}

AI 应用场景

实时风控反欺诈

阶段：特征工程与在线推理

解决的问题：传统风控用离线特征做判断，欺诈行为从发生到被识别往往滞后几小时，资金早已转移。流式特征把“该设备最近 5 分钟失败登录次数”“当前交易偏离该用户历史行为模式的程度”等特征实时算出来，让风控模型在每笔交易的几十毫秒内就能给出风险评分。

具体案例：某支付平台接入流式计算后，同一张银行卡在异地短时间连续出现多笔大额消费，实时特征在第二笔交易时就拉高了风险分，直接触发短信验证和人工复核，拦截了一起盗刷事件。

个性化推荐实时兴趣

阶段：实时特征服务

解决的问题：用户刷信息流时，兴趣变化极快——刚看完三条火锅视频，下一条再推烧烤就有点晚了。传统批处理特征按天更新，无法捕捉这种短时兴趣漂移。流式特征以秒级窗口聚合“最近 10 分钟该用户点击内容的主题分布”，并写入在线特征存储供推荐服务实时读取。

具体案例：某短视频 App 用滑动窗口统计用户最近 20 次点击的主题占比，一旦“美食”类目占比超过阈值，推荐列表立刻向该方向倾斜，用户平均观看时长提升了 9%。

智能运维监控告警

阶段：流式特征计算

解决的问题：传统监控用静态阈值，流量突增或慢查询异常要靠人工盯 DashBoard。流式特征把“最近 10 分钟错误率均值”“错误率变化斜率”“当前 QPS 与过去 1 小时基线的偏差”实时算出来，交给异常检测模型自动判断是否告警，并附带可解释的特征快照。

具体案例：某电商大促期间，核心订单服务的错误率斜率在 30 秒内连续越界，监控系统提前 8 分钟发出告警，运维团队在用户可感知前完成了扩容，避免了 P0 事故。

Python 演示

python46 行
from collections import deque  class SlidingWindowFeature:    """滑动窗口流式特征器：同时产出窗口均值与 EWMA 平滑值。"""     def __init__(self, window_size=5, alpha=0.3):        self.window = deque(maxlen=window_size)        self.window_sum = 0        self.ewma_value = None        self.alpha = alpha        self.event_count = 0     def update(self, x):        if len(self.window) == self.window.maxlen:            self.window_sum -= self.window[0]        self.window.append(x)        self.window_sum += x        self.event_count += 1        if self.ewma_value is None:            self.ewma_value = x        else:            self.ewma_value = self.alpha * x + (1 - self.alpha) * self.ewma_value     def window_mean(self):        if not self.window:            return 0.0        return self.window_sum / len(self.window)     def snapshot(self):        return {            "window_mean": self.window_mean(),            "ewma": self.ewma_value,            "events": self.event_count,        }  def main():    sf = SlidingWindowFeature(window_size=5, alpha=0.3)    for x in [10, 12, 9, 14, 11, 13, 15, 12]:        sf.update(x)        print(f"输入 {x:>4} -> {sf.snapshot()}")  if __name__ == "__main__":    main()
目的：模拟一条实时数据流，逐个喂入特征计算器，实时输出“最近 5 个数据的滑动均值”和“带记忆衰减的 EWMA 平滑值”。
  1. self.window = deque(maxlen=window_size)用双端队列做滑动窗口，容量满时自动挤出最老的数据。
  2. self.window_sum = 0维护窗口内总和，新增数据时不必重新求和，做到真正的增量更新。
  3. self.ewma_value = self.alpha * x + (1 - self.alpha) * self.ewma_value这就是正文里的 EWMA 递推：一个变量记住全部历史。
  4. sf.update(x)每条新数据到达时调用一次，模拟流式引擎的“事件到来即触发”。
  5. sf.snapshot()随时取当前特征快照，对应在线特征存储里“随时可查”的上游产出。

常见误区

误区我以为流式特征引擎会对每一条到达的数据都立刻跑一遍完整计算，所以数据量一大肯定撑不住，流式特征只能用在数据量很小的场景。

正解流式计算是“事件触发 + 窗口聚合”的组合。数据确实会触发引擎执行，但绝大多数计算是按窗口攒到一定程度才算一次，比如滑动窗口每 30 秒算一次最近 5 分钟的均值，而不是每毫秒都算。真正每条数据都算的只有少数轻量算子。

为何常见：看到“实时”“流式”这些词，直觉上就会以为是“每条都算”，忽略了窗口聚合这个缓冲层。

误区我以为数据上的时间戳就是它被计算引擎处理的那一刻的时间，所以排错时对着处理日志对不上事件时间，怎么都想不明白。

正解事件时间是业务真实发生的时刻，处理时间是数据抵达引擎的时刻。网络传输、队列堆积、重试都会让处理时间远晚于事件时间。流式引擎才需要 watermark 机制来兜住乱序迟到数据。

为何常见：在本地小数据量测试时两者几乎一致，初学者很容易把这两个概念混为一谈。

误区我以为流式任务只要重启，之前累计的用户点击数、会话金额全都会清零，所以每次发布都要担心线上特征归零导致模型行为突变。

正解生产级流引擎会定期把状态做 checkpoint 快照存入分布式存储，重启后从最近快照恢复，再重放中间日志，状态可以精确续上。真正该担心的是 checkpoint 频率没配好、或者恢复期间读到了半新半旧的特征。

为何常见：没接触过状态后端和容错机制的人，容易用单机进程的内存直觉去推断分布式流计算。

误区我以为只要离线训练和在线推理用的是同一个特征计算函数，结果就一定一模一样，所以从没监控过两边特征的分布差异。

正解代码一致只是必要条件，不是充分条件。两边读到的数据可能不同（离线有全量历史、在线只有实时窗口）、时间基准可能不同（业务时间 vs 到达时间）、缺失值填充路径不同，都会造成偏差。必须靠分布监控和质量校验持续盯住。

为何常见：人容易相信“相同的代码 = 相同的结果”，忽略了数据环境本身的差异。

误区我以为实时特征服务的缓存命中率冲到 99% 就是完美状态，于是把特征 TTL 设得非常长，结果模型效果悄悄变差。

正解命中率过高可能恰恰说明特征长期不更新、新鲜度严重不足。实时特征是有时效性的，缓存策略要在命中率和新鲜度之间取平衡：热点特征给几秒 TTL，冷门特征可以长缓存，而不是一味追求命中率数字。

为何常见：缓存命中率是个非常直观的“好指标”，容易让人忽略它背后牺牲掉的时效性。

面试题

Q1. 流式特征和批处理特征的核心区别是什么？

单选题 · easy

  • A.流式特征只用实时数据源，不包含任何历史信息
  • B.数据到达即增量更新特征值，不等待批量落地← 正确答案
  • C.流式计算不需要统一的时间语义做数据对齐
  • D.所有特征都必须改用实时计算，批处理已过时

答案：B。区别在于计算时机：流式特征按到达顺序增量更新，批处理等数据攒齐再统一算。A 错在流式也依赖历史状态（如 EWMA）；C 错在流式恰恰依赖事件时间对齐；D 错在批处理仍有准确性和成本优势，两者是互补关系。

Q2. 关于滚动窗口和滑动窗口，下列说法正确的是？

单选题 · mid

  • A.滚动窗口各窗口之间互相重叠
  • B.滑动窗口固定步长滑移且窗口可重叠← 正确答案
  • C.滚动窗口与滑动窗口的机制完全相同
  • D.滑动窗口周期固定且窗口互不重叠

答案：B。滚动窗口按固定周期切分，窗口之间无重叠；滑动窗口按固定步长移动，步长小于窗口大小时产生重叠。A 把滚动窗口说成重叠，错；C 混淆两种窗口；D 描述的是滚动窗口的特征，张冠李戴。

Q3. 关于事件时间和处理时间，以下理解正确的有？

多选题 · mid

  • A.事件时间是数据对应行为实际发生的时刻← 正确答案
  • B.处理时间是流式计算引擎当前时钟的时刻← 正确答案
  • C.事件时间一定晚于处理时间
  • D.事件时间和处理时间通常完全等价

答案：AB。事件时间是业务真实发生时刻，处理时间是引擎处理它的时刻。网络传输和队列排队会让处理时间晚于事件时间，所以 C 说反了，D 说“完全等价”也不对。理解二者差异，是掌握 watermark 和窗口触发的前提。

Q4. Watermark（水位线）在流式计算中的作用是什么？

单选题 · mid

  • A.对窗口状态做加密保护的密钥
  • B.标记事件时间进度并决定何时安全触发窗口← 正确答案
  • C.限制批处理任务吞吐量的阈值参数
  • D.完全取代事件时间作为唯一时间基准

答案：B。水位线表示“早于该时间戳的事件基本到齐”，当它越过窗口结束时间，引擎就可以安全关闭窗口并计算结果。它不是密钥、不是批处理参数、也不取代事件时间，而是“等待多久才动手”的决策依据。

Q5. 指数加权移动平均（EWMA）的主要特点是？

单选题 · easy

  • A.对所有历史数据赋予完全相同的权重
  • B.越靠近当前时刻的数据权重越大← 正确答案
  • C.只依赖当前一个数据点，不保留历史记忆
  • D.必须保存窗口内全部原始数据才能计算

答案：B。EWMA 用 \(S_t = \alpha x_t + (1-\alpha)S_{t-1}\) 递推，只需记住上一个平滑值，就能让近期数据权重更大并保留衰减的历史记忆。A 是滑动平均的等权特征；C 丢掉历史记忆；D 是滑动窗口的存储方式，EWMA 不需要。

Q6. 有状态流式计算故障恢复通常依赖什么机制？

单选题 · mid

  • A.从源头重放全部历史输入并重建状态
  • B.定期检查点快照加日志重放的组合恢复← 正确答案
  • C.只能由人工介入手工重建全部状态
  • D.重启后默认丢弃状态并重新初始化

答案：B。生产引擎定期把状态做 checkpoint 快照，故障后从最近快照恢复，再重放少量中间事件即可续上状态。A 全量重放代价太大；C 违背自动化容错目标；D 会丢失状态导致结果突变。

Q7. 下列哪些手段有助于保障离线在线特征一致性？

多选题 · hard

  • A.离线和在线复用同一套计算逻辑与参数← 正确答案
  • B.对在线特征分布设置监控告警和漂移检测← 正确答案
  • C.在线特征完全不参考离线特征的计算口径
  • D.特征质量异常时自动回退到备用特征兜底← 正确答案

答案：ABD。一致性靠“同源同算 + 监控 + 兜底”三件套。A 从根上消除实现差异；B 发现漂移；D 防止脏特征上线。C 反而让离线和在线彻底脱节，不是保障手段。

Q8. 在线特征存储通常采用什么架构来支撑高并发低延迟查询？

单选题 · mid

  • A.键值在线存储加本地与分布式缓存分层← 正确答案
  • B.把特征全量存放在 HDFS 大文件中扫描读取
  • C.每次查询实时调用流式计算现场算全部特征
  • D.只依赖 MySQL 单表做全表扫描过滤

答案：A。在线特征服务用 KV 存储（Redis/HBase/内存表）做底座，配合本地缓存和分布式缓存把热点特征就近存放，命中后延迟可降到毫秒级。全量扫描、现场现算、单表扫库都扛不住高并发。

Q9. 关于 Kappa 架构，下列说法正确的是？

单选题 · easy

  • A.Kappa 架构只使用批处理链路完成全部计算
  • B.Kappa 架构用一套流引擎统一处理实时和重放← 正确答案
  • C.Kappa 架构必须同时维护批流两套代码逻辑
  • D.Kappa 和 Lambda 两种架构在本质上完全相同

答案：B。Kappa 的核心是用同一套流引擎处理所有数据：实时数据直接算，历史重算就从头流式回放，避免维护两套代码。A 说的是批处理；C 是流批分离的痛点；D 混淆了 Kappa 与 Lambda。

Q10. 关于会话窗口（session window）的触发与关闭条件，正确的有？

多选题 · hard

  • A.达到固定时间长度后自动切分窗口
  • B.超过设定空闲间隔没有新事件随即关闭← 正确答案
  • C.按事件累积条数达到阈值切分窗口
  • D.结合事件时间间隔判断会话是否中断← 正确答案

答案：BD。会话窗口以“事件之间超过空闲阈值”为边界，判断时基于事件时间而非处理时间，避免传输延迟造成误切。A 是滚动窗口特征；C 是计数窗口特征，都不属于会话窗口。