深度｜顶级项目管理独角兽Airtable，百万用户语义检索方案硬核拆解

如果你有任何关于项目管理或团队协作的需求，那么对Airtable 你一定不会陌生。

亚马逊、贝克休斯、Netflix和耐克在内，全球超过八成的财富 100 强企业使用这家公司的产品。

在AI时代，这家估值已经达到110亿美元的 SaaS独角兽，不仅是ChatGPT 应用目录的首发合作伙伴之一，长期被挂在ChatGPT的首页推荐位，也是全球关于AI落地，探索最积极，最深度的团队。

以下是 Airtable 团队发表在其Medium 官方频道技术深度分析文章，讲述了他们如何基于 Milvus 搭建分布式向量检索系统，以及如何采用基于Partition的物理隔离方案，双链路同步与检索实现数据实时一致，最终支撑起 Omni AI 问答与关联记录智能推荐两大核心场景，支持40 万Partition高写入吞吐、水平弹性扩展的目标，以及数据冷热分离75% 的在线成本降低，为大规模语义检索提供了稳定、高效、安全的底层能力

全文经授权转载如下。

Airtable 内部语义搜索功能从初步概念落地成核心产品功能后，如何让这套向量检索系统同时承载海量数据与高并发访问，成了摆在 我们数据infra团队面前的一大难题。

在此之前，我们团队已经为向量全生命周期搭建了稳定的业务层，并依靠最终一致性机制保障两端数据同步。但当时整套架构还缺失一块核心组件：向量数据库。

我们需要一套产品，它既能完成数十亿条向量的索引与检索，又能适配大规模多租户场景，还能在分布式云环境中长期稳定地满足性能与可用性标准。

本文将完整拆解 Airtable 向量检索平台的设计、优化与迭代全过程，讲述它如何一步步成长为公司底层基础设施的核心模块。

业务背景

Airtable 的核心定位，是为企业提供直观灵活的数据处理工具。

随着大模型的能力与识别精度持续提升，文本语义理解、语义检索，已经逐步成为 Airtable 产品不可或缺的核心能力。

在我们产品内部，语义搜索有两大落地场景：

场景一，Omni：基于海量数据表的自然语言问答工具

Omni 是 Airtable 内置的 AI 对话产品。 举个实际场景的例子：一张数据表存储五十万条业务数据，用户可直接用自然语言提问，系统会结合关联上下文给出精准答复，例如：

“近期客户针对电池续航的反馈有哪些？”

这时候，数据体量较小，可以直接将全表内容传入大模型处理。但数据规模上涨后，这样简单粗暴的方式，显然就会超过模型的上下文限度与企业的预算额度。

为此团队设计了一套标准化检索流程，分为三步执行：

1. 解析用户查询背后的真实语义诉求；
2. 通过向量相似度检索，筛选出关联度最高的数据行；
3. 将筛选后的内容作为上下文，传入大模型生成回答。

这套业务逻辑直接决定了后续所有架构设计方向与服务能力上限。它保证了即便用户查询超大型数据表，Omni 也可以维持稳定低延迟，输出贴合语义的匹配结果。

场景二，关联记录智能推荐：依托语义匹配，跳出关键词精准匹配局限

语义搜索同时用于优化 Airtable 核心功能 —— 关联记录匹配。

多数业务场景下，用户需要的不是文本完全一致，而是基于内容语义推荐存在业务关联的数据。

举个例子：一段项目描述通篇没有出现 “基础架构团队” 字样，但内容高度匹配该团队业务。传统关键词检索根本无法识别这类隐性关联，语义检索却能依托文本内涵完成匹配。

在这一背景下，想要实时输出这类推荐结果，系统不仅要保证检索准确度，还需维持平稳可控的查询延迟，保障结果输出稳定可预期。

四大核心设计目标

为支撑上述两类产品功能以及未来的产品规划，团队明确了系统四项硬性设计指标：

• 低延迟查询，P99 控制在 500 毫秒以内。 平稳可控的响应速度，是用户信任产品的关键基础。
• 高吞吐写入： 数据表数据会持续发生新增、修改、删除操作，对应的向量数据需要同步更新。
• 水平扩展能力： 平台需要承载数百万套相互隔离的用户数据表，无法依靠单台机器扩容支撑业务增长。
• 自托管： 所有客户数据都必须保留在由 Airtable 控制的基础设施中。

