Notion数据基建评测：Agent标杆，完成度仅50%

Notion 近日发布了一篇工程博客，详细回顾了过去两年在向量搜索基础设施领域的实验与决策。

读后深感共鸣。他们遭遇的每个瓶颈、执行的每次迁移、设计的每个过渡方案，几乎都能在大数据演进历程中找到前例。与此同时，该团队的工程实力令人印象深刻——短短两年内，他们投入大量资源攻克那些通常属于平台级基础设施的问题。

回顾传统大数据领域，行业大约耗费十五载才逐步收敛至如今相对稳定的架构。Notion 用两年时间走完了其中绝大部分路程，这本身就是能力的佐证。但反过来看，这也恰恰凸显了当行业选型尚未定型时，早期决策所埋下的隐性成本。

因此，如果非要预测他们下一篇工程博客的标题，大概率会是：“我们如何用六个月完成一次 embedding 模型升级”，或“我们如何在零停机条件下将一亿个 workspace 迁移至全新向量空间”，又或是“我们如何构建离线 context engineering，赋予 Notion AI 持久记忆”。未来只会更加复杂，而这些踩过的坑，也势必会被更多 AI agent 产品重新经历一遍。

01

Notion 做了什么

故事要从 2023 年 11 月说起。Notion 推出 AI Q&A 功能，底层架构上，向量数据库运行在 pod 集群中，存储与计算绑定，并按 workspace ID 分片。

功能上线后效果立竿见影。短短一个月内，数百万个 workspace 迅速填满等待列表，向量数据库容量直接告急。

如何应对？摆在前面的只有两条路：要么冒险在实时流量下重新分片，要么设计一个临时方案先撑住。

Notion 选择了后者。他们启动了一个带有 generation ID 的新索引集群，新 workspace 进入新集群，老的原地不动。同时配合 Spark 和 Airflow 进行调优，最终在四个月内清空等待列表，每日 onboarding 能力提升了 600 倍。

从应急角度看，这无疑是成功的。但代价也随之而来：generation 路由逻辑这根“技术债”，在接下来两年里一直困扰着团队。

随后是两次重大迁移。2024 年 5 月，Notion 从 pod 架构迁移到 serverless，存储与计算解耦。成本立即下降 50%，generation routing 的复杂度也彻底消失——因为容量不再是需要提前规划的有限资源。2024 年底到 2025 年初，他们又从原有 serverless 供应商迁移到 turbopuffer。由于数据存储在供应商的专有存储系统中，切换需要一次完整的 re-index，他们也借此机会升级了 embedding 模型。

2025 年中，Page State 上线。每个文本片段都会用 xxHash 64-bit 做哈希，并存入 DynamoDB。页面更新时，系统先比较 hash，再决定是否需要重新 embedding。如果只是 metadata 变化，系统会直接 patch 向量数据库，而不是重新计算向量。

不久后，embedding 生成也从 Spark 加外部 API 切换到了基于 Ray 和 Anyscale 的自托管模型。CPU 预处理与 GPU 推理运行在同一条 pipeline 中，消除了系统之间通过 S3 交接数据的过程。

两年。五个重大决策。成本从峰值下降了 90%。这确实是一段令人印象深刻的工程旅程。

02

为什么说这些都是大数据时代的旧问题

读这篇文章时，很容易在脑海中给每个阶段打上一个时间戳：大数据生态在某某年已经解决过类似问题。工程团队之所以踩这些坑，不是因为他们不够聪明，而是因为相同的约束，必然会推导出相似的架构演进路径。

（一）存储计算分离与 serverless：为运行付费，而不是为“存在”付费

Notion 的两次成本迁移——从 pod 集群到 serverless，再到基于对象存储的 serverless——其实都可以归结为同一个架构动作：停止为基础设施的“存在”付费，改为为“实际完成的工作”付费。旧模式下，无论一个 workspace 是频繁查询还是长期闲置，集群都得持续运行并持续计费。存储计算分离后，索引可以放在对象存储里，冷数据几乎不占计算资源，热数据按需加载，成本和实际使用量之间的关系变得更为紧密。

