Always know what to expect from your data. —— Great Expectations 2017 至今 9 年，把 ” 数据单元测试化 ” 做成行业标准。
写在前面
数据团队的痛苦有多安静：凌晨 3 点报警响，下游报表全错，定位发现是 ETL 某个字段突然多了空值；机器学习模型上线后精度掉了，复盘发现训练数据里混了几行异常分布；仓库里没人知道 customer 表到底有哪些规则，只知道 ” 大家都是在某次事故后补的 CHECK”。
Great Expectations（现名 GX Core）解决的就是这个 ：把 ” 我们期望数据是什么样 ” 写成一组声明式断言， 先声明 → 再执行 → 自动出可视报告 。11,600+ stars、Apache-2.0、Fivetran 2025 年收购并持续推进，是 Python 数据质量赛道 事实上的开源标准。
一、它解决什么问题
一句话：用 Python 写 ” 数据契约 ”，自动校验 + 自动出可视化报告 + 自动触发后续动作。
基本信息
| 字段 | 值 |
|---|---|
| GitHub | fivetran/great_expectations |
| 官网 | greatexpectations.io |
| Stars / Forks | 11,667 / 1,782 |
| License | Apache-2.0 ✅ |
| 主语言 | Python（250 MB 仓库，9 年累积） |
| 首次 commit | 2017-09-11 |
| 最近 commit | 2026-07-23（24h 内仍活跃） |
| 当前版本 | GX Core（原 0.x 系列，2025 Fivetran 收购后改名） |
| 支持 Python | 3.10 – 3.13（3.14 实验性） |
| 核心 4 件套 | Data Context / Expectation Suite / Checkpoint / Data Docs |
Fivetran 收购背景 ：2025 年数据集成龙头 Fivetran 收购 Great Expectations 的公司，仓库从
great-expectations/great_expectations迁到fivetran/great_expectations，产品名改为 GX Core（开源引擎层），上层还有 GX Cloud（SaaS 控制台）—— 开源协议 承诺永久免费 Apache-2.0。
二、核心能力：数据契约怎么写
GX Core 的 ” 期望 ” 分 12 大类、50+ 内置规则，覆盖数据质量的所有维度：
1. 完整性（Existence）——空值检测
expect_column_values_to_not_be_null(column="email")
expect_column_values_to_be_null(column="deleted_at") # 镜像字段应当全空
每个数据团队的 ” 凌晨三点钟事故 ” 基本都被这两条规则防住。
2. 唯一性（Uniqueness）——主键 / 去重
expect_column_values_to_be_unique(column="order_id")
expect_compound_columns_to_be_unique(column_list=["user_id", "order_date"])
3. 范围（Range）——业务上下界
expect_column_values_to_be_between(column="age", min_value=0, max_value=150)
expect_column_values_to_be_in_set(column="status", value_set=["active", "frozen", "closed"])
4. 分布（Distribution）——漂移检测
expect_column_mean_to_be_between(column="price", min_value=10, max_value=1000)
expect_column_stdev_to_be_between(column="latency_ms", min_value=0, max_value=200)
这一类最强——机器学习训练数据漂移问题 靠这组规则兜底。
5. 类型 / 模式 / 解析——字段稳定性
expect_column_values_to_match_regex(column="email", regex="^[^@]+@[^@]+\\.[^@]+$")
expect_column_values_to_be_dateutil_parseable(column="created_at")
expect_column_values_to_be_of_type(column="qty", type_="INTEGER")
6. 时新（Freshness）——管道延迟
expect_column_max_to_be_between(column="sync_at", min_value=..., max_value=...)
典型用法：上游最近一次同步时间必须在 1h 内。
7. 列对 / 表对（Relationship）——参照完整性
expect_column_pair_values_A_to_be_greater_than_B(column_A="end_time", column_B="start_time")
这一类直接做 ” 业务规则 ”——比如完单时间必须晚于下单时间。
8. 自定义 SQL / Python——业务专属
expect_query_output_row_count_to_be_between(query="SELECT * FROM fact_orders WHERE ...", min_value=1000)
expect_column_values_to_be_in_set(column="region", value_set=["north", "south", "east", "west"])
当 50+ 内置规则不够时，可注入任意 SQL 或 Python 函数。
三、差异化能力（GX 相对 dbt test / Soda 的护城河）
1. Data Docs：自动 HTML 报告（核心卖点）
一次校验，自动生成 完整 HTML 报告（带成功 / 失败可视化、统计图、可点开看哪一行挂了），无需写前端。
- 类似工具 1：dbt test 只输出 pass/fail 日志，要自己拼报告
- 类似工具 2：Soda Core 的报告是命令行表格，HTML 要自己配
- GX 报告是开箱即用
2. Action 机制：失败即触发
Checkpoint 配置 Actions，可以在 校验失败时自动执行：
- 发 Slack 到数据值班群
- 触发邮件 / 钉钉 / 飞书通知
- 阻断 CI/CD pipeline（PR 不通过不允许合并）
- 写入数据库让上游系统查询
- 触发 webhook 调业务侧补偿
这一条让 GX 从 ” 写出来 ” 变成 ” 用起来 ”——校验不再是人肉看日志。
3. Data Assistant（自动生成期望）
context.assistants.onboarding.run("batch_data")
GX 会自动扫一遍数据，生成推荐期望套件——非空 / 唯一 / 分位数 / 常见值都列好，再人工微调。这是 GX 的 ” 开箱 80 分 ” 机制。
4. 多数据源覆盖（40+ 种 Data Source）
| 数据源类型 | 覆盖情况 |
|---|---|
| 本地文件 | CSV / Parquet / JSON / Excel |
| 关系数据库 | PostgreSQL / MySQL / SQL Server / Oracle / SQLite（via SQLAlchemy） |
| 现代仓库 | Snowflake / BigQuery / Redshift / Databricks SQL |
| Spark / Pandas DataFrame | 原生支持 |
| 流式 | 待靠 partition 增量校验 |
完整列表见 GX 兼容性参考。
5. Python 3.10-3.13 全支持
涵盖主流生产 Python 版本；3.14 实验支持可通过环境变量开启。
四、对比工具矩阵
| 维度 | Great Expectations (GX Core) | dbt test | Soda Core | Deequ (Spark) |
|---|---|---|---|---|
| 定位 | 声明式期望 + 数据契约 | 转换 + 内置测试 | YAML 定义质量检查 | Spark 内置约束 |
| 语言 | Python | SQL (Jinja) | YAML / Python | Scala / Python |
| 数据源 | 40+ | 仅数仓 (JDBC) | 20+ | Spark DataFrame |
| HTML 报告 | ✅ 开箱即用（Data Docs） | ❌ 自己拼 | ❌ CLI 表格 | ❌ 自己拼 |
| Action 自动化 | ✅ Slack/ 邮件 /Webhook 全支持 | ⚠️ 靠 macros | ✅ | ⚠️ 靠 Spark event |
| 自动生成期望 | ✅ Data Assistant | ❌ | ⚠️ 部分 | ⚠️ 部分 |
| 商业路径 | GX Cloud（独家） | dbt Cloud | Soda Cloud | AWS Glue Data Quality |
| License | Apache-2.0 ✅ | Apache-2.0 ✅ | Apache-2.0 ✅ | Apache-2.0 ✅ |
| 学习曲线 | 中（API/ 类 Python 风格） | 低（团队已在用 dbt 几乎零成本） | 低 | 中（需 Spark 知识） |
| 1 万行代码可撑 | ✅ 仓库 250MB | ✅ | ✅ | ✅ |
| Stars | 11,600+ | 11,000+ (dbt-utils+dbt-core) | 1,800+ | 3,700+ |
结论：
- 已用 dbt 做转换 ：直接上
dbt test，零额外依赖。 升级路径：仅当需要自动 HTML 报告或 Action 时加 GX。 - 不用 dbt / 多数据源：GX 是默认选择。
- Python + Spark 数据湖 + ML 训练数据：Deequ 更原生；GX 也支持 Pandas → Parquet 路径。
- 团队偏好 YAML：Soda Core 更轻量，但社区规模和自报告丰富度低于 GX。
五、实战：10 分钟跑通第一条契约
按 GX 官方 quickstart：
Step 1：装 + 起 Context（90s）
pip install great_expectations
Step 2：连一个 Pandas DataFrame（30s）
import pandas as pd
import great_expectations as gx
df = pd.read_csv("orders.csv")
context = gx.get_context(mode="file", project_root_dir="./")
data_source = context.data_sources.add_pandas("orders_src")
data_asset = data_source.add_dataframe_asset(name="orders_asset")
batch_def = data_asset.add_batch_definition_whole_dataframe("orders_batch")
batch = batch_def.get_batch(batch_parameters={"dataframe": df})
Step 3：声明 3 条核心期望（3min）
suite = context.suites.add(name="orders_suite")
suite.add_expectation(gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeUnique(column="order_id"))
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeBetween(column="qty", min_value=1, max_value=100))
Step 4：跑 Checkpoint + 生成 Data Docs（5min）
checkpoint = context.checkpoints.add(name="orders_cp", validation_definitions=[
context.validation_definitions.add(
data=batch_def,
suite=suite,
name="orders_vd",
)
])
result = checkpoint.run()
context.build_data_docs() # 自动在 ./uncommitted/data_docs/local_site/ 出 HTML
打开 index.html → 看到完整的可视化报告，每条期望成功 / 失败 + 失败样本 + 统计图。
Step 5：接 CI（5min）
# .github/workflows/dq.yml
- name: Run data quality checks
run: |
python scripts/run_dq.py
- name: Upload Data Docs
uses: actions/upload-artifact@v3
with:
name: data-docs
path: gx/uncommitted/data_docs/local_site/
Action 配置（失败发 Slack）见 GX 官方文档 – Actions
六、风险与坑
1. API 频变大版本时易踩坑
2025 年 Fivetran 收购后，GX Core 1.0 重构 API（FilesystemDataContext → get_context(mode=...)），旧 0.x 教程大量失效。新建项目走 1.0 API，不要复制 2 年前的 Stack Overflow 答案。
2. Data Context 是状态文件（容易乱）
模式 = file 时，GX 会写一堆配置文件到 gx/ 目录，多分支合并容易冲突。建议：
–
mode="ephemeral"：纯内存，CI 友好
–
mode="file"：本机开发，把 gx/ 加进 git
–
永远不要两人共用同一份 gx/ 目录
3. 大表校验慢（要分批）
全表校验时 GX 会把数据全部加载进内存（除非用 SQL asset 让 DB 端算）。经验值：
– Pandas asset：<1000 万行 OK
– Spark asset：默认 OK
– SQL asset（直接 SELECT WHERE）：可扛 100 亿行
–
失败模式：直接对 5 亿行 expect_column_mean_to_be_between 用 Pandas 跑 → OOM
4. Action 副作用要小心
Webhook Action 写错目标，可能 ” 校验失败 → 触发下游清库 ”。第一次配 Action 时关掉生产环境，先 dry-run 验证。
5. 与 dbt test 重叠决策成本
如果团队已经在用 dbt，再上 GX 是 ” 双测试套件 ”，治理成本上升。结论：
– dbt 转换层 + dbt test：
够了，不引入 GX
– 非 dbt 环境 / Python ETL / 流处理：
GX 首选
6. GX Cloud 锁定心智
Fivetran 主推 GX Cloud（SaaS 控制台）。Apache-2.0 承诺永远免费 GX Core，但 GX Cloud 高阶功能（团队协作、UI、告警）不在开源范围。
7. Expectation 数量不是越多越好
业界经验：1000+ 条 Expectation 会拖垮 Checkpoint（单次校验 5min+）。建议分层：
– 关键路径（订单 / 支付 / 账务）：详尽
– 边缘日志表：抽样 / 无校验
七、总结
最值得装的 3 个理由
- 数据契约正式化 ：从 ” 代码注释 ” 到 ” 可执行期望 ”，让团队 有共同的 ” 数据长什么样 ” 的语言。
- Data Docs 自动报告 ：让非技术 stakeholder（产品 / 运营 / 老板） 打开 HTML 就能看当前数据健康度——这是 GX 最被低估的能力。
- Action 接 CI / 告警：把 ” 数据质量 ” 从 ” 事后监控 ” 升级到 ” 事前阻断 ”。
一句话建议
如果你的团队在 Python 生态做 ETL/ 数仓 /ML，装一次 GX Core 用两周。装完大概率你会想：为什么我以前全是深夜报警。
适配场景
| ✅ 推荐 | ❌ 不推荐 |
|---|---|
| Python ETL 团队 | 纯 dbt 转换团队（用 dbt test 就够） |
| 多数据源混合 | 单数据源 + 简单表 |
| ML 训练数据治理 | 小项目（<10 表） |
| 需要 HTML 报告给 stakeholder | 团队更熟 SQL / 不想碰 Python |
| 希望校验失败阻断 CI | 极简逻辑校验 |