摘要：nbsp;优步采用OpenSearch的第一步是使用HNSW（Hierarchical Navigable Small World）nbsp;在数据摄入方面，工程师优化了原型系统的基准配置，将完整摄入15亿文档数据集所需时间从12.5小时缩短至仅2.5小时，提升了79%。nbsp;原文链接： Uber Adopts Amazon OpenSearch for Semantic Search to Better Capture User Intent"
为了提升搜索与推荐的用户体验，优步（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"
为了提升搜索与推荐的用户体验，优步（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也是导致索引延迟的重要因素。
对此，团队通过调整刷新间隔和合并策略，并禁用_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"