目标
目前搜索业务除了搜商品之外,我总结为都是输入为query,输出为根据query推荐的信息。比如"搜索导航"输出的是一堆类目id和属性id, "搜索提示"输出的是query相关根据算法提供的score排序, "热搜词"输出的是与query相关的热门搜索, "你可能会搜产品"输出的是对应中心词。这些产品可以统一成一张以query词key,collum为算法输出的query特征Hbase表。在这张表中,除了存储一些算法数据,还可以插入query维度的相关特征信息比如pv;uv;gmv等。 根据这张表, 我能很方便的管理算法的abtest功能,搜索词的数据统计功能,所有搜索词相关产品工程实现可以对接这张表,算法开发的搜索词的基础数据也可以接入这张表。
Hbase表设计如下
query 导航类目id 导航属性id 搜索提示算法score1 搜索提示算法score2 相关搜索词.......
衣服 10001 10048 1.6 1.7 冬季衣服 ,冬季女装
裤子 10003 10048 1.5 2.0 ....
包包 10006 10048 1.4 2.1 ....
搜索相关算法产品的query为网站的历史搜索词, 可以通过添加列添加对应的内容。由于Hbase 面向列存储的,可以横向扩展,只要有query维度的算法产品需求，我们可以添加一列,算法工程师可以把query对应的值存在这个列中。这样对于搜索业务开发取对应的算法数据非常方便。在这个搜索词特征表的基础下，设想的算法出数据,工程组装数据并展示给用户的流程如下:
为什么需要搜索词特征表
以前接到搜索词维度的需求是，都是算法产出的数据通过人肉的方法(热搜词推荐,xxx告诉我redis地址或者接口)给工程人员，获取干脆工程人员自己维护一份算法数据(导航和搜索提示)。这样的结果是,开发过程是非常高效的单兵作战, 但是后期有算法人员需要优化的时候,就会研究整个具体的工程(比如svn up一个搜索提示的工程,然后开始debug),这样并不适合快速算法更新迭代。假如采用上述的方式,算法开发只需要对接Hbase表, 根据对算法工程师的调研,他们产生最终算法数据生成一个文件给我,和把这些数据插入到Hbase的成本是一样的。那么从搜索业务工程师的角度而言,只要了解算法产品对应的Hbase列,那么导航、搜索提示等搜索词维度工程的初始化操作也都是统一的,那就是从表中select某个列,然后开始处理。
搜索词特征表其他功能
既然这张搜索词特征表可以存储算法数据， 那也可以把计算搜索词pv,uv,gmv看做一个“算法”，存储搜索词对应的pv,uv,gmv等数据, 接下来这张表的结构可以演变成如下:
query 导类目id 导航属性id 提示算法score1 提示算法score2 相关搜索词 pv uv gmv
衣服 10001 10048 1.5 1.6 冬季衣服 112 12 32
裤子 10002 10001 1.7 1.9 ....
包包 10004 10003 1.8 2.1 ....
对于搜索词的算法产品, 几乎都需要搜索词的pv,uv,gmv数据。 上一节提到算法开发可以很方便的输出到搜索词特征表, 那么我们把这些数据存在这张表, 算法工程师的输入也可以来自这张表, 这对算法开发的工作也很有帮助。我了解到算法团队一般用spark跑算法数据,这样做的结果是spark工程中的输入和输出都是同一个地方,可以简少代码维护工作。这样做的结果如下:
其他衍生功能
如果算法开发有abtest需求, 搜索词工程(搜索提示,导航)处理之前可以获取abtest配置信息,这个配置信息包括走哪个算法(对应Hbase列)，还包括打点信息(自定义参数)。从kafka日志系统获取这些打点数据分析后,可以计算出该搜索词在该算法下的表现如何。这个表现结果还是插入到搜索词特征表，那么算法的总体表现可以通过特征表画出曲线图看到算法结果。最终的搜索词query产品的规划如下:
希望有搜索业务的相关开发或者产品提出意见,针对query分析的相关业务,如何有一个更好的方式统一起来。
