数据治理常被提及的问题是数据质量：数据中存在缺失值、异常值、分布漂移、重复、逻辑冲突等等问题，这些问题如果不加识别、不加管控，就会不断在下游放大，导致模型训练出错、分析报告误导、业务指标失真，甚至触发重大事故。与其让这些问题潜伏在系统里等待爆发，不如在数据流转与处理的各个环节里设立“护栏”——类似软件工程里的单元测试、断言机制，让数据在进入下游之前就被“检测”和“审查”。
需要注意“数据质量”这个概念。数据质量出问题不是数据自身出了问题。因为数据自身是没有问题的，而只有数据要表达自己的意义时才会出问题。因此，只有在有明确数据标准情况下才能讨论数据质量是否有问题。但是否要等待数据标准的治理活动结束才开始质量管理呢？当然不是！即刻行动起来比什么都好，我在我劝你做数字化转型时“朋克 PUNK”一点详细谈过中小企转型该有的态度。
Great Expectations
数据质量即测试
“Great Expectations”[链接1]（常简称为 GX）是一个针对数据质量、数据断言与数据文档化的平台。在这个平台里，数据团队可以用一种可表达、可测试、自动化方式对每一个数据集、每一个数据管道设定质量期望（Expectation）[注释1]，并在管道运行时自动评估、记录、报警、文档化，从而让数据质量管控成为一种“即服务化(as-a-Service）” [注释2]的实践。
GX 核心定位可以总结为：数据管道级别的断言 + 数据文档 + 报告 / 报警系统。
在软件开发中，单元测试、断言机制是保障代码正确性的基本工具；在数据工程中，GX 希望成为 “数据的断言（Assertion）框架”，即可以对每个表、列、分布、聚合等设定“期望”（Expectations），在管道运行时自动校验是否满足。
此外，GX 还有如下特点：
- 文档化
每次断言、每个数据集的特征、分布、异常情况都要被记录、可视化、可追踪。 - 可扩展 / 可定制
用户可以写自定义断言 / 验证逻辑。 - 可融入已有数据流程
支持与主流数据仓库 / ETL /数据平台结合，如 dbt、Airflow、Spark、Pandas 等。 - 协作与可观察
数据质量问题要能够向业务、分析人员、管理层提供可视化报告、预警，并定位问题。
GX Cloud 和 GX Core
GX 提供了 SaaS 服务：GX Cloud[注释3]。不需要自己搭建基础设施。 拥有 Web 界面 + API + 后台服务，允许自己定义 “期望”（Expectations），然后连接到数据源，对数据做验证（Validation），并查看结果、报告和历史趋势等。
我们使用的是 GX Core 。需要自行搭建监控管道。我认为 GX 对于中小企而言有点重。另外在落地过程中由于我们数据治理体系滞后，导致 GX 在实际工作中会遭受来自数据 Owner 的各种抱怨。但只要权衡目标，缩减预期就可以避免实施不下去的后果。我们把已把 GX 用于了数据仓库质量监控，同时 GX 也嵌入 Frappe 中作为数据质量审查管道。在数据质量这个系列我会继续介绍 GX 核心概念以及如何搭建使用 GX Core。
基本工作流程
通过一个典型的工作流程初窥 GX 全貌（在数据管道中插入 GX）。看看数据质量控制如何像代码里的单元测试、集成测试那样自然融入数据管道中：
-
在项目中初始化 Data Context → 定义数据源、存储目录、断言规则模板等。 -
为每个数据集 / 表 / 列编写或生成 Expectation Suite（期望集合）。 -
在数据管道中，每当某个数据 Batch 被生成 / 载入时，调用 Validator 用该 Batch 及其对应 Expectation Suite 进行校验。 -
Validator 执行断言，对每条期望计算是否通过 / 失败，并生成 Validation Result。 -
Checkpoint 将这个验证流程包裹起来，定期或按需触发验证运行。 -
验证完成后，Actions（触发器）可以对结果做后续处理：记录日志、发送警报、阻断流程、持久化结果、触发回滚 / 补跑。 -
Data Docs 将验证结果、断言定义、数据特征等生成 HTML 报表 / 文档供团队访问、追踪和查看历史趋势。
实际落地中可能遇到的挑战
在实际使用 GX 过程中我明显感觉在中小企实施中会遇到较多困难。就像软件工程师有几个愿意为了代码质量而去写测试用例？GX 道理一样。所以再强调一下我的观点，适当降低预期和缩小范围，但不要直接放弃。
- 初期规则设定成本高
针对每张表、每个字段设规则，需要人工理解业务、调优断言。这在初期可能是较大的工作投入。 - 断言维护与变更成本
随着业务变化、字段变动、数据模型升级等，需要不断调整期望规则。如果没有良好的流程管理，容易出“期望集体失效”问题。 - 性能 / 规模压力
在极大规模数据 /复杂断言情形下，执行断言本身会带来计算开销。尤其是对大表或流式数据，如何做到高效校验是考验。 - 工具集成与兼容性
在已有数据平台 /数据管道中（如公司已有自研 ETL 框架、定制度高的数据中台），如何与 Great Expectations 对接、兼容、嵌入可能需要一定工程投入。 - 结果治理 / 告警策略设计
断言失败后是直接阻断流程？还是降级处理？告警的频率与策略如何设计？这些治理设计需要结合团队能力与业务风险来定。数据治理是企业数字化转型永远的疼。
结语
Great Expectations 代表了一种先进质量管理理念：把“数据质量治理”从事后纠错的形式，前置到“数据的断言 / 持续校验 / 即时反馈”；让数据团队能够像写代码那样写数据质量规则，把数据质量作为数据资产管理的一部分。
同时，我多次强调 GX 对于中小企而言有点重。它不像 Frappe 那样很快能看到成效。质量管理永远都是这样一个幕后英雄：不出问题就是最好的 KPI，但是没有问题又何来的 KPI ？这非常无奈。
但是很多事情都不是线性发展的，曲线落地 GX 我认为是一个路子。最后再给几条建议：
- 先从关键业务表 / 核心字段着手
不要一开始就想把所有表都覆盖。 - 设计良好的断言治理流程
如规则审批、版本管理、规则变更评审。 - 设计合理的失败处理策略
部分断言失败不必终止流程，而是进行预警 /降级处理。 - 配工具 / 平台支持
例如把断言结果写入监控系统、告警系统、日志系统，甚至触发自动补跑。 - 持续优化与调整
断言规则要随着业务变化不断迭代和优化。
文章注释
1. Great Expectations 已经定义了非常多 Expectations，日常数据验证已经足够使用↩︎2. 数据质量检测不再是分散、手工、临时的脚本工作，而是通过标准化的服务接口（API / Web / Agent）进行集中管理和自动化运行。成了一种可编排、可复用、可观察、可协作的服务↩︎3. GX Cloud 的部署模式有几种，比如 “fully hosted”（全部托管）、“Org-hosted GX Agent”、还有 “Self-hosted Agent” 等↩︎
引用链接
[1] “Great Expectations”: https://greatexpectations.io/