AI 原生数据库吃掉 OLAP：向量+语义层+Agent 革命

一个不太有人提的事实：2026 年，OLAP 查询在很多新公司里正在变成少数派。

这是个看起来很违反直觉的判断。毕竟过去三十年，企业分析的默认范式就是 OLAP。星型模型、维度建模、立方体、MDX、Kimball，一整套方法论深入到每一个数据工程师的骨髓里。

但今天你去看那些 2024 年之后才搭数据平台的新公司，尤其是 AI 重度的那批，会发现一个非常古怪的现象：他们的数据平台里，传统 OLAP 查询只占一小部分。更多的查询长这样：

“找出和这段文字最相似的 1000 条历史工单”
“这个用户画像和我们最成功的客户群有多接近？”
“把上周的销售异常找出来，并解释为什么”
“帮我把这三个表 join 起来，我不知道怎么写”

这些查询没有一个是传统 OLAP 能好好回答的。它们都在绕过 SQL，绕过维度建模，绕过”先建仓再分析”的范式。

这不是一个小变化。这是数据库世界一场静悄悄的政变。

OLAP 的效率瓶颈：它不是慢，是问错了问题

先说清楚一点。OLAP 技术本身没问题。ClickHouse、Druid、StarRocks 这些引擎的查询性能依然惊人，列存 + 向量化执行 + MPP 架构可以做到亚秒级响应。

问题不在性能。问题在它的问题模型。

OLAP 的整个世界观是这样的：

业务需求可以结构化
结构化的需求可以转成 SQL
SQL 作用于干净的维度表和事实表
输出是精确的数字或者聚合结果

这个世界观在 2010-2020 年是成立的。那时候”分析”就是”算数”。算 GMV、算留存、算漏斗、算 ARPU，所有业务问题最终都能归约到 SUM / COUNT / GROUP BY。

但 2023 年之后，业务对”分析”的定义变了。

你看现在业务最频繁问的那类问题：

“这个客户为什么流失？”
“这批订单有什么共同点？”
“我们的竞争对手正在做什么？”
“这份合同和过去哪些合同最像？”

这些都不是算数问题。它们是语义问题、相似度问题、解释问题、探索问题。

OLAP 在回答这些问题时，显得格外笨拙。你必须先把模糊问题翻译成精确 SQL，翻译过程本身就是信息损耗。数据工程师要坐下来和业务拉会、理需求、写 DDL、建维度、造指标，一套流程走完，机会窗口早就没了。

这不是 OLAP 变慢了。这是业务需要的答案，OLAP 本来就答不了。

向量成为一等公民：存储层的重新洗牌

第一波真正的变化，发生在存储层。

2023 年前后，向量数据库作为独立品类爆发：Pinecone、Weaviate、Milvus、Qdrant。当时大家还觉得它是个 RAG 时代的配套产品，和正经数据库是两回事。

两年过去，情况完全变了。

向量不再是一个独立的数据类型，它正在和结构化数据同等地位。

具体来说：

Postgres 有 pgvector，AWS Aurora 有原生向量索引
BigQuery 和 Snowflake 都把 VECTOR_SEARCH 变成 SQL 函数
Databricks 的 Delta Lake 直接支持在 Parquet 文件上做向量搜索
新一代 AI 原生数据库（如 LanceDB、TurboPuffer、Chroma）把向量做进了核心数据模型

这意味着什么？意味着未来的查询，不会再分”这是结构化查询”和”这是向量查询”，它们会混在同一条 SQL 里：

SELECT customer_id, name, order_count
FROM customers
WHERE region = 'APAC'
  AND EMBEDDING_SIMILARITY(profile, '高价值 SaaS 决策者') > 0.8
ORDER BY order_count DESC
LIMIT 50;

这种查询跨越了结构化和非结构化的边界。它既用了传统的 WHERE 和 ORDER BY，又用了向量相似度。这种混合模式在 2022 年几乎是不可想象的，因为你要起两个系统、同步数据、写胶水代码。现在你只需要一张表。

这是第一步变化：向量从”AI 附件”变成”数据一等公民”。

语义层替代 SQL：自然语言成为新的查询接口

第二波变化更激进。

OLAP 时代，SQL 是通用语言。所有分析都要落回 SQL。业务用 BI 工具，工具底下还是 SQL。

但 2025 年之后，一个新的中间层浮出水面：语义层（Semantic Layer）。

语义层不是新概念。Looker 的 LookML、dbt 的 Semantic Layer 都属于这个范畴。但之前它只是 BI 工具的配套。现在它成了 AI 和数据库之间的默认接口。

为什么？因为 LLM 不擅长直接写 SQL。

