从概念的角度审视一淘商品搜索的Online系统架构

从概念上讲，一淘商品搜索涉及的几个重要名词的关系可以粗略地用下面这张图描述。

其中涉及到如下不同层次的术语：

• 类目、一级类目、叶子类目、前后台类目

• 产品节点、SPU、SKU、节点父子关系

• 产品属性、商品属性、类目公共属性、关键属性、导航属性

为什么这些概念随着时间的推移逐渐地出现，是因为系统里的商品越来越多了，一个概念Hold不住。

从上到下，从“类目”到“叶子类目”，类目数成千上万了，再加上前后台类目，运营同学Hold不住了。

从下到上，从“商品”到“SKU”再到“SPU”，在一个叶子类目范围内，也是几十万级别的，加上SPU/SKU的易混淆，产品库同学Hold不住了。

在一淘商品搜索Online系统中，这些概念对应的信息都体现在哪些模块中？又存在什么问题？

一.产品节点的类目信息为什么不能被利用起来？产品节点的父子关系如何在系统中实施？

一淘第一版的产品搜，有一个关键模块叫PS Server，它的位置就是今天AGG的位置。它有一个AGG今天没有的职能，就是访问产品搜自己的Forest，负责翻译产品搜的类目属性信息。为什么是自己的Forest？因为一淘产品库为了快速迭代，从淘宝SPU库中脱离出来，类目用的是淘宝的后台类目，但SPU的pid/vid是完全独立的一套数据，这么做有利有弊，因此欠下的债我们早晚也要还的，这块不是问题的主干路径，就先不展开谈了。

由于线上用命中Query的商品召回产品的逻辑，目前起作用的是商品的Forest。换句话说，产品节点的类目信息在Online系统没有被使用，只是用于离线Pidmatch的前处理环节，那么产品库下半年要做节点分层产生的SPU/SKU的父子关系保存在哪里呢？ Online系统如何使用呢？所以，在Online系统中，我邮件中第一张概念图的树形关系有一部分是缺失的。这个缺失一定会产生问题，我认为它造成产品节点一直在SRP页展现很别扭的重要原因之一。

在展开说上面这个问题前，先说一下我心目中更符合第一张概念图的实现方式：

CatId、SpuId (Epid)、SkuId(CSpuId)共用一个数值空间；(概念图中的那颗大树就完整了，但意味要颁布一套新的Epid/SkuId，要和CatId兼容)

查询服务统一由一个模块提供；(意味要在Forest的基础上进行扩展)

模块的数据增量更新要支持秒级的，因为大树底部的关系是易变的，人工干预也是少不了的；(Forest目前是一天更新一次)

二.谁决定产品节点是否展现？如何展现？具体展现到哪个层次？

有了一个更完整、深度更深的大树后，我们能解决哪些问题？

先看几个典型的线上Query：

三星： http://s.etao.com/search?q=%C8%FD%D0%C7

三星 Galaxy：http://s.etao.com/search?q=%C8%FD%D0%C7+Galaxy

三星 Galaxy Tab： http://s.etao.com/search?q=%C8%FD%D0%C7+Galaxy+Tab

三星 Galaxy Note： http://s.etao.com/search?q=%C8%FD%D0%C7+Galaxy+Note

三星 Galaxy Note I9228：http://s.etao.com/search?q=%C8%FD%D0%C7+Galaxy+Note+I9228

Query1落在大树的偏上部：搜索结果页上面是结构化Combo，但自然搜索结果中只有手机节点。如果AGG对召回的节点按类目进行统计，返回节点的类目丰富性会不会更好一些？结构化Combo人工编辑的成本会不会进一步降低？

Query2顺着大树往下走了一步：返回结果都是手机，其实把Query3的平板电脑分支给丢掉了，理由是“淘宝输入这个query的用户，点击的都是手机类目”，可是AGG对召回节点做个类目统计呢？

Query4顺着大树又往下走了一步：不仅返回了Galaxy Note，还召回了GALAXY S I9070，只因为这个节点下有一个傻B天猫商家上架了一个商品

http://detail.tmall.com/item.htm?id=17758176369标题是“Samsung/三星 I9070 Galaxy Note 双核纤薄智能手机正品行货”，如果AGG对召回的商品的Epid做Uniq的统计，类似的节点是否展现还需要交给相关性同学来决定吗？

Query5来到了大树的底部(最底部的SKU层还没建设出来)：AGG发现只返回了一个节点，它能告诉前端跳转到比价页吗？这个跳转逻辑还需要QP维护一个定期更新的词表吗？

