4. 核心概念详解

在 Great Expectations(GX)中,真正决定“数据质量工程能否落地”的,不是某一条断言写得多漂亮,而是六个核心概念之间的协作关系:Expectation 定义单条质量规则,Expectation Suite 把规则组织成可复用的契约,Validator 负责在具体数据上执行规则,Checkpoint 把校验、动作与运行配置打包成可调度任务,Data Context 是贯穿全局的项目上下文与资源注册中心,Data Assistant 则用于从数据中自动生成候选规则。理解它们的边界与数据流,是后续所有实战操作的基础。

一、核心原理:六个概念各管什么

可以把 GX 的数据质量体系类比为“合同—执行—归档”三层结构。Expectation 是合同条款,Expectation Suite 是合同文本,Validator 是执行合同的审计员,Checkpoint 是安排审计并触发后续动作的调度器,Data Context 是存放合同、审计记录和资源地址的项目办公室,Data Assistant 则是帮你起草合同条款的智能助手。

  • Expectation(期望):最小质量断言单元,例如“该列不能为空”“订单金额必须大于 0”“枚举值只能属于 {已支付, 已退款, 待支付}”。它只描述规则,不绑定具体数据。
  • Expectation Suite(期望套件):一组 Expectation 的集合,通常按数据集或业务域组织,如 orders_suite、user_profile_suite。套件可版本化、可复用、可被多个 Checkpoint 引用。
  • Validator(校验器):把 Suite 绑定到一份具体 Batch(数据批次)上执行,产出校验结果。它回答“这批数据到底过没过”。
  • Checkpoint(检查点):把 Validator、Batch 请求、Action(如发邮件、写 Data Docs、更新告警)组合成一个可运行单元,是生产调度的入口。
  • Data Context(数据上下文):GX 的项目根对象,管理数据源、Suite、Checkpoint、Data Docs 站点等配置,分为 Ephemeral、File、Cloud 等类型。
  • Data Assistant(数据助手):基于 Profiler 自动扫描数据并生成候选 Expectation,降低手工编写规则的成本。
核心记忆法:Expectation 是“规则”,Suite 是“规则集”,Validator 是“执行器”,Checkpoint 是“调度器”,Data Context 是“资源中心”,Data Assistant 是“规则生成器”。

二、方法流程:从规则到运行结果的数据流

六个概念并非并列,而是存在清晰的依赖与调用方向。下图展示了它们之间的数据流与职责边界:Data Context 作为根容器,向下注册数据源与 Suite;Data Assistant 从数据源读取样本生成候选 Expectation 并写入 Suite;Validator 从 Context 取 Suite 与 Batch 执行校验;Checkpoint 调用 Validator 并触发 Action。

Data Context:项目上下文与资源注册中心 Expectation Suite orders_suite 规则集合 · 可版本化 Expectation 单条质量断言 not_null / between / in_set Data Assistant 扫描样本数据 生成候选 Expectation Validator Suite + Batch 执行校验 产出 Validation Result Checkpoint 调度 Validator 触发 Action 写 Data Docs / 告警 Action 邮件 / Slack / 更新指标 阻断下游任务 生成候选规则 绑定执行 引用 调用 触发 组成

典型工作流如下:

  1. 初始化 Data Context,注册数据源(如 PostgreSQL、S3、Spark)。
  2. 用 Data Assistant 对样本数据做 Profile,生成候选 Expectation。
  3. 人工审阅候选规则,保存为 Expectation Suite。
  4. 创建 Checkpoint,绑定 Suite、Batch 请求与 Action。
  5. 运行 Checkpoint,Validator 执行校验,结果写入 Data Docs 并触发告警。

三、案例场景:订单表质量校验

假设有一张 orders 表,需要校验订单号非空、金额为正、状态枚举合法。下面展示从 Suite 定义到 Checkpoint 运行的关键代码片段。

import great_expectations as gx

context = gx.get_context()

suite = context.suites.add(
    gx.ExpectationSuite(name="orders_suite")
)

suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="amount", min_value=0.01
    )
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeInSet(
        column="status",
        value_set=["已支付", "已退款", "待支付"]
    )
)

checkpoint = context.checkpoints.add(
    gx.Checkpoint(
        name="orders_checkpoint",
        validation_definitions=[
            gx.ValidationDefinition(
                name="orders_validation",
                data=batch_definition,
                suite=suite
            )
        ],
        actions=[gx.actions.UpdateDataDocsAction(name="update_docs")]
    )
)

result = checkpoint.run()
print(result.success)

运行后,若 amount 出现负值,Validator 会返回 success=False,Checkpoint 触发 Action 更新 Data Docs 并发送告警。整个过程无需人工逐条比对,规则与执行彻底解耦。

四、误区与复盘

常见误区 问题本质 正确做法
把 Expectation 直接绑定到某张表 规则与数据耦合,无法复用 规则写入 Suite,由 Validator 绑定 Batch
每个 Checkpoint 只放一条规则 调度碎片化,运维成本高 按业务域组织 Suite,Checkpoint 批量引用
用 Data Assistant 生成后直接上线 候选规则含噪声,误报率高 人工审阅、裁剪、补充业务约束
忽略 Data Context 类型选择 本地 Ephemeral 无法持久化配置 生产环境使用 File 或 Cloud Context
Checkpoint 不配置 Action 校验结果无人知晓,形同虚设 至少配置 Data Docs 与告警 Action
复盘建议:每次新增 Suite 后,先用 Validator 在样本数据上试跑,确认规则无误再接入 Checkpoint 调度。规则变更时,优先更新 Suite 版本,而不是修改 Checkpoint。
注意:Data Assistant 生成的 Expectation 只是“候选”,不能替代业务判断。例如它可能把某列的空值率阈值设得过宽,导致真实数据质量问题被漏检。务必结合业务语义做二次确认。