数据质量与契约强绑定概述
大家好，我是这门课的主讲。做了十几年数据架构，我见过太多因为数据质量问题翻车的项目。说白了，数据质量不是技术问题，而是信任问题。你想想看，如果连数据的生产者都不清楚自己该产出什么、怎么产，那下游用数据的人怎么可能放心？
今天这第一讲，我们先聊聊基础概念。什么是数据质量？什么是数据契约？为什么要把它们强绑定在一起？
数据质量的定义
数据质量，听起来很抽象。我习惯用一个简单的定义：数据是否满足其预期用途的程度。
举个例子。你做一个用户画像系统，需要用户的年龄字段。如果这个字段有 30% 是空的，或者填的是「999岁」，那这个数据质量就是不合格的。因为它没法支撑你的业务场景。
数据质量通常从以下几个维度衡量：
| 维度 | 说明 | 我踩过的坑 |
|---|---|---|
| 完整性 | 数据是否有缺失 | 曾经有个订单表，支付时间字段一半是空的，导致财务对账对了一个月 |
| 准确性 | 数据是否真实反映客观事实 | 用户地址字段里填「火星」的，我见过不止一次 |
| 一致性 | 不同系统间的数据是否矛盾 | CRM 里用户等级是 VIP，订单系统里却是普通用户，这种冲突最头疼 |
| 及时性 | 数据是否在需要的时候可用 | T+1 的数据报表，老板下午开会要，你上午才跑出来，这就晚了 |
| 唯一性 | 是否存在重复数据 | 同一个客户在数据库里出现三条记录，三条地址还不一样 |
核心观点：数据质量不是的「好」或「坏」，而是相对的「够用」或「不够用」。脱离业务场景谈数据质量，都是耍流氓。
数据契约的概念
数据契约，说白了就是一份数据生产者和数据消费者之间的协议。
我举个例子你就明白了。你负责维护一个用户基础信息表，下游有三个团队在用：推荐团队需要用户标签，风控团队需要实名状态，财务团队需要付费记录。每个团队对数据的要求都不一样。
数据契约就是把这些要求明确写下来：
- 生产者承诺：我每天凌晨 2 点前产出数据，字段 A 不能为空，字段 B 取值范围是 1-5
- 消费者承诺：我不会要求你提供超出你能力范围的数据，我会在数据产出后 1 小时内消费完
嗯，这里要注意。数据契约不是一张纸，而是一套可执行、可验证的规则。它应该包含：
- Schema 定义：字段名、类型、是否可为空、默认值
- 质量约束：完整性阈值、准确性规则、一致性校验
- SLA 承诺：产出时间、可用性、响应时间
- 变更流程：字段变更怎么通知、版本怎么管理
一个小建议：刚开始做数据契约时，别想着一步到位。先挑一个核心表，和下游团队坐下来聊清楚，把契约写出来。哪怕只有 5 个字段，也比没有强。
为什么需要强绑定
你可能会问：数据质量和数据契约，分开管理不行吗？
我告诉你，不行。原因很简单——没有契约的质量是空话，没有质量的契约是废纸。
我在项目中遇到过这样的情况：数据团队制定了很完善的质量规则，但下游根本不知道这些规则的存在。结果数据出了问题，下游跑过来质问，数据团队说「我们规则里写了啊」，下游说「我怎么知道你们有规则？」。这就是典型的脱节。
强绑定要解决三个核心问题：
- 责任明确：谁生产、谁消费、谁负责，白纸黑字写清楚
- 可追溯：数据出问题，能快速定位是哪个环节、哪个字段、哪条规则没满足
- 自动化：契约不是摆设，要能自动校验、自动告警、自动阻断
避坑指南：我曾经在一个项目里，把数据契约写成了 50 页的 Word 文档。结果呢？没人看，也没人执行。后来我改成代码化的契约，用 YAML 定义规则，集成到 CI/CD 流水线里，每次数据发布自动校验。效果立竿见影。
课程目标与学习路径
这门课的目标很明确：让你能独立设计并落地一套数据质量与契约强绑定的体系。
整个课程分四个阶段：
| 阶段 | 内容 | 你能学到什么 |
|---|---|---|
| 基础篇 | 数据质量体系、数据契约设计、强绑定原理 | 建立完整认知框架 |
| 工具篇 | Great Expectations、dbt、Apache Avro 等工具实战 | 掌握主流工具的使用和集成 |
| 实战篇 | 从零搭建数据质量平台、契约管理平台 | 具备独立落地能力 |
| 进阶篇 | 大规模数据治理、实时数据质量、AI 辅助质量检测 | 解决复杂场景问题 |
下面这张图，是整个课程的知识体系框架。你可以先有个整体印象。
嗯，这就是第一章的全部内容。数据质量不是一个人的事，也不是一个工具能解决的。它需要一套体系、一份契约、一种机制，把所有人绑在一起。后面的课程，我们会一步步把这些东西落地。