为了提升搜索与推荐的用户体验，优步（Uber）从Apache Lucene迁移到了Amazon OpenSearch，以支持大规模向量搜索并更精准地捕捉用户搜索意图。此次迁移带来了若干基础设施方面的挑战，优步的工程师通过针对性的解决方案逐一将其克服。
优步采用 OpenSearch 的第一步是使用 HNSW（Hierarchical Navigable Small World）算法对现有的基于 Lucene 的系统进行评估：
我们发现自己受限于算法选项的匮乏，这阻碍了我们在不同场景下对精度与成本之间进行精细权衡的能力。这意味着我们无法始终为用户提供最准确的结果或最具成本效益的方案。
现有架构的另一个关键限制是缺乏原生 GPU 的支持，这成为个性化推荐和欺诈检测等依赖高维向量的复杂工作负载的性能瓶颈。
Amazon OpenSearch 通过支持多种 ANN（Approximate Nearest Neighbor）算法，为不同使用场景提供了灵活性，并借助FacebookAI相似性搜索（Facebook AI Similarity Search，FAISS）实现了 GPU 加速，从而解决了上述两个限制。
此外，OpenSearch 的稳健性和灵活的 API 也满足了优步对可扩展性与多功能性的要求，确保了流畅且响应迅速的用户体验。
在选定技术后，优步构建了一个原型系统，它能够处理超过 15 亿个、近 400 维的向量，以实现大规模语义检索。该原型将原始数据处理生成嵌入向量，并使用Apache Hive存储。随后，这些数据通过 Spark 批量导入 OpenSearch，并使用 FAISS 进行查询。
优步工程师面临的最主要挑战集中在数据摄入速度与稳定性，以及查询性能方面。
在数据摄入方面，工程师优化了原型系统的基准配置，将完整摄入 15 亿文档数据集所需时间从 12.5 小时缩短至仅 2.5 小时，提升了 79%。这一成果通过调整 Spark 的核心数、执行器数量和分区策略，以及优化 OpenSearch 的索引线程实现。I/O 也是导致索引延迟的重要因素。
总 I/O 量甚至超过了索引本身的大小，表明存在大量不必要的冗余写入。同时，较高的读取 I/O 暗示后台频繁进行段合并（segment compaction）。这些问题很可能源于索引过程中生成了大量小段（small segments）。
对此，团队通过调整刷新间隔和合并策略，并禁用_source和doc_values字段，成功将索引体积从约 11TB 减少到约 4TB。
另一个与索引相关的性能问题是索引期间查询延迟波动较大。为解决此问题，优步将索引构建任务卸载到一个独立集群上，使主集群专注于搜索服务，待新索引准备就绪后，再将搜索流量切换至新集群。
在查询性能方面，优步的工程师通过多项架构优化，将 2000 QPS 下的 P99 延迟从约 250 毫秒降至 120 毫秒以下，性能提升约 52%。这些优化包括：调整分片数量以匹配节点数量，从而提升并行度；增加副本数量以更均衡地分担负载，同时不损害搜索性能。
然而，并发段搜索（Concurrent Segment Search, CSS）这项允许多个核心同时在多个段上执行搜索的功能，并未带来预期的性能提升。
尽管原生 GPU 支持是优步工程师选择 OpenSearch 的关键因素之一，但其全部潜力仍有待深入挖掘，有望进一步加快搜索响应速度、提升系统灵敏度，并为用户带来更优质的整体体验。另一个待改进的方向是从当前的批量数据摄入转向基于 Apache Flink 的实时更新机制，这对于更动态、时效性更强的应用场景至关重要。
原文链接：
Uber Adopts Amazon OpenSearch for Semantic Search to Better Capture User Intent