你让一个 LLM 面对 500 张表、2 万个字段、几千个业务指标，直接生成正确的 SQL，成功率低得惊人。但如果在中间放一层语义层，把业务概念（客户、订单、留存率、活跃度）抽象出来，LLM 只需要理解业务概念，剩下的交给语义层翻译成 SQL，成功率立刻上一个量级。

所以现在的新架构变成这样：

用户自然语言
    ↓
LLM 理解意图，输出语义层查询
    ↓
语义层把业务概念翻译成技术 SQL
    ↓
数据仓库执行 SQL
    ↓
结果回流

这里面最有意思的一个变化是：业务用户不再学 SQL，数据工程师不再写报表。业务用户用自然语言提问，数据工程师维护语义层本身。角色分工彻底洗牌。

dbt、Cube、AtScale、MetricFlow 这几年成长都很快，原因就是这个。它们踩在了这条新范式的主通道上。

顺便说一句，传统 BI 厂商（Tableau、Power BI）如果不能在这个新栈里找到自己的位置，会越来越被边缘化。它们原来的价值是”让业务能画图”，但当”业务能直接用语言问数据”的时候，画图只是附属功能了。

Agent-native 查询：数据库长出了可编程的嘴

最彻底的变化，是 Agent 正在成为新的查询主体。

什么意思？以前查询都是人发起的。人坐在 SQL 编辑器前面，写 query，点运行，看结果。人是主体，数据库是被动工具。

2026 年正在发生的事情：Agent 开始成为比人更频繁的查询发起者。

举几个实际例子：

场景 1：客服 Agent。 用户问”我上个月的订单什么时候到？”Agent 需要查订单表、查物流表、查退款记录、查地理位置数据。这不是一条查询，是 5-10 条查询的组合。人做这个要写前端 + 后端 + API，Agent 自己就把活全干了。

场景 2：风控 Agent。 实时监控交易流，发现异常，自动调用 LLM 判断风险类型，写入新表，触发工作流。这里面每一步都在和数据库交互。

场景 3：BI Agent。 业务问一句”为什么上周销售掉了？”Agent 自动拆解问题，写出 20 条探索性查询，找到异常维度，生成报告。整个过程没有人直接写 SQL。

这些场景共同特点是：查询不再是孤立的，它们是工作流的一部分。

这对数据库提出了全新要求：

支持结构化的工具调用（function calling、tool use 在数据层的落地）
高并发、低延迟、成本可控（Agent 会疯狂发查询，传统按 TB 扫描计费的模式会被打爆）
原生支持可解释性（Agent 需要知道”这个数据从哪来的”）
强大的权限和审计（你不能让 Agent 乱查）

这就催生了一批新型的”Agent-native 数据平台”：Motherduck（把 DuckDB 做成 serverless）、TurboPuffer（专为 Agent workload 设计的向量 + KV 混合存储）、Databricks 的 Agent Bricks、Snowflake 的 Cortex Agents。

它们的共同卖点是：为 Agent 的查询模式专门优化。

反对意见与回应

以上这些听起来很美，但也会有反对声音。我试着把最强的反对意见摆出来，逐一回应。

反对 1：OLAP 不会被淘汰，它会一直是核心分析工具。

同意一半。OLAP 作为底层引擎，短期内不会被淘汰，列存和向量化执行这些能力依然必要。但它作为”默认分析范式”的地位，正在被削弱。未来更可能的情况是：OLAP 引擎成为新架构里的”计算层”，上面包一层语义层 + 向量能力 + Agent 接口。它不死，但它不再是舞台中央。

反对 2：自然语言查询不可靠，LLM 会出错。

这是真的。但 2023 年和 2026 年的差距比大多数人想象的大。三年前 Text-to-SQL 准确率 30-40%，现在配合语义层 + 思维链 + 自检机制，能做到 85%+。而且”不可靠”是一个移动的目标，今年的不可靠明年就解决了。更重要的是，对于探索性分析场景（占业务分析 60%+），85% 的准确率已经够用。精确报表依然可以用传统方式。

反对 3：向量 + OLAP 混合查询性能不行。

早期确实有这个问题。但 2024 年之后，HNSW 索引、IVF、DiskANN、filtered vector search 这一系列技术成熟，向量和结构化的混合查询性能已经进到生产可用水平。pgvector 在 2025 年的版本里，和 Qdrant、Milvus 这类专用向量库的性能差距已经很小。

反对 4：这些变化只适合新项目，存量系统不会迁移。

这也对。但历史告诉我们，新范式的扩散从来不是靠存量系统迁移，而是靠新项目挤占市场份额。Snowflake 十年前也是这样崛起的。五年后回头看，这批 AI 原生架构占的份额会远超现在的预期。