老灶火锅是这条街上生意最火的火锅店。每天后厨要用掉三百斤毛肚、五百份锅底，这份生意能撑住，靠的不是运气，而是一份压在采购经理抽屉里的“供货契约”：白纸上写着，牛油锅底必须用老灶熬制、毛肚新鲜度不得低于 95%、每天早上 6 点前送到后门、做不到谁负责、怎么赔偿。数据世界其实也是一家“火锅店”。AI 模型训练、实时推荐、经营报表，每一个系统都要“吃”数据。可数据生产方（供应商）和数据消费方（算法工程师、数据分析师）往往来自不同团队，如果没人规定数据长什么样、质量够不够、多久更新一次、改版了怎么通知，数据管道迟早变成一团乱麻。数据契约（Data Contract）就是数据世界的那份“供货契约”。它把数据的结构、质量、时效、责任白纸黑字写下来，让数据从生产到消费的每一站都有据可依。本文就从这份“契约”讲起，带你看懂它是什么、怎么写、怎么管、怎么用。

岗位关联

对 AI 从业者而言，掌握数据契约等于给模型训练数据装上“质检闸门”，能大幅减少数据漂移引发的返工，让你从“跪求数据”变成“按契约取数”，这是数据工程落地的核心能力之一。

目录
  1. 可视化演示
  2. 契约基本概念：数据世界的“供货契约”
  3. 契约五大要素：一张契约要写清五件事
  4. 版本演化机制：改版不是偷偷改，而是走流程
  5. 生命周期管理：从草稿到归档的四站旅程
  6. 工程实践落地：收菜必检，不合格拒收
  7. 工具生态选型：到底该找谁签这份契约
  8. 演进趋势展望：契约正在成为数据世界的通用语言
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示SOLID五大设计原则的核心思想与依赖关系，点击各原则查看详细说明和代码结构示意。

本节配有交互动效（进入视口后自动加载，约 3KB）。

单一职责原则 SRP 一个类只应有一个引起变化的原因，职责单一化 将不同职责分离到不同类中，降低耦合度 Cohesion ↑, Coupling ↓

契约基本概念：数据世界的“供货契约”

老灶火锅的采购经理老张最怕一件事：供应商不打招呼就换货。上个月，牛油供应商悄悄把“老灶熬制牛油”换成了“普通工业牛油”，锅底味道立刻不对，差评潮涌来。老张痛定思痛，拟了一份供货契约，把“老灶熬制”四个字白纸黑字写进合同，供应商违约就得赔钱。从那以后，后厨再没收到过“惊喜”。数据世界也一样：数据生产方不打招呼改字段、降质量、断更新，消费方（算法训练、报表分析）就会集体“翻车”。

数据契约（Data Contract）的本质，就是数据生产方与数据消费方之间的一份正式协议。它把数据结构、质量门槛、时效承诺、责任归属都写成明文，任何一方变更都要按流程走，避免“悄悄换货”。在 AI 数据管道里，这份契约是“数据版本与迭代”的关键抓手——没有它，训练数据漂移、特征口径错乱、字段突然消失都只能靠事后救火。它诞生的背景正是数据管道日益复杂后信任崩塌：消费方不敢用数据，生产方不知道谁在用，出了问题互相推诿。

很多人会把数据契约和 API 混淆。API 解决的是“数据怎么传输”，而数据契约回答的是“数据是什么、可靠吗、谁负责”。一份数据契约通常包含四个核心部分：模式（Schema）、质量（Quality）、承诺（Agreement）、责任（Ownership）。

有了这份“供货契约”，数据消费方再也不用每天提心吊胆地猜“今天的数据到底能不能用”。就像老张现在只需按契约验货：缺斤少两、规格不符，直接拒收并找供应商索赔。契约把“信任”从口号变成了有据可依的工程制度。

