Great Expectations 数据质量验证10 分钟搭出第一条规则【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations它到底解决了什么问题数据工程师上游 ETL 往客户表里写了三年数据某天报表显示customer_id为空的客户数突然上涨。没有它之前只能手写 SQL 抽查、把检查逻辑记在脑子里现在用 Great Expectations一个开源的 Python 数据质量校验框架加一行期望入库的 NULL 会被自动拦下并给出失败行样例。BI 分析师周报里的订单金额出现负数想回溯是哪次写入造成的以前要挨个问同事翻日志现在打开自动生成的 DataDocs每次校验的通过/失败记录和失败明细都留痕可查。技术负责人数据质量规范散落在各人口头约定里没人能完整复述现在一份期望清单就是团队的共同语言谁在什么时候校验过什么、结果如何全部沉淀在文档里。这就是 Great Expectations 解决的核心问题把数据应该长什么样变成可执行、可测试、可文档化的数据入库校验规则不再依赖个人记忆和抽查运气。核心能力拆解能力项一句话说明典型使用场景Expectation期望声明式校验规则写法接近单元测试拦掉空值、越界、分布漂移ExpectationSuite套件把多条期望打包成一组整体运行一张表的完整质量检查Data Context项目级中枢管理数据源、套件与校验历史本地开发与 CI 共享配置Checkpoint检查点触发校验并决定后续动作的入口入库前门禁、告警Data Docs校验后自动生成静态 HTML 文档给非技术同事看质量状态Data Assistant根据数据分布推断并生成候选期望新表接入时冷启动内置期望覆盖空值、取值范围、正则匹配、表行数等常见诉求核心实现都在 期望源码。一条期望既能单独跑用来调试也能挂进套件批量执行从抽查一次到常态化质检的迁移成本很低。跟着做一遍最小可运行流程先确认 Python 版本在 3.10 及以上官方支持 3.10–3.13建一个虚拟环境装包即可没有其他前置依赖python -m venv .venv source .venv/bin/activate pip install great_expectations装好后可以直接跑最小闭环。下面用 pandas 内存表演示modeephemeral创建临时上下文不落盘写文件适合第一次上手import pandas as pd import great_expectations as gx from great_expectations import expectations as gxe df pd.DataFrame({customer_id: [1, 2, None], amount: [100, -5, 300]}) context gx.get_context(modeephemeral) # 临时上下文不写配置到磁盘 ds context.sources.add_pandas(demo_ds) asset ds.add_dataframe_asset(namecustomers, dataframedf) batch asset.add_batch_definition_whole_dataframe(bd).get_batch() # 校验结果对象带 success 标记和失败行明细不只是布尔值 result batch.validate(gxe.ExpectColumnValuesToNotBeNull(columncustomer_id)) print(result.success) # False捕获到一行 NULL 想要批量运行并留档就把规则挂进套件再一键生成文档suite context.suites.add(expectation_suite_namecustomer_quality) suite.add_expectation(gxe.ExpectColumnValuesToBeBetween(columnamount, min_value0)) batch.validate(suite) context.build_data_docs() # 生成静态 DataDocs 站点以上是最短路径具体参数以官方文档为准。典型落地场景电商订单表入库前拦掉脏数据order_id非空且唯一主键重复是数据血缘问题不该留给下游报表订单金额min_value0负数通常意味着退款流程写串了邮箱字段用内置正则期望校验格式不用自己拼 SQL状态字段落在约定枚举集合内集合外的值直接判失败行数与昨日对比的漂移阈值超阈值标记本批校验失败金融风控夜间批跑前做入库校验交易时间戳必须晚于开户时间、早于当前时间风险评级必填字段完整性NULL 一律失败核心对账表行数与总额和上游核对校验失败时由 Checkpoint 触发告警并阻断下游任务踩过的坑和绕路技巧⚠️ 团队实际项目里踩过的三个现象suite.add_expectation(e)抛 RuntimeError提示该期望已属于另一个套件。原因期望对象带全局 id只能被一个套件收养把已入套的期望对象直接塞进别的套件必然报错。解法跨套件复用时复制配置新建对象或在原套件里用save()原地更新。现象生产 MySQL 上校验失败报错是一长串翻译后的 SQL很难读。原因SQL 数据源会把期望翻译成数据库端 SQL 执行报错信息也随数据库输出。解法调试期先切 pandas 内存后端复现问题确认逻辑后再切回生产数据源。现象从老版本升级后great_expectations.yml里的数据源配置和新 API 对不上。原因项目从 0.x 到 1.x 重构了数据源与配置结构旧配置不兼容。解法升级前先跑仓库内置的迁移工具great_expectations/data_context/migrator/按生成的迁移方案执行。和现有工具链怎么配合在典型技术栈里Great Expectations 位于调度器和数据库之间Airflow、Prefect 等调度任务先跑校验通过才放行业务逻辑校验结果可通过渲染器推送到 Slack、Microsoft Teams 等渠道。社区集成还包括 dbt可在模型构建后直接校验。真实数据库的接入写法可以看 集成测试示例。写在最后表不多但每张都关键或者流水线已经自动化、有明确的入库环节可以挂校验门禁——这时上 Great Expectations 收益最明显如果只是偶尔看一眼某张表先手写几条期望练熟 API比急着铺开整套设施更实际。想深入的话从仓库里的 官方文档目录 开始读最合适。【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Great Expectations 数据质量验证：10 分钟搭出第一条规则
Great Expectations 数据质量验证10 分钟搭出第一条规则【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations它到底解决了什么问题数据工程师上游 ETL 往客户表里写了三年数据某天报表显示customer_id为空的客户数突然上涨。没有它之前只能手写 SQL 抽查、把检查逻辑记在脑子里现在用 Great Expectations一个开源的 Python 数据质量校验框架加一行期望入库的 NULL 会被自动拦下并给出失败行样例。BI 分析师周报里的订单金额出现负数想回溯是哪次写入造成的以前要挨个问同事翻日志现在打开自动生成的 DataDocs每次校验的通过/失败记录和失败明细都留痕可查。技术负责人数据质量规范散落在各人口头约定里没人能完整复述现在一份期望清单就是团队的共同语言谁在什么时候校验过什么、结果如何全部沉淀在文档里。这就是 Great Expectations 解决的核心问题把数据应该长什么样变成可执行、可测试、可文档化的数据入库校验规则不再依赖个人记忆和抽查运气。核心能力拆解能力项一句话说明典型使用场景Expectation期望声明式校验规则写法接近单元测试拦掉空值、越界、分布漂移ExpectationSuite套件把多条期望打包成一组整体运行一张表的完整质量检查Data Context项目级中枢管理数据源、套件与校验历史本地开发与 CI 共享配置Checkpoint检查点触发校验并决定后续动作的入口入库前门禁、告警Data Docs校验后自动生成静态 HTML 文档给非技术同事看质量状态Data Assistant根据数据分布推断并生成候选期望新表接入时冷启动内置期望覆盖空值、取值范围、正则匹配、表行数等常见诉求核心实现都在 期望源码。一条期望既能单独跑用来调试也能挂进套件批量执行从抽查一次到常态化质检的迁移成本很低。跟着做一遍最小可运行流程先确认 Python 版本在 3.10 及以上官方支持 3.10–3.13建一个虚拟环境装包即可没有其他前置依赖python -m venv .venv source .venv/bin/activate pip install great_expectations装好后可以直接跑最小闭环。下面用 pandas 内存表演示modeephemeral创建临时上下文不落盘写文件适合第一次上手import pandas as pd import great_expectations as gx from great_expectations import expectations as gxe df pd.DataFrame({customer_id: [1, 2, None], amount: [100, -5, 300]}) context gx.get_context(modeephemeral) # 临时上下文不写配置到磁盘 ds context.sources.add_pandas(demo_ds) asset ds.add_dataframe_asset(namecustomers, dataframedf) batch asset.add_batch_definition_whole_dataframe(bd).get_batch() # 校验结果对象带 success 标记和失败行明细不只是布尔值 result batch.validate(gxe.ExpectColumnValuesToNotBeNull(columncustomer_id)) print(result.success) # False捕获到一行 NULL 想要批量运行并留档就把规则挂进套件再一键生成文档suite context.suites.add(expectation_suite_namecustomer_quality) suite.add_expectation(gxe.ExpectColumnValuesToBeBetween(columnamount, min_value0)) batch.validate(suite) context.build_data_docs() # 生成静态 DataDocs 站点以上是最短路径具体参数以官方文档为准。典型落地场景电商订单表入库前拦掉脏数据order_id非空且唯一主键重复是数据血缘问题不该留给下游报表订单金额min_value0负数通常意味着退款流程写串了邮箱字段用内置正则期望校验格式不用自己拼 SQL状态字段落在约定枚举集合内集合外的值直接判失败行数与昨日对比的漂移阈值超阈值标记本批校验失败金融风控夜间批跑前做入库校验交易时间戳必须晚于开户时间、早于当前时间风险评级必填字段完整性NULL 一律失败核心对账表行数与总额和上游核对校验失败时由 Checkpoint 触发告警并阻断下游任务踩过的坑和绕路技巧⚠️ 团队实际项目里踩过的三个现象suite.add_expectation(e)抛 RuntimeError提示该期望已属于另一个套件。原因期望对象带全局 id只能被一个套件收养把已入套的期望对象直接塞进别的套件必然报错。解法跨套件复用时复制配置新建对象或在原套件里用save()原地更新。现象生产 MySQL 上校验失败报错是一长串翻译后的 SQL很难读。原因SQL 数据源会把期望翻译成数据库端 SQL 执行报错信息也随数据库输出。解法调试期先切 pandas 内存后端复现问题确认逻辑后再切回生产数据源。现象从老版本升级后great_expectations.yml里的数据源配置和新 API 对不上。原因项目从 0.x 到 1.x 重构了数据源与配置结构旧配置不兼容。解法升级前先跑仓库内置的迁移工具great_expectations/data_context/migrator/按生成的迁移方案执行。和现有工具链怎么配合在典型技术栈里Great Expectations 位于调度器和数据库之间Airflow、Prefect 等调度任务先跑校验通过才放行业务逻辑校验结果可通过渲染器推送到 Slack、Microsoft Teams 等渠道。社区集成还包括 dbt可在模型构建后直接校验。真实数据库的接入写法可以看 集成测试示例。写在最后表不多但每张都关键或者流水线已经自动化、有明确的入库环节可以挂校验门禁——这时上 Great Expectations 收益最明显如果只是偶尔看一眼某张表先手写几条期望练熟 API比急着铺开整套设施更实际。想深入的话从仓库里的 官方文档目录 开始读最合适。【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考