企业官网建设流程全解析

Great Expectations 数据验证快速上手指南：六步从安装到读懂验证报告

【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations

Great Expectations 是一个开源数据验证框架，它把「数据质量检查」从散落在各个脚本里的手写断言，变成可复用、可文档化、可调度执行的测试。本教程用一份用户行为日志 CSV 做示例数据，走完完整链路：装好框架、创建数据上下文、登记数据源、写三条数据期望（Expectation）、跑一次验证、打开报告。

一条命令装好 Great Expectations

Great Expectations 支持 Python 3.10 到 3.13，官方建议在虚拟环境中部署，避免和系统里已有的包互相污染。建环境、激活、安装，三步走完：

python -m venv gx_env source gx_env/bin/activate pip install great_expectations

⚠️ Windows 下激活命令是gx_env\Scripts\activate；如果系统里装过旧版 Great Expectations，先在虚拟环境外确认pip list里没有残留，避免版本混用。

安装包已带齐 Pandas 等核心依赖，装完即可进入下一步。

创建数据上下文：整个项目的家

数据上下文（Data Context）是 Great Expectations 的核心对象：数据源、期望套件、验证定义、检查点、报告站点，全都挂在它下面。在准备存放项目的空目录里执行：

import great_expectations as gx context = gx.get_context()

get_context()会自动检测当前目录：已有配置就加载，没有就生成一个文件型上下文，并顺手搭好项目骨架。

数据上下文落在磁盘上是什么样

当前目录会多出一个great_expectations/子目录，里面是主配置great_expectations.yml、期望套件与验证结果的存储目录，以及 Data Docs 报告站点的位置。后面所有操作，本质上都是在往这个上下文里登记对象。

登记数据源，指向行为日志

假设行为日志放在data/user_events.csv，有user_id、event_type、event_time三列。登记数据源分三步：圈定文件夹、声明 CSV 资产、指向具体文件：

data_source = context.data_sources.add_pandas_filesystem( name="user_events_source", base_directory="./data", ) csv_asset = data_source.add_csv_asset(name="user_events") batch_definition = csv_asset.add_batch_definition_path( name="user_events_batch", path="user_events.csv", )

这三层对象各司其职：数据源（Data Source）描述"数据从哪来"，数据资产（Data Asset）描述"哪一类文件"，批次定义（Batch Definition）描述"验证哪一份具体文件"。真正执行验证时，加载进内存的是批次定义对应的数据。以后日志按月分目录，也可以换成按正则批量匹配的方式，模式不变。

写三条数据期望

期望（Expectation）就是写给数据的测试用例。先建一个期望套件（Expectation Suite），挂上前两条规则：

expectation_suite = context.suites.add(gx.ExpectationSuite(name="user_events_suite")) expectation_suite.add_expectation( gx.expectations.ExpectColumnValuesToNotBeNull(column="user_id") ) expectation_suite.add_expectation( gx.expectations.ExpectColumnValuesToBeInSet( column="event_type", value_set=["page_view", "page_load", "purchase", "user_signup"], ) )

第一条要求user_id不能有空值，第二条限定event_type只能取四种事件名。再补一条时间窗规则：

expectation_suite.add_expectation( gx.expectations.ExpectColumnValuesToBeBetween( column="event_time", min_value="2024-01-01", max_value="2024-12-31", ) )

内置的期望类型有几十种：非空、唯一性、取值范围、枚举、分布、列间关系都能覆盖，还可以给规则加mostly参数容忍少量异常值。跑通流程，上面三条足够。

把数据和规则绑起来，执行一次验证

规则和数据各自都不产生作用，绑到一起才生效。要登记两个对象：验证定义（Validation Definition）负责"哪份数据用哪套规则"，检查点（Checkpoint）负责"跑哪些验证、跑完做什么"：

validation_definition = context.validation_definitions.add( gx.ValidationDefinition( name="user_events_validation", data=batch_definition, suite=expectation_suite, ) ) checkpoint = context.checkpoints.add( gx.Checkpoint( name="user_events_checkpoint", validation_definitions=[validation_definition], actions=[gx.checkpoint.actions.UpdateDataDocsAction(name="update_data_docs")], ) ) result = checkpoint.run()

result["success"]为 True 表示所有期望都通过；actions列表还能挂 Slack 通知、结果回写对象存储等动作，每个动作一行代码，官方文档有完整清单。

生成并阅读 Data Docs 报告

验证结果不该只留在result变量里。Great Expectations 能把历次结果编译成一个可浏览的静态站点，叫 Data Docs：

context.build_data_docs() context.open_data_docs()

第一行把静态 HTML 写进 data_docs 目录，第二行直接在浏览器打开。

报告怎么读

站点首页是每次验证的总体通过情况，点进单次验证能看到每条 Expectation 的判定结果、观测值和样本统计。失败的期望会展开「失败行预览」，像下面这张截图，还附带一段可直接运行的取数代码，方便你定位到具体坏行：

提示：第一次跑几乎必然有期望失败，这很正常。数据验证的价值在于把"数据可能有问题"变成"确切知道哪些行有问题"，失败报告本身就是资产。

把验证接进日常工作流

到这里整条链路已经闭环：每来一份新数据，调一次checkpoint.run()就能出验证结果并自动刷新报告。要上调度，只需把这段调用包成一个脚本，交给 Airflow、Prefect 或系统 cron 按时触发；也可以改用great_expectations命令行工具在 CI 里执行。SQL 类数据源（PostgreSQL、Snowflake 等）与期望参数化的写法，可以照着仓库 docs/docusaurus/docs/core/ 目录下的入门教程延伸，结构和刚才跑通的流程一致。

下一步行动：给你的检查点 actions 加一个 Slack 通知动作，具体做法见官方文档的 Trigger Actions 章节和 GitHub 仓库中的示例。

【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations