陶玉印的博客

企业数据治理、数据仓库、数据质量、AI应用实践与研究

0%

企业需要怎样的数据底座，才能真正支撑Data Agent？

发表于

企业需要怎样的数据底座，才能真正支撑Data Agent？

前面的文章中，我们讨论了一个越来越明确的趋势：随着ChatBI和Data Agent的发展，企业数据应用正在从“提前开发答案”转向“根据问题生成答案”，而数据仓库的角色，也正在从传统BI的后台逐渐演变为AI应用的可信数据底座。

但是，当企业真正准备建设Data Agent时，一个更加现实的问题随之而来：

现有的数据仓库，真的可以直接支撑Data Agent吗？

我的答案是：大多数情况下还不够。

很多企业已经建设了多年的数据仓库，拥有ODS、DWD、DWS、ADS等完整的数据分层，也建立了大量面向财务、营销、供应链和生产管理的报表。在传统BI体系下，这套架构已经能够很好地工作，但如果直接在它上面接入大模型，让Agent面对数千张数据表自动生成SQL并回答业务问题，很快就会发现很多以前并不明显的问题。

AI不知道哪张表是可信的，不知道同名指标应该选择哪个口径，不知道表与表之间应该怎样关联，也不知道某个用户是否有权查看某些数据；即使它成功生成了一段语法完全正确的SQL，也无法证明最终返回的结果就是企业希望得到的那个答案。

因此，Data Agent时代真正需要建设的，并不是一个“可以被大模型访问的数据仓库”，而是一套可以被机器准确理解、可靠查询、受控访问并能够追溯结果的数据体系。

这两者之间，有着本质区别。

一、传统数据仓库解决了数据问题，但没有完全解决“机器理解”问题

先看一套比较典型的企业数据架构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ERP / CRM / MES / SRM / WMS
              │
              ▼
        数据集成 / CDC
              │
              ▼
             ODS
              │
              ▼
             DWD
              │
              ▼
             DWS
              │
              ▼
             ADS
              │
              ▼
        OLAP / BI / 报表

这套架构的核心目标，是将不同业务系统的数据汇集起来，经过清洗、转换、建模和汇总之后，为下游数据分析提供统一的数据来源。

在过去二十年里，它已经被证明是一种非常成功的架构。

问题在于，这套体系主要是为人和预定义程序设计的。

数据开发工程师知道dwd_sales_order_detail是什么，BI工程师知道应该使用哪张DWS表，财务分析人员知道“含税销售收入”和“不含税销售收入”有什么区别，这些知识大量存在于人的经验、需求文档、SQL代码以及部门内部约定中。

Data Agent却没有这些经验。

假设一家企业的数据仓库拥有1200张表，Agent面对的可能是这样的对象：

1
2
3
4
5
6
7
8
dwd_sales_order_detail
dwd_sales_invoice_detail
dwd_sales_return_detail
dws_customer_sales_month
dws_customer_profit_month
ads_sales_analysis
ads_finance_revenue
...

业务人员只问了一句话：

“今年华东地区的销售收入同比增长多少？”

对于人类数据工程师来说，这可能是一个非常简单的问题，因为他知道公司默认使用财务确认收入，知道应该使用哪个日期字段，也知道华东区域按照客户所属销售区域而不是发货地址划分。

但是对于Agent来说，这句话至少包含四个需要解释的概念：

什么叫“销售收入”？

什么叫“今年”？

什么叫“华东地区”？

同比应该和哪个期间比较？

如果这些规则没有被显式表达出来，大模型只能根据字段名称、表结构和上下文进行猜测。

而企业数据分析最不能依赖的，恰恰就是猜测。

二、Data Agent需要的不是数据库访问权，而是企业数据的“说明书”

早期ChatBI产品有一种很常见的技术路线：把数据库Schema提供给大模型，让模型根据用户问题生成SQL，然后执行SQL并返回结果。

