别再迷信引擎了，胜负在存储层

数据平台圈流传一句话：架构师的收入，靠的是踩坑次数，而不是 PPT 页数。过去两年，厂商营销页上的对比图让我们习惯性地相信：换一个更聪明的引擎，一切数据问题都会自动消失。但最近三件事凑到一起——Vast Data 的 CTO 公开说 AI Agent 的记忆 belongs to storage、一场凌晨三点的 BigQuery/Databricks 迁移翻车、Fivetran 推出托管数据湖服务——指向同一个判断：行业的价值重心正在从‘更聪明的引擎’挪回‘更扎实的存储与数据层’。这不是概念轮回，是需求结构真的变了。

🧠 Agent 的记忆，凭什么归存储管

一句话：Agent 跑得越久，记忆越不像缓存问题，越像存储问题。

先讲一个正在发生的场景。一家企业部署了几十个 Agent：客服 Agent 处理工单，销售 Agent 跟进线索，运维 Agent 巡检集群。单次会话的上下文，GPU 显存和大模型服务还能兜住。真正的麻烦在会话之外——这些 Agent 要跨部门、跨天、跨业务地运行，它们需要的是可持久化、可共享、可检索的企业级记忆：上周的决策、三个月前的工单结论、其他 Agent 留下的中间状态。

Vast Data 的 CTO 给出的答案很直接：这件事应该交给存储层，用分层存储来承接。他的逻辑是，Agent 记忆的需求结构天然是分层的——热数据（当前会话上下文）要求极低延迟，温数据（近期会话与共享知识）要求随机读取，冷数据（历史轨迹、合规留存）要求低成本长期保存。让每一层都用最合适的介质，才是工程上说得通的方案。

三层各自的介质选型、访问模式和生命周期差异，正文里只点了需求方向，落成一张对照图会更清楚——这也是判断“某类负载适不适合放某一层”时实际要过的三道检查项：

这背后是一个产业级转向。过去十年，存储层的叙事一直是“当数据的仓库，当算力的配角”。而 AI Agent 把需求倒过来了：记忆的容量、迁移成本和检索效率，直接决定 Agent 能在多大规模上跑起来。这意味着存储厂商第一次站到了 AI 应用架构的关键路径上。

判断很清晰：如果 Agent 要在企业里长期驻留，记忆基础设施就必须像数据库一样可靠、像对象存储一样便宜——这个交集，正是存储厂商的主场。

⚠️ 凌晨三点的那笔 400 美元账单

一句话：‘引擎会自己搞定’，是数据团队讲给自己听的最大的谎。

“叙事口径说明：本节为基于真实事故改写的案例化叙事。企业与人物已匿名处理，时间点与账单金额为当事工程师的回忆口径，未经独立核实，仅用于说明失效模式，不构成对任何厂商产品的评价依据。

接下来是事故现场。凌晨 3 点 42 分，把一位工程师吵醒的不是 PagerDuty 的告警，而是笔记本风扇的啸叫——某个仪表盘平时 12 秒加载完，这次转了 14 分钟，最后抛出一个 RESOURCE_EXHAUSTED。当时团队正处在迁移中途：核心报表层对接的是 S3 上 4TB 的 Parquet 文件，一边用 Databricks 的 Serverless SQL，一边用 BigQuery 的 BigLake 做对照测试。

问题出在哪？一张按天分区、去范式化的大事实表（Delta 开放格式），去 JOIN 一张维度表——而这张维度表，被某位同事不小心存成了一千个小 JSON 文件。

后果很直白：Databricks 侧，SQL Warehouse 开着 Pro 档位和 Auto-stop，一个跑在非分区列上的复杂窗口函数直接把 spill-to-disk 指标打爆，io.file.write.bytes 飙升，查询调度器超时；BigQuery 侧更简单粗暴——一次探索性分析，账单 400 美元。

下面的图在事故链路之外，同时标出了三个事后复盘确认的“堵点”——也就是这条链路里最早可以被打断的位置。正文只讲了事故怎么发生，堵点在哪、按什么优先级去堵，是图里补充的信息：

这件事的价值不在事故本身，而在于它戳破的幻觉：团队当时默认‘我们用的是 Serverless + BigLake 这层抽象，重活会被引擎接管’。结果引擎没有接管——它只是忠实地、按计费规则地，执行了一次灾难性的物理执行计划。

值得强调的是，这不是哪家引擎的锅。Databricks 和 BigQuery 都是优秀的引擎，问题在于：当数据的物理布局已经烂掉（小文件、错分区、错格式），再聪明的优化器也只能在烂地基上盖楼。‘BigQuery 和 Databricks 都是 SQL 引擎所以性能差不多’，以及反过来说‘换个引擎就能救’，是同一种懒惰的两面。

🔧 抽象层幻觉，正在被逐一清算

一句话：抽象解决的是人机接口问题，从不解决物理问题。

把事故拆开看，你会发现三个行业性的认知债。

第一，抽象层不等于优化层。BigLake、Serverless 这类抽象的职责是‘让你不用关心数据在哪、格式是什么’，但引擎的执行计划仍然要面对物理现实：一千个小文件意味着上千次 I/O，非分区列意味着全表扫描。抽象只是把复杂性藏起来了，没有消灭它——被藏起来的复杂性，最终以账单和超时的形式回来。

