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,降低手工编写规则的成本。
二、方法流程:从规则到运行结果的数据流
六个概念并非并列,而是存在清晰的依赖与调用方向。下图展示了它们之间的数据流与职责边界:Data Context 作为根容器,向下注册数据源与 Suite;Data Assistant 从数据源读取样本生成候选 Expectation 并写入 Suite;Validator 从 Context 取 Suite 与 Batch 执行校验;Checkpoint 调用 Validator 并触发 Action。
典型工作流如下:
- 初始化 Data Context,注册数据源(如 PostgreSQL、S3、Spark)。
- 用 Data Assistant 对样本数据做 Profile,生成候选 Expectation。
- 人工审阅候选规则,保存为 Expectation Suite。
- 创建 Checkpoint,绑定 Suite、Batch 请求与 Action。
- 运行 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 |