对于十几张结构清晰的表，这种Text-to-SQL模式可能工作得很好。

但是进入企业级数据仓库之后，问题会迅速复杂化。

例如：

1
2
3
4
5
6
SELECT
    region_name,
    SUM(sales_amount) AS sales_amount
FROM dws_sales_month
WHERE year_id = 2026
GROUP BY region_name;

从SQL语法来看没有任何问题。

但真正需要确认的是：

sales_amount是含税还是不含税？

是否扣除了退货？

区域按照客户归属还是订单归属？

2026年的数据是否已经完成月结？

这意味着，企业不能只把Schema交给Agent，还必须告诉它Schema背后的业务含义。

因此，在数据仓库与Agent之间，我认为必须增加一个非常重要的能力层：

Semantic Layer，也就是语义层。

它负责把数据库中的物理结构转换成业务可以理解、Agent也可以理解的语义模型。

例如，不应该让Agent自己推断“销售收入”应该如何计算，而应该明确告诉它：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
metric:
  name: sales_revenue
  label: 销售收入
  description: 财务确认的销售收入，不含税并扣除销售退回

  source: dws_finance_sales_month

  measure:
    type: sum
    field: revenue_excluding_tax

  time_dimension: accounting_date

  dimensions:
    - sales_region
    - customer
    - product

  owner: finance_center
  certified: true

这样，当业务人员询问销售收入时，Agent需要做的就不再是“猜测应该使用哪个字段”，而是选择一个已经经过企业认证的指标。

这正是语义层在AI时代重新受到重视的重要原因：它将过去存在于数据工程师头脑里的隐性知识，转换成机器可以理解和调用的显性知识。

三、一个真正面向Data Agent的数据架构应该是什么样？

如果重新设计一套面向Data Agent的数据体系，我更倾向于采用下面这样的逻辑架构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
┌───────────────────────────────────────────────┐
│                AI Application Layer           │
│                                               │
│   ChatBI   Data Agent   AI Copilot   Workflow │
└───────────────────────┬───────────────────────┘
                        │
                 MCP / API / SQL
                        │
┌───────────────────────▼───────────────────────┐
│              Semantic & Knowledge Layer       │
│                                               │
│  Metrics │ Dimensions │ Entities │ Glossary   │
│  Joins   │ Business Rules │ Knowledge │ ACL   │
└───────────────────────┬───────────────────────┘
                        │
┌───────────────────────▼───────────────────────┐
│              Trusted Data Foundation          │
│                                               │
│ Data Warehouse │ Lakehouse │ MDM │ Metadata   │
│ Data Quality   │ Lineage   │ Catalog │ Security│
└───────────────────────┬───────────────────────┘
                        │
┌───────────────────────▼───────────────────────┐
│                 Source Systems                │
│                                               │
│ ERP │ MES │ CRM │ SRM │ WMS │ OA │ Files     │
└───────────────────────────────────────────────┘

与传统数据仓库相比，底层的数据采集、清洗、建模和存储并没有消失，真正增加的是中间的Semantic & Knowledge Layer。

这也是我认为AI时代企业数据架构最值得关注的变化之一。

过去的架构重点解决：

数据如何从源系统流向BI？

未来还必须解决：

AI如何理解这些数据代表什么？

四、第一项基础能力：可信的数据仓库或Lakehouse

无论上层采用什么样的Agent框架，最底层仍然需要一个稳定的数据基础设施。

它可能是传统Hive数据仓库，也可能是Snowflake、Databricks等云数据平台，还可能采用Iceberg、Hudi、Paimon等开放表格式建设Lakehouse。

技术选择本身并不是最重要的。

真正重要的是这一层能够提供几个基本能力：

稳定的数据模型、完整的历史数据、可追溯的数据加工过程、可靠的数据更新机制，以及能够满足Agent查询需求的性能。

尤其需要注意最后一点。

