Inside the feature store powering real-time AI in Dropbox Dash

// By Jason Shang and Artem Nabirkin • Dec 18, 2025

Our goals and requirements

Designing our hybrid feature store

Making search fast

Keeping features fresh

What we learned

Dropbox Dash 利用 AI 来理解关于你的文件、工作聊天和公司内容的问题，将所有内容汇集在一处，以便进行更深入、更专注的工作。考虑到数以万计的潜在工作文档，无论是搜索还是智能代理，都依赖一个由实时机器学习驱动的排序系统来快速找到正确的文件。Dash 排序系统的核心是我们的特征存储，这是一个管理和传递我们的模型用于预测相关性的数据信号（“特征”）的系统。

为了帮助用户准确找到所需内容，Dash 必须解读用户在不同文件类型、公司内容以及杂乱、碎片化的协作现实中的行为背后的含义。然后，它需要在需要的时候并以需要的方式呈现最相关的文档、图像和对话。特征存储是我们跨您的工作领域对正确上下文进行排序和检索的关键部分。它的构建旨在快速提供特征、跟上用户行为的变化步伐，并让工程师能够快速从想法走向生产。（关于特征存储如何与 Dash 中的上下文工程相关联的更多信息，请查看我们关于上下文工程的深度解析。）

在本文中，我们将介绍我们如何构建支持 Dash 排序系统的特征存储，为什么现成的解决方案不适用，我们如何为速度和规模进行设计，以及随着用户行为的变化，保持特征新鲜度需要付出什么。在此过程中，我们将分享我们做出的权衡以及塑造我们方法的心得教训。

Dropbox Dash：理解您工作的 AI 队友

Dash 了解您的上下文、您的团队和您的工作，因此您的团队可以保持井然有序，轻松查找和分享知识，并确保项目安全，所有这些都在一个地方完成。很快，Dash 将登陆 Dropbox。

了解更多 →

我们的目标和要求

为 Dash 构建一个特征存储不仅仅是选择一个现成的解决方案，这背后有几个原因。首先，我们的基础设施分布在两个截然不同的环境中：一个是为低延迟服务间通信设计的本地部署生态系统，另一个是以 Spark 为核心的云环境，特征工程和大规模数据处理在此进行。这种划分排除了标准的云原生特征存储，迫使我们找到一种在不降低开发速度的前提下桥接这两个系统的方法。

除此之外，Dash 的搜索排序系统带来了其自身的扩展挑战。一个用户查询不只是拉出一个文档。相反，它会触发我们的排序器评估许多文件，每个文件都需要几十个行为和上下文特征。一次搜索很快就会扩展成数千次特征查找，涉及交互历史、元数据、协作模式和实时信号。最终，我们的特征存储必须处理这种大规模并行读取，同时仍要满足严格的亚 100 毫秒延迟预算。

相关性也取决于速度和实时捕捉用户意图。如果用户打开文档或加入 Slack 频道，该信号应该在他们下一次搜索时（几秒内）就反映出来，这意味着需要构建一个能够跟上大规模用户行为的摄取流水线。

最后，我们必须协调两种非常不同的计算模式。有些特征天然适合实时流式处理，而另一些则依赖于历史数据的批处理。我们需要一个统一的框架来高效地支持两者，从而减少工程师的认知负担，并为他们提供从想法到生产就绪特征的更快路径。

设计我们的混合特征存储

在考察了特征存储领域的方案（Feast、Hopsworks、Featureform、Feathr、Databricks 和 Tecton）之后，Feast 因两个原因脱颖而出。首先，它在特征定义和基础设施关注点之间有清晰的分离，这意味着我们的机器学习工程师可以专注于编写 PySpark 转换，而无需关心服务、存储或编排的复杂性。其次，Feast 的模块化架构和丰富的适配器生态系统使其易于与我们现有的基础设施集成。（适配器指的是 Feast 提供的接口，用于将其框架与不同的后端系统集成。）其 AWS DynamoDB 适配器尤为关键，它使我们能够利用 Dynovault——我们内部兼容 DynamoDB 的存储解决方案——在满足延迟要求的同时降低成本。

我们基于 Feast 的架构结合了三个关键组件，每个组件都针对其角色进行了优化。 Feast 为我们提供了编排层和服务 API，但我们将其 Python 在线服务路径替换为我们自己的 Go 服务，以便真正达到我们所需的并发性和延迟指标。 基于云的存储负责离线索引和存储的重任，而 Spark 作业则处理特征摄取和计算。 Dynovault 处理每次搜索查询所需的即时特征查找。Dynovault 与推理工作负载位于同一位置，并利用 Dropbox 的混合云基础设施，避免了公共互联网调用的延迟，在平衡成本和地理可扩展性的同时，可靠地提供约 20 毫秒的客户端延迟。

