数据中心服务器封面

图片来源：Pexels - panumas nikhomkhai，可免费用于网站和博客。

AI 时代数据仓库总体架构

前言

AI 时代的数据仓库不再只是“给 BI 报表供数”的离线仓库，而要升级成企业的可信数据底座：既能支撑经营分析，也能支撑实时决策、机器学习、RAG、智能体和数据产品。建设重点从“建表”转向“建设可被人和 AI 共同使用的数据资产体系”。

最核心的判断：AI 能不能用好企业数据，取决于数据是否可发现、可信、可解释、可治理、可调用、可追溯。数仓建设要围绕这 6 个能力展开。

1. 为什么 AI 时代需要重新理解数仓

传统数仓主要解决 4 件事：数据集中、口径统一、分析查询、报表服务。AI 时代又增加了 5 类新需求：

  • 非结构化数据进入主链路：文档、图片、音视频、客服记录、合同、日志都可能成为 AI 上下文。
  • 数据服务对象变化：使用者不仅是分析师和业务人员，也包括大模型、RAG 应用、AI Agent、推荐和预测模型。
  • 数据质量要求变高：过去报表错了是决策偏差；现在 RAG 检索错了，模型可能一本正经地产生错误答案。
  • 数据治理前移：权限、血缘、口径、脱敏、审计不能只在报表层做，必须贯穿数据、特征、向量、模型、应用。
  • 数据交付方式变化：从“给表/给报表”变成“给指标、给 API、给语义层、给向量索引、给可执行上下文”。

2. 建设目标

AI 时代的数据仓库要形成 7 类能力：

  1. 数据统一：结构化、半结构化、非结构化数据统一接入、统一编目。
  2. 口径统一：指标、维度、实体、标签、特征要有唯一权威定义。
  3. 质量可信：关键数据有质量规则、SLA、告警、数据契约和责任人。
  4. 语义可懂：业务术语、指标口径、表字段、知识文档能被人和 AI 理解。
  5. 实时可用：支持 T+1、准实时、实时的分层服务，不强行一种架构打天下。
  6. 安全可控：权限、脱敏、审计、数据分级、模型访问策略一体化。
  7. 产品化交付：以数据产品、指标服务、特征服务、RAG 知识库、数据 API 的形式交付。

3. 总体架构：Lakehouse/Warehouse + 标准数仓分层 + AI 数据服务

建议采用 Lakehouse/Warehouse 作为架构底座，但数据建模和分层命名仍然遵循标准数仓规范。更实际的结构是：

层级 作用 典型产出
数据源 业务系统、日志、埋点、文档、API 等原始来源 业务库、日志流、文件、第三方接口
采集层 负责批处理、流处理、CDC、文件和 API 接入 同步任务、采集链路、落地 SLA
原始层 / ODS 保留源系统原貌，支持重放和追溯 原始表、原始文件区、采集批次信息
明细层 / DWD + DIM 统一清洗明细事实和公共维度 明细事实表、公共维度表、统一实体 ID
数仓层 / DWS 沉淀主题汇总和公共指标 主题汇总表、指标服务、指标字典
应用层 / ADS + RPT 面向具体业务场景交付数据 报表数据集、数据 API、数据产品
AI 数据服务层 让 AI 能安全、准确地使用企业数据 语义层、指标层、特征层、向量索引
消费端 支撑分析、决策、问答和自动化动作 BI、API、RAG、Agent、模型训练、实时决策

关键设计原则

  • 存储上可以采用 Lakehouse/Warehouse 架构，底层优先选择 Parquet + Iceberg/Delta/Hudi 这类开放表格式，降低迁移和多引擎协作成本。
  • 计算上多引擎协同：Spark/Flink 做批流处理，Trino/ClickHouse/Doris/Snowflake/BigQuery/Fabric/Databricks 做交互分析或托管能力，按团队和成本选择。
  • 建模上保留经典数仓方法：ODS、DWD、DIM、DWS、ADS、RPT 的分层规范，结合 Kimball 维度建模和 OneData 指标体系，仍然有效。
  • 治理上统一元数据：表、字段、指标、血缘、质量、权限、数据产品、特征、向量索引都要进入统一目录。
  • AI 服务上单独建设：不要把向量库、RAG 切片、Embedding、提示词、模型调用散落在应用代码里。

4. 分层设计

原始层 / ODS：原始可信留存

目标：保留数据原貌，支持重放和追溯。

建设要求：

  • 原始数据尽量不可变，保留采集时间、来源系统、批次号、操作类型。
  • CDC、日志、埋点、文件、API 数据分来源落地。
  • 对非结构化数据保存原文、文件元信息、解析状态、权限来源。
  • 只做轻度校验，不在这一层做复杂业务清洗。