传统BI的查询模式相对稳定，一张Dashboard可能每天执行几十次固定SQL，而Agent的查询模式完全不同。一个复杂问题可能被拆解成十几个子问题，Agent不断执行查询、验证假设并继续追问，这会使数据平台面临完全不同的并发和计算压力。

因此，未来的数据底座不仅要“存得下”，还要能够支撑大量动态、不可预测的分析请求。

对于传统Hive体系，可以继续承担离线数据加工和历史数据沉淀；对于需要秒级交互的数据，可以通过ClickHouse、Doris、StarRocks等OLAP引擎提供服务；如果企业正在建设新的湖仓体系，则可以考虑Iceberg、Paimon等表格式解决数据湖上的事务、Schema演进以及批流数据管理问题。

关键不是追求某一种“AI原生数据库”，而是根据数据规模、时效要求和查询模式建立合理的数据服务层。

五、第二项基础能力：统一语义层

如果只能从整个架构中选择一个我认为最值得企业AI团队重点建设的能力，我会选择Semantic Layer。

原因并不复杂。

Data Agent最危险的情况并不是“不会回答”，而是：

它非常自信地回答了一个口径错误的答案。

假设企业存在三个销售额指标：

1
2
3
sales_order_amount       订单金额
sales_invoice_amount     开票金额
sales_revenue            财务确认收入

业务人员问：

“今年销售额是多少？”

传统BI不存在太大问题，因为报表开发时已经选择了指标。

而Agent必须实时做出选择。

如果没有Semantic Layer，它只能根据名称猜测；如果存在统一语义层，则可以根据业务定义、用户角色和分析场景选择经过认证的指标。

截至2026年，Semantic Layer已经形成了比较明确的产品方向，例如dbt Semantic Layer、Cube以及部分云数据平台和BI产品自身的语义模型。它们实现方式不同，但核心思想非常接近：将Metric、Dimension、Entity、Join和Access Policy从具体报表中抽离出来，形成可以被多个数据应用复用的统一业务语义。

在AI时代，这一能力的意义已经不仅仅是让“不同BI看到同一个数字”，而是让人和Agent使用同一种企业语言。

六、第三项基础能力：元数据必须从“给人看”变成“给机器用”

过去企业建设元数据平台，更多是为了数据资产目录、血缘查询和数据治理。

数据人员打开数据目录，搜索一张表，查看字段说明和上下游血缘。

Agent时代，元数据的消费者发生了变化。

Agent同样需要知道：

customer_id是什么意思？

这张表由谁负责？

数据多久更新一次？

上一次质量检查是否通过？

这个指标来自哪些源系统？

哪些字段属于敏感数据？

因此，未来元数据平台必须具备机器可访问能力，而不能只是一个Web管理页面。

DataHub、OpenMetadata、Apache Atlas等元数据平台所沉淀的Schema、Ownership、Lineage、Glossary、Tag等信息，都有可能成为Agent Context的一部分。

例如，当Agent准备查询某个指标时，可以先获取：

1
2
3
4
5
6
7
8
{
  "metric": "gross_profit",
  "owner": "finance_center",
  "certified": true,
  "freshness": "T+1",
  "last_quality_check": "PASS",
  "source": "dws_finance_profit_month"
}

然后再决定是否使用这份数据。

这实际上意味着：

Metadata正在从数据治理系统的辅助信息，转变为Agent的上下文基础设施。

七、第四项基础能力：数据质量必须成为Agent调用数据之前的门禁

上一篇文章重点讨论了AI时代的数据质量。

如果把这个观点真正落到架构上，我认为应该遵循一个非常重要的原则：

质量检查应该发生在Agent消费数据之前，而不是回答错误之后。

传统的数据质量规则通常运行在ETL过程中，例如：

1
2
3
SELECT COUNT(*)
FROM dwd_sales_order
WHERE customer_id IS NULL;

