AI 没革掉数据库，先革掉了数据入口

很多数据工程师的第一反应是恐慌：AI 都能写 SQL 了，查询引擎和 BI 是不是要被推平重来？

但把两件正在同时发生的事放在一起看——AI Agent 驱动的灾备分析工作流开始落地，以及一位博主实测算出百万级文本块的向量存储成本远不止调用费——你会发现结论恰恰相反：AI 改变的不是底下的查询引擎，而是人和数据之间的那层接口。与此同时，向量这条新数据链路的成本结构，正在被严重低估。

这篇拆两件事：接口层到底怎么变了，以及这层变化背后的钱和账。

📉 一场灾备分析，暴露了 Agent 的工作真相

灾备演练是最诚实的场景——平时的一切优雅设计，在这里都要接受"数据还在不在、能不能快速算出可信结论"的拷问。

Peihao Yuan 在 InfoQ 的文章里描述了这样一个工作流：AI Agent 接到分析任务后，生成受约束的 SQL 或 Python 脚本，真正的计算交给 DuckDB 在 Parquet 文件上完成，算出可复现的事实（reproducible facts），最后再由 Agent 对结果做解读和归因。

注意这个分工的精妙之处：Agent 不直接"算数"，它只负责"写算式"和"念答案"。

这背后是一个清晰的原则——确定性拆分（determinism split）。大模型的输出天然带随机性，同一个问题问三遍可能得到三种表述；但灾备场景要的是同一个问题跑三遍，数字一分钱都不能差。于是架构被切成两半：LLM 的非确定性被隔离在"生成查询"和"解读结果"两端，中间夹着一个确定性的计算核心——DuckDB 读 Parquet，同样的输入永远给出同样的输出。

由此带来一个对灾备场景至关重要的性质：分析是可重放的（replayable）。只要把 Agent 生成的查询语句和数据快照存下来，任何时候重跑一遍，都能得到完全一致的事实。出了问题，你不需要怀疑"是不是模型幻觉把数算错了"——引擎层不存在幻觉，你只需要审计那几条 SQL。

据多位一线数据平台团队的人士私下聊，这套"Agent 写查询、引擎算事实"的模式，正在从灾备这种边缘场景，悄悄往日常的数据自助分析里渗。原因很朴素：审计员接受 SQL，不接受一个黑盒直接给出结论。

产业逻辑已经浮出水面：AI 没有淘汰 SQL，反而让 SQL 成了人机之间新的契约文本——机器写，人审，引擎执行。

💸 100 万文本块的账单：调用费只是冰山一角

做知识库检索（RAG）的团队，几乎人人算过 embedding 的调用费，但很少有人算过：向量本身占多少地方？

博主大Token用 Python 3.13 标准库写了个纯算术脚本（outputs/vector_store_measure.py），把账摊开了算：场景是 100 万条文本块、每块 500 token。按 OpenAI 官方文档，text-embedding-3-small 默认 1536 维，text-embedding-3-large 默认更高维度。

这个数字意味着什么？按 float32 存储，一个 1536 维向量约 6KB。100 万条，仅原始向量就是 6GB 起步；如果用更高维的 large 模型，直接翻倍。而这还只是"向量躺在磁盘上"的钱——真实的向量数据库在生产环境里，上面还压着好几层隐性开销。

最容易被忽略的是最后一层：embedding 模型不是永久的。换了新模型、调整了切块粒度，整个向量库就要推倒重建——调用费付一次，存储费和重建费付一辈子。

这就是那句话的分量：很多人只算 embedding 调用费，很少算向量本身占多少地方。

产业逻辑同样清晰：当"数据"的定义从结构化表格扩展到千万级高维向量，存储和索引的成本模型必须重算。那些靠"调用费很便宜"讲增长故事的应用团队，账本迟早会在规模化后翻车。

🧩 确定性拆分：Agent 负责"说"，引擎负责"算"

把第一节和第二节连起来看，会发现它们指向同一个底层判断：AI 时代的计算架构，关键在于把确定性和非确定性放在正确的位置。

（注：上图为笔者基于公开口碑的行业观察定位，不代表任何官方数据。）

有意思的是，在这张图上最"老"的技术组合——SQL + 列存文件——反而在 Agent 时代被重新盘活了。原因有三：

