2. 监控系统架构总览：分层架构设计
工业级模型漂移监控系统需要处理高吞吐、多模态的推理数据，同时保证实时性与历史回溯能力。采用分层架构将数据流、计算逻辑与展示解耦，是生产环境中最成熟的实践模式。本章定义四层核心架构，并给出技术选型原则。
2.1 四层架构总览
系统从下至上分为：数据采集层 → 特征存储层 → 检测计算层 → 告警与可视化层。每层职责独立，通过标准接口通信，便于独立扩缩容与升级。
2.2 各层职责与关键组件
| 层级 | 核心职责 | 关键组件 / 技术 | 数据形态 |
|---|---|---|---|
| 数据采集层 | 从推理服务实时拉取请求/响应日志，提取模型输入、输出、置信度等原始特征 | Filebeat / Fluentd · Kafka / Pulsar · 轻量特征提取 SDK | 原始 JSON 日志 → 结构化特征事件 |
| 特征存储层 | 保存近期滑动窗口特征与长期历史特征，支持快速读取与批量分析 | Redis / Aerospike（实时） · ClickHouse / Parquet（离线） | 特征向量 + 时间戳 + 模型版本标签 |
| 检测计算层 | 按调度周期对比参考分布与当前分布，计算漂移指标 | Spark Streaming / Flink · PSI / KS / 马氏距离 计算库 | 分布统计量 → 漂移分数 |
| 告警与可视化层 | 根据阈值触发告警，提供交互式仪表盘与定期报告 | Prometheus + Alertmanager · Grafana · 飞书/钉钉 Webhook | 漂移事件 → 通知 / 图表 |
实践建议： 数据采集层与特征存储层之间务必引入消息队列（如 Kafka），实现生产端与消费端的流量削峰与解耦。生产环境中，推理日志的峰值 QPS 可能达到数万，直接写入数据库会导致连接打满。
2.3 技术选型三大原则
技术选型直接影响系统能否在 99.9% 可用性要求下稳定运行。以下三条原则是架构评审的核心依据：
- 可扩展性（Scalability）：每一层都应支持水平扩展。数据采集层通过增加消费者组分区数提升吞吐；特征存储层使用分片集群；检测计算层采用无状态计算节点，通过 K8s HPA 自动扩缩。
- 低延迟（Low Latency）：从推理日志产生到漂移检测结果可见，端到端延迟应控制在 1 分钟以内（滑动窗口 10 分钟场景）。关键路径避免串行写库，采用内存计算 + 异步持久化。
- 容错性（Fault Tolerance）：任何单点故障不应导致数据丢失或检测中断。消息队列开启副本机制；特征存储层主从切换；检测计算层支持 checkpoint 与 exactly-once 语义。
2.4 分层架构的典型数据流
一次完整的漂移检测请求经历以下步骤：
- 采集：推理服务将请求/响应日志以 JSON 格式写入本地文件，Filebeat 实时采集并推送至 Kafka Topic
model-inference-log。 - 特征提取：Flink 作业消费 Kafka 消息，解析出模型输入特征分布、预测类别、置信度等字段，写入 Redis 实时窗口（最近 10 分钟）与 ClickHouse 离线表。
- 检测计算：定时任务（每 5 分钟）从 Redis 读取当前窗口特征，从 ClickHouse 读取参考分布（上一周数据），计算 PSI 或 KS 统计量。
- 告警与展示：若漂移分数超过阈值（如 PSI > 0.2），Prometheus 记录指标并触发 Alertmanager 发送告警至飞书群；Grafana 仪表盘实时更新漂移趋势曲线。
关键指标参考： 在日均 1000 万次推理的生产环境中，上述架构可实现：采集延迟 < 2 秒，特征写入延迟 < 500 毫秒，检测计算延迟 < 30 秒，端到端总延迟 < 1 分钟。单层故障不影响其他层数据持久化。
2.5 架构决策记录（示例）
| 决策编号 | 决策内容 | 备选方案 | 选择理由 |
|---|---|---|---|
| ADR-001 | 数据采集层使用 Kafka 作为消息中间件 | RabbitMQ、Pulsar | Kafka 在日志采集场景吞吐量最高，社区成熟，与 Flink 集成最佳 |
| ADR-002 | 实时特征存储使用 Redis Cluster | Memcached、Aerospike | Redis 支持丰富的数据结构（Sorted Set 用于时间窗口），且运维成本低 |
| ADR-003 | 检测计算层采用 Flink 流处理 + 定时窗口触发 | Spark Streaming、纯批处理 | Flink 原生支持事件时间与精确一次语义，适合滑动窗口漂移计算 |
| ADR-004 | 告警使用 Prometheus + Alertmanager | Zabbix、自研告警模块 | Prometheus 生态与 K8s 深度集成，Alertmanager 支持告警分组与静默 |
避坑提醒： 不要将所有特征数据都写入同一张 ClickHouse 表。建议按模型名称和时间分区，避免单表数据量过大导致查询性能劣化。实时窗口数据（Redis）与离线数据（ClickHouse）的 TTL 策略必须分开设置，防止存储爆炸。