一个建设多年的企业数仓，ODS、DWD、DWS、ADS分层清晰，几百张表、上千个字段，指标体系也相当完善。

可一旦接入 Data Agent，问题就暴露了：

数仓里明明有数据，AI 却不知道该查哪张表，更分不清字段背后的业务含义。

比如让 AI 分析销售收入，它可能混淆订单金额、确认收入和实际回款；让它统计客户数量，又容易忽略去重规则和有效客户的定义。

SQL 能正常执行，结果却未必准确。

问题不一定出在大模型，而在于传统数仓主要面向开发和分析人员设计，缺少让 AI 理解业务、识别口径和可信调用数据的能力。

那么，数仓已经建了这么多年，为什么 AI 还是看不懂？企业又该如何在现有架构上补齐这些能力？

如果你正在系统梳理企业数仓建设、数据分层、指标体系和数据应用，可以先看看这份《数据仓库建设解决方案》。从数据接入、数据加工到数仓分层和业务应用，能够把一套企业数仓是如何规划和落地的讲清楚，也有助于进一步理解：数据为什么要这样组织，指标口径为什么需要统一，以及这些基础能力如何支撑后续的数据分析和智能应用。

需要的可以自取：https://s.fanruan.com/7igmg（复制到浏览器）

一、为什么数仓建了几百张表，AI 还是看不懂？

首先要明确一点：数据库能够存储业务数据，不代表它能完整表达业务含义。

传统数仓通过 ODS、DWD、DWS、ADS 分层，解决了数据分散、重复加工和分析效率等问题，但这套体系有一个默认前提：使用者具备一定的业务知识，能够理解字段含义和指标口径。

比如一张名为dws_sales_order_summary_di的汇总表，开发人员可能一眼就知道它的用途，但 AI 还需要判断：数据按什么粒度汇总、是否包含取消订单、金额是否含税、日期代表下单时间还是确认时间。

这些业务规则往往散落在 SQL 脚本、指标文档和开发人员的经验中，并没有完整体现在数据模型里。

这就造成了一个核心矛盾：数仓完成了数据的技术整合，却没有充分完成业务语义的标准化表达。

人可以凭借经验理解这些规则，但 AI 如果缺少明确的语义信息，就容易选错数据源、用错计算口径。

因此，Data Agent 时代的数仓升级，重点不只是增加数据表，而是让数据具备可理解、可追溯、可调用的业务语义。

二、传统宽表思维，为什么在 Data Agent 时代不够用了？

过去企业做数仓优化，通常会将常用数据提前关联、汇总成宽表，以减少查询时的关联计算，提高固定报表和高频分析的效率。

但Data Agent 改变了传统的数据消费方式。

BI 报表的指标、维度和分析路径通常提前确定，而 Data Agent 面对的是动态、连续的业务问题，可能从销售额一路分析到毛利、库存、订单履约和回款情况。

宽表适合解决已知场景的查询效率问题，却难以覆盖不断变化的跨主题分析需求。

如果企业仍然完全依赖固定宽表，就容易遇到三个问题。

1. 宽表解决了查询效率，却没有解决业务理解

一张包含订单、客户、商品、区域、金额等字段的宽表，确实方便分析，但字段越多，未必意味着 AI 越容易理解。

如果没有明确说明指标定义、主键粒度、关联关系和使用范围，AI 仍然可能错误组合字段。

尤其是在多事实表分析中，不同表的统计粒度可能不同。订单明细是一行一个商品，回款记录可能是一行一笔收款，如果直接关联后求和，就可能产生重复计算。

对于 Data Agent 来说，知道两张表能够关联，和知道两张表应该如何关联，是两回事。

2. 预先设计的宽表，难以覆盖动态变化的分析需求

宽表往往围绕已知需求建设，但业务问题会不断变化。

如果每增加一种分析场景，就重新开发一张宽表，容易造成字段重复、加工链路增加、口径维护分散。时间一长，数仓中的表越来越多，真正可复用的数据资产却不一定同步增加。

