Pandas基础校验应避免硬编码阈值，需基于历史基线动态生成（如7天mean+2*std）；规则须拆分为独立可测函数，报警前需Redis去重抑制，日志表字段应包含run_id、check_params、sample_values、ts等扩展字段，并与ETL解耦调度。
用 pandas 做基础校验时，别直接写死阈值
硬编码缺失率、重复率阈值会导致监控脚本一升级就误报。实际生产中，阈值应基于历史基线动态生成——比如用过去7天同口径数据的 mean + 2*std 作为上限。
常见错误是把校验逻辑塞进一个大函数里，导致无法单独调试某条规则。建议按规则拆成独立函数，例如：
def check_null_ratio(df: pd.DataFrame, col: str, threshold: float) -> dict:
ratio = df[col].isnull().mean()
return {"metric": "null_ratio", "column": col, "value": ratio, "alert": ratio > threshold}
这样每条规则可单独测试、复用、打日志，也方便后续接入规则配置文件。
报警触发前必须做「去重抑制」，否则同一问题刷屏
数据库延迟、任务重跑、上游重推都可能让同一条异常在几分钟内反复出现。不加抑制机制，Slack 或 Webhook 会瞬间收到几十条相同告警。
实操建议用轻量级缓存控制重复发送：
- 用
redis存"dq_{rule_id}_{key}_last_alert_ts"，有效期设为1小时 - 每次准备发警前，先查缓存：若存在且距上次不足15分钟，跳过
-
key要包含业务上下文，比如日期分区dt=20240520或表名user_order
不用数据库存状态，避免引入新单点依赖；也不用本地变量，跨进程不生效。
把校验结果写入 data_quality_log 表时，字段设计要留扩展余地
初期只记 table_name、check_name、status 很容易后期翻车。当需要定位“为什么今天 null_ratio 突然升高”，却没存原始样本或时间窗口，就只能干瞪眼。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
至少保留这些字段：
-
run_id：关联调度系统（如airflow_run_id或自增UUID） -
check_params：JSON 字符串，存本次校验用的阈值、列名、时间范围等 -
sample_values：非必填，但对分布类检查（如value_in_range）建议存3个异常样例 -
ts：精确到秒，且统一用 UTC，避免时区混淆
别图省事用 TEXT 存所有内容——字段化才支持后续用 SQL 快速查“近3天哪些规则连续失败”。
用 airflow 调度时，别让 DQ 任务和 ETL 任务强耦合
把数据质量检查塞进主 ETL DAG 的下游 task，看似省事，实则埋雷：ETL 失败时 DQ 不跑，你就不知道问题是数据本身坏了，还是 ETL 逻辑错了。
正确做法是解耦：
- DQ DAG 独立运行，靠外部传感器（
ExternalTaskSensor）等待对应 ETL 完成 - ETL 任务成功后只负责写
_SUCCESS文件或更新元数据表，不负责触发 DQ - DQ DAG 自己决定检查哪天的数据——比如固定查
{{ ds }} - 1，而不是盲目跟 ETL 的execution_date
这样即使 ETL 某天延迟6小时，DQ 仍能准时检查昨日数据，不会漏掉关键窗口。
复杂点在于规则版本管理：今天上线的新校验逻辑，不该回扫历史30天数据。得在 DAG 中显式控制 start_date 和规则启用时间戳，这个细节容易被忽略。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
