Appearance
数据架构：让企业事实具有统一语义、责任与证据
某门店系统显示一件商品库存为 100，商城也显示 100，仓储系统同样显示 100。三个数字相同，并不意味着数据一致：门店记录的是实物数量，商城展示的是扣除锁定后的可售数量，仓储系统记录的可能是昨天批量同步的账面数量。
数据架构要解决的不是“把数据集中到一个库”，而是让企业知道每个数字代表什么、由谁产生、谁能修改、多久有效、经过哪些转换，以及发生冲突时谁拥有最终裁决权。
数据对象不等于数据库表
数据库表是某个应用的存储实现，企业数据对象描述跨系统仍然成立的业务事实。
| 层次 | 示例 | 关注点 |
|---|---|---|
| 业务概念 | 商品、客户、订单、库存、地点 | 企业共同语言和边界 |
| 业务事实 | 商品已上架、库存已锁定、订单已支付 | 谁在何时改变了什么 |
| 逻辑模型 | 标识、属性、关系、状态和规则 | 语义一致性与生命周期 |
| 物理模型 | 表、字段、索引、分区和文件 | 性能、存储和实现约束 |
| 消费视图 | API、事件、读模型、报表 | 时效、权限和用途 |
同一个订单对象可以在交易库、客服读模型、数据仓库和搜索索引中出现多次。数据架构不要求只存一份，而要求这些副本能够追溯到权威事实，并且用途和时效明确。
先拆开“库存”这个词
库存不是单一字段，而是一组具有不同责任和时间语义的事实：
| 事实 | 含义 | 典型产生方 | 关键风险 |
|---|---|---|---|
| 实物库存 | 某地点实际持有的数量 | WMS、门店盘点 | 盘点和系统记录存在延迟 |
| 冻结库存 | 因质检、破损或监管不能使用的数量 | 仓储、门店运营 | 被误计入可售 |
| 安全库存 | 为波动和误差预留的数量 | 库存策略 | 不同渠道自行扣减 |
| 锁定库存 | 已被交易临时占用的数量 | 库存承诺服务 | 超时不释放、重复锁定 |
| 可售库存 | 当前允许对某渠道承诺的数量 | 库存平台计算 | 规则、时效和渠道配额不一致 |
| 在途库存 | 正在调拨或采购途中的数量 | WMS、采购系统 | 被错误承诺为立即可用 |
简化计算可以表示为：
text
可售库存 = 实物库存 - 冻结库存 - 安全库存 - 已锁定库存真实规则还会加入地点服务范围、渠道配额、预售、商品批次、保质期和优先级。因此，可售库存是带有规则版本和计算时间的业务结果，不应被所有系统当成可随意覆盖的字段。
给核心事实指定权威责任
权威责任包含两部分：业务上谁定义事实，技术上哪个系统拥有修改事实的最终裁决权。
| 数据对象 | 业务定义负责人 | 权威修改方 | 允许的副本 | 冲突裁决 |
|---|---|---|---|---|
| 企业客户身份 | 会员运营 | 会员中心 | 渠道身份映射、客服视图 | 会员中心的身份合并规则 |
| 企业商品身份 | 商品运营 | 商品中心 | 渠道商品、搜索索引 | 企业 SKU 与来源映射 |
| 实物库存 | 仓储/门店运营 | 对应地点的 WMS 或 POS 台账 | 库存平台、分析仓库 | 地点权威台账与盘点凭证 |
| 库存锁定 | 交易与库存运营 | 库存平台 | 订单快照、客服视图 | 预占状态机和业务凭证 |
| 订单状态 | 交易运营 | 订单管理 | 渠道、客服、数据仓库 | 订单状态机与支付凭证 |
| 履约状态 | 履约运营 | 履约系统 | 订单视图、客户通知 | 履约单和包裹事件 |
一个权威修改方不等于一个数据库。实物库存可以按地点由不同系统负责，只要责任范围互斥并且能汇聚成统一语义。危险的是同一范围、同一事实有多个系统都认为自己可以最终修改。
身份问题必须早于同步问题
如果同一商品在 POS 中是 A-1024，商城中是 SKU-8848，WMS 中又按包装规格编码，增加 Kafka 不能解决问题。消息只会更快复制歧义。
企业标识设计至少要回答：
- 企业内部使用哪个稳定 ID，业务编码是否允许改变。
- 来源系统 ID 如何映射，映射是否有有效期。
- 一个客户或商品被错误合并后如何拆分。
- 合并和拆分如何影响历史订单、权益和审计。
- 新旧标识在迁移期间如何同时解析。
主数据管理的重点不是建设 MDM 产品，而是让身份、关键属性和责任形成可执行规则。
生命周期比字段定义更重要
数据字典只能说明字段含义，生命周期说明事实如何变化。以库存锁定为例：
text
不存在
-> 已预占
-> 已确认扣减
-> 已释放
-> 已过期释放
-> 异常待处理需要进一步定义：
- 哪个命令可以触发每次状态变化。
- 重复命令是否返回原结果。
- 支付成功和锁定过期同时发生时如何裁决。
- 释放失败是否重试，谁负责人工处理。
- 状态和数量变化保留哪些业务凭证。
- 历史记录保存多久，是否允许修正。
这些规则连接业务架构、数据架构和应用状态机，也是后续对账和审计的基础。
数据流需要标明时效和用途
API、事件、批处理和数据仓库不是互相替代的技术选项，它们承担不同数据语义。
| 方式 | 适合用途 | 时效特征 | 必须说明的风险 |
|---|---|---|---|
| 同步 API | 下单前预占、实时校验 | 请求内返回明确结果 | 超时、重试、幂等、依赖故障 |
| 业务事件 | 已发生事实的跨系统传播 | 秒级到分钟级最终一致 | 重复、乱序、版本、积压 |
| CDC | 遗留系统增量同步和迁移 | 接近实时但依赖源表语义 | 表结构变化、缺少业务意图 |
| 批处理 | 对账、历史迁移、周期汇总 | 小时或天级 | 截止点、断点续跑、重复批次 |
| 分析仓库 | 趋势、预测、经营分析 | 不承担交易裁决 | 口径、血缘和刷新时间 |
每条数据流应标出来源、权威程度、最大可接受延迟、消费者、转换规则和失败处理。只画箭头而不标语义，会掩盖“读到的是事实还是副本”这一关键问题。
事件契约表达业务事实
库存预占成功事件可以包含以下信息：
json
{
"eventId": "evt-20260718-0001",
"eventType": "InventoryReserved",
"occurredAt": "2026-07-18T10:20:31+08:00",
"reservationId": "res-90817",
"orderId": "ord-57201",
"skuId": "sku-enterprise-1024",
"locationId": "store-3102",
"quantity": 2,
"expiresAt": "2026-07-18T10:35:31+08:00",
"schemaVersion": 3
}这个事件说明已经发生的事实，不要求某个消费者执行具体动作。消费者可以据此更新订单视图、准备履约或记录分析数据。事件还需要定义唯一性、字段兼容、枚举扩展、敏感信息和保留策略，不能只约定 JSON 示例。
数据质量必须连接业务后果
“完整率 99%”不说明剩余 1% 是否重要。数据质量应按业务对象和使用场景度量。
| 质量维度 | 库存场景的检查 | 业务影响 |
|---|---|---|
| 完整性 | 所有交易商品是否都有企业 SKU 映射 | 无映射商品无法统一承诺 |
| 唯一性 | 同一来源商品是否映射到多个有效 SKU | 库存和销售被重复统计 |
| 一致性 | 预占、确认、释放数量能否守恒 | 超卖或库存长期占用 |
| 及时性 | 门店实物库存距离最新采集多久 | 客户看到过期可售数量 |
| 有效性 | 数量、状态、地点是否符合业务规则 | 异常数据进入交易链路 |
| 可追溯性 | 数量变化能否回到凭证和操作者 | 无法对账、审计和排错 |
质量规则需要负责人、阈值、告警、修复流程和豁免范围。数据平台发现问题但业务流程继续制造问题，质量不会真正改善。
设计可解释的对账闭环
迁移期间新旧系统结果不一致是常态。对账不能只输出“数量不同”，而要把差异分类：
- 采集时间不同导致的暂时差异。
- 商品或地点映射错误。
- 业务规则不同，例如安全库存和渠道配额。
- 事件丢失、重复或乱序。
- 人工调整未带业务凭证。
- 代码缺陷或数据损坏。
每类差异要对应自动修复、重放、人工审批或规则调整。差异分布本身是架构证据：当无法解释的差异持续下降，新平台才具备接管权威责任的条件。
数据迁移覆盖历史、增量和切换
迁移方案至少包含四条链路：
| 链路 | 需要解决的问题 |
|---|---|
| 历史迁移 | 清洗、映射、批次、校验和失败重跑 |
| 增量追平 | 迁移期间新增与修改如何持续同步 |
| 切换窗口 | 谁停止写入，何时完成最后追平 |
| 回退处理 | 新系统已产生的数据如何回灌或保留 |
双写不是默认答案。双写把一次业务操作扩展成两个可能独立成功或失败的写入，状态空间迅速增加。必须双写时，要明确冲突裁决方、对账频率、补偿路径和退出日期。
安全与隐私进入数据生命周期
访问控制不能只放在接口网关。数据架构还要处理：
- 对象和字段的分级分类。
- 采集目的、最小化和保存期限。
- 生产、分析、测试和导出场景的权限差异。
- 静态、传输和备份数据的加密。
- 脱敏、匿名化和重新识别风险。
- 删除、更正、归档和法律保留之间的冲突。
- 管理员操作和批量导出的审计。
同一客户信息进入客服读模型或数据仓库后，仍然受原始用途和权限约束。复制数据不能复制出新的无限权限。
数据架构的最小交付物
- 核心业务对象、定义和边界。
- 企业标识与来源标识映射规则。
- 数据 Owner、Steward 和权威修改方。
- 对象生命周期、状态与业务凭证。
- 数据流、时效预算和消费者用途。
- 质量规则、阈值、修复和对账流程。
- 安全分类、访问控制与保存策略。
- Baseline、Target、Gap 和迁移批次。
这些工件应服务具体决策。只有表名和字段，没有责任与生命周期，仍然不是企业数据架构。
常见失效方式
- 把数据集中到湖仓或中台，就认为语义已经统一。
- 用数据库主键直接充当跨企业稳定身份。
- 先建设实时同步，再处理来源数据的歧义。
- 多个系统都保留修改权，只靠定时对账修复。
- 数据质量只由数据团队负责，源业务流程不改变。
- CDC 直接暴露表变化，消费者依赖内部存储结构。
- 迁移只设计正向导入，没有增量、回退和退出。
能力验证
- 能区分业务对象、业务事实、逻辑模型、物理模型和消费视图。
- 能为核心事实定义语义、身份、生命周期和权威责任。
- 能根据用途选择 API、事件、CDC、批处理或分析仓库。
- 能把数据质量指标连接到业务后果和修复流程。
- 能设计可解释的对账与数据迁移闭环。
- 能说明副本为何存在、多久有效、如何追溯到权威事实。
总结
数据架构的目标不是消灭所有副本，也不是把所有数据放进统一平台，而是让企业事实具有稳定语义、明确身份、权威责任、可控流动和可验证质量。对后端工程而言，这些决策最终会落到状态机、接口、事件、表和对账任务；但在编码之前，必须先回答企业层面的事实由谁定义、谁能改变、何时可信。