这和大数据从 HDFS 走向 S3 的过程如出一辙。早期 Hadoop 把存储和计算放在一起，是为了数据本地性，但这种架构的弹性扩展能力很差。当数据迁移到 S3 之后，Spark 集群可以按任务启动，任务结束后关闭，存储仍然保持持久化。计算变成临时资源，存储变成长期资源，两者的生命周期不再绑定。

当然，存储计算分离也不是没有代价。对象存储会带来冷启动延迟，一个冷索引在可查询之前，可能需要多次 GET 请求、反序列化和索引重建。这更像是一个物理规律问题，而不是参数调优能解决的。对 Notion 当前的 workload 来说，这个取舍是合理的——大多数 workspace 查询频率不高，用对象存储换成本下降是划算的。但未来 AI 使用变得更加深入后，两个问题会越来越突出：大客户的持续高查询量，以及用户重新访问冷 workspace 时的尾延迟。到那时，单层 S3-native caching 往往不够用，本地 SSD 和多级缓存会变得更为重要。

（二）Lambda 架构：实时是需求，碎片化是代价

Notion 的 indexing 系统有两条路径：一条是离线 Spark pipeline，用来做大规模 backfill；另一条是 Kafka consumer，用来处理实时更新。这是典型的 Lambda 架构。如果系统需要同时支持大规模离线处理和实时数据新鲜度，这种设计无可厚非。但问题是，时间一长，同一套逻辑会分散到多个系统里，团队将越来越多地处理同步、状态交接和一致性问题。

在 Notion 的案例中，这个拆分已经横跨 Spark、Kafka consumer、DynamoDB、Ray 和独立的 serving layer。每个组件本身都很合理，但当它们组合在一起后，系统边界增多，胶水代码增多，状态在系统之间流转的次数也在增加。Page State 的 xxHash 加 DynamoDB，本质上就是为了解决批处理和实时视图之间的一致性问题。这个设计很实用，但也说明了一点：当底层系统没有统一的数据视图时，一致性就只能靠应用层逻辑来弥补。

更麻烦的是，离线侧的改进无法直接改善在线 retrieval。比如离线 pipeline 发现了某个 workspace 中不同文档之间的强语义关系，这个结果不能自动进入在线查询路径。它必须先被写到在线系统能读到的地方，中间就会产生同步延迟和一致性风险。这也解释了为什么很多系统最终会走向 One Engine 或 OneData 的方向。理想状态下，batch 和 streaming 不应该完全是两套分裂的系统，而应该是同一个数据基础上的不同计算模式。在线 serving 和离线 processing 也不应该维护多份视图，而应该共享同一张底层表。这正是 Lakebase 这类架构想要解决的问题。

（三）缺失的向量系统声明式操作层

Notion 从 Spark 加外部 embedding API 迁移到 Ray pipeline，是一次很合理的简化。原来分散在不同系统中的 CPU 预处理、S3 交接、外部 API 调用和后续处理，现在被整合到同一条计算 pipeline 中，明显降低了成本，减少了系统间的 I/O。

但这仅仅是在执行层面上的简化。向量和非结构化数据真正缺失的，是更高一层的声明式接口。回想大数据早期，写 MapReduce job 有多痛苦？开发者不仅要关心业务逻辑，还要理解 Mapper、Reducer、shuffle、失败重试和多阶段任务编排。Hive 出现后，用户只需要用 SQL 表达想要的结果，系统负责生成执行计划。这个变化降低的不仅仅是运行成本，更是工程门槛。

但今天的向量数据还没有类似的成熟抽象。如果你想在模型训练前，对十亿级向量语料做去重，通常还得自己写 Spark job，选择距离计算方式，管理输出格式，再将结果同步回 serving layer。如果你想把几亿份文档从旧 embedding 模型升级到新模型，需要搭建 backfill pipeline，处理新旧 embedding 共存，设计 cutover 流程，最后再清理旧数据。这往往是一个耗时数月的工程项目，而不是一个常规的数据操作。如果你想跨 session 维护压缩后的用户记忆，也要自己设计压缩逻辑、版本化写入和 retrieval path 接入方式。