Cdata=(S,Q,A,O)C_{\text{data}} = (S, Q, A, O)
数据契约 = 一个四元组：数据结构（S）、质量标准（Q）、服务承诺（A）和责任归属（O）。它像供货契约同时写清“货品规格、品质标准、到货时限、赔偿责任”。
  1. 数据模式 S列出数据集的字段清单，相当于供货单上的“品名与规格”，规定每个字段叫什么、是什么类型、是否可为空。
    S={s1,s2,…,sn}S = \{s_1, s_2, \ldots, s_n\}
  2. 质量指标 Q定义数据必须满足的质量门槛，如完整率≥95%、唯一率=100%、新鲜度≤1 小时。
    Q={qcomplete,qunique,qfresh}Q = \{q_{\text{complete}}, q_{\text{unique}}, q_{\text{fresh}}\}
  3. 服务承诺 A生产者承诺的时效与可用性，类似“每天早上 6 点前送到后门”。
    A=(alatency,auptime)A = (a_{\text{latency}}, a_{\text{uptime}})
  4. 责任归属 O标明谁是数据的所有者（Owner），出了问题找谁、谁负责修复。
    O=(oproducer,oconsumer,oowner)O = (o_{\text{producer}}, o_{\text{consumer}}, o_{\text{owner}})

契约五大要素：一张契约要写清五件事

老张拟供货契约时，特意请了法务、采购、后厨三方坐下来逐条过：原料规格、品质标准、送货时限、违约赔偿、变更通知。他说“少写一条，后面就有十倍的麻烦”。这份谨慎完全适用于数据契约：一份完整的契约必须有足够的条款，才能在数据管道里撑起一道不塌的防线。

业界普遍认为一份完整的数据契约至少包含五大要素：数据模式（Schema）、质量指标（Quality）、服务承诺（SLA）、权责归属（Ownership）、使用条款（Terms）。其中数据模式是最核心的骨架——它不像质量指标那样可以靠监控“事后补救”，而是消费方解析数据的第一道关卡。模式定义清楚了，下游才能知道第一个字段是 ID 还是金额。

数据模式定义了每个字段的完整细节：

模式之外，质量指标、SLA、权责、条款共同构成完整契约——正如供货契约不能只写“牛油”两个字而不写“老灶熬制、新鲜度 95%、早上 6 点送达”。质量指标回答“数据够不够好”，SLA 回答“多久送到”，权责回答“坏了谁负责”，条款回答“能拿来做什么”。五要素齐全，契约才真正可执行，而不是一纸空文。

si=(namei,typei,nullablei,constrainti)s_i = (\mathrm{name}_i, \mathrm{type}_i, \mathrm{nullable}_i, \mathrm{constraint}_i)
一个字段的完整定义由四部分组成：名称、类型、可空性、约束条件。例如字段 "amount“ 必须是浮点数、不可为空、且取值 ≥ 0。这就像供货单上”毛肚"要写明产地、规格、新鲜度阈值一样。
  1. 字段名称 name字段的唯一标识，相当于货物品名，消费方靠它定位数据。
    namei字段唯一且稳定的名称\mathrm{name}_i \quad \text{字段唯一且稳定的名称}
  2. 字段类型 type规定取值范围，如整数、字符串、浮点数、时间戳。
    typei∈{int,float,string,timestamp}\mathrm{type}_i \in \{\mathrm{int}, \mathrm{float}, \mathrm{string}, \mathrm{timestamp}\}
  3. 可空性 nullable该字段是否允许为空值，允许为空就像“允许部分商品缺货并提前声明”。
    nullablei∈{true,false}\mathrm{nullable}_i \in \{\mathrm{true}, \mathrm{false}\}
  4. 约束条件 constraint业务规则约束，如金额必须非负、ID 必须唯一。
    constrainti:amount≥0\mathrm{constraint}_i : \mathrm{amount} \ge 0

版本演化机制：改版不是偷偷改，而是走流程

老张的契约里有一条规定：供应商若要换配方，必须提前 30 天书面通知，并附样品试供；若只换包装，提前 7 天即可。这项“分级通知”制度，让后厨永远知道自己在用什么货，也给了备货调整的时间。数据契约的版本机制，就是数据世界的“分级通知”。

数据契约不可能一成不变。字段新增、删除、改类型，对消费方的影响天差地别。业界通用做法是语义化版本控制（Semantic Versioning）：主版本号（Major）、次版本号（Minor）、补丁号（Patch）三位数字各司其职。

除了版本号，完整的演化机制还包括变更流程与废弃策略：每次变更先发布新版本契约、通知所有注册消费方、约定旧版本保留的缓冲期（如 6 个月），最后将旧版本标记为 Deprecated 再下线。废弃策略尤其关键，它防止“旧契约突然消失”造成的生产事故，给迁移留出足够的窗口期。

