跳到主要内容

搜索发现索引平台的演变

分(阅读时间)
网络特写

简介

搜索是顾客开启Coupang之旅的主要入口。为了创造一个让顾客无法想象“如果离开了Coupang该如何生活?”的世界,搜索体验是完成公司使命的关键。Coupang搜索引擎的目标是根据用户搜索关键字提供最佳商品(相关度、评级、评论、价格、品牌)。不像类似Google的传统网络搜索引擎,认为关联性是最重要的因素,顾客还关心商品在Coupang上的评级、评论、价格、品牌等。所有这些因素都会影响搜索的数据检索和排名。本文将让您总体了解Coupang的搜索工作原理,并集中理解如何构建搜索索引。

搜索架构概述

搜索引擎会在接收搜索请求后找到最佳结果,包含以下几个步骤

查询理解。找出查询意图、查询注释,例如类别/品牌。

检索。根据搜索查询和商品文字信息找到匹配的候选商品

Ranking排名。使用排名功能或机器学习模型对候选商品进行排名。排名功能通常将ranking signal作为输入信息,并返回每个候选商品的所得分数。

索引平台提供搜索引擎所需的所有数据,以进行检索和排名。它将所有源数据合并,并为搜索引擎生成搜索索引。

为了改善搜索体验,排名算法是关键的一部分。因此,一个成功的搜索平台应支持基于排名算法的快速迭代。Ranking开发人员构建新排名算法的第一个挑战,就是他们在哪里可以找到所需的数据。他们如何从这些商品数据和顾客行为数据中轻松得出排序特征? — -索引平台!

索引平台是一个基础,能提供检索和排名所需的所有数据的搜索引擎。

索引平台概述

索引平台是一个可扩展的平台,它从不同的ground truth数据表中收集数据,对由商品/查询键入的数据进行反规格化处理,并建立搜索引擎索引。同时,它还应为ranking开发人员提供一个框架,使他们更容易开发ranking signal。

阶段1:索引平台0.1

在早期阶段,Coupang上只有少量的商品。大多数ground truth数据都在关系型数据库中,例如价格、品牌、类别等。索引平台的第一个版本是利用关系型数据库的sql引擎通过商品关键信息(product key)来join多个表,并将它们合并到一个反规格化表中。然后,它将来自反规格化表的数据传到在线服务搜索集群中以动态创建索引。现在,搜索引擎已经能够根据商品的文本信息和一些简单signal的基本排名提供基本检索。但随着商品数量的快速增长,出现了很多问题,索引时间很长,服务不稳定。系统的问题很明显

实际上它根本不是个平台!它只是一个ground truth数据和在线服务搜索集群之间的连接器。

无法向外扩展处理大量数据。

关系型数据库变得缓慢且不稳定,无法join数十个大型表格。

要在线服务搜索集群中创建索引极其缓慢而且很贵。每个副本都需要使用相同的数据创建相同的索引,这在资源上是一种巨大的浪费。

Ranking开发人员几乎不可能在几天内添加检索/ranking signal

阶段2: 索引平台 1.0

商品数量迅速增长,以至于以前的设计无法支持。我们决定重构整个系统,创建一个可以轻松扩展的真实分布式平台。新系统基于Hadoop构建,Hadoop是一个被广泛应用的处理分布式数据的开源平台。由于关系型数据库是瓶颈,因此所有基础真实(ground truth)数据都从关系型数据库复制到了Hive,也就是Hadoop中的数据warehouse。同时,Ranking signal也被生成为Hive表。现在,用于构建搜索索引(search index)的所有必需数据都在Hadoop平台中。索引合并器(Index Merger)是一个将所有这些数据合并到ProductJoin的Spark job。而ProductJoin是一个protobuf结构,包含有关商品的所有内容。之后合并的数据存储在Hbase中。下一步,索引生成器(Index Builder)作为另一个Spark job,它从Hbase中消费了ProductJoin,生成了search index并将其存储在S3中。在线服务集群将直接从S3下载索引展开服务。该索引仅创建一次,并且可以被所有副本(replica)使用。

对于查询数据,我们还建立了类似的pipeline以更好地支持查询理解服务(Query Understanding Service)。

索引平台0.1和索引平台1.0的对比

阶段3: 索引平台2.0

尽管索引平台1.0已经是成功的平台,解决了性能和扩展性问题。但是,索引平台的另一个主要任务是减轻Ranking开发人员的工作,释放他们在构建Ranking signal时的生产力。索引平台1.0并没有为开发人员提供任何帮助使他们更快地构建Signal。新手Ranking开发人员可能需要花费数周的时间建立新Signal并进行实验。因为Ranking开发人员需要花费大量时间查找数据源,处理数据pipeline,并安排workflow。

索引平台2.0是每个Ranking开发人员都可以使用的索引总线(Indexing Bus),并且能使他们真正专注于Signal的逻辑,而不必担心数据源、数据pipepline和workflow的安排。

索引平台2.0的主要改变在于大多数signal是在平台中生成的,而索引平台 1.0需要在外部Hive表中合并signal。在索引平台2.0中,所有ground truth数据将通过Ground Truth Merger合并在一起。并通过Session Long Parser解析和合并所有顾客行为。它们都是易于扩展的Spark job。 ProductJoiner和QueryJoiner负责根据ground truth数据和会话日志导出所有Signal。

该框架的优点在于ProductJoin和QueryJoin之间存在一个闭环。这使得简单的Signal有可能演变成强大的Signal。例如价格在product join中是ground truth数据。在构建query join时,可以使用每个product join的价格信息来构建查询价格分布,然后就能根据商品价格和查询价格分布构建一个Signal,用来提升/降低商品。这样,在Ranking中,简单的价格便成为了一个强大的Signal。

以QueryJoin为例,生成QueryJoin的过程如下:

加载所有源数据,包括ground truth数据和已解析的会话日志

在查询级别和商品查询级别生成内置的聚合原始顾客行为数据,例如曝光量、点击数、购买数、收益。

处理所有Signal处理器,生成Signal

将QueryJoin和所有Signal存储到Hbase

每个处理器的工作流(workflow)如下:

从效率的角度来看,以前创建一个新的Signal,从解析原始日志到创建signal,需要建立一个完整的pipeline。通常,生成一个新Signal需要许多Hive查询/Spark job,并花费数小时。我们有大约70条这样的pipeline,维护它们几乎是一场灾难,造成了巨大的资源浪费。而在索引平台2.0中,解析日志和生成原始Signal的功能是一体且由平台自身提供的,添加新Signal只需实现一个Class并添加一些逻辑来处理在新平台上几乎免费的数据。

Indexing Bus索引总线使用前后效率对比

通过索引平台2.0

Ranking开发人员可以在几小时内创建一个新的Ranking signal,完全专注于Signal的逻辑和公式。

节省了大量的EMR资源,并且可以几乎免费在索引平台 2.0中添加新的Signal。

提供单元测试/集成测试,以确保Signal质量。

未来愿景

这并不是结束,这仅仅是个开始!在Product和Query之间建立关系,只是平台的第一步。未来,我们将在顾客、商品、查询、品类、品牌等之间建立类似的关系,造福于其它业务(如推荐和广告)。最后的最后,索引平台将成为Coupang业务的核心大脑。

作者: Winter Wang

标记

推荐文章