因此，Data Agent 时代并不是不需要宽表，而是不能再把不断增加宽表数量，当成满足所有数据消费需求的主要手段。

对于固定、高频、性能敏感的分析，可以继续使用宽表；

对于跨主题、动态组合的分析，则更需要标准化主题模型、统一指标语义和明确的关联规则。

3. 数据模型缺少可供 AI 使用的上下文

传统数仓中的很多业务知识存在于开发过程，却没有成为可被机器稳定读取和执行的规则。

比如“有效订单”的定义，可能涉及订单状态、退款规则、交易时间和特殊业务类型。

如果这些规则只写在某个 SQL 任务里，AI 即使能够读取底层数据，也未必知道应该使用哪套规则。

因此，数仓需要进一步补齐的，不只是字段备注，而是一套能够表达业务实体、指标公式、统计粒度、维度关系、时间口径和适用范围的语义体系。

它的价值，是让 AI 不必每次从几百张表中重新猜测业务规则，而是优先使用经过确认的业务定义。

三、数据接进数仓只是第一步，真正麻烦的是数据链路不可控

聊到这里，很多人可能会觉得，既然 AI 看不懂数据，那给数仓补充元数据、增加语义层不就行了？

实际上，事情没这么简单。

AI 能否正确使用数据，不仅取决于它是否理解字段，还取决于底层数据是否完整、及时和可信。

企业数仓中的数据通常经过多个环节：从 ERP、CRM、MES 等业务系统抽取，进入原始数据层，再经过清洗、关联、计算，最终形成面向分析的数据模型。

只要其中一环出现问题，即使上层语义定义完全正确，AI 得到的结果仍然可能不准确。

而且，AI 应用会进一步放大这些问题。过去一张报表的数据异常，通常由分析师发现并核查；

现在一个 Data Agent 可能连续调用多个数据接口，在错误数据基础上继续分析，甚至生成后续操作建议。

这也是我认为企业改造 AI 数据架构时，应该首先检查数据集成层的原因。

最近在研究FineDataLink 5.0时，我比较关注的就是它在数据接入、实时计算、数据质量和数据服务方面的升级。

它强调的“接得上、算得快、可相信、广消费”，实际上对应了企业从传统数仓走向 AI Ready 数据体系时需要解决的几项基础问题。

第一步：先保证关键业务数据能够稳定接入，而不是盲目扩大数仓规模

很多企业在建设数仓时习惯先考虑需要同步多少张表，但实际落地时，更应该优先判断关键业务数据是否完整覆盖，以及不同数据源能否持续稳定地接入。

例如，经营分析需要将订单、库存、成本和回款数据联系起来，如果只同步了订单数据，却没有及时获取后续退款和回款变化，那么即使数仓中拥有完整的销售主题模型，也很难还原真实经营状态。

FineDataLink 5.0增强了异构数据源接入能力，除了常见关系型数据库，还支持多种国产数据库、SaaS 应用、API 以及消息队列等数据来源。

其中，我认为比较有实际价值的是针对达梦、电科金仓、OceanBase、GaussDB 等数据库的日志解析级实时接入，以及 Oracle 的独立日志解析能力。

对于企业数据架构来说，日志增量捕获的重要性在于，它可以从数据库变更记录中获取新增、修改、删除等变化，而不必完全依赖周期性全表扫描。

当然，CDC 能否稳定运行，还要关注日志保留时间、初始全量与后续增量的衔接、断点恢复和目标端数据一致性。这些都是生产环境部署时必须验证的内容。

因此，实际建设时，我更建议企业先梳理核心数据链路，明确哪些数据适合批量同步，哪些需要基于 CDC 持续更新，哪些需要通过 API 或消息队列接入，而不是要求所有数据都采用同一种同步方式。

第二步：把数据加工前移，让数据在进入消费层之前完成必要处理