以上四项硬性标准，是后续全部技术选型与架构方案的基础。

向量数据库选型

2024 年末，我们评估了多种向量数据库方案，最终基于三个核心需求选择了 Milvus。

首先，我们优先考虑自托管方案，既保障客户数据隐私安全，也方便团队精细化管控底层资源；

其次，Airtable 业务写入流量占比高，查询流量波动极强，数据库需要支持负载弹性扩缩容，同时维持平稳低查询延迟；

最后，平台需要在数百万独立租户之间实现严格的数据隔离，避免租户间互相干扰。

Milvus 完美适配上述需求，它采用分布式架构，能够支持大规模多租户之外，写入、建索引、查询三类资源可独立扩容，在保障性能的同时，精准控制基础设施投入成本。

架构设计

敲定 Milvus 后，如何基于它适配 Airtable 独特的多数据表业务结构，成为架构设计的核心难点。

平台内存在数百万归属不同客户的数据表，每张数据表都需要独立存储、独立检索，基于Partition的分区方案，是整套架构的关键决策点。

以下是我们测评过的两套分区方案对比

方案一：多数据表共用同一个Partition

将多张用户数据表的数据存入同一个 Milvus Partition，查询时通过 Base ID 过滤目标数据。

该方案的优势是资源利用率更高，但也会增加额外的过滤开销，让 Base 删除操作变得更加复杂。

方案二：一个数据表对应一个Partition

每个 Airtable Base 都映射到 Milvus 中的一个独立物理Partition。

这种方式能够让不同客户数据表数据物理隔离，租户边界清晰，不仅删除操作变得简单，查询阶段也无需额外过滤数据表 ID，减少耗时损耗。

出于架构简单性和强隔离性的考虑，我们最终选择了第二种方案。

但早期测试中，我们发现单个 Milvus 集合内Partition数量达到十万级时，系统性能会大幅衰减：Partition创建延迟从约 20 毫秒增加到约 250 毫秒；Partition加载时间也会超过 30 秒。

为了解决这一问题，我们限制了每个 Collection 中的Partition数量。在每个 Milvus 集群中，我们创建 400 个 Collection，每个 Collection 最多包含 1,000 个Partition。这样，每个集群最多能够承载 40 万个 Base。随着更多客户接入，我们会继续部署新的集群实现扩容。

索引与召回率

索引类型是影响系统综合表现最关键的技术选择。partition加载完成后，对应索引会缓存至内存或磁盘，如何在检索精度、索引存储开销、查询性能三者间取得平衡，我们团队对主流索引类型完成全量基准测试，结论如下：

• IVF-SQ8： 内存占用较小，但召回率相对较低。
• HNSW： 能够实现最高的召回率，约为 99% 至 100%，但需要消耗大量内存。
• DiskANN： 召回率与 HNSW 接近，但查询延迟更高。

最终，我们选择了 HNSW，用一定的内存成本，让产品的检索精度、查询速度提升，是产品体验提升的关键。

上层业务完整架构

从宏观角度来看，Airtable 的语义搜索流程主要包含两个核心数据pipeline：

• 数据写入pipeline： 将 Airtable 数据行转换为向量，并存储到 Milvus 中。
• 查询pipeline： 对用户查询生成向量，在 Milvus 中检索匹配数据，筛选结果作为上下文传入大模型生成回答。

接下来，我们分点讲述两个 pipeline。

写入链路：如何保障 Milvus 与业务数据表实时同步

用户启用 Omni 功能时，系统会启动对应数据表的全量同步流程：

先为该数据表创建独立partition，分批拉取全表数据，逐行生成向量，批量写入 （upsert）Milvus。

完成初次全量同步后，系统持续监听数据表的数据变更。只要任意一行内容发生改动，就重新生成对应向量并完成写入，以此保证 Milvus 向量数据与业务数据表实时一致。

查询链路：向量仅负责匹配，最终数据以业务库为准

收到用户查询请求后，完整处理流程如下：

将用户提问转换为对应查询向量→向量下发至 Milvus，依靠相似度匹配返回关联数据行编号→系统回拉 Airtable 业务库，读取对应行的最新完整内容→将实时业务数据搭配用户问题，一并传入大模型生成回复。