围绕这个核心架构，我们通过作业故障监控、新鲜度跟踪和数据沿袭可见性增加了可观测性。结果是带来了简化的体验：工程师选择数据源，编写 PySpark 转换，并在需要的地方请求特征，而基础设施则抽象掉了离线和在线数据管理、流水线编排、低延迟服务以及数据新鲜度保证。

让搜索变得快速

架构就位后，下一个挑战是满足 Dash 的亚 100 毫秒延迟要求。特征检索直接位于搜索和 LLM 答案生成的关键路径上，因此即使是微小的延迟在规模下也会迅速累积，并降低 Dash 快捷的搜索检索体验。

我们最初的特征服务实现是使用 Feast SDK 在 Python 中构建的。虽然并行化在中等规模下有所帮助，但性能剖析显示，在更高的并发下，CPU 密集型的 JSON 解析和 Python 的全局解释器锁成为了主要瓶颈。转向多进程暂时改善了延迟，但引入了限制可扩展性的协调开销。

为了消除这些限制，我们用 Go 重写了特征服务层。使用轻量级 goroutine、共享内存和更快的 JSON 解析，Go 服务实现了真正的并发，而没有我们在 Python 中遇到的协调成本。如今，它在 Dynovault 的客户端延迟之上仅增加约 5–10 毫秒的处理开销，就能处理每秒数千个请求，持续实现大约 25–35 毫秒范围内的 p95 延迟。

这一转变使我们能够可靠地满足 Dash 的延迟目标，并确保特征服务不会随着搜索流量和特征复杂性的持续增长而成为限制因素。

保持特征新鲜度

只有当数据本身是新鲜的时，速度才有意义。过时的特征会降低排序质量并损害用户体验，因此我们的特征存储必须尽快反映新的信号，通常在用户操作的几分钟内。

挑战在于规模。Dash 中许多最重要的特征依赖于大型连接、聚合和历史上下文，这使得完全实时的计算不切实际。我们需要一种平衡新鲜度与可靠性的摄取策略，同时不会压垮我们的基础设施或拖慢开发速度。为此，我们构建了一个三部分的摄取系统。

批量摄取处理基于勋章架构（一种将数据从原始阶段组织到精炼阶段的分层数据模型）构建的复杂、高容量的转换。我们没有在每次运行时重写每个特征，而是增加了智能变化检测，只有被修改的记录才会写入在线存储。这将写入量从每次运行数亿条记录减少到不足一百万条，并将更新时间从超过一小时缩短到不到五分钟。

流式摄取捕捉快速变化的信号，例如协作活动或内容交互。通过近实时地处理无界数据集，它确保特征与用户当前的行为保持一致。

直接写入通过完全绕过批处理流水线来处理轻量级或预计算的特征。例如，由单独的 LLM 评估流水线产生的相关性分数可以在几秒钟内直接写入在线存储，而无需等待下一个批处理周期。

这些方法共同使 Dash 能够保持特征值的新鲜度，而无需将所有计算强加到单一的摄取路径上，在保持排序质量的同时扩展到实际使用规模。

我们的心得

在 Dropbox 的规模上构建特征存储，让我们在系统设计方面获得了一些来之不易的经验。在服务方面，Python 的并发模型对于高吞吐量、混合 CPU 和 I/O 的工作负载来说成为了一个限制因素。即使小心地进行并行化，全局解释器锁也限制了像 JSON 解析这样的 CPU 密集型工作的性能，而转向多进程则引入了新的协调瓶颈。用 Go 重写服务层使我们能够消除这些权衡，并更可预测地扩展并发性。

在数据方面，基础设施的更改很重要，但理解访问模式同样重要。通过认识到在典型的 15 分钟窗口内只有 1–5% 的特征值会发生变化，我们能够显著减少写入量和摄取时间。这一转变将长达数小时的批处理周期变成了五分钟的更新，在不增加系统负载的情况下提高了新鲜度。

这些优化共同构成了一种平衡灵活性和性能的混合架构：Feast 用于编排和一致性，Spark 用于大规模计算，Dynovault 用于低延迟在线服务。这种方法不是依赖于单一的供应商解决方案，而是让我们能够调整每一层以发挥其优势，同时保持训练和服务的一致性。

最终，这项工作强调了在从头开始构建一切和全盘采用现成系统之间走一条中间道路的价值。通过将开源基础与内部基础设施相结合，并根据实际约束进行定制，我们能够构建一个满足 Dash 当前需求的、并最终能够随着它未来发展的特征存储。

致谢：特别感谢 AI/ML 平台和数据平台团队所有现任和过去的成员所做的贡献，以及我们可爱的机器学习工程师们，他们利用我们构建的工具创造出神奇的效果。 ~ ~ ~ 如果构建创新产品、体验和基础设施让您兴奋，请加入我们一起构建未来！访问 jobs.dropbox.com 查看我们的空缺职位。

        // 标签

                    机器学习
                LLM

AI Dash