Compass 公司使用 Amazon ES 升级传统搜索模式「其他」

Amazon ES 为客户提供符合其需求的搜索结果。无论大家希望实时搜索新列表，还是打算使用已保存搜索机制进行市场监控，Amazon ES 都能为您提供良好的运行效果

以下各节将从最初的 Apache Lucene 架构开始，详细介绍 Compass 主搜索功能及其架构随时间发生的一系列演变。

Compass 公司最初通过直接集成 Lucene 的方式实现其搜索功能，并通过对 Amazon Web Services 虚拟机的手动置备与手动安装对 Lucene 进行配置。

如下方架构图所示，MLS（主列表服务）系统的数据通过一套常规提取、转换与加载（ETL）框架进行推送，并被进一步填充至列表数据库当中。在数据库内，数据又进一步被推送至 Lucene 集群中以供前端搜索 REST API 进行查询。

这套架构当中存在多个痛点，且主要与 Lucene 的自身特征有关，具体包括：

为了克服上述挑战，Compass 公司决定使用 Amazon ES。

通过以下架构示意图，可以看到 Compass 系统的演变过程。Compass 首先以并行方式运行 Amazon ES 与 Lucene，通过影子流量对生产结果进行验证与质量保证。整个服务并行评估持续达两个月，他们也最终确认 Amazon ES 完全能够实现相同的运行效果。

此外，Compass 公司还在切换至 Amazon ES 之后立即添加了全文本搜索（描述搜索）功能。由此，客户可以提高列表与功能的使用速度，并使 Compass 平台得以在全国范围内扩展并实现本地化搜索。

Compass 公司又进一步使用 Amazon MSK 对架构加以增强。新架构使不同团队能够并行处理事务，并将转换后的事件推送至 Kafka 集群。下图所示为增强之后的新架构。

在新架构的支持下，Compass 的搜索功能立即迎来了以下提升：

凭借 Amazon ES 提供的用户界面与监控功能，Compass 团队得以轻松评估当前资源使用情况，并据此进行容量规划与成本预测。

Elasticsearch 过滤器实际上反转了查询-文档这一固有使用模式——我们的索引将围绕查询（而非文档）建立，这意味着用户可以配合文档内容对经过索引的查询执行查询。过滤查询的搜索结果，正是能够匹配所提供文档的对应查询本身。

Compass 公司使用这项功能对每位用户的搜索查询进行索引，由此实现搜索保存功能。当收到资产列表时，Compass 会使用 Amazon ES 检索与列表内容相匹配的查询，并向各位客户发出通知。

以下示意图展示了这一工作流。

在执行过滤之前，Compass 会重新运行已保存的搜索查询以检查是否存在样报的匹配项。通过过滤功能，Compass 能够及时将搜索变更通知给用户。在任意时间点上，Compass 都平均存储有 25 万条搜索查询。

在有新列表传入时，这些列表每分钟平均提交 5 到 10 项批量请求，每项批量请求包含 1000 个文档。在使用 18 节点 m5.12xlarge 实例类型的集群时，Amazon ES 端的最大延迟在 750 毫秒到 2500 毫秒之间浮动。

以下示意图展示了保存搜索机制的基本架构。搜索条件被保存在搜索索引当中。当新列表通过 MLS 及 Amazon MSK 列表流传入时，此架构将执行过滤处理程序，由该程序将消息推送至 Amazon MSK 的已保存搜索匹配主题流当中。接下来，架构会从已保存搜索服务处提取消息，并将其推送至最终用户。

这套架构具有以下优势：

在根据搜索条件查询房产时，结果会被保存在 Amazon ES 当中。而在代理商将与已保存搜索条件相匹配的房产添加到系统中后，用户就会收到通知，提醒列表中添加了一处与搜索条件相符的新房产。
由于具有过滤功能，因此在将房产添加至系统之后，用户会立即得到通知——通知延迟由过去的 1 小时缩短到现在的 1 分钟。
在采用过滤功能之前，Compass 团队需要通过批处理任务根据搜索条件检索新的房产记录。但现在，直接使用基于推送的通知功能即可。

随着其平台逐步扩展至更多房产列表、代理与用户群体当中，Compass 公司有非常宏大的发展路径。他们目前计划开发以下功能：