Milvus 仅承担快速筛选关联记录的职责，不会直接使用库内缓存的历史文本，传递给大模型的内容永远是数据表最新数据。

线上运维痛点与落地解决方案

完成架构设计只是第一步，如何让整套系统稳定承载数十万数据表长期运行，还需要解决大量生产环境独有的运维难题。

以下是我们在实践过程中总结出的几项关键运维经验。

1. 集群部署方案

依托 Milvus Operator 提供的 Kubernetes CRD完成集群部署，全部配置采用声明式管理。

无论配置调整、客户端升级还是 Milvus 版本迭代，所有变更都需要先完成单元测试，再执行模拟真实流量的压力测试。只有压测验证无异常后，变更才会灰度发布至线上环境。

在 Milvus 2.5 中，Milvus 集群主要由以下核心组件组成：

• Query Node： 将向量索引保存在内存中，并执行向量搜索。
• Data Node： 负责数据写入和 Compaction，并将新数据持久化到存储系统。
• Index Node： 构建并维护向量索引，确保随着数据规模增长，搜索仍然保持高效。
• Coordinator Node： 协调整个集群的活动及partition分配。
• Proxy Node： 路由 API 流量，并在节点之间进行负载均衡。
• Kafka： 为内部消息传递和数据流提供日志及流式处理基础设施。
• Etcd： 存储集群元数据和协调状态。

依靠 CRD 自动化管控与完备的测试流程，团队既能快速迭代功能，又能大幅降低版本升级带来的故障风险。

2. 全链路可观测体系：覆盖底层基础设施与业务链路

为长期保障检索速度稳定，团队搭建了双层监控体系，全方位感知系统运行状态：

在基础设施层面，我们会持续采集 Milvus 各组件 CPU、内存使用率、容器健康度等指标。依托指标提前识别资源打满、节点异常等隐患，避免故障传导至用户查询请求。

在服务层面，我们重点关注单张数据表的读写处理状态，比如：Compaction 吞吐量和索引构建吞吐量等指标，可以帮助我们了解数据写入系统的运行效率。查询成功率和查询延迟能够反映真实的用户体验。Partition数量和容量增长则帮助我们理解数据规模的变化，并在需要扩容时及时触发告警。

3. 节点轮换更新机制

出于安全和合规要求，我们会定期轮换 Kubernetes 节点。但在向量搜索集群中，这并不是一项简单的操作。

因为向量检索集群无法简单关停旧节点、启动新节点：当 Query Node 被轮换时，Coordinator 会在不同 Query Node 之间重新平衡内存中的数据。同时 Kafka、Etcd 承载核心有状态数据，轮换过程中必须持续维持集群过半节点可用，保障服务不中断。

对此，团队配置了严格的容器中断预算，规定单次仅轮换一台节点；等待Milvus Coordinator 完成数据重新平衡，再执行下一台节点的轮换操作。

这套方案兼顾集群高可用，不会拖慢基础设施迭代更新进度。

4. 冷分区卸载

我们在运维方面取得的一项重要成果，是认识到系统中的数据具有非常明显的冷热访问模式：任意一周周期内，Milvus 仅有约 25% 的数据会产生读写访问。

Milvus 支持完整Partition卸载，从而释放 Query Node 上的内存。如果后续再次需要这些数据，系统可以在数秒内重新加载对应Partition。

基于该特性，团队可以将高频访问的热数据常驻内存，长期闲置的冷数据执行卸载操作，既削减内存硬件成本，又提升集群整体资源利用率。

5. 故障数据恢复方案

大规模落地 Milvus 前，团队还提前搭建了完整的容灾流程，应对各类极端故障场景。

常规节点故障可依靠集群自带容错机制自动修复；针对数据损坏、集群整体宕机等极端场景，标准化恢复流程如下：

1. 快速搭建一套全新 Milvus 集群，优先恢复用户检索服务；
2. 新集群上线后，优先重建高频访问数据表的向量数据，快速恢复绝大多数用户功能；
3. 后台逐步补全全量语义索引，低频数据在用户访问时按需、延迟处理，最大限度降低故障影响范围。

这种方式可以最大限度缩短高频数据的不可用时间，同时让系统逐步重建完整且一致的语义索引。