数据质量验证器

数据质量验证器 通过定义期望、分析分布、检测异常和生成质量报告来验证数据管道中的数据质量。 审核数据的完整性、一致性、更新性、准确性、唯一性和模式一致性。 作为高级数据质量工程师，审计您的数据管道以确保可信度。 使用方法 当您需要验证数据质量、定义质量期望、检测异常或审计数据管道时，调用此技能。 基本调用： 验证订单管道的数据质量 为 /path/to/data/ 设置数据质量检查 审计此数据集的完整性和一致性 重点分析： 检查所有管道输出的数据更新性 分析分布以检测异常 检测管道运行之间的模式漂移 为利益相关者生成数据质量评分卡 代理读取数据源定义、管道代码、模式文件和示例数据，然后生成具有可执行期望的全面数据质量评估。

工作原理 步骤 1：发现和分析数据源 代理定位数据源并生成初始配置文件： # 查找数据管道定义 find /path/to/pipelines/ -name ".py" -o -name ".sql" -o -name ".yaml" | head -50 # 查找模式定义 grep -rl "CREATE TABLE\|schema\|DataFrame\|Column(" /path/to/src/ --include=".py" --include=".sql" # 查找数据文件 find /path/to/data/ -name ".csv" -o -name ".parquet" -o -name ".json" | head -30 # 检查现有的质量框架 grep -rl "great_expectations\|dbt_expectations\|soda\|pandera\|pydantic" /path/to/src/ --include=".py" --include=".yaml" 代理分析每个数据源： 数据源配置文件：orders_daily 源：PostgreSQL（analytics.orders） 格式：表（按order_date分区） 记录：2.4M（最新分区：12,847） 列：18 最后更新：2026-04-30 06:15:00 UTC 更新频率：每日（预计07:00 UTC） 列配置文件： order_id INT NOT NULL unique=100% nulls=0% customer_id INT NOT NULL unique=8.2% nulls=0% order_date DATE NOT NULL unique=0.1% nulls=0% total_amount DECIMAL NOT NULL min=0.01 max=99999.99 mean=127.43 stddev=284.91 status VARCHAR NOT NULL distinct=5 top：completed（72%），pending（15%），cancelled（8%） email VARCHAR NULLABLE unique=91.2% nulls=2.3% country_code CHAR(2) NOT NULL distinct=47 top：US（42%），GB（18%），DE（12%） created_at TIMESTAMP NOT NULL min=2024-01-01 max=2026-04-30 shipping_cost DECIMAL NULLABLE min=0 max=299.99 nulls=12% discount_code VARCHAR NULLABLE distinct=234 nulls=68% ...

步骤 2：定义完整性期望 代理检查缺失数据和覆盖范围： 完整性分析：orders_daily 列级完整性： PASS：order_id — 0% null（预期：0%） PASS：customer_id — 0% null（预期：0%） PASS：order_date — 0% null（预期：0%） PASS：total_amount — 0% null（预期：0%） PASS：status — 0% null（预期：0%） FAIL：email — 2.3% null（预期：< 1%） 趋势：上个月为 0.8%，本月增加到 2.3% 调查：新结账流程可能不需要电子邮件 影响：电子邮件营销活动错过 2.3% 的客户 PASS：country_code — 0% null（预期：0%） WARN：shipping_cost — 12% null（预期：< 5%） 可能是数字产品的有效值 — 验证业务规则 PASS：discount_code — 68% null（预期：高空值率的可选字段） 行级完整性： FAIL：预期 4 月 30 日分区的 12,000-15,000 行 实际：8,247 行 风险：比预期少 35% 的记录 — 可能是摄取失败 前 7 天：12,100 | 13,400 | 11,900 | 12,800 | 14,200 | 12,600 | 13,100 今天是统计异常值（> 3 个标准差以下平均值） 调查：检查源系统的提取错误 时间完整性： PASS：order_date 序列中没有间隙（2024-01-01 至 2026-04-30） FAIL：缺少 2026-03-15 的数据（0 行） 已知问题？如果不是：检查 3 月 15 日运行的管道日志 WARN：周末量减少 30% — 预期业务模式（已验证） 实体完整性： PASS：所有 47 个国家都出现在最新分区中 FAIL：过去 3 天缺少“JP”国家 之前存在（平均每天 150 个订单来自 JP） 调查：可能是区域支付网关问题

步骤 3：验证一致性规则 代理检查跨字段和跨源一致性： 一致性分析：orders_daily 记录内一致性： FAIL：847 个订单的 total_amount = 0 但 status = “completed” 业务规则：已完成的订单必须有 total > 0 期望：total_amount > 0 WHEN status IN (“completed”，“shipped”） 影响：收入报告低估了约 107,000 美元（估计） SQL：SEL...