浅议Notion 的data infra进化：堪称agent行业的标杆，但完成度只有50%

Notion 最近发了一篇工程文章，复盘过去两年他们怎么做向量搜索基础设施。

我读完之后，有一种强烈的似曾相识感。因为他们描述的几乎每一个问题、每一次迁移、每一个临时方案，都能在大数据的发展史中找到近似对应。

同时，也由衷的钦佩这个团队：因为他们的产品工程团队，用两年时间，花了大量精力去解决一些平台级infra侧问题。

而过去，大数据大约花了十五年，才逐渐收敛到它如今的长期架构。

这是 Notion 的胜利，也是行业尚未成熟、选型一开始就出了问题的标志。

所以如果让我猜他们下一篇工程文章的标题，可能会是《我们如何花六个月完成一次 embedding 模型升级》。或者《我们如何在不停机的情况下，把一亿个 workspace 迁移到新的向量空间》。或者《我们如何构建离线 context engineering，让 Notion AI 拥有持久记忆》。

未来的挑战只会越来越大，而Notion所经历的这些挫折与经验，未来也会有更多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 provider 迁移到 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%。这确实是一段非常 impressive 的工程旅程。

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 这类架构想解决的问题：让实时更新、在线查询和离线处理运行在同一个 lake-native 数据基础之上，弥合 OLTP 和 OLAP 之间的断层，让实时更新、在线 serving 和离线处理运行在同一张表上。

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

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 在两年内走完了这条路径中的大部分，已经非常 impressive。

但他们还没有落地的那一块，其实才是能让接下来两年的建设成本大幅降低的部分。

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 Al & Data 基金会技术咨询委员会成员

文章来自于"Zilliz"，作者 "栾小凡"。