这套机制的精髓在于“变化可以预告”。就像供应商换配方前先送样品，数据契约改版前先发布新版本、给消费方留出迁移窗口——数据管道里的每个团队都不再被“惊喜”吓到。版本化让迭代有节奏、可回滚、可追溯，这正是“数据版本与迭代”主题的灵魂所在。

ΔV={1.0.0,不兼容变更（删除字段/改类型）0.1.0,兼容新增（新增可空字段）0.0.1,缺陷修复（修正描述错误）\Delta V = \begin{cases} 1.0.0, & \text{不兼容变更（删除字段/改类型）} \\ 0.1.0, & \text{兼容新增（新增可空字段）} \\ 0.0.1, & \text{缺陷修复（修正描述错误）} \end{cases}
版本号三位数字分别是主版本、次版本、补丁。破坏性变更必须升主版本，兼容性新增升次版本，修复升补丁版本——就像换配方要提前 30 天，换包装只需提前 7 天。
  1. 主版本 Major发生破坏性变更（breaking change）时 +1，例如删除字段、修改字段类型。
    Vmajor=Vmajor+1V_{\mathrm{major}} = V_{\mathrm{major}} + 1
  2. 次版本 Minor向后兼容的新增（如增加可空字段）时 +1，消费方旧逻辑不受影响。
    Vminor=Vminor+1V_{\mathrm{minor}} = V_{\mathrm{minor}} + 1
  3. 补丁版本 Patch普通修复（如修正描述、默认值）时 +1，行为几乎不变。
    Vpatch=Vpatch+1V_{\mathrm{patch}} = V_{\mathrm{patch}} + 1

生命周期管理：从草稿到归档的四站旅程

一份供货契约不是写完就永远生效。老张的流程是：先由采购拟草稿，法务和供应商逐条评审，签字后生效执行，每年续签审查，最终淘汰换新。每一步都有状态标记，贴在档案柜上，谁也不知道哪份契约“没头没尾”。数据治理同样需要这种清晰的阶段感。

数据契约的生命周期通常被建模为一个状态机，每个状态代表契约当前的可操作性与效力。状态流转不是随意的，每次转移都有明确的触发条件：评审通过才发布、监控中发现新版本才弃用、缓冲期结束才归档。

这个状态机看似简单，却解决了数据工程里最大的痛点：版本多了之后“没人知道哪份契约还活着”。有了生命周期管理，契约仓库就像老张的档案柜，哪份生效、哪份待审、哪份快过期，一目了然。契约开发、审查批准、发布落地、监测反馈四个环节形成闭环，每一步都有系统记录。

更重要的是，生命周期把“人的沟通”变成了“系统状态”。状态流转自动触发通知：评审通过自动发布、进入弃用自动提醒消费方迁移、归档后自动回收资源。正如老张的档案柜里每份契约的到期时间都有标注，数据契约的生命周期管理让治理过程有迹可循、责任清晰，是“数据可信层”工程的基石。

Status:Draft→评审Published→监控Deprecated→下线Archived\text{Status}: \mathrm{Draft} \xrightarrow[\text{评审}]{} \mathrm{Published} \xrightarrow[\text{监控}]{} \mathrm{Deprecated} \xrightarrow[\text{下线}]{} \mathrm{Archived}
契约状态依次流转：草稿 → 已发布 → 已弃用 → 已归档。发布前要评审，发布后要监控，弃用是为了给旧消费方缓冲期，归档则彻底退出服务，只保留历史记录。
  1. 草稿 Draft契约编写中，尚未生效。此时生产方与消费方可以反复讨论字段和质量阈值。
    Status=Draft,仅可编辑不可消费\mathrm{Status} = \mathrm{Draft}, \quad \text{仅可编辑不可消费}
  2. 已发布 Published评审通过并注册到契约仓库，生产方开始履约、消费方按契约取数。
    Status=Published,双方正式生效\mathrm{Status} = \mathrm{Published}, \quad \text{双方正式生效}
  3. 已弃用 Deprecated新版本发布后，旧版本进入过渡期。仍可消费，但会提示“即将下线”。
    Status=Deprecated,保留迁移缓冲期\mathrm{Status} = \mathrm{Deprecated}, \quad \text{保留迁移缓冲期}
  4. 已归档 Archived缓冲期结束，旧契约被归档，只读且不再提供数据。
    Status=Archived,只读存档\mathrm{Status} = \mathrm{Archived}, \quad \text{只读存档}

工程实践落地：收菜必检，不合格拒收

老张定下规矩：每天早上收货时，采购员必须按契约逐项验货——数箱数、看新鲜度、抽查重量，三项缺一不可。有一次毛肚新鲜度只有 92%，低于契约规定的 95%，整车拒收，供应商连夜补货。老张说“验收这个动作省不得，省一次后面赔十次”。

数据管道要践行同一条规矩：消费前置校验。工程实践上，落地数据契约需要三件套——契约测试（Contract Test）、质量监控（Quality Monitor）、异常处理（Error Handling）。核心度量是“契约符合率”：

工程上还强调“契约测试前置、质量监控兜底”。契约测试在数据进入消费管道前运行，像收货验货；质量监控在运行期持续运行，像后厨随机抽查。两者配合的典型分工是：数据平台团队维护契约与校验网关，算法团队按契约声明消费数据，业务方参与契约评审。异常处理则负责失败时的通知、重试与降级策略。

这套流程把“信任”落实成了自动化防线。就像老张拒收 92% 新鲜度的毛肚一样，数据管道可以在契约违规时自动拦截脏数据、给生产者推送失败原因，而不是让下游模型在沉默中崩溃。契约测试与监控双保险，让数据工程从“人治”走向“法治”，这是每个算法工程师都该熟悉的地基工程。

P=npassntotal×100%P = \frac{n_{\text{pass}}}{n_{\text{total}}} \times 100\%
契约符合率 = 通过校验的数据包数量 ÷ 总数据包数量。它像验收抽检的合格率，低于门槛就要触发告警或拦截，防止脏数据流入下游模型。
  1. 通过项 n_pass通过模式校验与质量检查的数据记录数。
    npass=∑i=1ntotalI(check(ri)=true)n_{\text{pass}} = \sum_{i=1}^{n_{\text{total}}} \mathbb{I}(\text{check}(r_i) = \text{true})
  2. 总检查项 n_total实际接收并接受检查的数据记录总数。
    ntotal=管道累计接收记录数n_{\text{total}} = \text{管道累计接收记录数}
  3. 符合率 P通过项与总数之比，常见行业阈值是 ≥99%，低于该值立即触发告警。
    P≥0.99否则触发告警并拦截P \ge 0.99 \quad \text{否则触发告警并拦截}

工具生态选型：到底该找谁签这份契约

老张写契约时发现，法务、采购、后厨各有一套意见，光靠手工维护根本跟不上。后来他采购了一款供应链管理系统，把契约模板、到期提醒、验收记录全部数字化，效率翻了一倍。选对工具，往往比多写十页制度更管用。

数据工程也是如此。早期团队用 YAML 手写契约、用 CI 脚本做校验，能跑通但维护成本极高。当契约数量超过几十份，就必须借助专门的工具生态。选型通常被转化为一个加权评分问题：

主流选项分三类：开源方案（如 Data Contract Specification + Great Expectations 组合、dbt 生态），适合技术能力强、希望掌控细节的团队；商业平台（如 Collibra、Atlan 等数据治理平台内置契约能力），适合预算充足、追求开箱即用的大企业；自研内置（在自有数据平台中实现轻量契约层），适合有特殊流程、深度绑定内部系统的团队。选型关键考量包括团队规模、已有技术栈、跨团队协作密度。

选型的本质是“用工具固化流程”。就像老张买供应链管理系统替代手工台账，数据团队选择契约工具是为了把版本控制、质量校验、通知订阅全部自动化，让契约从“文件夹里的文档”变成“系统里活着的规则”。好的工具能让契约的维护成本趋近于零，团队才愿意长期坚持下去。

Score=∑i=1nwiri\text{Score} = \sum_{i=1}^{n} w_i r_i
工具选型评分 = 每个评价维度的得分 × 权重之和。维度包括 schema 管理、版本控制、质量监控、告警通知等，权重由团队阶段与规模决定。
  1. 评价维度 r_i逐项评估候选工具的 schema 管理、质量校验、版本控制、生态集成等能力。
    ri∈[0,5],i∈{1,2,…,n}r_i \in [0, 5], \quad i \in \{1, 2, \dots, n\}
  2. 权重 w_i按团队战略给每个维度配权重，如初创团队更看重快速集成，大团队更看重权限治理。
    ∑i=1nwi=1\sum_{i=1}^{n} w_i = 1
  3. 总分 Score加权求和，得分最高者胜出，再结合人力投入做二次取舍。
    Score=w1r1+w2r2+⋯+wnrn\text{Score} = w_1 r_1 + w_2 r_2 + \dots + w_n r_n

演进趋势展望：契约正在成为数据世界的通用语言

老张最近发现，新的采购系统已经开始自动生成契约草案：根据历史收货数据推荐新鲜度阈值，供应商一改配方系统就自动比对并预警。他说“这合同，越来越聪明了”。数据契约正走在同一条路上：从人写的文档，变成机器可执行、可自动维护的制品。

一个重要的建模视角是：数据可用性不再是单点指标，而是多个环节通过率的乘积。这意味着契约的每个环节都必须可靠，否则整体信任归零。

展望未来，三个趋势值得关注：契约智能生成——AI 根据历史数据与业务元数据自动生成契约草案，并持续推荐质量阈值；微服务全链路融合——每个服务的数据输出都自带契约，像 API 文档一样成为工程标配；数据网格（Data Mesh）——将契约作为数据产品的核心交付物，每个数据域为自己的契约负责。

契约终将像老张的智能采购系统一样“自己会思考”：自动识别数据漂移、主动提醒契约过期、智能建议新阈值。到那时，数据契约不再是一纸文书，而是一套自我演进的数据治理神经系统。这是每个 AI 数据管道工程师都值得押注的方向——越早掌握，越能在数据可信层占据先机。

P(数据可用)=P(S)×P(Q)×P(A)P(\text{数据可用}) = P(S) \times P(Q) \times P(A)
数据可用概率 = 模式通过率 × 质量通过率 × 承诺达成率。乘积模型揭示“木桶效应”：任一环节失守，整体可用性随之归零，因此契约必须全链路自动校验。
  1. 模式通过率 P(S)数据与契约 schema 完全匹配的概率，决定数据能否被正确解析。
    P(S)=模式匹配的数据量总数据量P(S) = \frac{\text{模式匹配的数据量}}{\text{总数据量}}
  2. 质量通过率 P(Q)完整率、唯一率、新鲜度同时达标的数据占比。
    P(Q)=QpassNtotalP(Q) = \frac{Q_{\text{pass}}}{N_{\text{total}}}
  3. 承诺达成率 P(A)时效、可用性等 SLA 被满足的概率，代表生产方的“履约水平”。
    P(A)=SLA 达成的周期数观察周期总数P(A) = \frac{\text{SLA 达成的周期数}}{\text{观察周期总数}}
  4. 乘积关系三项相乘得到整体可用性，任何一项接近 0 都会拖垮整体。
    P=P(S)⋅P(Q)⋅P(A),取极小即整体失效P = P(S) \cdot P(Q) \cdot P(A), \quad \text{取极小即整体失效}

AI 应用场景

场景一：大模型训练数据质检闸门

阶段：数据准备与特征工程

解决的问题：大模型微调前要消费海量用户行为数据，传统靠“字段文档 + 口头通知”，埋点团队改字段后训练管道直接崩溃，返工成本以周计。数据契约让每个数据源在进入训练管道前自动通过契约校验，schema 漂移与质量下降在消费前被拦截，数据从“不可控输入”变成“可验收的货物”。

具体案例：某 NLP 团队微调对话模型时，消费用户日志管道。数据契约规定 user_id 为 string 且非空、event_type 枚举白名单、timestamp 新鲜度 ≤ 5 分钟。某天新增了 event_type=voice 的埋点，契约从 1.2.0 升级到 1.3.0（兼容新增），校验网关自动放行，训练管道零感知完成适配。若没有契约，这次改动又会引发一整周的“字段找不到”排查。

场景二：在线离线特征一致性保障

阶段：模型服务与在线推理

解决的问题：推荐系统最怕“训练用离线特征、推理用在线特征，两边口径不一致”。传统靠开会对齐口径，改一次崩一次。数据契约把特征语义、计算窗口、统计口径写成可执行的 schema，在线离线共用同一份契约校验规则，从源头消除训练/推理偏差（Training-Serving Skew）。

具体案例：某推荐团队将“近 7 天点击量”特征发布为两份数据：离线表（T-1 全量）与在线流（Kafka 实时），统一挂在同一份数据契约下。契约声明字段类型、时间窗口、聚合口径，每日运行一致性校验任务，偏差超过 1% 自动拦截并告警。落地后训练/推理偏差从 8% 降到 0.5% 以内，模型线上效果显著回升。

场景三：跨团队数据共享与数据产品化

阶段：数据治理与数据消费

解决的问题：业务团队与数据团队对"GMV"“DAU“等指标口径争论不休，报表经常被打回重做。数据契约把指标口径契约化，业务方按契约订阅数据产品，变更时自动收到通知，数据消费从”猜度量“变成”按契约取数”。

具体案例：电商公司数据团队发布“交易域 GMV 日报”数据契约，写明 GMV = 已支付订单金额 − 退款金额、时间戳按支付时间归属等规则，并配套质量监控（完整率 ≥ 99.5%、时效 < 30 分钟）。市场部按契约订阅，口径再无争执；新增字段时契约版本更新并自动推送变更说明，双方协作效率大幅提升。

Python 演示

python69 行
from datetime import datetime  class DataContract:    """极简数据契约: 模式 + 质量 + 版本"""     def __init__(self, schema, quality, version="1.0.0"):        self.schema = schema          # 字段名 -> 期望类型        self.quality = quality        # 质量阈值, 如完整率下限        self.version = version        # 语义化版本号     def validate_schema(self, record):        # 检查字段是否齐全且类型正确        missing = [f for f in self.schema if f not in record]        extras = [f for f in record if f not in self.schema]        wrong = [            f for f, t in self.schema.items()            if f in record and not isinstance(record[f], t)        ]        passed = not (missing or extras or wrong)        return passed, {"missing": missing, "extra": extras, "wrong_type": wrong}     def validate_quality(self, rows, now=None):        # 检查完整率和新鲜度两个质量指标        if not rows:            return False, {"completeness": 0.0, "stale": 0}        now = now or datetime.now()        total = len(rows)        complete = sum(            1 for r in rows            if all(r.get(f) is not None for f in self.schema)        )        max_age = self.quality.get("max_age_seconds", 0)        fresh = sum(            1 for r in rows            if max_age == 0 or (now - r.get("_ts", now)).total_seconds() <= max_age        )        completeness = complete / total        passed = completeness >= self.quality.get("min_completeness", 1.0)        return passed, {"completeness": completeness, "stale": total - fresh}     def bump_version(self, major=0, minor=1, patch=0):        # 按语义化版本规则升级: 不兼容/新增/修复        parts = [int(x) for x in self.version.split(".")]        parts[0] += major        parts[1] += minor        parts[2] += patch        self.version = ".".join(map(str, parts))        return self.version  def main():    schema = {"user_id": int, "city": str, "amount": float}    contract = DataContract(schema, {"min_completeness": 0.9})    ok_row = {"user_id": 1, "city": "上海", "amount": 99.5}    bad_row = {"user_id": "x", "amount": "Y"}    print("合法记录契约校验:", contract.validate_schema(ok_row))    print("非法记录契约校验:", contract.validate_schema(bad_row))     rows = [        {"user_id": 1, "city": "上海", "amount": 88.0, "_ts": datetime.now()},        {"user_id": 2, "city": "北京", "amount": None, "_ts": datetime.now()},    ]    print("批量质量校验:", contract.validate_quality(rows))    print("升级契约版本:", contract.bump_version(major=1))  if __name__ == "__main__":    main()
目的：用一个极简 DataContract 类演示数据契约三大核心能力——模式校验、质量校验、语义化版本升级，对应文中“供货契约逐项验收”的过程。
  1. contract = DataContract(schema, {"min_completeness": 0.9})创建契约对象，schema 规定字段及类型，quality 设定完整率下限，相当于拟好一份供货契约。
  2. missing = [f for f in self.schema if f not in record]找出记录里缺失的必填字段，等于验收时核对货品是否缺项。
  3. wrong = [f for f, t in self.schema.items() if f in record and not isinstance(record[f], t)]找出类型不匹配的字段，相当于“货不对板”。
  4. passed = not (missing or extras or wrong)只要有任何一项违约，契约校验就不通过。
  5. completeness = complete / total完整率 = 非空字段完备的记录数 ÷ 总记录数，对应质量指标中的完整率。
  6. parts[0] += major主版本号递增，对应破坏性变更时契约升级为 2.0.0。
  7. print("合法记录契约校验:", contract.validate_schema(ok_row))输出校验结果，消费方据此决定是否放行数据。

常见误区

误区很多人觉得数据契约就是把字段名和类型写下来，整理成一篇 wiki 文档发个链接就算完事了。文档有了，契约就算签了。

正解数据契约是“活的协议”，包含 schema、质量、SLA、权责四元组，并且要接入 CI 测试与运行时监控。就像供货契约不只是一张“菜品清单”，还必须有新鲜度标准和违约赔偿条款。文档写了没人执行，契约却会验收、会拦截、会告警——这是本质区别。

为何常见：数据字典的老概念太深入人心，大家天然把“写清楚结构”当成数据契约的全部，忽视了契约的“可执行性”这一灵魂。

误区既然签了契约，就应该固定不变，任何改动都是违约。所以团队害怕改契约，宁可数据烂着也不敢升级版本。

正解数据永远在演化，契约必须有版本机制。兼容性新增走 minor 升级，破坏性变更走 major 升级并给消费方留缓冲期。契约的价值不是禁止变化，而是让变化“可预告、可评估、可追溯”，就像供应商换配方要提前 30 天书面通知，而不是永远不换。

为何常见：把“契约”联想成法律合同的刚性条款，忽略了数据契约本质上是工程制品，需要随数据一起迭代。

误区schema 校验全绿，就认为数据靠谱。有人只做类型检查，觉得“能解析就等于能用”。

正解字段正确不代表数据可用。完整率 50%、重复率 80%、一周没更新，都会让下游模型悄悄崩溃。质量指标与模式校验是并列的契约要素，就像毛肚“重量合格”但“不新鲜”，后厨照样没法用。契约五要素缺一不可。

为何常见：schema 校验最简单直观、最容易自动化，给人造成“数据没报错就是没问题”的错觉。

误区数据团队自己写契约、自己执行校验，消费方完全不参与，甚至不知道契约存在。数据团队觉得“我已经写得很清楚了”。

正解契约是“双方协议”，消费方必须有权提出质量诉求、参与评审。就像供货契约必须供应商和采购方都签字才生效，单方面说了不算。消费方不参与，生产方就会闭门造车，契约变成自说自话，质量痛点永远没人提。

为何常见：数据团队天然掌握 schema 信息，容易陷入“自我服务”心态，而消费方的诉求缺乏表达渠道，久而久之双方失去对话习惯。

误区我们在管道里加了质量监控，出问题会告警，就不用花精力写契约了。监控屏幕上的绿灯让人产生安全感。

正解监控是“事后发现”，契约是“事先约定 + 自动拦截”。监控告诉你“毛肚坏了”，契约规定“坏了的毛肚不许进后厨”——两者互补而非替代。契约把质量门槛前置到消费之前，监控负责持续兜底并量化履约水平，缺一不可。

为何常见：监控见效快、告警直观，让团队误以为它已经覆盖了契约的防御性作用，忽略了契约在“约定标准”这件事上的不可替代性。

面试题

Q1. 数据契约最核心的作用是什么？

单选题 · easy

  • A.让数据生产方和消费方对齐结构与质量预期← 正确答案
  • B.提升数据库查询性能，降低整体延迟
  • C.替代数据仓库成为新的存储引擎
  • D.自动生成机器学习模型的训练样本

答案：A。数据契约是生产方与消费方之间的正式协议，旨在规约数据结构、质量与责任，因此 A 正确。它不负责查询性能、存储引擎或样本生成，B、C、D 均与契约职能无关。

Q2. 下列哪一项属于数据契约的五大要素？

单选题 · easy

  • A.数据模式（Schema）与质量指标← 正确答案
  • B.Kafka 的主题分区数配置
  • C.Spark 执行器数量参数
  • D.GPU 显存的分配策略

答案：A。数据契约五大要素包括数据模式、质量指标、服务承诺、权责归属、使用条款。Kafka 分区、Spark 参数、GPU 配置都属于基础设施调优，与契约的“约定数据本身”范畴无关，故选 A。

Q3. 数据契约与 API 的根本区别是什么？

单选题 · mid

  • A.契约额外承诺数据结构质量与责任← 正确答案
  • B.API 永远比契约传输数据更快
  • C.契约只能应用在批处理场景中
  • D.契约取代了 API 完成数据搬运

答案：A。API 解决“怎么传输”，数据契约回答“数据是什么、好不好、谁负责”，A 正确。B 无依据；C 错误，契约同样适用于流式场景；D 错误，契约是约定而非传输通道，与 API 互补而非替代。

Q4. 语义化版本中，出现破坏性字段变更应如何升级？

单选题 · mid

  • A.主版本加一，如从 1.2.0 升到 2.0.0← 正确答案
  • B.次版本加一，如从 1.2.0 升到 1.3.0
  • C.补丁加一，如从 1.2.0 升到 1.2.1
  • D.保持版本不变，直接替换字段

答案：A。删除字段或修改类型属于破坏性变更，必须升级主版本才能让消费方意识到风险，A 正确。B 是兼容新增，C 是缺陷修复，D 违反版本管理最基本的原则——重大变更必须可追溯。

Q5. 契约生命周期里“已弃用”状态的含义是什么？

单选题 · mid

  • A.旧版本仍在运行但等待下线过渡← 正确答案
  • B.契约刚创建还未接受正式评审
  • C.契约已通过评审并正式生效
  • D.契约被归档且完全停止服务

答案：A。Deprecated 表示新版本已发布、旧版本仍可消费但进入下线倒计时，A 正确。B 是 Draft 草稿态，C 是 Published 发布态，D 是 Archived 归档态。四者区分的关键是“是否仍生效、是否还能消费”。

Q6. 下列哪些属于数据契约中的质量指标？

多选题 · mid

  • A.完整率：非空记录占总记录的比例← 正确答案
  • B.唯一率：主键不重复的记录占比← 正确答案
  • C.新鲜度：数据距离当前时间的新旧程度← 正确答案
  • D.画布尺寸：前端页面的渲染分辨率

答案：ABC。完整率、唯一率、新鲜度是数据质量三大经典指标，A、B、C 正确。画布尺寸完全无关，D 是干扰项。质量指标对模型训练至关重要——脏数据比缺数据更隐蔽也更危险。

Q7. 关于契约测试与质量监控之间的关系，正确的是？

单选题 · hard

  • A.契约测试消费前拦截，监控持续兜底← 正确答案
  • B.两者功能重复，只需保留其中一个
  • C.监控告警可以完全替代契约测试
  • D.契约测试只在模型推理阶段运行

答案：A。契约测试在数据进入消费管道前执行，相当于“收货验货”；质量监控在运行期持续运行，相当于“后厨抽查”。二者是前置与兜底的关系，A 正确。B、C 否定了互补性，D 混淆了测试阶段——契约测试属于数据准备阶段，与推理无关。

Q8. 关于数据契约版本演化，下列说法正确的是？

多选题 · mid

  • A.新增可空字段通常升级次版本← 正确答案
  • B.删除字段属于破坏性变更← 正确答案
  • C.修复文档错误可走补丁版本← 正确答案
  • D.任意变更都必须升级主版本

答案：ABC。语义化版本规则：兼容新增升 minor（A 对），删除字段破坏兼容需升 major（B 对），纯文档修复升 patch（C 对）。D 过于绝对，只有破坏性变更才必须升级主版本，普通修复和兼容新增都不需要。

Q9. 数据契约里的权责归属要素指向什么？

单选题 · easy

  • A.指明数据负责与问题追溯的对象← 正确答案
  • B.规定 SQL 查询的语法规范
  • C.决定模型的激活函数种类
  • D.配置 GPU 集群的调度策略

答案：A。权责归属（Ownership）标明谁是数据 Owner、出了问题找谁修复，是契约可执行性的保障，A 正确。SQL 语法、激活函数、GPU 调度均与契约要素无关。就像供货契约必须写明“供应商承担赔偿责任”一样。

Q10. 实施数据契约后，哪些属于典型收益场景？

多选题 · hard

  • A.训练数据漂移在消费前被拦截住← 正确答案
  • B.在线与离线特征口径一致可查← 正确答案
  • C.跨团队共享数据的质量可量化← 正确答案
  • D.彻底消灭管道中所有延迟问题

答案：ABC。契约通过前置校验拦截数据漂移（A），通过统一 schema 消除训练/推理偏差（B），通过质量指标让数据质量可度量（C），三者均是契约落地的直接收益。D 是绝对化表述，契约无法消灭网络、计算等物理延迟，属于过度承诺。