传统离线数仓通常把数据接入与数据计算分开处理，先同步、再加工、最后提供给应用。这种架构适合稳定的批处理需求，但对实时经营分析或需要及时感知业务状态的 Agent 来说，数据延迟可能成为问题。

FineDataLink 5.0 新增的实时计算能力，可以让业务数据在流动过程中进行过滤、转换、关联和聚合等处理。

这里的价值不是单纯把同步速度做快，而是让一些对时效性敏感的业务指标能够更早形成可消费的数据结果。

不过，实时并不等于所有指标都应该实时计算。

实际架构设计中，还需要根据业务时效要求、计算复杂度和数据一致性要求进行分层。高频变化、需要及时响应的数据适合实时处理；历史归档、复杂批量计算以及部分周期性对账任务，仍然适合离线处理。

对于 Data Agent 来说，最重要的是能够区分不同数据的更新频率，并了解当前结果对应的数据时间点，避免把尚未完成更新的指标当成最终结果。

第三步：建立数据质量与血缘体系，让 AI 查询结果有据可查

很多企业的数据治理工作，主要集中在字段标准化、去重、缺失值处理等方面。这些工作当然重要，但如果质量检查只发生在数据入仓时，后续加工过程中出现的问题仍然可能被忽略。

对于面向 AI 的数据体系，我认为数据质量至少需要覆盖三个层面：源头数据是否符合规则，加工过程是否保持业务一致性，最终指标是否满足消费要求。

FineDataLink 5.0 在这一部分的升级比较值得关注。它提供基于数据完整性、一致性、准确性、唯一性、时效性和有效性的数据质量检查，并结合血缘分析、异常明细、问题流转等能力，形成从问题发现到整改验证的管理闭环。

这和传统的任务执行监控有明显区别。任务成功只能说明技术流程执行完毕，并不能证明数据结果正确。比如订单同步任务正常完成，但由于源系统状态字段发生变化，导致部分订单被错误纳入有效销售额统计。这种问题单靠任务成功率是无法识别的。

因此，实际落地时，建议把数据质量规则与业务指标关联起来。对于核心经营指标，除了检查字段是否为空、数据是否重复，还应该检查主键唯一性、跨表关联完整性、金额勾稽关系、数据更新时效以及异常波动。

同时，利用数据血缘建立从源系统、同步任务、加工模型到最终数据资产的依赖关系。这样当某个指标异常时，就可以沿着加工链路定位问题，并判断哪些下游数据受到影响。

需要注意的是，数据血缘能够说明指标是如何形成的，但不能替代业务口径定义。两者必须结合，才能让 AI 既知道一个数字从哪里来，也知道它为什么这样计算。

四、只把表开放给 AI 还不够，企业真正缺的是统一语义层

如果说数据集成解决的是数据能否稳定供给，那么语义层解决的就是 AI 能否正确理解和使用这些数据。

目前比较常见的做法，是让大模型读取数据库 Schema，通过 Text-to-SQL 自动生成查询语句。

演示环境里，这种方式通常效果不错，但进入复杂的企业数仓后，准确率往往会受到表数量、命名规范、关联复杂度和业务口径差异的影响。

尤其是财务、经营、供应链等领域，同一个业务概念可能存在多个合法定义，AI 不能仅仅依靠字段名称进行选择。

所以，企业不能只把几百张表的结构信息交给 AI，还需要建立能够被程序调用的业务语义体系。

1. 先建立统一指标定义，而不是直接开放所有字段

以销售收入为例，至少需要明确指标名称、计算公式、统计粒度、时间口径、组织范围、过滤条件、数据来源和业务负责人。

对于同一个指标，如果财务和销售部门存在不同口径，也不应该简单地合并成一个定义，而是需要分别标识适用范围，并明确哪些场景使用哪个版本。

只有这样，Data Agent 才能够根据用户问题选择合适的计算逻辑，而不是临时生成一套自己认为合理的 SQL。