未来可以进一步把质量状态暴露给语义层和Agent。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
sales_revenue
    │
    ├── Accuracy      PASS
    ├── Completeness  PASS
    ├── Freshness     PASS
    ├── Reconciliation PASS
    │
    ▼
Certified Metric
    │
    ▼
Data Agent

如果当天财务数据尚未完成同步，指标状态就不应该是“Certified”，Agent可以直接告诉用户：

当前财务收入数据更新至8月9日，8月10日数据尚未完成同步，本次分析基于8月9日数据。

这比生成一个看起来准确、实际上数据并不完整的答案更加专业。

未来成熟的Data Agent，不应该只返回一个数字，还应该返回这个数字的可信状态。

八、第五项基础能力：主数据决定Agent能否正确理解企业实体

主数据管理在BI时代已经非常重要，而到了Agent时代，它的重要性会进一步提高。

假设同一个经销商在三个系统中的编码分别是：

1
2
3
ERP        C000238
CRM        CRM_10086
SRM        SUP-238

对于业务人员来说，这三个编码可能都代表同一家企业。

对于Agent来说，如果没有统一Customer ID，它们就是三个不同的实体。

于是，当业务人员问：

“分析这个经销商过去三年的销售、回款和售后情况。”

Agent需要同时关联CRM、ERP、财务以及售后数据。

如果企业没有做好主数据管理，这个问题甚至无法可靠计算。

因此，MDM在AI时代承担了一个新的角色：

为Agent建立企业实体的统一身份体系。

Customer、Product、Supplier、Employee、Organization等核心实体，都需要形成稳定的Entity ID。

只有这样，Agent才能真正完成跨系统推理。

九、第六项基础能力：权限必须跟着用户，而不是跟着Agent

这是很多Data Agent Demo最容易忽略的问题。

假设销售经理问：

“所有区域销售人员的奖金分别是多少？”

Agent有能力查询。

数据库也有这些数据。

但问题是：

他有权限查看吗？

传统BI通常通过报表权限、行级权限和字段权限控制访问。

Agent时代，这些权限不能消失，更不能简单地给Agent一个拥有全部数据库权限的Service Account。

正确的架构应该是：

1
2
3
4
5
6
7
8
9
10
11
12
User
 │
 │ Identity / Role
 ▼
Agent
 │
 ▼
Semantic Layer
 │
 │ Row / Column / Metric Policy
 ▼
Data Platform

也就是说，Agent只是代表用户执行任务，最终能够看到什么数据，仍然应该由用户身份和数据权限决定。

这也是为什么我不建议企业直接让大模型连接生产数据仓库并自由生成SQL。

真正的企业级Data Agent，必须运行在受治理的数据访问层之上。

十、企业案例：制造业Data Agent应该怎样查询“利润下降原因”？

假设一家制造企业拥有ERP、MES、CRM、SRM和财务系统。

总经理提出一个问题：

“为什么这个季度某产品线毛利率下降了？”

如果只是Text-to-SQL，Agent可能找到一张利润表，然后计算毛利率变化。

但真正的Data Agent应该完成更加完整的分析链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
问题：毛利率为什么下降？
            │
            ▼
识别指标：Gross Margin
            │
            ▼
Semantic Layer确认指标口径
            │
            ▼
获取销售收入、销售成本
            │
            ▼
发现成本同比上升
            │
            ▼
进一步拆解
      ┌─────┼─────┐
      ▼     ▼     ▼
   材料成本 人工成本 制造费用
      │
      ▼
发现某材料采购价格上涨
      │
      ▼
关联SRM采购数据
      │
      ▼
识别主要供应商及价格变化
      │
      ▼
生成原因分析

这个场景真正考验的，已经不是大模型能不能写SQL，而是企业是否已经建立：

统一的产品主数据。

统一的毛利率指标。

销售与成本模型。

ERP与SRM之间的数据映射。

可信的数据质量体系。

完整的数据血缘。

只有这些能力存在，Agent才可能完成真正有业务价值的多步分析。