这些工作，本质上都是系统工程项目，而不是数据操作。更理想的方式应该是：用户表达意图，系统负责执行。比如对某个 collection 按 cosine tolerance 去重并写回，用新模型 backfill embeddings，把 90 天以前的交互历史压缩成长期记忆表示。开发者不应该每次都重新搭一套分布式 pipeline，系统应该负责执行计划、资源管理和一致性。这层抽象如果不存在，Context Engineering 就很难规模化。每做一个新能力，都要重新写工程胶水，系统复杂度会持续上升。

当然，说这些并不是在质疑 Notion 的眼光与能力。大数据花了 15 年才收敛到一种存储、计算和处理语义被清晰分离并可组合的架构，Notion 在两年内走完了这条路径中的绝大部分，已经非常了不起。但他们还没有落地的那一块，恰恰才是能让接下来两年的建设成本大幅降低的关键部分。

03

Notion 还留有哪些悬而未决的问题

Notion 目前解决的所有问题，基本都是围绕 AI Q&A 这个功能展开的。Generation routing、provider migration、Page State、Ray pipeline，所有这些工作都是为了同一个目标：让 AI Q&A 跑得更稳定、成本更低、更新更及时。这个阶段他们做得很好。但 Notion 不会只做一个 AI Q&A。接下来，问题会从“如何做好向量搜索”变成“如何让 AI 系统长期理解用户、维护记忆、利用反馈，并持续提升”。

接下来，他们一定会遇到三个更难的问题。

问题 1：serverless 加冷热分离会遇到性能上限

Notion 当前架构很适合现在的业务特征：workspace 数量很大，但大多数查询频率不高。S3-native 的成本优势在这种场景下非常明显。但这个架构的性能上限在于：冷查询的延迟主要受对象存储行为影响，而不是受软件参数影响。S3 的 first-byte latency 往往在 10 到 100ms 之间，一个冷索引可能需要多次 GET 请求和反序列化才能被查询。在生产环境里，冷查询 p99 进入数秒级并不罕见。

大租户会最先碰到这个问题。它们的查询量高且持续，单层缓存未必能承受。另一个问题是，当用户重新访问冷 workspace 时，延迟尖峰会直接影响体验。多层缓存——memory + local SSD + object storage——会比单层缓存更能控制尾延迟。计费模型也可能带来误判：如果按 namespace size 计费，而不是按 query workload 计费，大型 workspace 即使单次 query 只扫描很小一部分，整体成本也可能很高。在多租户分布极不均匀的情况下，账单支出可能会完全偏离团队基于 query 直觉的判断。

还有一个潜在问题是 filter recall。ANN 加 post-filter 在过滤条件很窄时，候选池可能会过小，导致 recall 下降。随着 Notion 增加更多带过滤条件的 AI retrieval path——比如按页面类型、协作者、时间范围过滤——这个问题会越来越频繁地出现。所以，当前取舍是合理的，但它不是终点。大租户、冷查询尾延迟、窄过滤下的 recall，迟早会暴露出来。

问题 2：实时和离线的拆分会变得越来越贵

Notion 当前的系统栈可以概括为：Spark 和 Airflow 做离线批处理，Kafka consumer 做实时更新，Ray 做 embedding，Turbopuffer 做查询。四个系统每个都把自己的工作做得很好，但问题在于，它们全都在处理同一份底层数据——用户的页面内容。这就是典型的数据孤岛问题。同一份源数据，在不同系统中被维护成多份视图，由应用层负责同步。Page State 的设计能解决一部分一致性问题，但随着 AI 功能增多，同步逻辑也会随之增加。每新增一个 AI 功能，可能就会多一条离线路径、多一个实时更新逻辑、多一个写回 serving layer 的流程。复杂度会线性上升，甚至在某些情况下变成指数级的运维负担。