第二，开放格式不是免维护协议。Delta、Parquet 这类开放表格式是过去几年最重要的产业共识，它们解开了厂商锁定。但开放格式只承诺‘你能读’，不承诺‘你读得快’。表的健康度——文件大小分布、分区策略、统计信息——依然需要人（或服务）持续照料。

行业叙事的重心迁移并非一蹴而就，四个阶段各自由不同的“谁在创造价值”主导，这条时间线补上了各阶段的代表性载体：

第三，成本模型变了。Serverless + 按扫描量计费的模式，把‘数据组织质量’直接换算成了美元。同样的查询，物理布局好与坏，成本可以差一个数量级。这不是预算问题，是架构问题：在按量计费时代，表设计就是成本设计。

所以当有人再拿厂商营销页上的对比图来做选型决策时，正确的反问是：对比用的数据布局是什么？分区策略一样吗？文件大小分布一样吗？离开这些前提，任何 benchmark 都只是幻灯片。‘别再基于营销幻灯片做选择了’，值得贴在每个数据团队的群里。

🌊 Fivetran 的算盘，表服务正在变成生意

一句话：谁替你管好湖里的表，谁就拿到了新入口。

第三个信号来自 Fivetran。这家以 ELT 连接器起家的公司，推出了 Managed Data Lake Service——把数据湖的表维护做成托管服务：持续同步、自动优化、让湖里的数据始终处于‘可查询的优化状态’。

这件事单看不大，放进前两个故事里看就很大了。还记得那张被存成一千个小 JSON 文件的维度表吗？还记得把 spill 指标打爆的非分区窗口函数吗？这些事故的共性是：湖是开放的，但湖的卫生是没人管的。过去这活儿要么靠工程师的手写作业（compaction 作业、分区重整、Z-Order 优化），要么压根没人干。

Fivetran 的算盘，是把这个脏活产品化：数据从源系统流进来，表维护自动化完成，下游引擎拿到的永远是收拾干净的表。这与 Vast 的思路异曲同工——都在做同一件事：把数据物理层的复杂性从用户侧转移到服务侧。

把三家厂商放进同一张管道图，可以看清一件正文没展开的事：它们的托管范围各占一段，但闭合路径是同一个——Agent 负载在消费数据湖的同时，还会把记忆写回存储层。这个写回回路，正是存储侧厂商拿到关键位置的原因：

竞争格局也随之清晰了。数据基础设施的争夺，正在从‘引擎性能对比’转移到‘数据层托管’：引擎侧（Databricks、BigQuery）比拼谁的家更封闭划算，存储侧（Vast Data）比拼谁能接住 Agent 记忆，数据工程侧（Fivetran）比拼谁能把表服务自动化做到极致。三条线最终会撞在一起——因为买方真正想采购的，是‘一个不用我操心的数据底座’。

📈 写在最后：回到工程的地基

一句话：Agent 时代的数据平台，赢在物理层，不在幻灯片上。

把三件事串起来：Vast Data 说 Agent 的记忆应该长在分层存储里；一场迁移事故证明引擎救不了烂掉的物理布局；Fivetran 干脆把表维护做成了托管生意。三者共同的底层逻辑是——当 AI 负载成为主负载，数据的容量、布局与维护质量，第一次直接决定了上层应用的可行性与成本。

给数据团队的三个可执行建议：其一，给 Agent 记忆做架构设计时，从分层存储出发，而不是从‘给大模型塞更多上下文’出发；其二，每次选型前先审计自己的物理布局——小文件、错分区，比选错引擎致命得多；其三，把表维护当成持续性工程投入，要么自建规范，要么评估托管服务。

引擎的战争还会继续打，营销幻灯片还会继续飞。但凌晨三点那台风扇狂转的笔记本提醒我们：数据平台的胜负手，从来都在看不见的存储层和表文件里。下一个十年，把地基打牢的人，才配得上上面的摩天大楼。

📚 参考信源

厂商公开表述与产品公告

1. Vast Data：CTO 关于 “AI Agent 记忆 belongs to storage” 的公开访谈及公司博客中对分层存储承接 Agent 记忆的论述（2025 年，Vast Data 官网 / 公开媒体访谈）。

2. Fivetran：Managed Data Lake Service 产品发布公告及官方文档（Fivetran Newsroom / docs.fivetran.com）。

3. Vast Data、Fivetran 相关行业动向报道（The Register、SiliconANGLE、TechCrunch 等公开报道）。

产品与技术文档（事故复现依据）

4. Google Cloud 文档：BigQuery RESOURCE_EXHAUSTED 错误码说明；BigQuery 按扫描量计费（on-demand pricing）文档；BigLake 简介。

5. Databricks 文档：SQL Warehouse（含 Serverless）计费与 Auto-stop 说明；查询执行中的 spill-to-disk 指标（io.file.write.bytes 等）说明。

6. Delta Lake 官方文档：表维护操作（OPTIMIZE / compaction、分区、VACUUM）。

7. Apache Iceberg / Hudi 官方文档：开放表格式的维护责任边界。

叙事口径说明

8. 文中迁移事故为案例化叙事：企业与人物已匿名，时间、金额为当事工程师回忆口径，未经独立核实。

9. 关于厂商方案“讨论热度”的主观判断已从正文移除，因其缺乏可引用的量化信源；如后续获得第三方调研数据（如 Gartner、a16z 行业报告），可补充为实证支撑。

本文基于公开报道与工程实践推演，案例细节经过改写，观点仅供产业参考。