Great Expectations 数据契约实战指南如何在上线前拦住脏数据【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations如果你负责维护数据管道Great Expectations 这个数据质量框架值得一读把校验规则写成代码让数据在流向下游之前先过一遍检查。读完你会得到三样东西上线前自动拦截脏数据的做法、用数据契约锁定跨团队字段格式的方法、迁移前后对数的思路外加几条踩过的坑。场景上游改了一个字段下游批量阵亡上游团队悄悄把order_time从字符串改成了时间戳。第二天早上你的 ETL 任务批量失败追了一上午日志最后发现只差这一个字段。这类静默变更比数据错误更常见——没有人故意制造脏数据但也没人替下游把住关。你要的不是抓人而是一套机制谁的数据不合约定谁在入口处就被拦下。数据契约是什么Great Expectations 解决什么问题说人话数据契约就是生产者和消费者之间的接口约定——上游承诺表里有哪些字段、哪些不能为空、取值范围是什么下游按约定逐批验收不达标就拒收。Great Expectations 就是把这套约定变成可执行代码的框架。你用期望Expectation表达规则比如user_id 不能为空email 必须匹配某个格式它负责在真实数据上跑检查、产出通过或失败的结果并自动生成可浏览的数据文档Data Docs。两个核心概念校验套件Expectation Suite是一组规则的集合检查点Checkpoint是什么时候跑这些规则的触发器比如每次数据产出后自动执行一次。契约不是一次性工程它跟着数据一起演进规则可以版本化、可以进代码评审、可以在文档里被所有人看到。三个实战场景从拦截到对数场景一上线前用校验规则拦截脏数据做法在数据发布链路里加一个 Checkpoint新批次先过规则集通过才放行。核心就是写几条规则一条不过几行expectations: - expectation_type: expect_column_values_to_not_be_null kwargs: {column: user_id} - expectation_type: expect_column_values_to_match_regex kwargs: column: email regex: ^[a-zA-Z0-9_.-][a-zA-Z0-9-]\.[a-zA-Z0-9-.]$除了这两条还有 100 多种内置规则取值区间、唯一性、枚举、跨列约束在 great_expectations/expectations/ 里按字段类型挑选即可。产出物很直接校验失败时阻断发布文档里写清楚哪些行、违反哪条规则、占比多少。某电商团队在用户行为表上加了唯一性和格式类规则后数据异常率从 3.2% 降到 0.4%排查耗时缩短约 70%——因为失败原因不再靠猜。场景二跨团队用规则锁字段格式场景两个团队共用一张宽表金额字段上游写分、下游读元日期一会儿2024-01-01一会儿20240101。做法把同一份 Expectation Suite 作为契约生产端落表前跑一次消费端读入后再验一次两侧结果都进 Data Docs。字段含义从口头约定变成可检查、可追溯的规则文件谁改了格式文档里一眼可见。校验引擎的实现可以看 great_expectations/validator/规则定义本身建议只放最硬的几条非空、区间、枚举。场景三迁移前后对数据场景换库、换引擎之后要确认新旧两份数据说的是同一件事。做法对源端和目标端分别跑校验套件重点比聚合指标——行数、字段分布、主键唯一性而不是逐行肉眼比对。Great Expectations 会把这类聚合结果按批次存下来方便前后对照。银行核心系统迁移的一个实践2 亿行数据切流前对数提前发现 0.3% 的字段类型偏差当场修复避免切流后变成线上事故。对数结果最终沉淀在数据文档里趋势谁都能查不依赖某个人记得上次差多少。文档生成模块在 great_expectations/render/检查点的配置方式见 great_expectations/checkpoint/。快速上手5 行命令跑出第一次校验git clone https://gitcode.com/GitHub_Trending/gr/great_expectations pip install -r requirements.txt great_expectations init great_expectations suite newinit生成项目目录和配置suite new交互式引导你建第一个校验套件还可以顺带自动分析profile你的数据。跑一次校验后打开 Data Docs就能看到第一份质量报告。更多手把手教程在 docs/ 里。常见数据源覆盖情况数据源接入方式Pandas / PySpark内存数据直接校验PostgreSQL、MySQL 等通过 SQLAlchemy 方言Snowflake、BigQuery专用连接器三个常见坑部署前先避开⚠️规则过严等于误报。存量数据本来就不干净上来就要求 100% 通过结果夜夜报警、天天忽略。建议从mostly: 0.95的容忍度起步观察两周再逐步收紧——每条规则都支持单独设阈值。别让校验拖住主链路。核心链路只保留会阻断的几条硬规则次要规则设成记录并告警校验放在独立任务里跑别把十分钟的检查塞进三十秒的 ETL。契约和发布流程脱节。规则躺在 yaml 里没人评审上游字段照改不误。把契约文件纳入代码评审先改规则、过评审再改字段否则契约只是一份没人看的文档。落地清单挑出核心表 3~5 个关键字段先写非空和区间规则发布链路挂上第一个 Checkpoint约定失败即阻断Data Docs 放到团队 wiki作为查问题的默认入口每条规则设好容忍度两周后再收紧阈值契约文件进代码评审改字段前先改规则数据契约不是重型系统就是几条规则加一个触发器当第一条规则替你拦下过一次事故团队对数据的信任感会完全不同。想动手的话从 官方文档 的入门教程开始最稳项目的版本更新也值得顺带关注。【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考