AI 项目常从模型演示开始，却经常卡在数据找不到、口径不一致、权限说不清和结果无法重放。面向 AI 的大数据底座需要同时服务报表、特征训练、实时决策和知识检索，并让每个结果回到原始证据。
一、六层逻辑架构
业务系统 / 文件 / 日志 / IoT / 第三方数据
↓
采集层：批量同步、CDC、消息与文档解析
↓
存储计算层：对象存储 + 表格式 + SQL/Spark/流计算
↓
可信数据层：原始区 → 清洗区 → 业务数据产品
↓
智能数据层：语义指标、特征、向量索引、知识图谱
↓
服务层：BI、API、模型训练、RAG、智能体
↓
横切能力：目录、血缘、权限、质量、成本、可观测性
逻辑分层比具体产品名更重要。小团队可以用一个数据库和对象存储实现这些职责；数据量、团队和延迟要求增长后，再拆分计算引擎与服务。
二、原始、可信与业务三层
常见的奖牌分层把数据分为 Bronze、Silver、Gold。原始层保留到达时的内容和元数据；可信层完成去重、标准化、主键处理和质量校验；业务层按订单、客户、资产等主题形成可消费的数据产品。
Microsoft 的 Databricks 文档把这一模式描述为逐层提升数据结构与质量的设计方法，并明确它是推荐模式而非强制要求。真正的验收标准应是：能否重放、是否保留错误记录、业务定义是否一致、下游变更是否可控。
三、流批一体不是所有数据都实时
实时化应由业务时效决定。月度经营分析适合批处理；欺诈告警、设备异常和在线推荐可能需要秒级或分钟级处理。同一套数据契约可以同时支持历史回放和实时增量，避免流与批生成两套不同口径。
每条事件至少包含事件时间、处理时间、来源、唯一键和模式版本。还要处理迟到、乱序、重复、重试与幂等，否则“实时”只会更快地产生不一致。
四、给 AI 增加三类数据产品
语义指标层统一收入、活跃、留存等定义，让人、BI 和问数助手使用相同口径。
特征层保存可复用的训练与推理特征，并控制时间穿越。离线训练和在线推理必须对同一特征有一致定义。
知识层把文档切分、元数据、向量与原文引用组织起来。索引必须继承源系统权限，并记录解析器、嵌入模型和切分版本。
五、治理要成为运行能力
数据目录负责发现，血缘负责解释来源，质量规则负责阻断错误，访问控制负责最小权限，审计日志负责回答谁在何时使用了什么。模型输入和输出也属于治理对象：训练集、评测集、提示词、检索结果和人工反馈都应有版本。
Google Cloud 对数据网格的定义把数据视为由最了解它的领域团队负责的数据产品，同时遵守组织统一治理标准。它适合多领域、多团队组织；小团队不必为了概念完整而过早拆出复杂平台。
六、最小可行底座
第一阶段只需打通一个高价值主题：保留原始快照，形成一张可信明细表、一组业务指标、一个带权限的知识索引，并加上质量和成本监控。随后再按真实瓶颈扩展 CDC、流处理、特征服务和数据网格。
底座完成后，继续阅读AI 数据架构如何演进，理解传统数仓怎样走向面向智能体的数据平台。
七、底座验收指标
平台验收不能只看吞吐量。还应记录数据到达延迟、质量规则通过率、血缘覆盖率、权限申请时间、查询与训练成本、故障恢复时间，以及数据产品被多少真实流程复用。
若团队还没有清晰的应用目标，可先回到AI 在数据中的应用地图选择一个可验证场景。底座建设应随着场景逐步扩展，避免一次性复制大型组织的全部组件。
实践检查清单
在评审方案时，要求团队画出从原始数据到最终用户的链路，并在每个节点标明输入、输出、负责人、质量阈值、访问权限、版本和失败处理。随机选择一条历史结果，确认可以根据日志与快照完整重放。
同时保留一个不使用复杂 AI 的基线方案。只有当新方案在质量、时效、成本或人工负担上产生可重复的改善，并且没有越过风险阈值，才扩大使用范围。若效果下降，应能快速切回规则、旧模型或人工流程，并把失败样本加入后续评测。