否则所谓的Data Agent，最终仍然只是一个高级Text-to-SQL工具。

十一、工具怎么选？不要为了Agent重建整个数据平台

企业很容易犯另一个错误：看到AI之后，认为现有的数据平台已经过时，于是准备重新建设一套“AI数据平台”。

我认为大多数企业没有这个必要。

更合理的方法，是在现有数据体系之上逐层补齐能力。

能力层 已有传统方案 可以演进的方向
数据加工 Hive / Spark / Flink 继续使用，不必为了AI替换
数据服务 ClickHouse / Doris / StarRocks 提供低延迟Agent查询
Lakehouse Hive Table Iceberg / Paimon等
元数据 Atlas / 自研 DataHub / OpenMetadata等
数据质量 SQL规则 / 自研 dbt Tests / Great Expectations / Soda等
Semantic Layer BI指标模型 dbt Semantic Layer / Cube / 自研指标语义层
Agent接口 JDBC / REST Governed API / MCP / Tool Calling
AI应用 ChatBI Data Agent / AI Copilot

这里没有所谓的标准答案。

如果企业已经拥有成熟的Hive数仓，没有必要为了AI把所有数据迁移到Lakehouse；如果已经拥有成熟的指标平台，也没有必要重新购买Semantic Layer产品。

真正需要判断的是：

现有的数据能力是否能够以标准化、机器可理解的方式提供给Agent。

这才是架构演进的核心。

十二、架构师视角：不要让Agent直接面对数据仓库

如果让我给正在建设Data Agent的企业一个最重要的架构建议，我会选择这一条：

不要让Agent直接面对整个数据仓库。

因为一个成熟企业的数据仓库中往往存在数百甚至数千张表，其中包含大量中间表、临时表、历史表以及不同版本的指标模型。

把这些Schema全部提供给LLM，不仅增加Context，还会增加模型选择错误数据源的概率。

更加合理的架构应该是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
           Data Agent
               │
               ▼
        Agent Data API
               │
               ▼
        Semantic Layer
               │
   ┌───────────┼───────────┐
   ▼           ▼           ▼
Metrics     Entities    Dimensions
   │           │           │
   └───────────┼───────────┘
               ▼
        Certified Data
               │
               ▼
       Data Warehouse

也就是说，Agent原则上应该优先访问经过认证的数据产品和业务语义，只有在需要深度探索时，才逐步开放更底层的数据能力。

这实际上与软件工程中的API设计非常相似。

我们不会让前端系统直接修改数据库。

同样，也不应该让Agent任意访问企业数据仓库。

Semantic Layer，本质上就是AI时代的数据API。

写在最后

如果说过去二十年企业数据平台建设的重点，是把分散的数据汇集起来，那么未来几年企业数据建设的重点，很可能会逐渐转向另一个问题：

如何让机器正确理解这些数据。

这也是Data Agent对企业数据体系提出的最大挑战。

它需要的不只是一个数据仓库，而是一套由可信数据、统一语义、元数据、主数据、数据质量、权限治理以及标准化访问接口共同组成的数据基础设施。

从这个角度看，AI并没有让过去的数据建设失去价值。

恰恰相反。

企业过去多年建设的数据仓库、数据治理、数据质量、主数据和元数据体系，正在第一次被连接起来，并共同成为AI应用的基础。

数据仓库解决的是“数据在哪里”。

Semantic Layer解决的是“数据是什么意思”。

数据质量解决的是“数据能不能相信”。

元数据解决的是“数据从哪里来”。

主数据解决的是“它到底是谁”。

权限体系解决的是“谁可以使用”。

而Data Agent最终解决的，才是：

如何利用这些数据和知识完成任务。

因此，真正成熟的企业Data Agent，并不是在大模型上增加一个数据库连接器，而是在企业已经形成的数据能力之上，再建立一层能够理解、推理和行动的智能系统。

这也是我认为AI时代企业数据架构真正的演进方向。