直接用columndriftmetric在生产中会失败，因其默认全量计算、不支持流式更新与checkpoint，导致高内存消耗、丢失历史drift趋势且无法用于实时监控。
为什么直接用 evidently 的 ColumnDriftMetric 在生产中会失败
因为 evidently 默认所有指标都基于“一次全量计算”，不支持流式/增量更新，也没有内置的 checkpoint 机制。你在生产中如果每小时拉一次新数据、调用 Report 重新生成整个报告，不仅耗内存（尤其列多、样本大时），还会丢失历史 drift 趋势——比如某列 p-value 连续三天缓慢下降，你根本没法感知。
- 别把
Report当监控服务用：它本质是离线分析工具，不是drift detector服务 - 不要在 Flask/FastAPI 接口里直接调用
Report.run()：会阻塞、OOM、且无法复用统计缓存 -
DataDriftTab和Report都不保存状态，每次运行都是“从零开始”
用 TestSuite + 自定义 TestDataQualityMetrics 做轻量级周期检查
适合中小规模数据（日增 10w~1M 行）、需要每 1–6 小时触发一次 drift 检查的场景。核心是绕过 Report 渲染开销，只取指标值做判断。
- 用
TestDataQualityMetrics替代DataDriftMetrics：前者对缺失率、类别分布变化更敏感，且计算更快 - 必须显式传入
reference_data和current_data，不能依赖get_reference_data()这类隐藏逻辑 - 设置
column_mapping显式声明数值列/分类列，否则evidently可能误判类型导致卡死
from evidently.test_suite import TestSuite
from evidently.tests import TestNumberOfDriftedColumns, TestShareOfDriftedColumns
from evidently.metrics import ColumnDriftMetric
<p>suite = TestSuite(tests=[
TestNumberOfDriftedColumns(),
TestShareOfDriftedColumns(),
])
suite.run(
reference_data=ref_df,
current_data=curr_df,
column_mapping={"numerical_features": ["age", "income"], "categorical_features": ["city", "gender"]}
)
result = suite.as_dict()</p><h1>拿到 'summary' -> 'failed_tests' 数量，或遍历 'tests' 提取具体列的 p_value</h1>
如何让 evidently 和 Prometheus + Grafana 对接
关键不是把 HTML 报告塞进 Grafana，而是把 drift 指标转成时间序列：每个列的 p_value、distance、是否 drifted（bool）都需要带 timestamp 上报。
- 用
PrometheusCounter或Gauge暴露指标，命名格式建议：evidently_column_drift_pvalue{column="user_id",dataset="prod"} - 避免直接上报 raw p-value：Grafana 画图时难设阈值，建议同时暴露
evidently_column_drift_status{column="user_id"} 1.0（1=drifted, 0=ok） -
evidently不提供异步 metric push，需你自己封装：在suite.as_dict()后遍历tests列表，提取每个ColumnDriftMetric对应的result.p_value
生产部署最常被忽略的三件事
不是模型上线才要关心稳定性，数据监控链路本身就有单点故障风险。
- ref_df 必须固化：不能每次从数据库
SELECT * FROM features WHERE dt='2024-01-01'动态加载——万一那天数据异常，后续所有 drift 判断都偏移 - curr_df 时间窗口必须对齐业务含义：比如“过去一小时订单”不能简单
WHERE created_at > NOW() - INTERVAL '1 HOUR'，要考虑数据延迟写入，建议用WHERE dt = '{{ ds }}'（Airflow 中的日期宏） - 没配
logging级别为 WARNING 以上：默认 INFO 会疯狂打Calculating drift for column: ...，日志量爆炸且无实际价值
真正难的不是跑通第一个 report，而是保证 ref 数据可信、时间窗口稳定、指标可归因——这三块出问题，drift 告警就变成噪音开关。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
