Great Expectations 数据校验3个接入决策【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations当一张宽表的某个字段被上游悄悄改成了 null下游三个报表同时静默出错——这类事故往往在周五下午才浮出水面。问题不在于没人发现而在于数据长什么样的契约没有写在任何地方。Great Expectations 对数据校验的思路把断言写成声明式套件在数据被消费之前先于 CI 执行让失败停在报表生成之前。这里挑三个真实接入时一定会遇到的决策逐个说清楚取舍。为什么不直接在管道里手写 SQL 断言多数团队的第一反应是在 ETL 里加 assert或定期跑几条检查查询。手写有两个问题一是断言逻辑和管道代码耦合引擎从 pandas 换到 Spark 时检查要重写二是检查结果散落在各个作业日志里没人能回答这周数据质量整体怎么样。Great Expectations 最本质的差异是把断言变成声明式 Expectation你只声明user_id 不能重复不写怎么查。指标的计算图在 great_expectations/validator/执行层在 great_expectations/execution_engine/按引擎分流实现。同一套套件既能跑本地 CSV 回归又能跑生产仓库校验——这是推荐它而不是手写断言的主要原因。写第一套 Expectation Suite6 行代码约束 user_id 不重复内置期望有 60 多种全部在 great_expectations/expectations/core/ 下文件名即期望名需要时直接找。用 fluent API 写第一条契约保持最小化import great_expectations as gx context gx.get_context() # 复用当前目录已有的项目 suite context.add_expectation_suite(nameuser_contract) suite.add_expectation( expect_column_values_to_be_unique, kwargs{column: user_id}, # 主键不能重复 )⚠️ 别一上来堆 30 条规则。先写 3~5 条违反了生产必出事的——主键唯一、关键列非空、金额不为负——等失败率稳定了再扩。数据质量校验接入 CICheckpoint 的最小配置套件本身是被动的驱动它运行的是 Checkpoint实现和结果结构在 great_expectations/checkpoint/。validation definition 把套件绑定到目标表Checkpoint 是一组 validation definitionvd context.add_validation_definition( suite_nameuser_contract, batch_definitionbatch_def # 套件 要校验的表 ) cp context.add_checkpoint( nameusers_nightly, validation_definitions[vd] ) result cp.run() # 真正执行校验 raise SystemExit(0 if result.success else 1) # CI 里直接按退出码判失败整个门禁就是一次run()加一个 CI 步骤退出码即门禁状态不需要再学一套调度系统。门禁挂了之后通知而不是淹没一次校验可能跑几十条期望告警全量发结果没人会看。Checkpoint 的 actions 机制让你为每个门禁挑选单一通知渠道实现都在 great_expectations/checkpoint/actions.py覆盖 Slack、PagerDuty、Email、SNS。做法是只有 failed 级别才推通知内容只放摘要和 Data Docs 链接细节留在页面上。Data Docs把结果变成人能看的页面每次校验结果会生成静态页面渲染模板在 great_expectations/render/。它对团队节省的是截图沟通时间出问题时打开页面直接看失败行的样本而不是互相贴日志复现。边界与成本它兜不住的地方接入前要知道三件事它不自己盯数据。Checkpoint 必须由你或调度器触发它是门禁不是监控常驻进程。同一期望在不同引擎的支持度可能不同。上线前把要用的规则在目标引擎上各跑一遍各数据源类型对应的连接器在 great_expectations/datasource/fluent/。学习成本集中在概念层DataContext、Datasource、Batch、Suite、Checkpoint 五个名词串起来之后不会忘。下表是接入现有环境时最常用的四类数据源数据源连接器典型场景本地 CSV/Parquetpandas_datasource.py小文件、本地回归通用 SQLsql_datasource.pyPostgreSQL、SQLite 等关系库Snowflakesnowflake_datasource.py数据仓库Sparkspark_datasource.py大规模离线能选通用 SQL 连接器就优先选因为同一套规则在两个环境里都能跑切换成本最低。Great Expectations 解决的是单一问题把数据应该长什么样从口口相传的默契变成可执行、可回归的断言并挂进 CI 门禁。随着数据网格Data Mesh在团队里铺开契约层会自然成为跨团队数据协作的接口值得持续留意。想深入的话从 docs/docusaurus/docs/ 的官方文档入手有想法想贡献先读一遍 CONTRIBUTING.md。【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 8:31:18 · 阅读 1.2k Great Expectations 数据校验：3个接入决策
Great Expectations 数据校验3个接入决策【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations当一张宽表的某个字段被上游悄悄改成了 null下游三个报表同时静默出错——这类事故往往在周五下午才浮出水面。问题不在于没人发现而在于数据长什么样的契约没有写在任何地方。Great Expectations 对数据校验的思路把断言写成声明式套件在数据被消费之前先于 CI 执行让失败停在报表生成之前。这里挑三个真实接入时一定会遇到的决策逐个说清楚取舍。为什么不直接在管道里手写 SQL 断言多数团队的第一反应是在 ETL 里加 assert或定期跑几条检查查询。手写有两个问题一是断言逻辑和管道代码耦合引擎从 pandas 换到 Spark 时检查要重写二是检查结果散落在各个作业日志里没人能回答这周数据质量整体怎么样。Great Expectations 最本质的差异是把断言变成声明式 Expectation你只声明user_id 不能重复不写怎么查。指标的计算图在 great_expectations/validator/执行层在 great_expectations/execution_engine/按引擎分流实现。同一套套件既能跑本地 CSV 回归又能跑生产仓库校验——这是推荐它而不是手写断言的主要原因。写第一套 Expectation Suite6 行代码约束 user_id 不重复内置期望有 60 多种全部在 great_expectations/expectations/core/ 下文件名即期望名需要时直接找。用 fluent API 写第一条契约保持最小化import great_expectations as gx context gx.get_context() # 复用当前目录已有的项目 suite context.add_expectation_suite(nameuser_contract) suite.add_expectation( expect_column_values_to_be_unique, kwargs{column: user_id}, # 主键不能重复 )⚠️ 别一上来堆 30 条规则。先写 3~5 条违反了生产必出事的——主键唯一、关键列非空、金额不为负——等失败率稳定了再扩。数据质量校验接入 CICheckpoint 的最小配置套件本身是被动的驱动它运行的是 Checkpoint实现和结果结构在 great_expectations/checkpoint/。validation definition 把套件绑定到目标表Checkpoint 是一组 validation definitionvd context.add_validation_definition( suite_nameuser_contract, batch_definitionbatch_def # 套件 要校验的表 ) cp context.add_checkpoint( nameusers_nightly, validation_definitions[vd] ) result cp.run() # 真正执行校验 raise SystemExit(0 if result.success else 1) # CI 里直接按退出码判失败整个门禁就是一次run()加一个 CI 步骤退出码即门禁状态不需要再学一套调度系统。门禁挂了之后通知而不是淹没一次校验可能跑几十条期望告警全量发结果没人会看。Checkpoint 的 actions 机制让你为每个门禁挑选单一通知渠道实现都在 great_expectations/checkpoint/actions.py覆盖 Slack、PagerDuty、Email、SNS。做法是只有 failed 级别才推通知内容只放摘要和 Data Docs 链接细节留在页面上。Data Docs把结果变成人能看的页面每次校验结果会生成静态页面渲染模板在 great_expectations/render/。它对团队节省的是截图沟通时间出问题时打开页面直接看失败行的样本而不是互相贴日志复现。边界与成本它兜不住的地方接入前要知道三件事它不自己盯数据。Checkpoint 必须由你或调度器触发它是门禁不是监控常驻进程。同一期望在不同引擎的支持度可能不同。上线前把要用的规则在目标引擎上各跑一遍各数据源类型对应的连接器在 great_expectations/datasource/fluent/。学习成本集中在概念层DataContext、Datasource、Batch、Suite、Checkpoint 五个名词串起来之后不会忘。下表是接入现有环境时最常用的四类数据源数据源连接器典型场景本地 CSV/Parquetpandas_datasource.py小文件、本地回归通用 SQLsql_datasource.pyPostgreSQL、SQLite 等关系库Snowflakesnowflake_datasource.py数据仓库Sparkspark_datasource.py大规模离线能选通用 SQL 连接器就优先选因为同一套规则在两个环境里都能跑切换成本最低。Great Expectations 解决的是单一问题把数据应该长什么样从口口相传的默契变成可执行、可回归的断言并挂进 CI 门禁。随着数据网格Data Mesh在团队里铺开契约层会自然成为跨团队数据协作的接口值得持续留意。想深入的话从 docs/docusaurus/docs/ 的官方文档入手有想法想贡献先读一遍 CONTRIBUTING.md。【免费下载链接】great_expectationsAlways know what to expect from your data.项目地址: https://gitcode.com/GitHub_Trending/gr/great_expectations创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考