数据质量框架实施校验

要解决的问题

数据管道最危险的故障往往不是报错，而是静默出错：上游表结构悄悄漂移、字段出现空值、指标口径与下游假设不一致，等问题暴露时，脏数据可能已经流入报表和模型。这个技能针对的正是「质量校验缺位」的现状——团队知道该做数据校验，但缺乏一套系统的方法，把期望（expectations）组织成可维护、可自动执行的校验层。

核心能力与工作方式

技能围绕三个层次展开：

1. 质量维度建模。它把数据质量拆为六个可操作的维度——完整性（Completeness）、唯一性（Uniqueness）、有效性（Validity）、准确性（Accuracy）、一致性（Consistency）、时效性（Timeliness）——并为每个维度给出对应的 Great Expectations 断言模式。例如用 expect_column_values_to_not_be_null 检查缺失值，用 expect_column_pair_values_A_to_be_greater_than_B 检查字段间的逻辑一致性，用 expect_column_max_to_be_between 控制数据的新鲜度。

2. 分层测试与数据契约。通过数据测试金字塔组织校验：单元级断言跑得快、失败定位准；跨表关系校验放在更高层，避免噪音淹没关键信号。数据契约（data contracts）则把 schema 与业务规则显式化，让上下游团队对「合法数据」有共同定义，并随 schema 变更进行版本化管理。

3. CI/CD 集成与报告。校验结果直接驱动管道决策——只要有任一张表未通过，就生成包含失败断言明细（如 expectation 与 observed_value）的报告并终止流程，防止脏数据继续向下游扩散。

适用边界与注意点

技能默认提供方法论与参考代码，而不是替你做决定：

• 测试要有重点：优先覆盖关键列，不必追求全覆盖，否则噪音会淹没真实问题
• 阈值不要硬编码：用动态基线代替写死的数值，降低环境变化带来的误报
• 时效性同样重要：新鲜度校验常被忽略，但过期数据等同于错误数据
• 代码默认仅供参考：涉及发送、删除、部署等外部写入操作时，技能会先展示目标与影响并等待明确确认；凭据只用于你指定的官方服务，不回显、不记录、不转发