Great Expectations 数据契约让坏数据在 CI 阶段就被拦下【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations早上九点告警邮件还没看完群里又弹出一条用户表主键出现 3700 个空值聚合任务重试两次仍失败报表要延迟了。你翻上游代码才发现——ID 生成逻辑昨晚刚被人改过上游团队全程没发一条通知。这类事故很少是恶意为之多半败在假设上你假设主键不会为空上游假设格式可以随便改。Great Expectations是一个 Python 的数据契约与数据质量校验库把这类假设变成声明式的规则在流水线或 CI 里自动执行让坏数据在进门那一刻就被拦下而不是第二天早上才被发现。问题本质坏在假设不在数据说直白点数据契约就是把数据应该长什么样写成生产者与消费者之间可执行的协议字段非空、主键唯一、邮箱格式、金额区间、更新频率。关键词是可执行。契约不是 wiki 里没人翻的文档而是每一批数据到达时都能给出通过或失败结论的规则。协议一旦被打破流水线当场失败下游任务根本不会醒。所以数据校验的价值不是多一个监控而是把出错成本的支付时点从第二天早上全组排查挪到数据进门那一刻责任方排查。排查时间从小时级缩回分钟级靠的不是更快的排查而是更短的暴露路径。机制深挖Checkpoint 到底做了什么在 Great Expectations 里一份数据契约由两部分组成Expectation Suite一组校验规则以文件形式存在项目里可以走代码评审和Checkpoint把一次或多次校验打包执行的触发点。调用checkpoint.run()后内部链路是固定的先按 batch 请求取出真实的数据批次交给 ValidatorValidator 把每条 expectation 编译成指标查询——在数据库上是 SQL 语句在内存 DataFrame 上是 pandas 操作——逐条算出结果最后 Checkpoint 把所有结果汇总成一个success布尔值再触发通知、更新 Data Docs 等后续动作。这条链路可以对照源码验证Checkpoint 实现 的执行入口只有几十行规则到指标的编译在 校验引擎 里完成。5 分钟验证在本地跑通第一条数据契约不用数据库一个内存 DataFrame 就够import pandas as pd import great_expectations as gx from great_expectations.expectations import ExpectColumnValuesToNotBeNull context gx.get_context() ds context.datasources.add_pandas_dataframe(namedemo) df pd.DataFrame({user_id: [1, None, 3], email: [ax.com, bad, cy.com]}) batch ds.read_dataframe(df, batch_identifiers[v1]) suite context.suites.add(nameuser_contract, expectations[ ExpectColumnValuesToNotBeNull(columnuser_id), gx.expectations.ExpectColumnValuesToMatchRegex(columnemail, regexr^[a-z][a-z]\.[a-z]$), ]) result context.run_validation(batchbatch, suitesuite) print(result.success) # FalseFalse才是你希望看到的结果——说明契约真的在工作一条主键为空、一条邮箱格式非法全被抓出来了。要接入真实数据源只需把add_pandas_dataframe换成对应的 数据源连接器规则一行不用改。让校验结果变成所有人能看的页面数据质量工作有个隐蔽的坑校验结果只落在日志文件里没人看等于没做。Great Expectations 把每次校验结果渲染成静态页面Data Docs包含每条规则的通过率、失败行的抽样值甚至一段可直接复制的 SQL用来捞取全部失败记录。页面由 文档渲染模块 生成托管在任何静态站点上即可。它还是数据是坏的还是代码是坏的这类争论里的证据。另外注意Data Docs 里默认只展示抽样失败行要全量明细时按页面里的 SQL 去查或在规则里配置 result_format。✅选型判断谁适合用谁不适合适合的批处理与近实时流水线、跨团队的数据依赖、需要审计留痕的场景——Data Docs 天然就是留痕证据。数据源覆盖面够广关系型数据库基本都走 SQLAlchemy另有 Spark、Pandas 和云数仓连接器。不适合的毫秒级延迟的行内校验放应用层做一次性 ad-hoc 分析pandas 加断言更快别上重工具。工具定位适用场景Great Expectations数据契约全链路规则、执行、报告跨团队批处理流水线、审计要求PanderaDataFrame 模式校验单 Python 项目的轻量检查DeequSpark 原生指标库Spark 生态内的数据校验一句话区分Pandera 和 Deequ 回答数据是否符合模式Great Expectations 多回答一层数据是否符合业务约定并且拿得出证明。⚖️真实会踩的三个坑阈值写死在规则里。均值在 100 到 200 之间写进规则业务一增长就天天红灯团队会对告警脱敏。解法用套件参数或mostly比例阈值把阈值抽到配置里一处调整全局生效。批次太大校验变负担。一张亿级大表全量校验跑 20 分钟团队自然会想办法绕过。解法按日期分区、只校验新分区。数据契约的执行成本必须低于问题成本否则它活不过第一个季度。校验通过但没人看结果。Checkpoint 跑完没配任何 actionData Docs 也不更新校验就成了形式主义。解法至少接一个通知渠道Slack、邮件、PagerDuty让失败这件事本身可见Data Docs 定期刷新。回到那个告警早晨如果那份用户契约当时就在流水线里那 3700 个空主键会在 ETL 跑完的分钟级时间里让构建失败下游任务压根不会被叫醒第二天早上的排查也省了。这周可以做的下一步挑一张项目里最不稳的表给主键和关键字段加 23 条非空校验挂进一个 CI 任务先观察一周。你会直观体会到数据先被检查、再被入库是什么感觉——剩下的事是照着它把契约一条一条写全。【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考