这些决定目前都是交给QP来做的，而QP的决策都是基于Offline统计来支持的，但是有了这颗大树，AGG做一些Online的统计，来辅助QP决策，会不会比龙猫更靠谱一些？另外，基于这颗大树(到底部一带，准确地说是一张大网)做一些关联推荐，不应该是难事吧？又扯远了(攻城师容易犯的病)

根据这些概念的功能，我归一下类，简化出来两个名词：

AP (AccessPoint、Aggregator Point聚合节点)：包括类目、SPU、SKU，当用户需要时，还包括品牌、系列等等等等。

TAG：就是我们常说的属性/属性名，颜色、尺寸、容量、行水，也会包括品牌、系列等等等等

两者的区别是：AP用于路径导航，Tag用于结果筛选。

两者会根据用户和运营的需求，在一定的范围内、一定时期内进行相互变换。

例如：当苹果手机没有正式入国内的网络时，“是否是合约机”只是个用户不关注的TAG；当正式入网后，用户导购路径中这个TAG成为一个重要因素后，苹果的几款合约机就有需求演变成AP了。

这个演变的动作，发生在大树的顶部叫做“前台类目”，发生在大树的底部叫做“产品节点”。

“AP用于路径导航”的深层含义：AP之间的路径父子关系，由浅而深。用户不用输入，只需要最少的点击，就能导航到心中想买的“叶子AP”(我们常叫SKU)。

有人要说了，属性导航也不需要用户输入，点击几次也能找到想要买的SKU。没错的，问题是，如果用户没这方面的专业知识，他这几次点击不一定能点对。

什么叫“路”？鲁迅说的好：地上本没有路，走的人多了，便成了路。

由AP构成的导航路径，是离线统计经验推荐的，是经过运营专家编辑的，把“一定时期内用户关注TAG”包装好的一条路，你觉得用户浏览起来会不会更爽一些？

路径导航，在SRP页下半年的产品方向上叫“结构化Combo”，大家搜一下“单反相机”就能看到PD想示范的效果。

请注意第二行“入门单反”，三个都是佳能600D

要是出现几个品牌和型号都各不相同的AP(这个Query要展现的AP可以类似下面这个效果和层次)，你觉得用户会不会更爽一些？

线上“结构化combo”的实现，是针对一个Query做一个定制的，不能规模化。你查询“佳能单反相机”、“入门单反相机”都没有效果，如果我们有保存了路径信息的AP树，产品的想象空间会不会更大一些？

产品库团队的Pbuilder/Pbase/PidMatch在干什么事情？

在全力结构化商品信息，尽所能(需要行业知识)找到最底层的AP。

不是每个叶子类目下的每类产品都需要做很细的划分，这就是为什么目前产品库有些类目节点建设到了SKU(相机、笔记本)，有些类目建设到了SPU(化妆品、百货)，细到什么程度取决于用户的需求和我们投入的精力。

会不会有比SPU更高层次的AP？淘宝集市最近有个“类产品”的概念，用于非标类的商品的聚合和导航，之前推荐的“淘宝网类目属性简介-2012年”有描述。

对于标类，我们把最底层的AP的用户关注属性拿出来做聚合条件，也会产生适合导航的高层AP，比如：苹果合约机、三星万元智能电视。

再强调一遍，AP用于导航，TAG用于筛选，两者可以相互转化。

导航不仅意味着单条路径的父子关系，还意味着当用户的意图被定位到AP树的一个层次的一撮节点时，我们可以根据AP树的局部关系，给出良好的导航体验。

另外，有了AP树，还有一个好处：公共描述信息可以上提。比如：iphone 4S的图文描述，没必要黑色、白色都编辑一淘；佳能单反相机不同于尼康的优点的知识信息，就可以放到佳能单反相机这个AP的附属信息里。可以在佳能所有单反相机的SRP页、比价页的推荐位置被调出来显示给用户。

========================================

有同学问：“统一catid/spuid/skuid三者的值域和产品节点的类目、父子关系的应用没直接关系吧？不统一表达spu父子关系也可以的吧。商品的 catid本身就具备父子关系，而且引擎也知道的，无需通过forest就能知道的。”

答：假如引擎里存了“catid/spuid/skuid”父子关系，也只是单条路径，还是需要有个服务提供类似Forest提供的“根据CATID返回所有的其子类目ID 或者其子孙类目ID”功能的。因此，catid/spuid/skuid所有用于路径导航的AP的值域还是需要统一的。

有同学问：“其实属性值也可以在这个数值区间内”。

答：需要保持两套，属性值是TAG的值域，量会很大；当某属性要做为一个AP产生的规则描述条件时，AP和TAG发生关系。

建议继续学习：