Great Expectations：数据质量验证框架

为什么需要 Great Expectations：质量规则散落 → 声明式契约集中治理

数据质量事故往往在管线深处爆发：ETL 空值没有拦截、金额出现负数、主键重复导致下游 join 膨胀。多数团队用临时脚本 if not df.isnull().any() 或分散在各环节的断言来拦截，但这些检查不可复用、没有文档、没有历史版本，换一个数据源就要重写。等到模型训练或报表上线才发现脏数据，溯源成本极高。

GX 把质量规则定义为声明的「期望」（Expectation），例如「字段 X 不为空」「金额在 0–100000 之间」；一组期望打包成 Expectation Suite，相当于数据集的质量契约。通过 Checkpoint 把数据源、套件、报告动作绑定，批量数据进入时统一校验，输出结构化结果并自动渲染 Data Docs 报告。规则可以跨 Pandas、Spark、SQL 复用，也能在 CI/CD 和调度系统中作为质量门禁，失败即阻断下游任务。

与 Soda 偏重监控告警、dbt tests 与模型绑定、Pandera 内嵌 Python 运行时的定位不同，GX 强调「契约 + 报告 + 协作」：开发期用 Notebook 交互设计规则，生产期用 Checkpoint 执行，业务方通过 Data Docs 查看质量报表。这种模式适合质量规则需要长期演进、跨团队沉淀的场景。

安装与环境配置：3 步就绪

步骤一：安装。 建议在独立虚拟环境中安装，避免与既有依赖冲突。GX 1.x 的核心安装命令只有一个。

步骤二：配置。 首次调用 gx.get_context() 会自动初始化项目级的 Data Context 配置目录（存放数据源、套件、Checkpoint 定义）。连接 SQL 数据仓库需额外安装对应驱动，例如 PostgreSQL 需要 pip install sqlalchemy psycopg2-binary；使用 Spark 则需 pip install pyspark。

步骤三：验证。 打印版本号确认安装成功。

mkdir gx_demo && cd gx_demopython -m venv .venvsource .venv/bin/activate    # Windows 使用 .venv\Scripts\activate pip install great_expectations python -c "import great_expectations as gx; print(gx.__version__)"

快速上手：10 分钟跑通第一个质量验证

最小可用流程的思路：构造一份含空值与负金额的订单示例数据，声明两条期望（order_id 不为空、金额在合法区间），执行验证并观察结论。整个流程不需要额外服务，本地 Python 即可跑通。

1. 在 gx_demo 目录新建 validate_demo.py，粘贴以下脚本。

2. 运行 python validate_demo.py。

3. 观察输出：本例中两条期望均失败（order_id 含空值、amount 含 -10.0），整体 success 为 False，这正是 GX 的拦截效果。

进阶技巧：验证结果对象的 results 列表中有每条期望的观测值（如空值数量 missing_count、超界行数），可用于告警日志或写入监控系统。生产环境应将套件定义与批量验证分离，套件在初始化阶段定义，调度阶段只执行验证。

# validate_demo.py — GX 1.x 最小验证示例import great_expectations as gximport pandas as pd df = pd.DataFrame({    "order_id": ["A001", "A002", "A003", None],    "amount": [100.0, 250.5, -10.0, 88.0],    "status": ["paid", "paid", "refunded", "paid"],}) context = gx.get_context()datasource = context.data_sources.add_pandas(name="orders_datasource")asset = datasource.add_dataframe_asset(name="orders_asset")batch = asset.get_batch(dataframe=df) 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, max_value=100000    )) result = batch.validate(suite)print("验证通过:", result.success)for r in result.results:    print(r.expectation_config.expectation_type, "->", r.success)

核心能力详解：5 大支柱

支柱一：声明式期望体系。 Expectation 是 GX 的最小质量规则单元，内置 100+ 种期望，覆盖单列值（非空、唯一、范围、枚举）、跨列关系、表级统计（行数、均值）等。规则用 Python 声明，不写 SQL 或自定义断言，天然可读、可复用。

支柱二：Expectation Suite。 一组期望的有序集合，相当于数据集的质量契约。多人口径一致：数据团队定义规则，业务方审阅规则，后续所有验证共用同一套契约，避免「生产验收一套、临时检查一套」。

支柱三：多数据源支持。 通过 Data Source / Data Asset 抽象，同一套 Expectation 可作用于 Pandas DataFrame、Spark DataFrame 以及 PostgreSQL、MySQL、BigQuery、Snowflake 等 SQLAlchemy 数据源。规则不绑定底层引擎，迁移数据栈时质量契约无需重写。

支柱四：Checkpoint。 把数据源、数据资产、期望套件与验证后的动作绑定成可执行工作流。Checkpoint 可在 Airflow、Prefect、cron 中被反复调用，每次运行产出结构化结果，失败时可通过退出码或异常阻断下游任务，是把 GX 从「Notebook 演示」推向「生产门禁」的关键组件。

支柱五：Data Docs。 自动渲染的 HTML 质量报告，展示每条期望的通过状态、观测值和可视化分布。报告可分享给非技术同事，也可以在 CI 或调度任务结束后归档，形成可追溯的质量审计记录。

生产部署与监控：从上线到运维

部署方式一：调度脚本 + Airflow/Prefect/cron。 在初始化阶段一次性定义数据源、资产与套件并落盘到 Data Context 配置目录；调度阶段执行独立 Python 脚本，读取已定义的资产、获取当日数据、运行验证、按失败抛出异常。以 Airflow 为例，将上述脚本封装为 PythonOperator，失败即标记任务失败并阻断下游依赖。

部署方式二：GX Cloud 托管。 商业托管版提供云端 Data Context、套件管理与 Data Docs 托管，无需自建文档服务或存储验证历史。适合多团队共享质量规则、需要统一审计平台的场景；开源版功能完整，可作为选型起点，后续按需迁移。

可观测性。 GX 本身不提供监控面板，验证结果以 ExpectationSuiteValidationResult 结构化输出，含整体 success 与逐条期望的成功状态、观测值。实践中把结果 JSON 写入数仓或日志系统，再对接 Grafana/Prometheus 告警；Data Docs 作为人工复盘入口。CI 场景下以进程退出码作为质量门禁信号。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>坑 1：把 GX 装进全局 Python 环境，依赖冲突后排查困难；始终用虚拟环境。</li><li>坑 2：混用 0.x 与 1.x API（create_expectation_suite、run_validation_operator 等老调用），报错难以定位；新项目以官方 1.x 文档为准。</li><li>坑 3：只记录 success 布尔值，缺失失败明细；应同时记录每条期望的成功状态和观测值，便于问题回溯。</li><li>坑 4：每次调度都重新 add 同名数据源或套件，触发重名报错；生产环境用初始化脚本一次性定义，调度阶段只读取与验证。</li></ul>

版本迭代

GX 从 0.x 系列走向 1.x 的主线是「API 简化与稳定」。0.x 时代围绕配置文件与 CLI，接口频繁演变；1.x 于 2024 年转为 Python-First 对象模型，以 context/data source/suite/batch 为核心，明确稳定 API。（截至训练数据 2024 年中，可能已有更新版本）

AI 应用场景

常见误区

面试题