2. 实时监控架构：Lambda架构与Kappa架构对比

在构建实时模型漂移检测系统时，架构选型直接决定了数据处理的时效性、复杂度和运维成本。当前流处理领域主流的两种架构模式——Lambda架构与Kappa架构——分别适用于不同的业务场景。本节将从实时漂移检测的视角，对比两种架构的优劣，并明确其在流处理管线中的位置。

2.1 Lambda架构：批流分离的经典模式

Lambda架构将数据管道拆分为批处理层（Batch Layer）和流处理层（Speed Layer），通过服务层（Serving Layer）合并结果。在模型漂移检测场景中，批处理层负责历史数据的全量统计与基线计算，流处理层负责实时特征提取与异常判定。

2.2 Kappa架构：流式优先的简化方案

Kappa架构舍弃批处理层，所有数据统一通过消息队列（如Kafka）进入流处理引擎，利用日志重放（Log Replay）机制实现历史数据回溯。在漂移检测中，Kappa架构将基线计算与实时判定统一在流处理DAG中完成，大幅降低运维复杂度。

• 统一数据管道：所有数据（实时+历史）均通过Kafka Topic接入，流处理引擎通过调整offset实现“时间旅行”。
• 状态管理：利用Spark Structured Streaming的State Store或Flink的Keyed State维护窗口聚合结果，替代批处理层的中间表。
• 漂移检测流程：流处理作业同时维护“基线窗口”与“检测窗口”，通过对比两个窗口的统计量（均值、方差、分位数）判定漂移。

2.3 实时漂移检测在流处理中的位置

无论采用哪种架构，实时漂移检测在流处理管线中均处于特征工程与模型推理之间的关键环节。其典型位置如下：

1. 数据接入层：Kafka Consumer 接收模型输入特征或预测结果日志。
2. 预处理层：对原始数据进行清洗、对齐、时间戳分配。
3. 特征窗口聚合：按固定时间窗口（如5分钟、1小时）计算特征分布统计量。
4. 漂移判定层：将当前窗口统计量与基线阈值对比，输出漂移评分与告警事件。
5. 模型推理层：若未发生漂移，继续使用当前模型进行推理；若发生漂移，触发模型重训练或回滚。

2.4 整体技术栈选型：Spark Streaming + Kafka + MLflow

本课程采用Spark Streaming + Kafka + MLflow作为核心技术栈，三者分别承担数据管道、流处理引擎与模型生命周期管理的角色。选型理由如下：

2.5 技术栈协作流程

三个组件在实时漂移检测中的协作关系如下：

1. Kafka Producer 将模型推理请求的特征向量与预测结果写入 model_features 和 prediction_results 两个Topic。
2. Spark Structured Streaming 从Kafka消费数据，按时间窗口（如5分钟）计算特征均值、标准差、PSI（群体稳定性指标）。
3. Spark作业将当前窗口统计量与MLflow Tracking中存储的基线阈值对比，若超出阈值则生成漂移事件。
4. 漂移事件写入Kafka drift_alerts Topic，同时通过MLflow Model Registry触发模型版本切换或重训练Pipeline。
5. MLflow记录每次漂移判定的特征分布快照、阈值、判定结果，形成可追溯的漂移审计日志。

2.6 架构选型建议

根据团队技术储备与业务需求，给出以下选型建议：

• 初创团队 / 快速验证阶段：优先采用Kappa架构 + Spark Structured Streaming + Kafka，减少运维组件，利用Kafka的日志保留能力实现数据回溯。
• 金融 / 合规敏感场景：采用Lambda架构，批处理层使用Spark Batch进行全量历史数据重算，确保漂移基线可审计、可复现。
• 大规模模型集群（100+模型）：在Kappa架构基础上引入MLflow Model Registry，通过模型版本标签（Stage）自动路由漂移告警到对应的重训练Pipeline。