2. 通过业务主题限制 AI 的查询范围

并不是让 AI 一次性看到全部数仓表，它就能获得更好的分析能力。

更合理的方式，是按照销售、采购、库存、财务、生产等业务主题组织数据资产，把经过认证的事实表、维度表、指标和关联规则整合成可消费的数据集合。

当用户提出库存周转问题时，系统应优先检索库存主题下的相关数据资产，而不是在全部数据表中查找名称相似的字段。

这样既能减少错误匹配，也能降低查询生成的复杂度。

3. 将业务规则变成可执行、可维护的语义资产

传统指标文档往往只供人阅读，但 AI 需要的是能够直接参与查询生成和结果校验的结构化规则。

例如，指标定义应关联具体的 SQL 表达式或计算服务，字段之间的关联关系需要标明连接键和基数约束，指标口径发生变化时还要保留版本信息。

这部分可以由专门的指标平台、语义层或数据建模体系承担。

FineDataLink这样的数据集成治理平台，重点负责保障底层数据连接、处理、质量、血缘和服务能力；

统一指标语义则需要与数仓建模、指标管理等能力协同建设。

只有把这几层打通，AI 才能从“根据字段猜 SQL”，逐步转向“按照企业确认的业务规则获取结果”。

五、Data Agent 时代，数据怎么安全地给 AI 用？

传统数仓主要面向 BI 报表、SQL 查询和数据分析人员，数据消费方式相对固定。

但 Data Agent 不一样，它可能根据用户提出的问题，动态选择数据源、调用工具，甚至连续执行多步分析任务。

这时候，数据架构就需要解决一个新的问题：

既要让 AI 灵活访问数据，又不能让它绕开企业已有的权限和安全管理体系。

比如，一个负责区域销售分析的 Agent，只应该访问授权区域的数据；一个面向采购部门的智能助手，不应该因为能够连接企业数仓，就自动获得所有供应商的敏感信息。

因此，我不太建议企业直接向 Data Agent 开放生产数据库或大范围数仓账号，而是优先建设统一、受控的数据服务层。

1. 将数据资产封装为标准化 API

过去业务系统需要使用数仓数据，往往需要开发人员针对每个需求单独写接口。这样不仅开发工作重复，也容易形成多个业务口径不一致的数据服务。

FineDataLink 5.0 支持通过可视化方式开发、发布和管理数据 API，让经过处理和治理的数据以接口形式提供给不同应用。

从架构角度看，这相当于在数仓和上层应用之间建立了一层相对稳定的数据服务接口。

企业可以把经过确认的指标、明细查询和业务数据能力封装为服务，而不要求每个应用都重新理解底层数据库结构。

2. 通过 MCP 将可信数据能力提供给 Agent

MCP 的价值在于提供标准化的工具和上下文交互机制，让 AI 应用可以通过统一方式发现和调用外部能力，而不是针对每个业务系统分别开发复杂的专用集成逻辑。

但企业仍然需要在数据服务层完成业务口径确认、权限配置、接口输入约束和输出范围控制，并结合身份鉴权、黑白名单、限流熔断等机制管理调用过程。

对于涉及敏感数据或自动执行业务动作的 Agent，还应补充更细粒度的数据权限、审计记录和必要的人工审批。

这样一来，Data Agent 不必直接面对数仓中几百张底层表，而是优先调用经过治理、授权和封装的数据服务。

这种架构不仅有利于控制数据风险，也能够降低 Agent 对底层数据库结构的依赖。

六、如果企业已经有几百张数仓表，应该怎么改造？

讲到这里，可能有人会问：现在数仓已经建设了好几年，表也有几百张，难道为了 AI 还要重新做一遍？

完全没有必要。

我认为，企业推进 AI Ready 数据架构，最合理的方式不是推翻原有数仓，而是保留成熟的数据分层和建模体系，在现有架构上补齐数据可信、语义理解和服务消费能力。

具体可以分成四步。

