深入了解在 Dropbox Dash 中驱动实时 AI 的 feature store
Source: Dropbox Tech Blog
Dropbox Dash 使用 AI 来理解关于您的文件、工作聊天和公司内容的问题，将所有内容汇聚到一个地方，以实现更深入、更专注的工作。面对成千上万可能的工作文档，搜索和智能体都依赖于实时机器学习驱动的排序系统，以快速找到正确的文件。该排序的核心是我们的 特征库，一个管理并提供模型用于预测相关性的数据信号（“特征”）的系统。
为什么需要自定义特征存储？
为了帮助用户精准找到所需内容，Dash 必须洞察用户在不同文件类型、公司内容以及混乱、碎片化的协作环境中的行为细节。随后，它会在用户需要时以及以合适的方式呈现最相关的文档、图片和对话。
特征存储是我们在工作中对正确上下文进行排序和检索的关键组成部分。它的设计目标是：
- 快速提供特征
- 随着用户行为的变化保持同步
- 让工程师从概念到生产快速迭代
（想了解特征存储如何与 Dash 的上下文工程相结合，请查看我们的 上下文工程深度解析。）
本文包含什么？
我们将逐步介绍：
- 我们如何构建 Dash 排名系统背后的特征存储
- 为什么现成的解决方案不适用
- 我们如何为速度和规模进行设计
- 随着用户行为变化，保持特征新鲜所需的工作
在此过程中，我们将分享所做的权衡以及塑造我们方法的经验教训。
我们的目标与需求
为 Dash 构建特征存储需要定制化方案，而非现成产品。主要约束如下：
| 区域 | 挑战 | 为什么重要 |
|---|---|---|
| 混合基础设施 | 本地低延迟服务网格 ↔ Spark 原生云环境 | 标准的云原生存储无法同时覆盖两者，需要一个桥梁来保持高开发速度。 |
| 搜索排序规模 | 单次查询 → 成千上万的特征查找（行为、上下文、实时信号） | 存储必须在 100 ms 以下 的延迟预算内支撑大规模并行读取。 |
| 实时相关性 | 信号（如文档打开、Slack 加入）必须在几秒内体现在下一次搜索中 | 需要一个能够跟上用户行为高速率的摄取管道。 |
| 混合计算模式 | 某些特征优先流式处理；其他则需对历史数据进行批处理 | 需要统一框架同时高效支持两者，降低工程师认知负担，加快从想法到生产的路径。 |
摘要
- 桥接本地与云，且不牺牲速度。
- 支持大规模并行读取，同时保证低延迟。
| 指标 | Python（原版） | Go（新） |
|---|---|---|
| 延迟 | ≤ 100 ms | 25–35 ms |
| 吞吐量 | 以高 CPU 处理每秒数千请求 | 以更低 CPU 处理每秒数千请求 |
| 可扩展性 | 受 GIL 与进程协调限制 | 随 goroutine 数线性扩展 |
Go 服务现在能够处理 每秒数千请求，仅在 Dynovault 客户端延迟之上增加 约 5–10 ms 的处理开销，并始终实现 p95 延迟约 25–35 ms。
影响
- 稳定达成 Dash 的延迟目标。
- 防止特征服务成为搜索流量和特征复杂度增长的瓶颈。
阅读更多关于 Go 的信息，请访问官方站点。
保持特征新鲜
速度只有在数据本身是最新的情况下才重要。过时的特征会降低排序质量并影响用户体验，因此我们的特征库必须尽快反映新信号——通常在用户行为发生后的几分钟内。
挑战
- 规模 – Dash 的许多关键特征依赖于大规模的连接、聚合和历史上下文，使得完全实时计算不可行。
- 平衡 – 我们需要一种摄取策略，既能保持数据新鲜 且 可靠，又不至于让基础设施超负荷或拖慢开发。
我们的解决方案：三段式摄取系统
| 摄取类型 | 处理内容 | 关键收益 |
|---|---|---|
| 批量摄取 | 基于 medallion architecture（原始 → 精炼阶段）的复杂、高容量转换。 | • 智能变更检测 → 仅写入已修改的记录。 • 写入量从每小时数亿条降至 5 分钟 内完成。 |
| 流式摄取 | 快速变化的信号（例如协作活动、内容交互）。 | • 对无限数据集进行近实时处理。 • 特征与用户当前行为保持同步。 |
| 直接写入 | 轻量或预计算特征（例如来自 LLM 评估流水线的相关性得分）。 | • 完全绕过批处理管道。 • 数据在几秒钟内出现在在线存储中。 |
成果
通过结合这三条摄取路径，Dash 能够在不将所有计算集中到单一管道的前提下保持特征值的新鲜度。这既保证了排序质量，又能够支撑真实业务的规模。
我们的收获
在 Dropbox 规模构建特征库，让我们再次体会到系统设计中的若干宝贵经验。
服务端洞察
- Python 的并发模型 成为了高吞吐、CPU‑I/O 混合工作负载的瓶颈。
- 即使仔细进行并行化，全球解释器锁（GIL）仍限制了 CPU 密集型任务（如 JSON 解析）的性能。
- 切换到多进程会引入新的协作瓶颈。
- 将服务层重写为 Go 消除了这些权衡，使我们能够可预测地扩展并发度。
数据端洞察
- 基础设施的改动固然重要，但对访问模式的理解同样关键。
- 在典型的 15 分钟窗口内，只有 1–5 % 的特征值会变化。
- 利用这一事实大幅降低了写入量和摄取时间，将原本需要数小时的批处理周期压缩为 五分钟更新——在不增加系统负载的前提下提升了新鲜度。
混合架构
- Feast – 编排与一致性
- Spark – 大规模计算
- Dynovault – 低延迟在线服务
我们没有依赖单一供应商的解决方案，而是通过这种方式让每一层都能发挥各自的优势，同时保持训练与服务的一致性。
结论
这项工作凸显了在“从头全部自行构建”和“全盘采用现成系统”之间走中间路线的价值。通过将开源基础与内部基础设施相结合，并根据真实约束进行定制，我们构建了一个满足当前需求、且能够随未来发展而演进的特征库。
致谢
特别感谢所有当前和过去的 AI/ML Platform 与 Data Platform 团队成员对我们的贡献，以及那些使用我们构建的工具来实现魔法的机器学习工程师。
如果构建创新的产品、体验和基础设施让你感到兴奋，欢迎加入我们共创未来！访问 jobs.dropbox.com 查看我们的招聘岗位。