典型产出：原始表、原始文件区、采集任务、数据源清单、落地 SLA。

明细层 / DWD + DIM：统一实体和明细事实

目标：把原始数据变成可复用的企业事实和维度。

建设要求：

  • 建统一实体：用户、客户、商品、订单、组织、设备、合同、内容、知识文档。
  • 建明细事实：交易、支付、退款、访问、履约、工单、营销触达、模型调用、Agent 操作。
  • 建公共维度：日期、地域、渠道、组织、类目、会员等级、业务状态。
  • 对脏数据做清洗、去重、补全、标准化，并记录异常数据去向。
  • 非结构化数据要完成解析、切片、结构化抽取、权限继承、质量评估。

典型产出：DWD 明细事实表、DIM 公共维度表、统一 ID、实体关系、文档切片表。

数仓层 / DWS：公共指标和主题汇总

目标：沉淀可复用的业务主题与核心指标。

建设要求：

  • 按业务域建设公共汇总：交易、用户、商品、营销、履约、财务、风控、客服。
  • 原子指标、派生指标、复合指标要进入指标字典。
  • 高频查询指标预聚合，低频探索保留明细查询能力。
  • 建指标血缘：指标 -> 汇总表 -> 明细表 -> 源系统。
  • 建指标版本：口径变化必须记录生效时间和影响范围。

典型产出：DWS 主题汇总表、指标服务、指标字典、经营看板公共数据集。

应用层 / ADS + RPT：面向场景的数据产品

目标：为具体业务动作交付数据，而不是堆更多表。

建设要求：

  • 每个 ADS/RPT 数据集必须绑定业务场景、使用方、SLA、负责人、下线条件。
  • 报表、推荐、风控、营销、客服、RAG、智能体分别建消费视图。
  • 对外服务优先通过 API、语义层、指标层或特征服务，不鼓励应用直接读底层明细。

典型产出：经营看板、用户画像服务、营销人群包、风控特征集、RAG 知识库、Agent 工具数据接口。

5. AI 专属数据能力

RAG 知识库建设链路

5.1 语义层

语义层解决“业务怎么说”和“数据怎么算”的一致性。它应该管理：

  • 业务术语：客户、活跃、有效订单、净收入等。
  • 指标定义：名称、编码、公式、过滤条件、统计周期、维度、负责人。
  • 实体关系：客户-订单-商品-门店-组织之间如何关联。
  • 查询权限：谁能看什么维度、什么粒度、什么脱敏字段。
  • 自然语言查询映射：让 AI 生成 SQL 时有标准上下文，而不是猜表猜字段。

验收标准：同一个经营问题，BI、SQL、AI 问答返回同一套指标口径。

5.2 向量索引和 RAG 知识库

RAG 不是简单“把文档扔进向量库”。要把它当成数据产品建设。

建设步骤：

  1. 数据源选择：制度、产品文档、客服知识、合同、代码文档、指标字典、数据血缘、业务 SOP。
  2. 文档解析：抽取标题、正文、表格、图片说明、章节层级、作者、更新时间。
  3. 切片策略：按语义章节切分，保留父标题、业务域、权限、时间、版本。
  4. Embedding：记录模型版本、向量维度、生成时间、重算策略。
  5. 检索：同时支持关键词、向量、过滤、重排，不只依赖相似度。
  6. 权限：检索阶段必须继承源文档权限，不能等答案生成后再过滤。
  7. 评估：维护标准问题集，评估召回率、答案正确率、引用完整性、拒答准确率。
  8. 反馈：记录用户点击、追问、纠错，用于优化切片、召回和重排。

典型表设计：

  • ai_doc_source：文档来源和权限。
  • ai_doc_chunk：文档切片、章节、正文、元数据。
  • ai_embedding_index：向量、embedding 模型、索引状态。
  • ai_rag_eval_set：标准问题、期望答案、期望引用。
  • ai_rag_trace：问题、召回片段、模型答案、用户反馈。

5.3 特征层 / Feature Store

如果企业有推荐、风控、预测、智能运营，需要把特征作为一等资产管理。

建设要求：

  • 离线特征和在线特征口径一致。
  • 特征要有 owner、描述、刷新周期、训练/推理一致性校验。
  • 特征血缘要能追到源表和计算逻辑。
  • 避免训练数据泄漏，明确特征可用时间点。
  • 建特征复用机制，减少每个模型重复造特征。

5.4 AI 可观测性