第一步：先盘点数据资产，明确哪些表值得开放给 AI

不要直接把整个数仓接入大模型。

应该先按照业务主题梳理核心数据资产，识别哪些表仍然在使用、哪些表存在重复建设、哪些指标已经形成统一口径。

建议优先选择经营分析、财务分析等业务定义相对明确的领域，确定一批经过认证的指标和数据模型，形成第一批 AI 可用数据资产。

评估重点不是开放了多少张表，而是这些数据资产是否具备清晰的业务含义、稳定的更新机制和明确的使用权限。

第二步：完善底层数据链路，补齐数据质量与血缘

对核心数据资产向上追溯，检查数据来源、同步方式、任务依赖和加工逻辑。

这一阶段可以利用FineDataLink的异构数据接入、实时计算、质量巡检和血缘分析等能力，先解决关键链路的数据及时性、质量监测和问题追踪。

尤其要为关键数据资产建立质量规则，明确规则责任人、异常处理方式和整改验证流程。

只有通过质量检查的数据，才应该进入经过认证的数据消费范围。 对于未通过检查的数据，可以根据业务风险采取告警、标记不可用、阻断发布等不同策略，而不是一律让 AI 直接消费。

第三步：建设业务语义层，让 AI 使用统一指标和关联规则

在已有的 DWD、DWS、ADS 数据模型基础上，整理统一指标定义、业务实体、维度关系和查询约束。

这里最重要的不是增加一套复杂的新平台，而是让原本散落在 SQL、报表和文档中的业务规则形成统一管理。

实际可以先选取一批高频业务问题，建立问题到指标、维度、数据服务的映射关系，再通过测试不断完善语义定义。

例如，同一个经营问题换成不同表达方式时，Agent 是否仍然选择相同的指标口径；涉及多表关联时，是否会发生数据重复计算；查询时间范围变化时，是否能够正确处理统计周期。

这些测试比单纯考察 Text-to-SQL 能否生成可执行语句更有价值。

第四步：通过数据 API 和 MCP 提供受控消费能力

最后，再把经过认证的数据能力封装为标准化服务，供 BI、业务系统和 Data Agent 使用。

在这一阶段，可以结合FineDataLink的数据 API 管理与 MCP 支持，减少上层应用直接访问底层表的需求。

同时建立 Agent 调用的权限、审计和结果验证机制，重点检查查询是否使用了正确指标、是否访问了授权数据、是否满足数据时效要求，以及输出结果能否追溯。

为保证这套架构长期运行，还应该建立指标变更、数据模型调整、接口版本更新时的影响评估机制，避免底层数据已经修改，上层 Agent 却仍使用旧规则。

从工程实践上看，我建议用下面这几个指标衡量改造效果，而不是只统计接入了多少张表。

这些指标不需要一开始全部做到最优，但至少能够帮助企业判断，自己的数据架构到底有没有真正变得更适合 AI 使用。

总结

数仓建了几百张表，AI 却不知道如何使用，问题不一定是数据架构建设失败了，而是原来的数据体系主要围绕存储、加工和报表分析设计，还没有充分考虑 AI 对业务语义、数据可信度和调用机制的要求。

所以，Data Agent 时代，企业数仓建设的重点需要发生一些调整：

不能只关注接入多少数据、加工多少模型、开发多少指标，还需要考虑这些数据能否被正确理解、稳定获取、质量验证和安全调用。

对于已有数仓，最值得做的不是重新建一遍，而是补齐缺失的能力，让成熟的数据资产真正能够服务 AI。

最后也留一个问题给正在做数仓和数据治理的同行：

你们企业目前的数据仓库，如果脱离分析师的人工解释，能有多少核心指标真正被 AI 准确理解和调用？

这或许比数仓里到底有多少张表，更能反映下一阶段的数据架构成熟度。

数仓建设的下一步，不是让数据越来越多，而是让业务规则越来越清晰、数据越来越可信、使用越来越简单。