📚 课程目录第3章理解核心概念

理解核心概念：Expectation、Suite、Checkpoint、Data Context、Store 的关系与作用

说实话，刚接触 Great Expectations 的时候，我被一堆术语搞得有点晕。Expectation、Suite、Checkpoint、Data Context、Store……每个词都认识，但放在一起就不知道谁管谁了。

后来我花了一下午，画了一张关系图，才彻底理清楚。说白了，这五个概念就是一套数据校验的「流水线」。你只要搞懂它们各自干什么、怎么配合，整个框架就通了。

一句话总结：Data Context 是总管家，Store 是仓库，Expectation 是规则，Suite 是规则包，Checkpoint 是执行器。

1. Data Context：一切从这里开始

Data Context 是整个 Great Expectations 的入口。你启动项目、加载配置、创建规则、运行校验，都得先通过它。

我个人习惯把 Data Context 理解成一个「项目上下文」。它知道你的数据源在哪、规则存在哪、结果写去哪。没有它，其他组件就是散沙。

我的经验：刚上手时，直接用 great_expectations init 生成默认的 Data Context 就行。它会自动创建 great_expectations.yml 配置文件和目录结构。等熟悉了再手动定制。

# 创建 Data Context 的两种方式
import great_expectations as ge

# 方式一：从现有项目加载（推荐）
context = ge.get_context()

# 方式二：临时创建（适合测试）
context = ge.get_context(mode="ephemeral")

2. Expectation：最细粒度的校验规则

Expectation 就是一条具体的校验规则。比如「这个字段不能为空」「那个列的值必须在 0 到 100 之间」。每条 Expectation 只做一件事，但组合起来就能覆盖复杂场景。

我记得有一次做电商订单数据校验，光「订单金额」这个字段就用了 5 条 Expectation：不能为空、必须大于 0、不能超过 10 万、小数位数不超过 2 位、不能有负值。每条规则单独定义，清晰又好维护。

# 常见的 Expectation 示例
expect_column_values_to_not_be_null("order_amount")
expect_column_values_to_be_between("order_amount", min_value=0, max_value=100000)
expect_column_values_to_be_of_type("order_amount", "float64")
expect_column_values_to_match_regex("phone", r"^1[3-9]\d{9}$")

注意：Expectation 只是定义规则，不会自动执行。它就像你写在纸上的质检标准，需要有人拿着它去检查产品。这个「检查的人」就是 Checkpoint。

3. Expectation Suite：规则包

一条 Expectation 太单薄，一百条又太散。所以 Great Expectations 用 Suite 来打包规则。一个 Suite 通常对应一张表或一个数据源。

举个例子，我负责的「用户画像」项目，有 3 张核心表：用户表、行为表、标签表。每张表我都建了一个 Suite，里面放各自相关的 Expectation。这样结构清晰，排查问题也快。

Suite 名称	包含的 Expectation 数量	校验目标
user_profile_suite	12	用户基础信息表
user_behavior_suite	8	用户行为日志表
user_tag_suite	6	用户标签宽表

# 创建 Suite 并添加 Expectation
suite = context.create_expectation_suite("user_profile_suite")

suite.add_expectation(
    ge.expectations.ExpectColumnValuesToNotBeNull(column="user_id")
)
suite.add_expectation(
    ge.expectations.ExpectColumnValuesToBeUnique(column="user_id")
)

4. Checkpoint：真正的执行者

Checkpoint 是连接「规则」和「数据」的桥梁。它告诉 Great Expectations：用哪个 Suite、校验哪个数据源、结果存到哪里。

我刚开始用的时候，总以为定义好 Suite 就完事了。结果发现数据没被校验，才意识到缺了 Checkpoint 这个「触发器」。说白了，Checkpoint 就是那个按下启动按钮的人。

# 配置并运行 Checkpoint
checkpoint = context.add_checkpoint(
    name="user_profile_checkpoint",
    expectation_suite_name="user_profile_suite",
    batch_request={
        "datasource_name": "my_database",
        "data_connector_name": "default_inferred_data_connector_name",
        "data_asset_name": "users"
    }
)

results = checkpoint.run()

避坑指南：我曾经把 Checkpoint 配置错了数据源，结果校验跑在测试库上，生产数据全漏了。后来我养成了一个习惯：每次新建 Checkpoint，先跑一次 checkpoint.run() 看看返回的 results 里数据行数对不对。

5. Store：数据持久化的仓库

Store 负责存东西。配置、Expectation、Suite、校验结果……这些都需要持久化。Great Expectations 默认用文件系统存，但你也可以换成数据库或 S3。

Store 有几种类型，各管各的：

Expectations Store：存 Expectation 和 Suite 的定义
Validations Store：存每次校验的结果
Checkpoint Store：存 Checkpoint 的配置
Data Docs Store：存生成的 HTML 报告

我记得有一次团队要求所有校验结果必须保留 30 天，方便回溯。我直接在 great_expectations.yml 里把 Validations Store 指向了 PostgreSQL，再配个定时清理脚本，搞定。

# great_expectations.yml 中配置 Store 示例
stores:
  expectations_store:
    class_name: ExpectationsStore
    store_backend:
      class_name: DatabaseStoreBackend
      credentials: ${POSTGRES_CONNECTION_STRING}
  
  validations_store:
    class_name: ValidationsStore
    store_backend:
      class_name: DatabaseStoreBackend
      credentials: ${POSTGRES_CONNECTION_STRING}

6. 它们怎么配合？一个完整的流程

说了这么多，不如看一个完整的例子。假设我要校验一张订单表：

Data Context 启动项目，加载配置
定义 Expectation：订单金额在 0-10000 之间、订单状态不能为空
把这些 Expectation 打包成 Suite：order_suite
创建 Checkpoint，指定用 order_suite 校验订单表
运行 Checkpoint，校验结果自动存入 Store
从 Store 里读取结果，生成报告或触发告警

核心要点：Data Context 是大脑，Store 是记忆，Expectation 是标准，Suite 是标准手册，Checkpoint 是执行者。五者缺一不可，配合起来才能构建自动化的数据校验流水线。

你想想看，如果没有 Store，校验结果跑完就丢了，怎么追溯？没有 Checkpoint，规则定义得再好也只是一堆静态文本。每个组件都有自己的位置，理解了这个关系，后面学起来就顺了。