AI 应用会改变数据仓库的监控对象。除了任务成功率、延迟、成本，还要监控：

  • 检索质量：召回为空、低相关召回、重复召回、过旧召回。
  • 答案质量：无引用回答、引用不匹配、事实错误、幻觉风险。
  • 权限风险：越权召回、敏感字段泄漏、脱敏失败。
  • 成本风险：Embedding 重算成本、向量索引成本、模型调用成本。
  • 数据漂移：源文档变化、指标口径变化、业务状态分布变化。

6. 数据治理体系

AI 时代的数据治理闭环

AI 时代治理不能只做“规范文档”，要做成工程约束。

必须建设的 8 类治理资产

  1. 数据目录：表、字段、指标、文档、特征、向量索引、API 都可搜索。
  2. 元数据：业务描述、技术描述、owner、生命周期、热度、成本。
  3. 血缘：源系统到模型、指标、报表、RAG 答案的链路。
  4. 质量规则：完整性、唯一性、准确性、及时性、一致性、合理性。
  5. 数据契约：上游承诺 schema、质量、SLA、语义、安全规则。
  6. 权限分级：公开、内部、敏感、机密；字段级和行级权限。
  7. 变更机制：表结构、指标口径、文档版本、特征逻辑都要评审和通知。
  8. 成本治理：表热度、任务成本、存储生命周期、低价值资产下线。

数据契约模板

每个关键数据资产至少定义：

  • 资产名称：如 dwd_trade_order_pay_di。
  • 业务 owner：确认业务含义。
  • 数据 owner：负责开发和质量。
  • schema 约束：字段名、类型、是否可空、主键、枚举值。
  • 质量规则：唯一性、非空率、金额范围、状态合法性。
  • SLA：刷新频率、最晚产出时间、可用性。
  • 安全规则：敏感字段、脱敏方式、允许用途。
  • 变更规则：提前多久通知，是否需要下游确认。

7. 技术选型建议

不要先问“用哪个平台”，先问 5 个问题：

  1. 数据规模：TB、PB，还是中小规模？
  2. 时效要求：T+1、小时级、分钟级、秒级分别占多少？
  3. 数据类型：结构化为主，还是文档/日志/图片/音视频也很重？
  4. 团队能力：是否有 Spark/Flink/运维能力，还是更适合托管平台？
  5. 使用场景：BI 为主，还是 AI/RAG/模型训练/实时决策很重？

常见组合

  • 中小团队、追求快：云数仓 + dbt/语义层 + 托管向量检索 + 数据目录。
  • 大数据团队、有 Spark/Flink 能力：Lakehouse + 开放表格式 + Spark/Flink + Trino/Doris/ClickHouse + 元数据治理。
  • 微软生态：Microsoft Fabric / OneLake + Lakehouse/Warehouse + Power BI + Purview。
  • Databricks 生态：Delta Lake + Unity Catalog + Workflows + MLflow + Vector Search。
  • Snowflake 生态：Snowflake Warehouse + Cortex Search + Stream/Task + Governance。

选择原则：核心数据资产尽量开放，消费服务可以托管；核心口径和元数据不能被单一应用绑死。

8. 可执行落地路线图

第 0 阶段：现状盘点，1-2 周

目标：知道现在有什么、哪里痛、先做什么。

任务：

  • 盘点数据源、核心表、核心报表、核心指标、业务系统、文档知识库。
  • 找出 10 个最高频数据问题：口径争议、延迟、质量、权限、重复建设。
  • 选 1 个试点业务域：建议从交易、用户、商品、客服、风控中选一个。

产出：数据资产盘点表、问题清单、试点范围、目标指标。

第 1 阶段：打底座，3-6 周

目标：把数据接住、管住、查得到。

任务：

  • 建 ODS 原始层。
  • 建统一数据目录和 owner 机制。
  • 建任务调度、监控、告警。
  • 建命名规范、分层规范、开发规范。
  • 建 20-50 个核心质量规则。

产出：分层规范、数据目录、核心源表、质量看板、任务监控。

第 2 阶段：建公共模型，6-10 周

目标：沉淀可复用数据资产。

任务：

  • 建 DWD 明细事实表和 DIM 公共维度。
  • 建统一 ID 和核心实体关系。
  • 建 DWS 主题汇总。
  • 建指标字典和核心指标口径。
  • 建数据血缘和影响分析。

产出：DWD/DIM/DWS 模型、指标字典、血缘图、公共数据集。

第 3 阶段：服务化，4-8 周

目标：让数据能稳定服务业务和系统。

任务：

  • 建 ADS/RPT 场景数据集。
  • 建指标 API、数据 API、语义查询入口。
  • 建权限、脱敏、审计。
  • 建数据产品目录和 SLA。
  • 对低价值、重复报表和表做下线治理。

产出：数据服务、经营看板、数据产品目录、SLA 报告。

