AI驱动的数据仓库：每个AI产品的架构启示

一些最引人入胜的AI架构工作正发生在数据栈内部。Snowflake、Databricks、ClickHouse、BigQuery、MotherDuck、Redshift等公司，正在为早于LLM构建的系统添加模型和代理。

这迫使它们解决每个AI构建者都开始面临的架构问题。推理应该在哪里运行？哪些部分应保持确定性？模型输出应如何表示为数据？代理应该驻留在哪里？所有这一切应如何融入现有系统，而不必围绕AI重建整个技术栈？

数据仓库是观察这一进程的一个特别有趣的领域。这些是成熟的系统，在查询执行、转换、计算、语义、治理和血缘关系方面有着明确的边界。AI现在正推动着几乎每一个这样的边界。这里涌现的架构模式，或许能让我们提前窥见软件栈其余部分将如何适应AI。

以下是我们从数据平台适应AI的方式中汲取的七个架构教训。

1. 推理正演变为数据库操作符

最明显的趋势之一是将推理直接融入查询层。Snowflake、BigQuery、Databricks 等平台现在允许开发者在数据查询中使用模型进行过滤、分类、提取、生成、评分和聚合。

从查询中调用 LLM 仅仅是开始。一旦推理能与普通数据库操作组合，模型实际上就参与了查询执行。查询可以扫描行，让模型判断其含义，基于该判断进行过滤，并将结果输入到确定性聚合中。

Snowflake 已更进一步，为 AI 操作符引入了 AI 感知的查询优化。LLM 调用的成本与传统谓词截然不同，因此优化器必须决定这些语义操作在查询计划中的位置。此时，推理更像是一种新型数据库操作符，而非外部服务调用。

2. 转换能推断事实，而不仅仅是重塑数据

仓库内部的转换层也在发生变化。传统转换通过确定性操作进行解析、连接、规范化和聚合。而LLM转换则更进一步，能够实际推断源数据的某些信息，并将这种推断物化为新数据。

这解锁了一整套全新的数据源，其中数据只能通过推断获得。例如，一份合同可以转化为一系列义务，或者一通销售电话可以转化为一系列异议。

Databricks能够在数据管道内结合文档解析与AI提取，而MotherDuck则能在行间应用推断，并返回类似于普通仓库数据的结构化值。

有些列直接来自源系统，有些是确定性计算的，还有一些可能代表管道过程中产生的模型判断。在下游，使用SQL时，它们看起来都像数据。

3. 语义层正转变为代理的基础设施

文本转SQL暴露了一个事实：模式并非业务模型。知道某列名为“收入”并不能告诉代理公司如何定义收入、哪个表是权威来源、通常应用哪些过滤器，或者分析师会如何回答特定问题。

Snowflake的语义视图通过暴露指标和关系，连同过滤器、指令和已验证查询，为Cortex Agents提供了这种理解。Databricks Genie同样将Unity Catalog数据与示例查询、业务语义和自然语言指令相结合。Microsoft Fabric的Data Agent在生成答案时，将模式信息与数据源指令和示例查询结合起来。

语义层最初主要是作为仓库数据与分析工具之间的接口而构建的。代理赋予了它另一项任务：提供额外的上下文，教导模型组织期望如何利用其数据。

这种模式在数据仓库之外也有用武之地。智能体需要访问数据，但它们同样需要一个机器可读的模型来理解这些数据的含义。

4. 智能体的位置是一个架构决策

各平台在智能体应驻留何处的问题上，正采取明显不同的策略。Snowflake Cortex Agents、Databricks Genie Agents 和 ClickHouse Agents 将智能体置于数据平台内部，使其紧邻执行层。

其他平台则期望智能体驻留在仓库之外，并将数据平台作为工具暴露出来。Databricks 和 MotherDuck 为外部智能体提供 MCP 接口，而 ClickHouse 也支持基于 MCP 的连接，贯穿其智能体与数据产品。同样，AWS 的 Agent Toolkit 允许外部编码智能体与仓库基础设施交互。

多家供应商正在双管齐下，这种做法最终可能成为普遍趋势。一家公司可能会使用仓库原生的智能体进行数据分析，同时允许 Claude Code、Codex 或更高级别的企业智能体将同一数据平台作为众多工具之一来使用。

5. 仓库现已成为智能体工作的执行环境

赋予智能体查询数据的权限，自然引出一个更大的问题：智能体能否也创建并操作生成数据的机制？

MotherDuck提供了一个尤为清晰的范例。其Flights运行时支持按需或定时在数据旁执行Python代码。外部编码智能体可通过MCP检查仓库数据，编写数据摄取或转换程序，将其部署为Flight，安排调度，随后查询该程序生成的结果。

Databricks则通过一个更为广泛的平台应对同一挑战。Unity Catalog、SQL、Python、Lakeflow、模型服务、Agent Bricks、应用及MLflow日益融合，共同构建了一个集数据管道与AI系统创建、执行、治理与评估于一体的统一环境。

在此背景下，旧有的界限开始变得模糊。以往，仓库存储数据，编排系统管理管道，而应用程序则独立于他处。如今，一个能够检视数据、生成转换并执行这些操作的智能体，已跨越了这三者之间的传统分界。

6. 智能体是数据库的新工作负载

ClickHouse对此尤为明确。他们认为智能体的行为方式与人类用户不同，而传统分析型数据库的设计围绕的是人类，而非智能体。

人类分析师在调查问题时可能会编写少量查询。而智能体能在几秒内检查元数据、生成查询、执行、检查结果、形成另一个假设、查询另一张表、遇到错误、检查模式、重试，并比较多种可能性。因此，一个人类请求可能产生数十次数据库操作。

另一方面，智能体的流量可能高度迭代、突发、并发且对延迟敏感。ClickHouse因此强调低查询延迟和高并发，而MotherDuck的超级多租户模型则为个人用户或智能体提供隔离的DuckDB计算资源，而非将所有活动置于同一共享计算上。

现代分析技术栈深受其主要消费者的影响：BI仪表板、定时转换、数据应用和人类分析师。随着智能体成为另一个主要消费者，数据库也需要围绕它们的访问模式进行设计。

7. AI生成的数据需要自己的血统

一旦LLM成为转换层的一部分，它们的输出就会与各种其他类型的数据一同出现在仓库中。但AI生成的数据与传统派生数据有着不同的历史。例如，如果模型判断某次客户互动属于账单投诉，我们可能还需要知道是哪个模型做出了这一决定，它接收了哪个提示词，以及当时运行的是哪个版本的转换。

关键问题在于，区分来自源系统的事实与最初源自LLM的判断将变得更加困难。

数据平台已经拥有丰富的系统来追踪数据的来源及其转换方式。随着推理融入这些转换过程，血统信息可能也需要包含帮助生成数据的模型和提示词。

数据栈是AI架构的预览

这些数据仓库公司正在采用的模式很可能具有重要意义，并且其适用性远超数据仓库本身。

数据仓库可能是大型企业首次在真实生产规模上部署AI驱动软件的地方之一。它们已经嵌入成熟的企业系统中，拥有现有的数据、治理、权限、基础设施和用户。

这使得数据栈成为观察成熟企业内部生产级AI实际形态的一个异常重要的试验场。这里涌现的架构模式最终可能会塑造企业软件栈中AI采纳的广泛程度。