InfoQ前Uber CTO加入韩国最大电商公司Coupang( 二 )

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

并不是一个平台，而是 ground truth 数据和在线服务搜索集群之间的连接器；
无法向外扩展处理大量数据；
关系型数据库变得缓慢且不稳定，无法连接数十个大型表格；
如果要在在线服务搜索集群中创建索，不仅慢而且贵；每个副本都需要使用相同的数据创建相同的索引，这在资源上是一种巨大的浪费；
Ranking 开发人员几乎不可能在短时间内添加检索 /ranking signal 。

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

本文插图
创新迭代: 索引平台（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 。