第 4 阶段：AI 化，6-12 周

目标：让 AI 能安全、准确地使用企业数据。

任务：

  • 建 RAG 知识库：文档解析、切片、Embedding、索引、评估集。
  • 把指标字典、表说明、血缘、业务术语接入 AI 上下文。
  • 建自然语言查数的语义层和 SQL 安全网关。
  • 建 AI 应用监控：召回、引用、权限、成本、用户反馈。
  • 建特征层，支撑推荐、风控、预测等模型场景。

产出：企业知识问答、指标问答、数据助手、特征服务、AI 质量评估报告。

9. 组织分工

AI 时代的数据仓库不是数据开发一个团队能闭门完成的项目。

角色 责任
业务 Owner 定义业务目标、指标含义、数据使用场景
数据产品/分析师 设计指标体系、看板、数据产品、验收标准
数仓工程师 分层建模、ETL/ELT、性能优化、公共模型建设
数据治理负责人 元数据、质量、血缘、权限、生命周期、标准规范
AI 工程师 RAG、Embedding、检索、评估、模型调用链路
平台工程师 调度、监控、成本、权限、CI/CD、平台稳定性
安全/合规 数据分级、脱敏、审计、合规策略

建议建立数据资产评审会，每周看 5 件事：新增资产、质量问题、口径变更、权限风险、成本异常。

10. 验收指标

数据底座指标

  • 核心表 owner 覆盖率 >= 95%。
  • 核心表字段描述覆盖率 >= 80%。
  • 核心任务 SLA 达成率 >= 99%。
  • 核心质量规则覆盖率 >= 80%。
  • P1 数据事故平均恢复时间逐月下降。

业务使用指标

  • 核心指标复用率提升。
  • 重复报表数量下降。
  • 经营会口径争议次数下降。
  • 数据需求平均交付周期下降。
  • 自助取数占比提升。

AI 使用指标

  • RAG 答案引用覆盖率 >= 90%。
  • 标准问题集正确率持续提升。
  • 越权召回次数为 0。
  • 无引用或低置信回答可被拒答。
  • AI 查数生成 SQL 的口径命中率持续提升。

11. 常见误区

误区 后果 修正方式
只买 AI 工具，不补数据底座 AI 看起来聪明，但回答不可信 先建元数据、指标、质量、权限
把向量库当数据仓库 无法做口径、血缘、质量和权限治理 向量索引只是服务层，源数据仍要入治理体系
Lakehouse/Warehouse 等于不要数仓建模 明细混乱，指标复用差 架构可以升级，ODS/DWD/DWS/ADS/RPT 分层建模和口径治理不能丢
报表层各算各的 BI 和 AI 答案不一致 建统一语义层和指标字典
RAG 只做相似度检索 召回不准、答案幻觉 加关键词、过滤、重排、评估和反馈
权限只在应用层控制 模型可能越权看到上下文 检索、SQL、API、模型调用全链路鉴权
没有变更机制 下游报表、模型、RAG 全部被静默影响 建数据契约和影响分析

12. 最小可行版本 MVP

如果从 0 开始，建议 8 周做一个 MVP：

  • 选一个业务域：交易或客服最适合，因为既有结构化数据，也有 AI 场景。
  • 建 10 张以内核心 DWD/DIM/DWS 表，并输出必要的 ADS/RPT 数据集。
  • 定义 20 个核心指标。
  • 建 30-50 条质量规则。
  • 建一个经营看板。
  • 建一个 RAG 知识库，接入指标字典、业务文档、数据表说明。
  • 建一个 AI 数据助手，支持“查指标解释、查表含义、查血缘、问业务文档”。
  • 用 50 个标准问题做验收。

验收通过的标准不是“能聊天”，而是：业务会议愿意用、数据团队愿意维护、AI 回答有引用、权限没有漏洞、错误能被追踪和修复。

13. MVP 行动清单

  • 先把现有数据资产分成 4 类：核心资产、重复资产、无人维护资产、AI 可用资产。
  • 选定一个试点业务域，明确 3 个业务目标和 20 个核心指标。
  • 建指标字典字段模板：名称、编码、业务定义、计算公式、统计周期、维度、owner、质量规则、血缘、版本。
  • 建核心表的数据契约模板，并从最重要的 5 张表开始执行。
  • 把已有的指标体系笔记和数仓建设笔记关联起来，形成“指标 -> 模型 -> 治理 -> AI 服务”的知识链。
  • 设计第一版 RAG 知识库：优先接入指标字典、表说明、业务 SOP、FAQ，而不是全量文档。
  • 建立每周数据资产评审节奏，持续看质量、口径、权限、成本和使用情况。

14. 参考资料