更深层的问题是，在线系统和离线系统之间没有自然闭环飞轮。在线使用产生的信号，不能直接进入离线模型训练或离线优化；离线处理得到的结果，也不能直接改善在线 retrieval，除非结果被写到在线 query 逻辑可以读取的地方。两者之间始终存在一个系统边界，并伴随着延迟和一致性风险。这会拖慢整体的 data flywheel。用户行为——比如哪些结果被点击、哪些问题没有满意答案、哪些文档经常被引用——本可以持续改善 retrieval，但如果这些信号只是停留在日志里，或者需要复杂同步才能进入向量层，它们就很难真正变成系统能力。

架构上的答案是 OneData：让在线 serving 和离线 processing 共享同一个底层数据基础。比如一张 Iceberg table，不同 compute mode 都读写同一个地方。离线层产生的结果可以直接写回，在线层产生的信号也可以直接被离线层消费。这样，数据飞轮才有可能稳定运转。

问题 3：离线 context engineering 才是真正的长期壁垒

今天的 Notion AI 是这样的：用户提出问题 → 实时检索相关 chunk → 送入 LLM → 返回答案。这个 pipeline 的质量上限，取决于索引中有什么。但真正决定长期体验的，不只是 query time retrieval，而是 query 发生之前系统已经构建好了什么。

第一个方向是用户记忆。用户和 Notion AI 的每次互动，都会留下信号：用户关心什么，如何组织工作，哪些知识对他们重要。把这些信号向量化不难，难的是长期维护。旧记忆需要压缩，过时记忆需要更新，互相冲突的记忆需要合并或修正，相关记忆还需要分层组织。这些都不是查询时能临时完成的工作，而是需要持续的离线处理。第二个方向是预计算知识图谱。系统不应该每次 query 到来时才从零开始判断哪些文档相关。更好的方式是提前构建 workspace 的语义拓扑：哪些文档讨论相同概念，哪些决策有依赖关系，一个想法如何随时间演变。这样，AI 在回答问题时，不再只是每次都从零开始做一次新搜索，而是基于对 workspace 的理解进行推理。第三个方向是数据飞轮。哪些 retrieval results 最终被用户采用，哪些问题反复出现但没有好答案，哪些文档在不同 query 中频繁被引用，这些信号都可以反过来优化 chunking、排序和索引策略。但前提是基础设施能把这些信号写回向量层，并持续影响在线服务。

Notion 拥有现存最有价值的 AI 数据集之一：它不是互联网上随便抓来的文本，而是用户主动组织过的结构化知识，分布在大量 workspace 中。这类数据非常适合做 AI context。但数据本身不是护城河。真正的护城河在于，系统能不能持续把数据转化成能力。Notion 当前的向量基础设施主要面向在线 serving，而 memory maintenance、knowledge graph precomputation、signal processing flywheel 这些工作，本质上都是大规模离线处理问题。它们需要一个更自然的系统归宿。

04 Lakebase 的定位

看到这里，问题就很清晰了。Notion 下一阶段的瓶颈，不是换一个查询引擎就能解决的，而是实时 serving 和离线 processing 之间的断层。Vector Lakebase 的定位，正是要把这两部分接起来。它强调的是一个统一的 OLTP 和 OLAP 平台：实时 serving、迭代式发现、批量分析运行在同一个 lake-native data foundation 和同一个 source of truth 上。它也能把 change capture、re-embedding、re-indexing 这些能力下沉到数据层，而不是让应用层继续维护大量 glue code。最后，让离线处理产生的结果可以直接进入在线系统。比如 memory compression、backfill、quality signals，都可以写回同一张表，并直接改善 serving。

这也是所有 AI agent 产品必须经历的 AI data infra 设施的第二阶段。在更快的搜索基础上，建立一个统一的向量数据运行模型：存储、处理、服务和反馈在同一个基础上闭环。而 Vector Lakebase 正是 Zilliz Cloud 在应对行业新需求时给出的最新版本答案：在现有数据湖之上，统一向量存储、处理和服务，让数据迁移彻底成为过去式。

作者介绍

栾小凡

Zilliz CTO

LF AI & Data 基金会技术咨询委员会成员

来源：互联网