第一，Parquet 是 Agent 最好的"共享记忆"。文件即数据，不依赖某个在线服务的会话状态，Agent 挂了重开一个，数据还在原地。

第二，DuckDB 这类嵌入式引擎把"计算"变成了一个纯函数。没有集群调度、没有排队、没有并发干扰，输入相同输出就相同——这正是可重放分析的技术前提。

第三，SQL 是可审计的。当 AI 进入数据分析流程，最刚性的需求不是更聪明的模型，而是每一步都可核查。一条 20 行的 SQL，人眼能扫完；一个黑盒推理过程，审计算法团队也没法签字。

一位在金融行业做数据合规的朋友说得更直白："监管问的不是 AI 多聪明，是问这个数字从哪来的。SQL 就是答案。"

所以别再争论"AI 会不会取代数据分析师"了。更准确的画像是：Agent 取代的是点击式分析界面，而不是计算引擎；人从写查询退到审查询。

🚦 四个信号：什么时候嵌入式够用，什么时候该上湖仓

既然 DuckDB + Parquet 这么香，湖仓平台还卖得动吗？这恰恰是这篇文章最工程化的部分：它给出了四个信号，帮你判断嵌入式引擎什么时候够用，托管湖仓什么时候才值得上。

文章没有把信号写死成教条，但结合工程实践，这条分界线大致可以这样归纳：

信号一：数据规模触顶。单机放得下的时候，任何分布式系统的运维成本都是纯浪费；一旦突破单机，嵌入式方案就开始透支未来。

信号二：并发与共享需求出现。DuckDB 是"每进程一个引擎"的思路，两个人同时改同一份数据，嵌入式方案立刻捉襟见肘。

信号三：数据新鲜度要求升级。灾备复盘可以接受昨天的快照，但实时风控、实时大屏不行——流式摄入是托管平台的主场。

信号四：治理与合规成本超阈值。数据一旦要从"我电脑上的 Parquet"变成"公司的数据资产"，权限、血缘、审计、生命周期管理，每一项都是成本。

注意这四个信号的共同点：它们全都来自组织协作，而不是技术先进性。嵌入式引擎没有输在性能，托管湖仓也不只是"更大的 DuckDB"——湖仓卖的从来是治理、共享和规模化协同，这也是为什么单机性能再强，也替代不了平台层的生意。

🏗️ 接口层，正在成为新的战场

把所有线索收拢，能得到一个对接下来两三年数据产业的判断：

查询引擎的格局基本稳定，变局发生在它上面那一层——数据接口。

过去十年，数据平台竞争的焦点是"怎么算得更快更省"——列存、向量化执行、湖仓一体，引擎层的创新红利已经被吃得很充分。而 Agent 的到来改变的是问题的提法：不再是人打开 BI 工具拖拽，而是 Agent 拿着自然语言需求，自己去找数据、自己写查询。

这意味着三件事正在同时发生：

语义层（Semantic Layer）价值重估。Agent 要正确地写 SQL，前提是它理解"营收""活跃用户"这些口径的定义。谁家的元数据和语义层最完整，谁的 Agent 分析就越可信——这解释了为什么各家湖仓厂商都在收紧自己的语义目录。

向量成了新的数据资产，但成本账要重算。百万级文本块的向量已经 GB 起步，乘上副本、索引和重建周期，RAG 团队的真实基础设施开支可能是 API 账单的数倍。给工程团队的建议很直接：把向量存储纳入容量规划，和表数据一视同仁地做生命周期管理。

"确定性外包给引擎，创造性留给模型"会成为标准架构模式。不管是灾备分析还是日常自助分析，可重放都是企业敢把 AI 放进关键流程的底线条件。做不到重放的分析产品，在采购评审时会被审计直接问死。

一位做了十几年数仓的架构师私下说："我们等了十年，等到的不是 SQL 的葬礼，是 SQL 的加冕。"

小结：AI 没有革掉查询引擎，它革掉的是人和数据之间的那层交互界面——Agent 成为新的入口，SQL 成为新的契约，确定性引擎成为信任的锚点。与此同时，向量这条新链路的存储成本正在浮出水面，嵌入式引擎与托管湖仓的边界由规模、并发、新鲜度和治理四个信号划定。对从业者而言，真正的机会不在"再造一个引擎"，而在把接口层、语义层和成本账算清楚——下一轮数据平台的洗牌，就从这里开始。