IT瘾搜索推荐

Google搜索引擎架构Caffeine

Wed, 04 Dec 2024 22:09:28 CST

什么是 Google Caffeine？

Google Caffeine 是 Google 搜索引擎的一次架构重构，旨在满足不断增长的互联网内容和用户实时搜索需求。它替代了 Google 早期的分层索引系统，转而采用更加实时的索引机制，使搜索结果更加快速和新鲜。

发布时间：Google 于 2009 年 8 月发布 Caffeine 项目 Beta 版本，并于 2010 年 6 月正式启用。

Google Caffeine的产生背景

传统索引架构的局限性

在 Caffeine 出现之前，Google 使用的是一个分层的索引结构：

分层索引：
- 数据分为“主索引”和“增量索引”。
- 主索引：周期性地更新，通常需要几天或几周。
- 增量索引：包含最新的数据，但覆盖范围较小。
更新延迟：对于新增的网页或内容，用户可能需要等待较长时间才能在搜索结果中看到。
扩展性瓶颈：随着互联网内容的指数增长，传统架构难以高效处理。

Google Caffeine 的目标

提高索引速度：支持更快地抓取和处理新增内容（如新闻、博客、社交媒体）。
改进搜索结果的新鲜度：实现接近实时的搜索结果，用户能够快速获取最新信息。
扩展性：提升 Google 数据中心的存储和处理能力，满足日益增长的互联网规模。
提升性能：降低搜索延迟，改善用户体验。

Google Caffeine 的核心特性

实时索引：
- Caffeine 实现了一个单层实时索引系统。
- 新的网页和内容在被抓取后，几乎立即可供搜索使用。
分布式处理：
- 利用 Google 的分布式文件系统（GFS），对网页进行分片存储和处理。
- 大量服务器协同工作，提高数据处理速度。
高效的分片机制：
- 把网页划分为多个独立的“索引片”（index shard），每个片可以独立更新和查询。
改进抓取策略：
- 更频繁地抓取更新频率高的网站（如新闻网站）。
- 对重要页面和内容优先处理。
支持海量数据：
- Caffeine 的架构允许 Google 索引比以前多得多的网页内容，同时支持更多种类的数据（如图片、视频、实时内容）。

Caffeine 的技术优势

特性	传统索引架构	Google Caffeine
索引更新频率	周期性（数天至数周）	实时更新
处理速度	较慢	高效并行处理
扩展性	有限	动态可扩展
数据类型支持	主要是网页	多种数据类型

速度与效率：每秒可以处理数以千计的网页更新，显著提高了索引更新的频率。
可扩展性：动态扩展索引容量，适应互联网规模的持续增长。
新鲜度：通过实时处理机制，确保用户搜索结果中始终包含最新内容。
数据融合：Caffeine 不仅索引网页，还将图片、视频、社交媒体内容等多种类型数据整合到搜索结果中。

Google Caffeine的影响

对用户的影响

更快的搜索结果：用户可以几乎实时地获得最新的新闻、博客和社交媒体内容。
更全面的搜索覆盖：索引规模的扩大意味着用户能够搜索到更多样化的内容。
搜索体验提升：减少了延迟，搜索结果更加相关。

对网站管理员的影响

频繁抓取：Googlebot 的抓取频率增加，对频繁更新的网站尤为明显。
关注内容更新：网站需要更注重内容质量和频繁更新，以便在搜索中保持竞争力。
页面权重动态变化：页面排名可能会更快地反映内容的更新和链接关系的变化。

对互联网行业的影响

推动实时搜索：其他搜索引擎（如 Bing、Yahoo）也纷纷改进索引技术，以缩短数据处理延迟。
促进内容生产：更快速的内容索引激励了新闻网站和博客作者加速生产优质内容。
提高搜索质量：用户能够获得更加多样化和相关的搜索结果。

Google Caffeine 是一次革命性的搜索引擎升级，标志着搜索技术进入实时化时代。它不仅大幅提升了 Google 的搜索能力，还推动了整个互联网生态系统的快速发展。如果对其架构或技术实现有更深入的兴趣，可以讨论相关的分布式系统和大规模数据处理技术（如 GFS、 Bigtable、 MapReduce 等）。

Google Caffeine后更新

Google Caffeine 的推出是 Google 搜索引擎历史上的重要里程碑，但它并不是终点。Caffeine 后，Google 持续在搜索算法、基础架构和用户体验方面进行升级，以应对互联网快速变化的需求和挑战。

Google 在 Caffeine 后的升级，主要集中在以下几个方向：

更智能的查询理解：RankBrain、BERT、MUM。
用户体验优化：移动优先索引、页面体验更新。
实时性与动态性：实时数据索引和搜索。
安全性与透明性：加强数据隐私和搜索可信度。
生成式 AI 的应用：引入生成式 AI，提供更全面和互动的答案。

每一次升级都反映了 Google 对搜索体验优化的持续追求，同时适应了技术趋势和用户需求的变化。

以下是 Google 在 Caffeine 后的主要升级和改进：

RankBrain（2015 年）

RankBrain 是 Google 搜索引擎引入的机器学习算法，用于更好地理解用户查询背后的意图，特别是长尾查询和模糊表达。

核心功能：
- 将查询转换为向量形式（数值表示），便于理解和匹配用户意图。
- 提升了对自然语言查询的处理能力。
影响：
- 搜索结果变得更加相关和智能。
- RankBrain 成为 Google 排名因素之一，与内容相关性和页面权威性共同决定排名。

BERT（2019 年）

BERT（Bidirectional Encoder Representations from Transformers） 是 Google 推出的基于深度学习的自然语言处理技术，用于理解查询的上下文含义。

核心改进：
- BERT 能双向分析查询中的词语和短语，而不是孤立地理解单个词。
- 尤其对长查询和疑问句效果显著。
应用场景：在多个语言版本的搜索中使用，改善了 70 多种语言的搜索质量。
举例：查询 “2019年在巴西的游客需要签证吗？”
- BERT 可以正确理解“在巴西”是对游客的修饰，而不是对签证的修饰。

移动优先索引（Mobile-First Indexing，2016 年启动，2021 年完成）

随着移动设备使用量的增加，Google 改变了索引策略，从桌面优先转向移动优先。

核心概念：Google 搜索索引以网站的移动版本为基础，而非桌面版本。
影响：
- 网站需要优化其移动页面，以确保排名不受影响。
- 响应式设计和快速加载成为关键因素。

Page Experience Update（页面体验更新，2021 年）

Google 强调用户体验因素，将 Core Web Vitals（核心网页指标）纳入排名算法。

核心指标：
- LCP（Largest Contentful Paint）：页面主要内容的加载速度。
- FID（First Input Delay）：用户与页面首次交互的响应速度。
- CLS（Cumulative Layout Shift）：页面布局稳定性。
其他因素：
- HTTPS 安全性。
- 无侵入性广告。
影响：更注重用户友好的设计，缓慢或交互不佳的网站可能失去排名。

MUM（Multitask Unified Model，2021 年）

MUM 是 Google 搜索的多任务统一模型，旨在更智能地处理复杂查询，并提供综合答案。

核心特点：
- 使用多模态模型，能够同时处理文本、图像甚至视频数据。
- 支持多语言理解，并能将知识迁移到不同语言。
应用场景：复杂查询（例如：计划登山旅行需要哪些准备？），MUM 可以整合多种资源，生成更全面的答案。
改进：支持图文结合的搜索，比如用户上传一张图片并配以问题。

实时搜索与增强数据呈现

Google 持续增强搜索结果的动态性和直观性：

实时搜索：整合新闻、社交媒体动态（如 Twitter）、股市变化等实时数据。
丰富的结果展示：
- 使用知识图谱（Knowledge Graph）提供结构化信息。
- 提供更直观的搜索结果卡片（例如：直接在搜索页面上显示天气、赛事结果、影片简介等）。

神经匹配（Neural Matching，2018 年）

Neural Matching 是一种基于神经网络的算法，专注于更好地匹配用户查询和网页内容之间的相关性。

特点：更偏向于全局语义理解，而非关键词匹配。
应用场景：特别是在用户查询中未使用精确关键词的情况下表现突出。

AI 驱动的改进（2023 年及之后）

Google 不断使用更先进的 AI 模型改进搜索引擎，包括生成式 AI 的引入：

生成式 AI 回答：提供直接的、简短的答案，尤其在用户提出的问题非常具体时。
对话式搜索：搜索引擎逐渐具备类似 ChatGPT 的能力，能够与用户进行多轮对话。

数据隐私与安全性改进

近年来，Google 加强了对用户数据隐私的保护，同时确保搜索结果的可信度：

隐私保护：为用户提供更多控制搜索记录的方式。
搜索透明性：提供“关于此结果”（About This Result）的功能，帮助用户了解来源的可靠性。

浅谈有赞搜索QP架构设计

Mon, 05 Sep 2022 13:27:28 CST

一、有赞搜索平台整体设计

在介绍QP前先简单介绍一下搜索平台的整体结构，方便大家快速了解QP在搜索平台中的作用。下图简单展示了一个搜索请求开始到结束的全部流程。业务通过简洁的api接入los，管理员在搜索平台新建配置并下发，完成整个搜索接入，并通过abtest验证QP带来的优化效果。

二、QP的作用

在NLP中，QP被称作Query理解（QueryParser），简单来说就是从词法、句法、语义三个层面对query进行结构化解析。这里query从广义上来说涉及的任务比较多，最常见的就是搜索系统中输入的查询词，也可以是FAQ问答或阅读理解中的问句，又或者可以是人机对话中用户的聊天输入。
在有赞，QP系统专注对查询内容进行结构化解析，整合了有赞NLP能力，提供统一对外接口，与业务逻辑解耦。通过配置化快速满足业务接入需求，同时将算法能力插件化，并支持人工干预插件执行结果。
以精选搜索为例，当用户输入衣服时用户往往想要搜的是衣服类商品，而不是衣服架，衣服配饰等衣服周边用品。通过将衣服类目进行加权，将衣服类的商品排在靠前的位置，优化用户搜索体验。 QP目前应用在新零售，微商城、精选、爱逛买手店、分销市场、帮助中心知识库、官网搜索等场景，通过类目加权，产品词识别，搜索词纠错，同近义词召回提升用户搜索效果。

三、QP应用整体设计

上图完整描述了QP请求流程和配置流程的执行情况。当搜索请求到达QP时，根据请求体中的场景标记获取QP配置。QP配置中包含搜索词位置标记，插件列表，dsl改写脚本等内容。
QP根据配置，按序执行相应插件。插件在执行后，可通过干预配置以及超参数对结果进行人工干预。
QP在获取到算法插件执行结果后，根据改写配置，对搜索dsl进行改写。如将纠错词放置在搜索词同一层级，将dsl改写成fuction score结构进行类目加权。

四、QP应用分层设计

上图按照请求流程从上到下展示了QP的分层设计，接下来将简单描述各层作用：
controller层：查询改写服务入口，对请求做预处理。
service层：根据场景获取QP改写配置，获取dsl里的搜索词，调用相应的插件返回qp结果。
plugin层：负责算法插件执行，调用插件对应的算法实现handler，对算法结果做干预并针对调用成功或者失败做处理。
handler层：算法具体实现放置在该层，该层会依赖各种算法服务（如小盒子，Milvus等）。
Intervener层：负责对handler结果做人工干预。
processor层：根据QP改写配置，调用改写插件，完成dsl的改写。

五、QP算法插件设计

5.1 预处理Preprocess插件

按照配置规则对搜索词进行预处理，预处理方式如下：
* 删除特殊符号 " “ \ 等；
* 大写转小写，全角转半角；
* 连续英文联合切分，连续数字联合切分，其余单独切分；
* 默认截取list前50个字/词；
* 将list拼接成一个字符串。

样例

  输入："史蒂夫新款\时尚套装夏修身圆领百搭钩花DWF镂空雪纺两件套套裙；"
输出："史蒂夫新款时尚套装夏修身圆领百搭钩花dwf镂空雪纺两件套套裙"

5.2 纠错Correction插件

纠错插件的作用是对搜索词中错误内容进行识别，返回正确内容。

样例

  输入：[上海牛黄皂]
输出：[上海硫磺皂]

当用户输入“上海牛黄皂”时，通过纠错插件能正确输出“上海硫磺皂”，其技术架构如下图所示。 1、纠错模型在bert基础上采用知识蒸馏，提升模型精度降低模型时延。
2、根据同音字召回候选集，使用tri-gram语言模型对候选集排序。

5.3 细粒度分词Tokenizer插件（基础分词）

样例

  输入：[雪地靴女2020年新款皮毛一体冬季加绒加厚防滑东北厚底保暖棉鞋子]
输出：[雪地 靴 女 2020 年 新款 皮毛 一体 冬季 加绒 加厚 防滑 东北 厚底 保暖 棉 鞋子]

该分词插件由Java版结巴 jieba-analysis 修改而来，修改内容如下：
* 从全网商品标题数据，有赞行业数据，开源数据中统计出词频，作为基础分词词典；
* 解决词典中由英文单词导致英文字符串被分开的问题；
* 限制DAG的长度，即匹配词的长度，以此控制分词粒度，目前默认是2，分出来的词除英文和数字外，长度不会超过2。

5.4 语义分词sementicSegment插件

样例

  输入：[雪地 靴 女 2020 年 新款 皮毛 一体 冬季 加绒 加厚 防滑 东北 厚底 保暖 棉 鞋子]
输出：[雪地靴 女 2020年 新款 皮毛一体 冬季 加绒加厚 防滑 东北 厚底 保暖 棉鞋子]

该插件在细粒度分词的基础上，通过模型生成语义树将关联度大的词列表进行合并，输出语义分词结果。在样例中，雪地与靴关联度更大，所以在语义分词中将雪地与靴合并输出。

5.5 实体识别Tagging插件

样例

  输入：["汽车","脚垫","刷子"]
输出：[{"word":"汽车","tag":"产品修饰词"},{"word":"脚垫","tag":"产品修饰词"},{"word":"刷子","tag":"产品词"}]

实体识别插件主要用于识别出搜索内容中的产品词。比如用户在输入“汽车脚垫刷子”时，如果没有做产品词识别，“脚垫”相关的商品会因为商品分高而排在“刷子”商品前面，影响用户搜索体验。
反之，经过命名实体识别，对“刷子”做产品词提权，刷子类商品就可以排在脚垫类商品前面，优化搜索体验。
目前有赞规划的实体类别列表如下所示：

  产品词 eg：“修身连衣裙”中的“连衣裙”
产品修饰词 eg：“汽车脚垫”中的“汽车”
普通词
新词
修饰
品牌
机构实体
地点地域
材质
人名
功能功效
专有名词
影视名称
型号
文娱书文曲
系列
游戏名称
款式元素
颜色
场景
风格
营销服务
人群
时间季节
性别
类目
母婴
规格
新品
前缀
后缀
数字
符号

实体识别方法

基于正则可以识别数字、符号、规格、时间季节。

  // 数字
private numWordRegex = "[0-9]+";  
// 符号
private String symbolWordRegex = "[\\[\\]\\{\\}【】「」\\\\\\|、｜‘'\"“”’；：;:>.。》/？\\?<《，,~`·！\\!@#\\$¥%\\^…&\\*（\\(\\)）\\-_—=\\+\\s]+";  
// 规格
private String unitRegex = "(?:\\d+|\\d+\\.\\d+|[一二三四五六七八九十百千万]+)\\s*(?:m|米|cm|厘米|ml|毫升|l|升|度|平米|件|块|元|片|张|本|条|瓶|部|辆|个|桶|包|盒|g|克|kg|千克|吨|寸|斤)";  
// 时间季节
private String seasonRegex = "[春夏秋冬]+[季天]?";  
private String yearRegex = "(?:18|19|20)\\d{2}";

基于词库可以识别产品词、品牌、产品修饰词。

  品牌：query->二级类目->品牌，条件：在当前类目品牌词库里且模型预测不是“产品词”，此时打“品牌”实体标。    
产品词：在产品词库且模型预测是普通词。   
产品修饰词：多个词出现时，除最后一个，其余打“产品修饰词”实体标。

基于模型可以识别剩余23类实体，类别如下所示：

  产品词
普通词
新词
修饰
品牌
机构实体
地点地域
材质
人名
功能功效
专有名词
影视名称
型号
文娱书文曲
系列
游戏名称
款式元素
颜色
场景
风格
营销服务
人群
时间季节

模型结构：

5.6 类目预测categoryPredict插件

样例

  输入：牛奶绒
输出: {
        "categoryId": "101000010001",
        "categoryName": "被套",
        "categoryChainList": [
            "家居建材",
            "床上用品",
            "被套"
        ],
        "parentCategoryId": "10100001",
        "level": 3,
        "hasChildren": true,
        "percent": 0.9010684490203857
    }

该插件会根据用户的搜索内容输出类目结果，主要应用在类目加权上。
例如当用户在有赞精选上输入牛奶绒，期望返回牛奶绒床单。
未使用类目加权，返回的商品大多为牛奶相关产品，不符合用户的搜索期望。
使用类目加权后，将床上用品类产品提权，返回的商品牛奶绒床单，符合用户期望。
类目预测模型是在对比学习基础上实现，具体内容可看对比学习在有赞的应用

5.7 同近义词插件

样例

  输入：[衬衣]
输出：[衬衫]

同近义词插件目前非常实现轻量，通过离线同义词表，搜索内容中的产品词作为输入，输出同义词。

六、总结与展望

本文从QP整体设计，分层设计，插件设计较为完整的介绍了QP的架构设计。目前经过一年多的迭代，QP已经实现业务场景小时级接入，优化了零售，微商城，精选，爱逛，分销等场景搜索效果。后续将会继续丰富算法插件能力同时完成QP可视化配置能力方便业务自主接入。

本文由吴鑫强，任艳萍负责收集整理。

4个步骤，小结搜索系统

Wed, 19 Dec 2018 22:04:37 CST

搜索系统作为用户自行使用的引导工具，重要程度不言而喻；本文主要从4步：需求识别、检索、排序、展现来总结搜索系统的工作机制。

搜索是一个比较有年份的功能，他不是一个简单的搜索框，毕竟搜索造就了一个百度帝国。

搜索系统在产品架构中是帮助用户搜索到他们想要的内容，当用户不知道如何通过其他路径直接获取特定内容的时候才会使用，也就是说搜索是用户自行使用最后的一个引导工具，重要程度不言而喻。

首先对搜索建立一个整体大概的认知，搜索工作机制如上图，主要分为4步：需求识别、检索、排序、展现。

一、需求识别

用户在搜索框中输入的关键词即用户想要查询的内容，首先需要机器去识别出用户想要的是什么，才能把用户想要的东西递给用户，首先介入工作就是分词系统，通过对关键词的整分词匹配或通过语义解析尽可能的了解当前用户的需求。

检索：了解用户想要什么东西了后，就去仓库里面把不同区存在的货物提取出来，准备交付。
排序：为了卖出更多的货物，会对自己的仓库定一系列的规则，如：近期要卖的优先、信誉好的供应商优先等进行排序，保证给到用户我们最好的货物。
展现：知道用户想要什么、也从仓库提取了后，按照排序规则展现给用户就可以了。

接下来落实到具体的产品方案，坚持一个底层原则：从业务中来，到业务中去。

明确本次搜素策略优化目标，围绕目标高举高打：

如：能够准确识别用户query背后对商品的需求，并根据排序规则在页面反馈结果集。

关键衡量指标：

商品需求识别准确率：已识别出的query中真正带有商品需求的query占比，越高越好；
商品需求识别召回率：已识别query中真正带有商品需求数量的query在所有带有商品需求query中占比，越高越好。

检验策略效果计算方式：

正确率 = 提取出的正确信息条数 / 提取出的信息条数
召回率 = 提取出的正确信息条数 / 样本中的信息条数

想要更好的优化方案，可以对现有的搜索关键词和模块数据进行分析，从某交易产品月上万个搜索关键词中，随机抽取了1000条搜索关键词字数分布如下图：

通过对用户输入的关键词进行分析，结论：

用户输入关键词数量：2、3、4占据总字数的80%，所以：我们需要做一个搜索联想提升用户搜索效率。
用户关键词主要分布在：品牌、商品名、品类名、其他特殊字词等，所以：我们要根据各种场景细化出不同的排序方案。
用户有较多次出现搜索为空的情况，引起这种结果有两种可能：① 搜索现有的准确率较低。 ② 现在平台商品SKU 较少。

二、用户搜索输入分析

该部分需要考虑到用户在使用搜索时有什么使用场景，在不同场景下有怎样的行为反应：

三、排序计算方式

排序是整个搜素平台最为关键的一环，此处需要权衡商家、用户、平台的综合利益考虑，如商品搜索可以将特征维度分为：商品维度、卖家维度、平台维度、个性化、反作弊等维度，通过落地到自身业务的当前状态，可得出关键参考点有：

商品名称：商品的全称匹配率。
副标题：副标题与关键词的匹配率。
销量：商品销售数据权重较高。
标签：有标签的商品比没有标签的商品权重更高，标签排名：促销（满减、N元任选）>秒杀>包邮 >其他。
权重参考值排序：商品名称 > 副标题 > 销量 > 标签

四、展现

最后根据用户搜索不同的关键词，使用特定的排序方案，输入机器得出的结果集：

本文由 @World 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。

Google 发布了一个全新的搜索引擎和两个文字游戏

Sun, 15 Apr 2018 18:25:13 CST

为了让你体验人工智能在语义理解和自然语言处理有多强大，Google 近日发布了一个新的搜索引擎，以及两个“文字游戏”。

在 Google 新发布的语义体验网站“ Semantic Experience”里，有一个全新的书籍搜索“Talk to Books”，以及基于机器学习的单词关联游戏。

相比平常我们搜索一本书，主要是通过书名、作者等关键词进行检索，在 Talk to Books 里，我们可以像平常讲话一样输入一句话，随后搜索引擎就会对这句话进行解读和预判，从而给出搜索结果。

也就是说，你可以用“聊天”的方式找到你想要的书籍。

我在搜索框输入了一个问题：

What is the best programming language？（什么是最好的编程语言？）

排在第一位的搜索结果，是一本用 C 语言编程的书籍，《C Programming for Arduino 》，作者是 Julien Bayle。这本书里有这样一句话，在搜索结果中被加粗：

There is no scientific or universal way to define what is the absolute best style of programming. （目前没有一个科学的或者广义的方式去定义什么是绝对好的编程方式。）

在搜索结果中，能够回答这个问题的句子或者段落被加粗显示，下方还有作者及书籍的信息。给我的体验就是，我们用聊天的方式向 Talk to Books 提问，然后它用搜索结果告诉你，这本书里的这段话，可以回答你的问题，这些或许就是你想要找的书。

在另一个名为“SEMANTRIS”的页面中，有两个基于机器学习的单词游戏 Arcade 和 Blocks。

（Arcade ）

玩 Arcade 时，需要在一定时间内输入与某个目标词语最相关的单词、短语或者句子，越相关得分越高，同时目标词语会下移。

（Blocks）

Blocks 则像是无时间限制的消消乐游戏。输入某个单词、短语或者句子后，游戏会自动判断页面上的哪个单词与之最相关，然后这个单词所在的方块，以及相邻同色的方块就会被消除。每一次消除都会有新的方块掉下来，方块堆积到达顶部，游戏结束。

“Semantic Experience”这个项目呈现的是机器学习中“词向量”的技术，这项技术能让机器更快、更准确地去理解人类的语言。目前 Google 已经在自己家的人工智能开源软件库 TensorFlow 上开源了一个预训练语义的模块，开发者可以使用自己的词汇或语句进行实验，训练自己的模型。

沈星佑

太阳底下全是新鲜事 | 工作邮箱：shenxingyou@ifanr.com

邮箱 3

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

一个完整推荐系统的设计实现-以百度关键词搜索推荐为例

Wed, 17 Sep 2014 22:42:45 CST

在之前一篇博文中，有同学在评论中问了个问题：如何解决因式分解带来的推荐冷门，热门关键词的问题。在回答这个问题的时候，想到了近几年在做搜索推荐系统的过程中，学术界和工业界的一些区别。正好最近正在做技术规划，于是写偏文章说下工业界完整推荐系统的设计。 结论是：没有某种算法能够完全解决问题，多重算法+交互设计，才能解决特定场景的需求。下文也对之前的一些博文进行梳理，构成一个完整工业界推荐系统所具有的方方面面（主要以百度关键词搜索推荐系统为例）

完整的推荐系统肯定不会只用一种推荐算法

在学术界，一般说到推荐引擎，我们都是围绕着某一种单独的算法的效果优化进行的，例如按内容推荐，协同过滤（包括item-based, user-based, SVD分解等），上下文推荐，Constraint-based推荐，图关系挖掘等。很多比较牛的单个算法，就能在某个指标上取得较好效果，例如MAE，RMSE。。。不过有自己的优点，每种算法也有自己的缺点，例如按内容推荐主要推荐和用户历史结果相似的item，一般的item-based容易推荐热门item（被更多人投票过）。。。。所以在工业界，例如各互联网公司，都会使用多种算法进行互相配合，取长补短，配合产品提升效果。而且 在完整的推荐系统中，不仅有传统的Rating推荐，还需要辅以非常多的挖掘， Ranking来达到预期效果。

推荐系统3大件：User Profile、基础挖掘推荐、Ranking

在实践中，一个完整的推荐系统会主要由3部分组成：

User Profile
基础推荐挖掘算法
Ranking

此处之所以将Ranking单独列出来，是因为其在推荐任务中过于重要，直接决定了推荐的效果。

以下为整个推荐的数据流：

User Profile

A user profile is a representation of information about an individual user that is essential for the (intelligent) application we are considering user profile主要是用户（注册）信息，以及对用户反馈的信息进行处理，聚合，用于描述用户的特征；是后续推荐和排序的基石。一般情况下，user profile会包含以下具体内容：

用户兴趣数据
用户的基础注册信息，背景信息：例如用户出生地，年龄，性别，星座，职业等。这些信息一般从用户注册信息中获取；例如高德，百度地图注册用户，淘宝注册用户等
用户行为反馈：包括显示的反馈(explicit)和隐藏(implicit)的反馈，显示的反馈包括用户的评分，点赞等操作，百度关键词搜索推荐工具上的点赞（正向显示反馈）和垃圾桶（负向显示反馈），淘宝上的评分；隐式反馈包括用户的浏览行为，例如在百度关键词搜索推荐上搜过那些词，淘宝上点击了那些页面，在高德上点击了那些POI等
用户交互偏好：例如用户喜欢使用哪些入口，喜欢哪些操作，以及从这些操作中分析出来的偏好，比如在高德地图上根据用户行为反馈分析出来的用户对美食的偏好：更喜欢火锅，粤菜，还是快餐
用户上下文信息：这些信息有些是分析出来的，例如在LBS中分析出来的用户的家在哪儿，公司在哪儿，经常活动的商圈，经常使用的路线等

user profile经常是一份维护好的数据，在使用的时候，会直接使用该数据，或是将该数据存储在KV系统中，供Online系统实时使用。在搜索或是推荐的场景下，每次请求一般只会涉及到一次user profile的KV请求，所以online使用的时候，主要的实现困难是存储，以及快速KV的快速响应。

基础挖掘推荐算法

基础挖掘推荐算法，主要使用传统推荐算法，结合分析的item profile和user profile，建立user和item的关系，此时并不会过多考虑其他因素，例如是否冷门/热门，最主要的就是建立user和item的关系。在各种论文中狭义的推荐，主要就是指该部分内容。主要围绕着Rating，以及Top N进行该处的Top N（更像是直接Rating值最高的Top N）传统的推荐算法研究主要围着这块工作进行，现在已经有很多比较成熟的算法，这些算法相关的研究可参见博文：《推荐系统经典论文文献及资料》；其中也能找到业界较多成功推荐系统的实践分享主要包含以下几类：

Content Based推荐：按内容推荐，主要的工作是user profile, item profile的提取和维护，然后研究各种相似度度量方法（具体相似度度量参见博文：《推荐系统中的相似度度量》）
协同过滤：相当于应用了用户的行为进行推荐（区别于Content based算法），比较经典的算法包括传统的item-based/user-based算法（参见博文：《协同过滤中item-based与user-based选择依据》，《 collaborative-filtering根据近邻推荐时需要考虑的3要素》），SVD，SVD++(具体原理及源码参见博文：《 SVD因式分解实现协同过滤-及源码实现》)
上下文相关推荐：和传统推荐相比，考虑更多上下文因素，LBS，移动场景下使用比较多（具体参见博文：《 context-aware-recommendation》）
基于图的关系挖掘推荐：主要是利用图论原理，根据item,user之间的数据，反馈关联关系，挖掘更深层次的关系进行推荐，该类方法一般效果都不错，当然资源要求也较高。具体参见博文：《级联二步图关系挖掘关键词推荐系统》，《频繁二项集合的hadoop实现》《 itemrankrandom-walk-based-scoring-algorithm-for-recommener-system》
Constrainted-based推荐：根据限制性条件进行演绎推荐

在实际应用时，我们经常使用按内容推荐，item-based寻找从感知的角度比较靠谱的结果，使用SVD,SVD++，图关系寻找更深层次的联系结果。同时在推荐时，会结合很多因素来进行综合排序，例如关键词，或是LBS中POI的热度等。具体可参见下文ranking部分。

算法效果衡量

以上这些算法，我们在离线的时候，使用Cross-Validation方式，就可以分析出其效果，而且离线分析的时候，代价比较小，比较容易操作。当然，对于不同的问题会使用对应的指标进行衡量。对于预测Rating准确性主要是用RMSE，或是MAE；具体可参见博文：《关键词搜索推荐系统中的推荐准确性度量》如果是排序，则更多使用NDCG，MAP, MRR等指标；具体可参见博文：《使用ndcg评估关键词推荐系统的相关性》在具体应用场景中，对于特定推荐问题，会涉及到选用哪种算法的问题。推荐不像CTR预估这样的问题，目标比较单一，经常我们需要考虑多个指标，而且这些指标可能此消彼长，需要做权衡，例如需要考虑算法的准确性(accuracy)，同时也需要考虑算法的覆盖(coverage)，置信度（confidence）,新鲜度(novelty)和惊喜度(Serendipity)，同时还需要考虑推荐为系统带来的收益和效用(utility)。这些指标经常需要权衡，而且经常提升某一个的时候会导致其它下降，所以有时候存在一定的主观性：我们到底看中哪一个指标？而且这个问题可能随着系统，平台所处的阶段而不同。例如在建立口碑的时候，我们可能不太关注coverage，而更关注accuracy，因为要让用户建立一种：该系统很准的认知；如果在系统已经比较成熟了，此时可能需要考虑novelty, serendipity的同时，还需要考虑utility：该推荐能为系统带来什么收益，例如对百度的变现有多大收益？对淘宝的销售有多少收益等具体这些指标的选择可参见博文：《选择推荐算法时需要考虑得因素》

Ranking，此部分是成熟的搜索，推荐系统具有的核心逻辑

比较简单的实现方法，是直接对各种特征拍阈值进行线性加权，比较成熟的系统一般会使用机器学习的方式和综合个维特征，学习出模型后进行排序，例如使用Learning to rank技术。该部分需要考虑的因素较多较为复杂。和传统的推荐相比，此处单独将Ranking拿出来。基础推荐挖掘，和传统的推荐部分比较类似，主要结合user profile，挖掘哪些item适合推给哪些user。但仅根据这些挖掘就直接进行推荐是不够的。真实online推荐场景中，需要考虑更多其他因素，例如：相关性，推荐的上下文，CTR预估，以及商业业务规则。

相关性： item与用户的相关性，这是大多数搜索和推荐任务的基石，例如在搜索中判定一个query和一个document的相关性，或是一个query 和另一个query的相关性，或是在特征比较多的情况下，一个user 和一个item 记录的相关性；实现方式可以很简单，例如传统的相似度度量方式（参见博文：《推荐系统中的相似度度量》），对于文本，业界使用简单的TF*IDF，或是BM25；不过很多时候我们需要增加更多维度特征，包括推荐item本身的重要性，例如IDF，Pagerank(具体参见博文：《 pagerank的经济学效用解释》)，同时使用模型来提升相关性判断的准确性。使用模型的方式会更加复杂，但效果提升也非常明显。具体可参见博文：《集成树类模型及其在搜索推荐系统中的应用》，《分类模型在关键词推荐系统中的应用》，《 adaboost》
推荐的上下文：例如推荐产品的入口，交互方式，不同的入口，甚至同一入口的不同交互方式，推荐的结果有可能都需要不一样；在LBS生活服务中，请求发生的时间，地点也是推荐需要重点考虑的上下文因素，例如饭点对餐饮item的提权；异地情况下对酒店等结果的加权等
CTR预估：成熟的商业系统都会使用模型来完成CTR预估，或是转化预估
以及商业业务规则：例如黑白名单，或者强制调权。例如在百度关键词搜索推荐中，某些有比较高变现潜力的词，就应该加权往前排；比如在高德LBS服务中，有些海底捞的店点评评分较低，但我们也应该往前排；或是在搜索引擎中，搜国家领导人的名字，有些最相关的结果可能因为法律因素是需要屏蔽的

算法评估

很直接，离线调研的时候看就看算法的评估指标，参见博文：《关键词搜索推荐系统中的推荐准确性度量》，《使用ndcg评估关键词推荐系统的相关性》上线的时候，进行圈用户（圈定某两个user集合作为实验/对照用户组）实验，或者圈请求实验（例如随机圈定5%流量进行实验），之后根据系统效果监控中的指标值判断实验效果。以下为一个典型的效果监控截图：实验如果证明成功，达到预期效果，一般之后推广到全流量；反之，如果实验未达到预期效果，则需要分析什么地方有问题，如何改进，之后继续调整算法继续实验。当实验较多时，还会涉及较多工程问题，例如分层实验框架等。

系统效果监控

对于整个系统，需要建立晚上的效果监控平台进行效果的实时监控，以便发现用户的行为模型，系统的不足，分析后续的发力点等。一般这样的监控平台会使用Dashboard来完成，基本的框架是前段UI + 后端数据库。很多时候，离线统计策略在hadoop上处理统计日志计算指标，并将计算出来的指标存入数据库，前端UI访问数据库，拉出指定时间段内某些指标的值，并进行简单分析。具体的监控指标，及指标体系的建立，可参见博文：《搜索引擎变现策略指标体系》

交互设计

完整的产品包括便捷的交互和背后牛叉的算法。很多时候，要提升推荐的效果，需要算法和交互配合，才能达到理想的效果：交互需要有健壮的算法产出结果；而算法也需要有配套的交互，才能达到预期效果，否则再牛叉的算法，对结果的影响也可能没那么明显。

一些交互的例子参见博文：

《关键词推荐工具中的用户引导机制之一：总述》

《关键词推荐工具中的用户引导机制之二：suggestion架构》

《关键词推荐工具中的用户引导机制之三：相关搜索query技术》

《关键词推荐工具中的用户引导机制之四：种子query推荐》

说了那么多，中心就是想说明，一个完整的推荐系统，远远不止是一两个rating算法能够覆盖的，而且此处还未涉及工程部分。

更多内容，也可直接访问： http://semocean.com

关键词推荐工具中的用户引导机制

Tue, 05 Nov 2013 11:54:32 CST

搜索引擎根据网民输入的检索词(query)猜测网民需要的信息，之后进行检索，排序后将相关的信息展现给网民。因为网名输入的query一般都较短，而且不同的网民使用搜索引擎的能力也不一样。所以一般搜索引擎都会有些查询引导机制，在猜测用户可能的意图后，推荐一些相关且高质量的种子query给网民。例如在百度搜索框搜索‘关键词工具’，在搜索结果的最下方，出现以下相关搜索结果：

这些相关搜索结果均是根据网民搜索session和网民搜索点击结果挖掘而来（因可能涉及泄密，百度的具体实现此处就不再介绍，后续会有博文介绍业界相关相关搜索结果的论文），这些（推荐）query一方面从搜索意图上和网民的搜索意图匹配，一方面和也能够达到引流的作用，例如能够快速引导网民找到需要的内容，或者考虑商业变现因素，能够将搜索引导向与搜索意图匹配且有商业价值的搜索上，提升搜索引擎的变现效率。

而作为完整的关键词推荐工具，不仅要能主动分析推荐结果给客户（关键词工具的用户为搜索引擎的商业客户，及广告投放客户），在用户输入种子query后展现相关结果给客户，还需要在客户操作的每一步，对客户的行为进行提示和引导。

关键词工具引导机制的功能

关键词推荐工具不仅能根据用户历史行为主动向用户push相关关键词，同时提供搜索功能，供用户输入种子query后推荐出相关的关键词。此时就会面临和搜索引擎一样的问题，用户输入query的质量，将会直接决定推荐结果的好坏，所以关键词推荐系统需要有完善的引导机制，提升用户输入query的质量，以便提升整体的推荐质量。

上图为KR关键词推荐工具

引导机制的类型及简单实现思路

一般说来，根据用户使用关键词工具的交互操作，按照交互阶段，可以将引导机制分为以下三类：

查询前：在用户进入关键词工具时，还未有任何交互时，此时关键词推荐系统主动向用户push用户可能感兴趣的种子query；具体实现时，可以根据客户历史上采纳的搜索引擎拍卖词（即客户采纳的符合客户客户推广意图的关键词）分析出客户的推广意图或业务点，使用传统推荐算法（content-based 或 collaborative 推荐算法）找出客户可能感兴趣的种子query进行推荐。该场景更偏推荐问题
查询中：即用户已经开始在关键词工具搜索框中进行输入，但输入还未完成的阶段。此时最常采用的方式是使用suggesion的方式，结合客户当前输入，向用户推荐完整的高质量query；具体suggesion挖掘，可以找到一些高频的query，结合session数据，搜索点击数据进行挖掘（百度suggesion具体的算法此处涉及泄密不再介绍，后续会有文章介绍业界公开的suggesion方法）
查询后：当客户完成一次搜索后，客户搜索的内容已经基本明确，此时就可以根据这次用户的搜索意图，找到相关的更高质量的query，以类似于搜索引擎相关搜索的方式推荐给客户。

引导机制在整个系统中的地位

引导机制无论是在搜索引擎中，或是关键词推荐系统中，都是必不可少的功能环节，能够带来以下收益：

推荐给客户能有多而好的检索结果的种子词，并逐步进行优化，提升用户体验，提高客户提词量；对于搜索引擎而言是优化输入query。
降低未曾使用过KR的客户的使用门槛，让KR的使用更为简单便利，扩大关键词工具的市场占有率；对于搜索引擎而言，也能够快速提升其他用户经常搜索的相同/类似意图的query给网民，提升搜索量。
通过种子词引导客户对账户关键词的优化，提高客户的ROI，提升百度收益，达到双赢目的。对搜索引擎而言则是能将搜索引导至相同/类似意图的搜索上，提升搜索引擎的变现效率。

如对以上功能感兴趣，各位可以在www2.baidu.com上注册一个凤巢帐号（无需缴费），在百度凤巢系统中的关键词工具中试用上述功能。

更多内容参见：

百度凤巢系统： www2.baidu.com

百度关键词工具介绍参见： http://support.baidu.com/product/fc/4.html?castk=24b18bi7062c720d0d596

suggestion的一种实现方法： Cao, Huanhuan, et al. 2008. Context-Aware Query Suggestion by Mining Click-Through and Session Data. Proceedings of the 14th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. 2008, 875-883.

也可关注我的微博： weibo.com/dustinsea

或是直接访问： http://semocean.com

基于Elasticsearch实现搜索建议

Mon, 23 Jan 2017 17:14:44 CST

搜索建议是搜索的一个重要组成部分，一个搜索建议的实现通常需要考虑建议词的来源、匹配、排序、聚合、关联的文档数和拼写纠错等，本文介绍一个基于Elasticsearch实现的搜索建议。

问题描述

电商网站的搜索是最基础最重要的功能之一，搜索框上面的良好体验能为电商带来更高的收益，我们先来看看淘宝、京东、亚马逊网站的搜索建议。

在淘宝的搜索框输入【卫衣】时，下方的搜索建议包括建议词以及相关的标签：

在京东的搜索框输入【卫衣】时，下方搜索建议右方显示建议词关联的商品数量：

在亚马逊的搜索框输入【卫衣】时，搜索建议上部分能支持在特定的分类下进行搜索：

通过上述对比可以看出，不同的电商对于搜索建议的侧重点略有不同，但核心的问题包括：

匹配：能够通过用户的输入进行前缀匹配；
排序：根据建议词的优先级进行排序；
聚合：能够根据建议词关联的商品进行聚合，比如聚合分类、聚合标签等；
纠错：能够对用户的输入进行拼写纠错；

搜索建议实现

在我们的搜索建议实现里，主要考虑了建议词的来源、匹配、排序、关联的商品数量和拼写纠错。

SuggestionDiscovery

SuggestionDiscovery的职责是发现建议词；
建议词的来源可以是商品的分类名称、品牌名称、商品标签、商品名称的高频词、热搜词，也可以是一些组合词，比如“分类 + 性别”和“分类 + 标签”，还可以是一些自定义添加的词；
建议词维护的时候需要考虑去重，比如“卫衣男”和“卫衣男”应该是相同的，“Nike”和“nike”也应该是相同的；
由于建议词的来源通常比较稳定，所以执行的周期可以比较长一点，比如每周一次；

SuggestionCounter

SuggestionCounter的职责是获取建议词关联的商品数量，如果需要可以进行一些聚合操作，比如聚合分类和标签；
SuggestionCounter的实现的时候由于要真正地调用搜索接口，应该尽量避免对用户搜索的影响，比如在凌晨执行并且使用单线程调用；
为了提升效率，应该使用Elasticsearch的Multi Search接口批量进行count，同时批量更新数据库里建议词的count值；
由于SuggestionCounter是比较耗资源的，可以考虑延长执行的周期，但是这可能会带来count值与实际搜索时误差较大的问题，这个需要根据实际情况考虑；

SuggestionIndexRebuiler

SuggestionIndexRebuiler的职责是负责重建索引；
考虑到用户的搜索习惯，可以使用 Multi-fields来给建议词增加多个分析器。比如对于【卫衣套头】的建议词使用Multi-fields增加不分词字段、拼音分词字段、拼音首字母分词字段、IK分词字段，这样输入【weiyi】和【套头】都可以匹配到该建议词；
重建索引时通过是通过bulk批量添加到临时索引中，然后通过别名来更新；
重建索引的数据依赖于SuggestionCounter，因此其执行的周期应该与SuggestionCounter保持一致；

SuggestionService

SuggestionService是真正处于用户搜索建议的服务类；
通常的实现是先到缓存中查询是否能匹配到缓存记录，如果能匹配到则直接返回；否则的话调用Elasticsearch的 Prefix Query进行搜索，由于我们在重建索引的时候定义了Multi-fields，在搜索的时候应该用boolQuery来处理；如果此时Elasticsearch返回不为空的结果数据，那么加入缓存并返回即可；

  POST /suggestion/_search
{
  "from" : 0,
  "size" : 10,
  "query" : {
    "bool" : {
      "must" : {
        "bool" : {
          "should" : [ {
            "prefix" : {
              "keyword" : "卫衣"
            }
          }, {
            "prefix" : {
              "keyword.keyword_ik" : "卫衣"
            }
          }, {
            "prefix" : {
              "keyword.keyword_pinyin" : "卫衣"
            }
          }, {
            "prefix" : {
              "keyword.keyword_first_py" : "卫衣"
            }
          } ]
        }
      },
      "filter" : {
        "range" : {
          "count" : {
            "from" : 5,
            "to" : null,
            "include_lower" : true,
            "include_upper" : true
          }
        }
      }
    }
  },
  "sort" : [ {
    "weight" : {
      "order" : "desc"
    }
  }, {
    "count" : {
      "order" : "desc"
    }
  } ]
}

如果Elasticsearch返回的是空结果，此时应该需要增加拼写纠错的处理（拼写纠错也可以在调用Elasticsearch搜索的时候带上，但是通常情况下用户并没有拼写错误，所以建议还是在后面单独调用suggester）；如果返回的suggest不为空，则根据新的词调用建议词服务；比如用户输入了【adidss】，调用Elasticsearch的suggester获取到的结果是【adidas】，则再根据adidas进行搜索建议词处理。

  POST /suggestion/_search
{
  "size" : 0,
  "suggest" : {
    "keyword_suggestion" : {
      "text" : "adidss",
      "term" : {
        "field" : "keyword",
        "size" : 1
      }
    }
  }
}

关于排序：在我们的实现里面是通过weight和count进行排序的，weight目前只考虑了建议词的类型（比如分类 > 品牌 > 标签）；

实现效果和后续改进

通过上面的实现，我们已经能实现一个比较强大的搜索建议词了，实际的效果如下所示：

后续可以考虑的改进：参考亚马逊增加分类的聚合展示、增加用户个性化的处理支持更好的建议词排序、基于用户的搜索历史支持更好的建议词推荐；

参考资料

基于Elasticsearch实现搜索推荐

Tue, 21 Mar 2017 17:18:39 CST

在基于Elasticsearch实现搜索建议一文中我们曾经介绍过如何基于Elasticsearch来实现搜索建议，而本文是在此基础上进一步优化搜索体验，在当搜索无结果或结果过少时提供推荐搜索词给用户。

背景介绍

在根据用户输入和筛选条件进行搜索后，有时返回的是无结果或者结果很少的情况，为了提升用户搜索体验，需要能够给用户推荐一些相关的搜索词，比如用户搜索【迪奥】时没有找到相关的商品，可以推荐搜索【香水】、【眼镜】等关键词。

设计思路

首先需要分析搜索无结果或者结果过少可能的原因，我总结了一下，主要包括主要可能：

搜索的关键词在本网不存在，比如【迪奥】；
搜索的关键词在本网的商品很少，比如【科比】；
搜索的关键词拼写有问题，比如把【阿迪达斯】写成了【阿迪大斯】；
搜索的关键词过多，由于我们采用的是cross_fields，在一个商品内不可能包含所有的Term，导致无结果，比如【阿迪达斯耐克卫衣运动鞋】；

那么针对以上情况，可以采用以下方式进行处理：

搜索的关键词在本网不存在，可以通过爬虫的方式获取相关知识，然后根据 搜索建议词去提取，比如去百度百科的迪奥词条里就能提取出【香水】、【香氛】和【眼镜】等关键词；当然基于爬虫的知识可能存在偏差，此时需要能够有人工审核或人工更正的部分；
搜索的关键词在本网的商品很少，有两种解决思路，一种是通过方式1的爬虫去提取关键词，另外一种是通过返回商品的信息去聚合出关键词，如品牌、品类、风格、标签等，这里我们采用的是后者（在测试后发现后者效果更佳）；
搜索的关键词拼写有问题，这就需要 拼写纠错出场了，先纠错然后根据纠错后的词去提供搜索推荐；
搜索的关键词过多，有两种解决思路，一种是识别关键词的类型，如是品牌、品类、风格还是性别，然后通过一定的组合策略来实现搜索推荐；另外一种则是根据用户的输入到搜索建议词里去匹配，设置最小匹配为一个匹配到一个Term即可，这种方式实现比较简单而且效果也不错，所以我们采用的是后者。

所以，我们在实现搜索推荐的核心是之前讲到的搜索建议词，它提供了本网主要的关键词，另外一个很重要的是它本身包含了 关联商品数的属性，这样就可以保证推荐给用户的关键词是可以搜索出结果的。

实现细节

整体设计

整体设计框架如下图所示：

搜索建议词索引

在基于Elasticsearch实现搜索建议一文已有说明，请移步阅读。此次增加了一个keyword.keyword_lowercase的字段用于拼写纠错，这里列取相关字段的索引：

  PUT /suggest_index
{
  "mappings": {
    "suggest": {
      "properties": {
        "keyword": {
          "fields": {
            "keyword": {
              "type": "string",
              "index": "not_analyzed"
            },
            "keyword_lowercase": {
              "type": "string",
              "analyzer": "lowercase_keyword"
            },
            "keyword_ik": {
              "type": "string",
              "analyzer": "ik_smart"
            },
            "keyword_pinyin": {
              "type": "string",
              "analyzer": "pinyin_analyzer"
            },
            "keyword_first_py": {
              "type": "string",
              "analyzer": "pinyin_first_letter_keyword_analyzer"
            }
          },
          "type": "multi_field"
        },
        "type": {
          "type": "long"
        },
        "weight": {
          "type": "long"
        },
        "count": {
          "type": "long"
        }
      }
    }
  }
}

商品数据索引

这里只列取相关字段的mapping：

  PUT /product_index
{
  "mappings": {
    "product": {
      "properties": {
        "productSkn": {
          "type": "long"
        },
        "productName": {
          "type": "string",
          "analyzer": "ik_smart"
        },
        "brandName": {
          "type": "string",
          "analyzer": "ik_smart"
        },
        "sortName": {
          "type": "string",
          "analyzer": "ik_smart"
        },
        "style": {
          "type": "string",
          "analyzer": "ik_smart"
        }
      }
    }
  }
}

关键词映射索引

主要就是source和dest直接的映射关系。

  PUT /conversion_index
{
  "mappings": {
    "conversion": {
      "properties": {
        "source": {
          "type": "string",
          "analyzer": "lowercase_keyword"
        },
        "dest": {
          "type": "string",
          "index": "not_analyzed"
        }
      }
    }
  }
}

爬虫数据爬取

在实现的时候，我们主要是爬取了百度百科上面的词条，在实际的实现中又分为了全量爬虫和增加爬虫。

全量爬虫

全量爬虫我这边是从网上下载了一份他人汇总的词条URL资源，里面根据一级分类包含多个目录，每个目录又根据二级分类包含多个词条，每一行的内容的格式如下：

  李宁!http://baike.baidu.com/view/10670.html?fromTaglist
diesel!http://baike.baidu.com/view/394305.html?fromTaglist
ONLY!http://baike.baidu.com/view/92541.html?fromTaglist
lotto!http://baike.baidu.com/view/907709.html?fromTaglist

这样在启动的时候我们就可以使用多线程甚至分布式的方式爬虫自己感兴趣的词条内容作为初始化数据保持到爬虫数据表。为了保证幂等性，如果再次全量爬取时就需要排除掉数据库里已有的词条。

增量爬虫

在商品搜索接口中，如果搜索某个关键词关联的商品数为0或小于一定的阈值（如20条），就通过Redis的ZSet进行按天统计；
统计的时候是区分搜索无结果和结果过少两个Key的，因为两种情况实际上是有所区别的，而且后续在搜索推荐查询时也有用到这个统计结果；
增量爬虫是每天凌晨运行，根据前一天统计的关键词进行爬取，爬取前需要排除掉已经爬过的关键词和黑名单中的关键词；
所谓黑名单的数据包含两种：一种是每天增量爬虫失败的关键字（一般会重试几次，确保失败后加入黑名单），一种是人工维护的确定不需要爬虫的关键词；

爬虫数据关键词提取

首先需要明确关键词的范围，这里我们采用的是suggest中类型为品牌、品类、风格、款式的词作为关键词；
关键词提取的核心步骤就是对爬虫内容和关键词分别分词，然后进行分词匹配，看该爬虫数据是否包含关键词的所有Term（如果就是一个Term就直接判断包含就好了）；在处理的时候还可以对匹配到关键词的次数进行排序，最终的结果就是一个key-value的映射，如{迪奥 -> [香水,香氛,时装,眼镜], 纪梵希 -> [香水,时装,彩妆,配饰,礼服]}；

管理关键词映射

由于爬虫数据提取的关键词是和词条的内容相关联的，因此很有可能提取的关键词效果不大好，因此就需要人工管理；
管理动作主要是包括添加、修改和置失效关键词映射，然后增量地更新到conversion_index索引中；

搜索推荐服务的实现

首先如果对搜索推荐的入口进行判断，一些非法的情况不进行推荐（比如关键词太短或太长），另外由于搜索推荐并非核心功能，可以增加一个全局动态参数来控制是否进行搜索推荐；
在 设计思路里面我们分析过可能有4中场景需要搜索推荐，如何高效、快速地找到具体的场景从而减少不必要的查询判断是推荐服务实现的关键；这个在设计的时候就需要综合权衡，我们通过一段时间的观察后，目前采用的逻辑的伪代码如下：

     public JSONObject recommend(SearchResult searchResult, String queryWord) {
         try {
             String keywordsToSearch = queryWord;
     
             // 搜索推荐分两部分
             // 1) 第一部分是最常见的情况，包括有结果、根据SKN搜索、关键词未出现在空结果Redis ZSet里
             if (containsProductInSearchResult(searchResult)) {
                 // 1.1） 搜索有结果的 优先从搜索结果聚合出品牌等关键词进行查询
                 String aggKeywords = aggKeywordsByProductList(searchResult);
                 keywordsToSearch = queryWord + " " + aggKeywords;
             } else if (isQuerySkn(queryWord)) {
                 // 1.2） 如果是查询SKN 没有查询到的 后续的逻辑也无法推荐 所以直接到ES里去获取关键词
                 keywordsToSearch = aggKeywordsBySkns(queryWord);
                 if (StringUtils.isEmpty(keywordsToSearch)) {
                     return defaultSuggestRecommendation();
                 }
             }
     
             Double count = searchKeyWordService.getKeywordCount(RedisKeys.SEARCH_KEYWORDS_EMPTY, queryWord);
             if (count == null || queryWord.length() >= 5) {
                 // 1.3) 如果该关键词一次都没有出现在空结果列表或者长度大于5 则该词很有可能是可以搜索出结果的
                 //      因此优先取suggest_index去搜索一把 减少后面的查询动作
                 JSONObject recommendResult = recommendBySuggestIndex(queryWord, keywordsToSearch, false);
                 if (isNotEmptyResult(recommendResult)) {
                     return recommendResult;
                 }
             }
     
             // 2) 第二部分是通过Conversion和拼写纠错去获取关键词 由于很多品牌的拼写可能比较相近 因此先走Conversion然后再拼写检查
             String spellingCorrentWord = null, dest = null;
             if (allowGetingDest(queryWord) && StringUtils.isNotEmpty((dest = getSuggestConversionDestBySource(queryWord)))) {
                 // 2.1) 爬虫和自定义的Conversion处理
                 keywordsToSearch = dest;
             } else if (allowSpellingCorrent(queryWord) 
     		         && StringUtils.isNotEmpty((spellingCorrentWord = suggestService.getSpellingCorrectKeyword(queryWord)))) {
                 // 2.2) 执行拼写检查 由于在搜索建议的时候会进行拼写检查 所以缓存命中率高
                 keywordsToSearch = spellingCorrentWord;
             } else {
                 // 2.3) 如果两者都没有 则直接返回
                 return defaultSuggestRecommendation();
             }
     
             JSONObject recommendResult = recommendBySuggestIndex(queryWord, keywordsToSearch, dest != null);
             return isNotEmptyResult(recommendResult) ? recommendResult : defaultSuggestRecommendation();
         } catch (Exception e) {
             logger.error("[func=recommend][queryWord=" + queryWord + "]", e);
             return defaultSuggestRecommendation();
         }
     }

其中涉及到的几个函数简单说明下：

aggKeywordsByProductList方法用商品列表的结果，聚合出出现次数最多的几个品牌和品类（比如各2个），这样我们就可以得到4个关键词，和原先用户的输入拼接后调用recommendBySuggestIndex获取推荐词；
aggKeywordsBySkns方法是根据用户输入的SKN先到product_index索引获取商品列表，然后再调用aggKeywordsByProductList去获取品牌和品类的关键词列表；
getSuggestConversionDestBySource方法是查询conversion_index索引去获取关键词提取的结果，这里在调用recommendBySuggestIndex时有个参数，该参数主要是用于处理是否限制只能是输入的关键词；
getSpellingCorrectKeyword方法为拼写检查，在调用suggest_index处理时有个地方需要注意一下，拼写检查是基于编辑距离的，大小写不一致的情况会导致Elasticsearch Suggester无法得到正确的拼写建议，因此在处理时需要两边都转换为小写后进行拼写检查；
最终都需要调用recommendBySuggestIndex方法获取搜索推荐，因为通过suggest_index索引可以确保推荐出去的词是有意义的且关联到商品的。该方法核心逻辑的伪代码如下：

     private JSONObject recommendBySuggestIndex(String srcQueryWord, String keywordsToSearch, boolean isLimitKeywords) {
         // 1) 先对keywordsToSearch进行分词
         List<String> terms = null;
         if (isLimitKeywords) {
             terms = Arrays.stream(keywordsToSearch.split(",")).filter(term -> term != null && term.length() > 1)
                           .distinct().collect(Collectors.toList());
         } else {
             terms = searchAnalyzeService.getAnalyzeTerms(keywordsToSearch, "ik_smart");
         }
     
         if (CollectionUtils.isEmpty(terms)) {
             return new JSONObject();
         }
     
         // 2) 根据terms搜索构造搜索请求
         SearchParam searchParam = new SearchParam();
         searchParam.setPage(1);
         searchParam.setSize(3);
     
         // 2.1) 构建FunctionScoreQueryBuilder
         QueryBuilder queryBuilder = isLimitKeywords ? buildQueryBuilderByLimit(terms)
                                       : buildQueryBuilder(keywordsToSearch, terms);
         searchParam.setQuery(queryBuilder);
         
         // 2.2) 设置过滤条件
         BoolQueryBuilder boolFilter = QueryBuilders.boolQuery();
         boolFilter.must(QueryBuilders.rangeQuery("count").gte(20));
         boolFilter.mustNot(QueryBuilders.termQuery("keyword.keyword_lowercase", srcQueryWord.toLowerCase()));
         if (isLimitKeywords) {
             boolFilter.must(QueryBuilders.termsQuery("keyword.keyword_lowercase", terms.stream()
                 .map(String::toLowerCase).collect(Collectors.toList())));
         }
         searchParam.setFiter(boolFilter);
     
         // 2.3) 按照得分、权重、数量的规则降序排序
         List<SortBuilder> sortBuilders = new ArrayList<>(3);
         sortBuilders.add(SortBuilders.fieldSort("_score").order(SortOrder.DESC));
         sortBuilders.add(SortBuilders.fieldSort("weight").order(SortOrder.DESC));
         sortBuilders.add(SortBuilders.fieldSort("count").order(SortOrder.DESC));
         searchParam.setSortBuilders(sortBuilders);
     
         // 4) 先从缓存中获取
         final String indexName = SearchConstants.INDEX_NAME_SUGGEST;
         JSONObject suggestResult = searchCacheService.getJSONObjectFromCache(indexName, searchParam);
         if (suggestResult != null) {
             return suggestResult;
         }
     
         // 5) 调用ES执行搜索
         SearchResult searchResult = searchCommonService.doSearch(indexName, searchParam);
     
         // 6) 构建结果加入缓存
         suggestResult = new JSONObject();
         List<String> resultTerms = searchResult.getResultList().stream()
                 .map(map -> (String) map.get("keyword")).collect(Collectors.toList());
         suggestResult.put("search_recommendation", resultTerms);
         searchCacheService.addJSONObjectToCache(indexName, searchParam, suggestResult);
         return suggestResult;
     }
     
     private QueryBuilder buildQueryBuilderByLimit(List<String> terms) {
         FunctionScoreQueryBuilder functionScoreQueryBuilder
             = new FunctionScoreQueryBuilder(QueryBuilders.matchAllQuery());
     
         // 给品类类型的关键词加分
         functionScoreQueryBuilder.add(QueryBuilders.termQuery("type", Integer.valueOf(2)),
             ScoreFunctionBuilders.weightFactorFunction(3));
     
         // 按词出现的顺序加分
         for (int i = 0; i < terms.size(); i++) {
             functionScoreQueryBuilder.add(QueryBuilders.termQuery("keyword.keyword_lowercase", 
        terms.get(i).toLowerCase()),
                 ScoreFunctionBuilders.weightFactorFunction(terms.size() - i));
         }
     
         functionScoreQueryBuilder.boostMode(CombineFunction.SUM);
         return functionScoreQueryBuilder;
     }
     
     private QueryBuilder buildQueryBuilder(String keywordsToSearch, Set<String> termSet) {
         // 1) 对于suggest的multi-fields至少要有一个字段匹配到 匹配得分为常量1
         MultiMatchQueryBuilder queryBuilder = QueryBuilders.multiMatchQuery(keywordsToSearch.toLowerCase(),
                 "keyword.keyword_ik", "keyword.keyword_pinyin", 
                 "keyword.keyword_first_py", "keyword.keyword_lowercase")
             .analyzer("ik_smart")
             .type(MultiMatchQueryBuilder.Type.BEST_FIELDS)
             .operator(MatchQueryBuilder.Operator.OR)
             .minimumShouldMatch("1");
     
         FunctionScoreQueryBuilder functionScoreQueryBuilder
             = new FunctionScoreQueryBuilder(QueryBuilders.constantScoreQuery(queryBuilder));
     			
         for (String term : termSet) {
             // 2) 对于完全匹配Term的加1分
             functionScoreQueryBuilder.add(QueryBuilders.termQuery("keyword.keyword_lowercase", term.toLowerCase()),
                 ScoreFunctionBuilders.weightFactorFunction(1));
     
             // 3) 对于匹配到一个Term的加2分
             functionScoreQueryBuilder.add(QueryBuilders.termQuery("keyword.keyword_ik", term),
                 ScoreFunctionBuilders.weightFactorFunction(2));
         }
     
         functionScoreQueryBuilder.boostMode(CombineFunction.SUM);
         return functionScoreQueryBuilder;
     }

最后，从实际运行的统计来看，有90%以上的查询都能在1.3)的情况下返回推荐词，而这一部分还没有进行拼写纠错和conversion_index索引的查询，因此还是比较高效的；剩下的10%在最坏的情况且缓存都没有命中的情况下，最多还需要进行三次ES的查询，性能是比较差的，但是由于有缓存而且大部分的无结果的关键词都比较集中，因此也在可接受的范围，这一块可以考虑再增加一个动态参数，在大促的时候进行关闭处理。

小结与后续改进

通过以上的设计和实现，我们实现了一个效果不错的搜索推荐功能，线上使用效果如下：

  //搜索【迪奥】，本站无该品牌商品
没有找到 "迪奥" 相关的商品， 为您推荐 "香水" 的搜索结果。或者试试 "香氛"  "眼镜" 

//搜索【puma 运动鞋 上衣】，关键词太多无法匹配
没有找到 "puma 运动鞋 上衣" 相关的商品， 为您推荐 "PUMA 运动鞋" 的搜索结果。或者试试 "PUMA 运动鞋 女"  "PUMA 运动鞋 男"

//搜索【puma 上衣】，结果太少
"puma 上衣" 搜索结果太少了，试试 "上衣"  "PUMA"  "PUMA 休闲" 关键词搜索

//搜索【51489312】特定的SKN，结果太少
"51489312" 搜索结果太少了，试试 "夹克"  "PUMA"  "户外" 关键词搜索

//搜索【blackjauk】，拼写错误
没有找到 "blackjauk" 相关的商品， 为您推荐 "BLACKJACK" 的搜索结果。或者试试 "BLACKJACK T恤"  "BLACKJACK 休闲裤"

后续考虑的改进包括：1.继续统计各种无结果或结果太少场景出现的频率和对应推荐词的实现，优化搜索推荐服务的效率；2.爬取更多的语料资源，提升Conversion的准确性；3.考虑增加个性化的功能，给用户推荐Ta最感兴趣的内容。

基于word2vec和Elasticsearch实现个性化搜索

Tue, 28 Mar 2017 15:51:02 CST

在 word2vec学习小记一文中我们曾经学习了word2vec这个工具，它基于神经网络语言模型并在其基础上进行优化，最终能获取词向量和语言模型。在我们的商品搜索系统里，采用了word2vec的方式来计算用户向量和商品向量，并通过Elasticsearch的function_score评分机制和自定义的脚本插件来实现个性化搜索。

背景介绍

先来看下维基百科上对于个性化搜索的定义和介绍：

Personalized search refers to web search experiences that are tailored specifically to an individual’s interests by incorporating information about the individual beyond specific query provided. Pitkow et al. describe two general approaches to personalizing search results, one involving modifying the user’s query and the other re-ranking search results.

由此我们可以得到两个重要的信息：

个性化搜索需要充分考虑到用户的偏好，将 用户感兴趣的内容优先展示给用户；
另外是对于实现个性化的方式上主要有 查询修改和对搜索结果的重排序两种。

而对我们电商网站来说，个性化搜索的重点是当用户搜索某个关键字，如【卫衣】时，能将用户最感兴趣最可能购买的商品（如用户偏好的品牌或款式）优先展示给用户，以提升用户体验和点击转化。

设计思路

在此之前我们曾经有一般的个性化搜索实现，其主要是通过计算用户和商品的一些重要属性（比如品牌、品类、性别等）的权重，然后得到一个用户和商品之间的关联系数，然后根据该系数进行重排序。
但是这一版从效果来看并不是很好，我个人觉得主要的原因有以下几点：用户对商品的各个属性的重视程度并不是一样的，另外考虑的商品的属性并不全，且没有去考虑商品和商品直接的关系；
在新的版本的设计中，我们考虑通过 用户的浏览记录这种时序数据来获取用户和商品以及商品和商品直接的关联关系，其核心就是通过类似于语言模型的词出现的顺序来训练向量表示结果；
在获取用户向量和商品向量表示后，我们就可以 根据向量直接的距离来计算相关性，从而将用户感兴趣的商品优先展示；

实现细节

商品向量的计算

根据用户最近某段时间（如30天内）的浏览记录，获取得到浏览SKN的列表并使用空格分隔；核心的逻辑如下面的SQL所示：

  select concat_ws(' ', collect_set(product_skn)) as skns 
from 
 (select uid, cast(product_skn as string) as product_skn, click_time_stamp 
  from product_click_record 
  where date_id <= $date_id and date_id >= $date_id_30_day_ago
  order by uid, click_time_stamp) as a 
group by uid;

将该SQL的执行结果写入文件作为word2vec训练的输入；
调用word2vec执行训练，并保存训练的结果：

  time ./word2vec -train $prepare_file -output $result_file -cbow 1 -size 20 
-window 8 -negative 25 -hs 0 -sample 1e-4 -threads 20 -iter 15

读取训练结果的向量，保存到搜索库的商品向量表。

用户向量的计算

在计算用户向量时采用了一种简化的处理，即通过用户最近某段时间（如30天内）的商品浏览记录，根据这些商品的向量进行每一维的求平均值处理来计算用户向量，核心的逻辑如下：

  vec_list = []
for i in range(feature_length):
    vec_list.append("avg(coalesce(b.vec[%s], 0))" % (str(i)))
vec = ', '.join(vec_list)


select a.uid as uid, array(%s) as vec 
from 
 (select * from product_click_record where date_id <= $date_id and date_id >= $date_id_30_day_ago) as a
left outer join
 (select * from product_w2v where date_id = $date_id) as b
on a.product_skn = b.product_skn
group by a.uid;

将计算获取的用户向量，保存到Redis里供搜索服务获取。

搜索服务时增加个性化评分

商品索引重建构造器在重建索引时设置商品向量到product_index的某个字段中，比如下面例子的productFeatureVector字段；
搜索服务在默认的cross_fields相关性评分的机制下，需要增加个性化的评分，这个可以通过 function_score来实现。

     Map<String, Object> scriptParams = new HashMap<>();
     scriptParams.put("field", "productFeatureVector");
     scriptParams.put("inputFeatureVector", userVector);
     scriptParams.put("version", version);
     Script script = new Script("feature_vector_scoring_script", ScriptService.ScriptType.INLINE, "native", scriptParams);
     functionScoreQueryBuilder.add(ScoreFunctionBuilders.scriptFunction(script));

这里采用了 elasticsearch-feature-vector-scoring插件来进行相关性评分，其核心是向量的余弦距离表示，具体见下面一小节的介绍。在脚本参数中，field表示索引中保存商品特征向量的字段；inputFeatureVector表示输入的向量，在这里为用户的向量；
这里把version参数单独拿出来解释一下，因为每天计算出来的向量是不一样的，向量的每一维并没有对应商品的某个具体的属性（至少我们现在看不出来这种关联），因此我们要特别避免不同时间计算出来的向量的之间计算相关性。在实现的时候，我们是通过一个中间变量来表示最新的版本，即在完成商品向量和用户向量的计算和推送给搜索之后，再更新这个中间向量；搜索的索引构造器定期轮询这个中间变量，当发现发生更新之后，就将商品的特征向量批量更新到ES中，在后面的搜索中就可以采用新版本的向量了；

elasticsearch-feature-vector-scoring插件

这是我自己写的一个插件，具体的使用可以看下项目主页，其核心也就一个类，我将其主要的代码和注释贴一下：

     public class FeatureVectorScoringSearchScript extends AbstractSearchScript {
         public static final ESLogger LOGGER = Loggers.getLogger("feature-vector-scoring");
         public static final String SCRIPT_NAME = "feature_vector_scoring_script";
         private static final double DEFAULT_BASE_CONSTANT = 1.0D;
         private static final double DEFAULT_FACTOR_CONSTANT = 1.0D;
     
         // field in index to store feature vector
         private String field;
     
         // version of feature vector, if it isn't null, it should match version of index
         private String version;
     
         // final_score = baseConstant + factorConstant * cos(X, Y)
         private double baseConstant;
     
         // final_score = baseConstant + factorConstant * cos(X, Y)
         private double factorConstant;
     
         // input feature vector
         private double[] inputFeatureVector;
     
         // cos(X, Y) = Σ(Xi * Yi) / ( sqrt(Σ(Xi * Xi)) * sqrt(Σ(Yi * Yi)) )
         // the inputFeatureVectorNorm is sqrt(Σ(Xi * Xi))
         private double inputFeatureVectorNorm;
     
         public static class ScriptFactory implements NativeScriptFactory {
             @Override
             public ExecutableScript newScript(@Nullable Map<String, Object> params) throws ScriptException {
                 return new FeatureVectorScoringSearchScript(params);
             }
     
             @Override
             public boolean needsScores() {
                 return false;
             }
         }
     
         private FeatureVectorScoringSearchScript(Map<String, Object> params) throws ScriptException {
             this.field = (String) params.get("field");
             String inputFeatureVectorStr = (String) params.get("inputFeatureVector");
             if (this.field == null || inputFeatureVectorStr == null || inputFeatureVectorStr.trim().length() == 0) {
                 throw new ScriptException("Initialize script " + SCRIPT_NAME + " failed!");
             }
     
             this.version = (String) params.get("version");
             this.baseConstant = params.get("baseConstant") != null ? Double.parseDouble(params.get("baseConstant").toString()) : DEFAULT_BASE_CONSTANT;
             this.factorConstant = params.get("factorConstant") != null ? Double.parseDouble(params.get("factorConstant").toString()) : DEFAULT_FACTOR_CONSTANT;
     
             String[] inputFeatureVectorArr = inputFeatureVectorStr.split(",");
             int dimension = inputFeatureVectorArr.length;
             double sumOfSquare = 0.0D;
             this.inputFeatureVector = new double[dimension];
             double temp;
             for (int index = 0; index < dimension; index++) {
                 temp = Double.parseDouble(inputFeatureVectorArr[index].trim());
                 this.inputFeatureVector[index] = temp;
                 sumOfSquare += temp * temp;
             }
     
             this.inputFeatureVectorNorm = Math.sqrt(sumOfSquare);
             LOGGER.debug("FeatureVectorScoringSearchScript.init, version:{}, norm:{}, baseConstant:{}, factorConstant:{}."
                     , this.version, this.inputFeatureVectorNorm, this.baseConstant, this.factorConstant);
         }
     
         @Override
         public Object run() {
             if (this.inputFeatureVectorNorm == 0) {
                 return this.baseConstant;
             }
     
             if (!doc().containsKey(this.field) || doc().get(this.field) == null) {
                 LOGGER.error("cannot find field {}.", field);
                 return this.baseConstant;
             }
     
             String docFeatureVectorStr = ((ScriptDocValues.Strings) doc().get(this.field)).getValue();
             return calculateScore(docFeatureVectorStr);
         }
     
         public double calculateScore(String docFeatureVectorStr) {
             // 1. check docFeatureVector
             if (docFeatureVectorStr == null) {
                 return this.baseConstant;
             }
     
             docFeatureVectorStr = docFeatureVectorStr.trim();
             if (docFeatureVectorStr.isEmpty()) {
                 return this.baseConstant;
             }
     
             // 2. check version and get feature vector array of document
             String[] docFeatureVectorArr;
             if (this.version != null) {
                 String versionPrefix = version + "|";
                 if (!docFeatureVectorStr.startsWith(versionPrefix)) {
                     return this.baseConstant;
                 }
     
                 docFeatureVectorArr = docFeatureVectorStr.substring(versionPrefix.length()).split(",");
             } else {
                 docFeatureVectorArr = docFeatureVectorStr.split(",");
             }
     
             // 3. check the dimension of input and document
             int dimension = this.inputFeatureVector.length;
             if (docFeatureVectorArr == null || docFeatureVectorArr.length != dimension) {
                 return this.baseConstant;
             }
     
             // 4. calculate the relevance score of the two feature vector
             double sumOfSquare = 0.0D;
             double sumOfProduct = 0.0D;
             double tempValueInDouble;
             for (int i = 0; i < dimension; i++) {
                 tempValueInDouble = Double.parseDouble(docFeatureVectorArr[i].trim());
                 sumOfProduct += tempValueInDouble * this.inputFeatureVector[i];
                 sumOfSquare += tempValueInDouble * tempValueInDouble;
             }
     
             if (sumOfSquare == 0) {
                 return this.baseConstant;
             }
     
             double cosScore = sumOfProduct / (Math.sqrt(sumOfSquare) * inputFeatureVectorNorm);
             return this.baseConstant + this.factorConstant * cosScore;
         }
     }

总结与后续改进

基于word2vec、Elasticsearch和自定义的脚本插件，我们就实现了一个个性化的搜索服务，相对于原有的实现，新版的点击率和转化率都有大幅的提升；
基于word2vec的商品向量还有一个可用之处，就是可以用来实现相似商品的推荐；
但是以我个人的理解，使用word2vec来实现个性化搜索或个性化推荐是有一定局限性的，因为它只能处理用户点击历史这样的时序数据，而无法全面的去考虑用户偏好，这个还是有很大的改进和提升的空间；
后续的话我们会更多的参考业界的做法，更多地更全面地考虑用户的偏好，另外还需要考虑时效性的问题，以优化商品排序和推荐。

参考资料

京东亿级商品搜索核心技术解密

Wed, 30 Nov 2016 10:20:07 CST

作者：王春明，现任京东搜索平台部负责人，2011年加入京东搜索团队，期间一直负责京东搜索引擎研发工作，主导了多次搜索架构升级工作保障其满足京东发展需求，擅长搜索引擎、高性能服务开发、分布式系统架构。

招聘：京东搜索平台部木有有高级/资深搜索引擎研发工程师（C/C++) 、高级/资深算法工程师（C/C++）、高级/资深数据系统工程师（java）等职位，期待您的加入，一起打造弹性搜索平台。简历投递至：wangchunming@jd.com，工作地点：北京-北辰世纪中心A座。

京东商品搜索简介

京东商品搜索引擎是搜索推荐部自主研发的商品搜索引擎，主要功能是为海量京东用户提供精准、快速的购物体验。目前入口主要有PC/移动/微信/手Q搜索、移动列表页、店铺搜索、店铺列表等。虽然只有短短几年的时间，系统已经能够支持日均PV过亿的请求，并且经过了多次618店庆和双11的考验。

与人们日常使用的如谷歌、百度等大搜索（或称为“全文搜索”）引擎相比，京东商品搜索引擎与前者有相通之处，比如“覆盖海量数据”、“超高并发查询”以及“超快速的请求响应时间”，同时又有自身显著的业务特点：

结构化的商品数据，需要从商品、库存、价格、促销、仓储等多个系统进行抽取；
极高的召回率要求，保证每一个状态正常的商品都能够被搜索到；
商品信息的及时更新，目的是为了保证用户极佳的购物体验——比如不能给用户展示出下柜的商品，或者商品的实时价格超出了用户搜索限定的范围。这就要求我们的搜索引擎要做到和各个系统的信息时刻保持同步，目前每天更新次数过亿；
逻辑复杂的商品业务，需要存储的商品属性信息是倒排索引信息的2倍之多；
用户购物的个性化需求，要求系统实现用户标签与商品标签的匹配。

正是由于既要兼顾大搜索引擎的通用需求，同时要契合京东的业务特点，我们将系统架构分为四个部分：1. 爬虫系统、2. 离线信息处理系统、3. 索引系统、4. 搜索服务系统。

为了使各位读者能够深入了解京东商品搜索引擎的架构，本文首先介绍了商品搜索的总体架构，然后依次介绍了爬虫系统、离线信息处理系统等各个部分，并且对搜索技术的最新研究方向做展望，希望对各位读者有所帮助。

总体架构

京东商品搜索引擎的整体架构如下图所示：

从上到下共分为3层。最上层是由搜索的前端UI层，负责页面展示。

中间层是由搜索索引服务、SUG搜索、相关搜索、划词服务和兜底服务组成。其中，SUG搜索提供输入框下拉提示词功能；相关搜索提供与query相关的其他搜索词服务；划词服务提供去除query部分词的功能；兜底服务用于索引服务异常情况下提供托底，保证用户基本的搜索可用。

最下层是索引生产端，主要功能是对接商品、库存、价格、促销、仓储等众多外部系统，整合相关数据生产全量和增量数据的索引，为在线检索服务集群提供全量索引和实时索引数据。

爬虫系统

商品搜索引擎的核心是建立商品索引，而建立索引需要详细的商品信息数据。我们利用大数据平台的数据库抽取接口和中间件系统，实现了站内商品爬虫系统，用来抽取数据库中的商品信息和及时发现变化的商品信息。从实践的效果上来看，爬虫系统表现是非常稳定和可靠的。

离线信息处理系统

离线信息处理系统主要功能是用来建立商品搜索引擎的待索引数据，包括全量待索引数据和增量待索引数据。

目前商品全量待索引数据按天进行更新，一部分是商品的基础属性信息，如商品sku、商品名称、颜色、规格、风格、材质面料等等，属于比较稳定、短时期内不会变化的数据。另外一部分是商品销售信息，如商品销量、销售额、评论等，属于易变数据。这些数据散布于多个系统中，使用的存储也各不相同。因此需要对这些来源分散的数据在商品维度进行合并，生成“商品全量待索引宽表”。目前我们建立的全量待索引宽表，不仅应用于搜索引擎服务，还同时应用于个性化推荐等其他产品服务当中。但是仅生成宽表是无法完成搜索引擎的索引需求的，因此我们利用Hadoop/MapReduce计算框架对宽表数据进行清洗，并且依照离线业务逻辑规则对数据进行二次“加工”，最终生成一份全量待索引数据。

有些商品信息，比如“价格”、“库存”、“上下架”等，经常会产生变化，因此对这些数据做全量索引满足不了商品搜索引擎的需求。为了解决数据实时性的强需求，我们建立了增量索引作为全量索引的补充。具体细节上，采用和全量索引类似的方法对数据进行处理，生成增量待索引数据。为了保证增量数据的及时性和准确性，离线信息处理系统会实时调用各商品信息接口获取数据，完成增量待索引数据的在线组装和生产。

索引系统

索引系统是商品搜索引擎的核心，主要功能是把以商品为维度进行存储的待索引数据，转换成以关键字为维度进行存储的数据，用于搜索引擎上层服务进行调用。这里待索引数据指前面离线信息处理系统生成的全量待索引数据和增量待索引数据。

此系统对于全量和增量的处理是一致的，唯一的区别在于待处理数据量的差异。一般情况下，全量数据索引由于数据量庞大，采用Hadoop/MapReduce进行；实时数据量小，采用单机进行索引生产。

为了满足分布式检索的需求，索引系统还会对索引数据进行分片处理，即按照一定策略将索引数据拆分成较小索引片，用于搜索服务系统调用。

搜索服务系统

搜索索引服务系统主要功能是接受用户请求并响应，返回搜索结果。搜索服务系统的发展也经历了从无到有，从简单到丰富到过程。主要分为如下几个阶段：

最初，搜索服务只有1列searcher组成在线检索服务，能够完成一些简单的商品搜索；
随着访问量的增长，搜索服务系统增加了缓存模块，大大加快了请求处理的速度；
接下来为了提高用户体验，我们增加了Query Processor服务，负责用户查询意图分析，提升搜索的准确性。目前Query Processor已经成为了一个融合自然语言处理、机器学习等先进技术的成熟服务，并且还在不断的进行优化；
为了支持个性化，增加了User Profile服务，负责查询用户标签。将商品的标签与用户标签是否匹配，作为一个特征加入排序因子，实现搜索的千人千面；
接着随着数据量（商品量）的增长，我们将结果包装功能从检索服务中独立出去，成为detail服务（基于缓存云实现的商品信息KV查询服务）；
将检索服务进行分片化处理，即采用类似数据库分库分表的思想，对商品id，进行hash处理后进行分片，保证各个分片数据均匀。查询时，将一个搜索请求分配到多个searcher列上，并行检索，进行局部排序后返回给merger。然后merger服务，将多个分片的检索结果进行归并，然后再进行业务排序和加工，确定要返回的商品，最后调用detail服务包装，将结果返给给blender。blender将多个搜索的结果进行融合，返回给前端。需要说明的是，此时搜索服务系统已经成为了一个“多blender&多Searcher&多merger”的系统。今后无论是访问量的增长或者数据量的增长，都可以通过扩容来满足。尤其对于618店庆、11.11之类的峰值搜索量剧增的情况下，可通过增加每个searcher列服务器的数量来满足需求。随着商品数据的不断增加，只要适时对数据做更多的分片，相应增加searcher列就可以了。检索服务分片化机制的建立也标志着京东搜索基础服务系统已经趋于完备。

完整的搜索索引服务架构，如下图所示：

搜索请求流程如下：

外部请求通过vip到达blender；
Blender调用QP，QP调用运营平台，其中运营平台主要负责将日常运营数据服务化，QP负责分析query；
Blender同时请求Merger和其他垂直搜索服务；
Merger调用UserProfile获取用户标签信息；
Merger将请求发给每列searcher；
每个searcher召回商品并返给Merger；
Merger合并多列searcher的结果，确定需要输出的商品，请求Datail包装对应的商品信息；
Detail包装商品信息返给Merger；
Merger将包装好的商品返给blender；
Blender将merger返回的结果与其他垂直搜索结果进行合并，最终返回给前端。

Blender、Merger、Searcher和Detail是整个系统的核心组件，它们之间的调用关系由Clustermap管理。各个模块将自己的服务注册到ClusterMap，同时从ClusterMap订阅其调用模块的信息来确定实际调用关系。

简要搜索服务流程，如下图所示（搜索服务系统内部处理流程）：

图中名词解释如下：

Page cache：页面缓存，blender模块直接缓存输出的页面，merger缓存了多页商品id；
Attr cache：属性缓存，缓存的搜索属性导航区的数据；
Doc cache：缓存查询词从全量索引召回的结果；
OP：运营平台服务，负责搜索运营数据的服务化；
QP：query processor，负责query意图识别。

用户请求发送到blender，首先解析参数。如果命中blender page cache直接返回给用户。如果没有命中，则调用运营平台服务（OP）和QP，并将其传给Merger，Merge会检查是否命中Attr cache，如果命中并且恰好仅请求属性汇总结果，直接返回给blender。否则进一步查看是否命中merger page cahce，如果命中直接调用detail包装，返给blender。如果没有命中，则调用User Profile获取用户标签，将其传给searcher（篇幅所限，图中只列了一个searcher，实际是多个）。Searcher接到请求，判断是否命中doc cache，如果命中doc cache，则拉取增量结果；如果没有命中doc cahe，则拉取全量和增量结果。然后依次进行排序、在线业务处理，把结果返给merger。Merger合并多个searcher结果，排序、在线业务处理，最后调用detail包装，最后将结果返给blender，blender合并多个搜索结果后返回给用户。

作为一个高并发系统，为了保证高召回率和低响应延时，我们把整个搜索服务流程的处理全部放在内存当中进行计算。多个searcher并发处理请求，同时单个searcher内部采用线程池技术，即所有线程之间共享倒排索引和商品属性信息，提高内存使用效率；每个查询使用一个独立线程串行执行，保证并发的多个查询线程之间互不影响。此外通过合理的设置线程池的大小，我们可以保证系统的CPU资源得到充分利用。在上述两个方面对系统进行优化之后，整个搜索服务系统的稳定性、召回率、内存使用率、计算速度等指标都有大幅度的提高。但是我们改进系统的步伐并没有停歇，因为通过实践发现基于内存和线程池的搜索服务仍然有几个瓶颈点亟需解决，主要包括：拉取倒排、排序和在线业务处理。针对这些问题，我们进行了二次优化，主要包括如下措施：

1. 多级缓存策略

Blender Page cache：由于搜索符合互联网的二八法则，20%热门查询频度非常高，占每天搜索请求量80%。针对这一特点，搜索第一级缓存以查询请求为key，将返回给用户的页面作为value。对于完全相同的请求，直接从缓存返回结果。页面缓存策略上线伊始，缓存命中率就接近了30%，基本解决了当时的性能问题。
Merge Page cache：随着业务的发展，排序结果需要针对不同用户实现个性化订制，这就导致请求中会包含用户的user pin。如果直接将user pin放入缓存作为key，会导致blender cache的key数量暴增，不但需要超大的缓存空间，同时缓存的命中率也会极低，最终会导致线上个性化服务的体验满意度降低。为了解决这个问题，将user_pin加入key，但是value只保存排序好的商品id，这样需要的缓存空间远远小于blender cache。当命中缓存后，调用detail直接进行结果包装。为了进一步提高缓存命中率，利用用户搜索的翻页习惯，即离线统计出用户的翻页数TP99，然后在value中缓存这些页面涉及到所有的商品id，从实践效果来看，用户后续的翻页请求大部分会命中cache。
在深入分析了业务和排序的需求之后，我们发现拉取倒排的结果只和“查询词&筛选条件”有关，而与用户无关，因此可以按照“查询词&筛选条件”作为key的方式对其进行缓存。

虽然拉取倒排结果缓存的key很快就解决了，但是我们在解决Value的存储时遇到了两个问题：1）拉取倒排的结果非常之多，导致缓存过大；2）对此结果缓存，会降低实时索引的时效性。

对于问题1），在分析了业务之后，对需要缓存的信息进行了大量的精简并采用压缩存储，最终将一个查询的缓存控制在0.5M以下。

对于问题2），我们将拉取倒排结果分为两部分，第一部分是从全量索引拉取倒排的结果，第二部分是从实时索引拉取倒排的结果。为了和全量索引的更新频率保持同步，我们把第一部分数据进行缓存的周期置为1天。对于第二部分数据，由于增量结果远远少于全量结果（一般增量只有全量5%不到），每次缓存都进行实时计算，这就是图3中的doc cache机制。从实践中来看，命中doc cache的响应时间比未命中的降低了1-2个数量级。将来随着增量结果的积累，如果实时拉取倒排结果成为性能瓶颈，可以对增量索引分段也进行缓存。

2. 截断策略

对于有些热门查询，由于其结果较多，比如“男装”、“鞋”之类的query，原始查询结果几千万个，如果对这些结果挨个进行处理，性能会非常差。同时，从用户角度分析，一个查询只有排在最前面的结果对用户才有意义。通过分析用户翻页次数，可以得到截断保留topN结果。如何保证截断不影响用户体验呢？首先我们对商品建立离线模型，即为每个商品计算出一个质量分数据。然后在索引阶段，将所有商品按照质量分降序排列，保证在倒排链中，排在前面的商品质量分总是高于后面的。在线从前往后拉取倒排过程中，如果结果数达到10*topN时，停止拉取倒排。随后对结果计算文本相关性，再按照文本相关性取topN个。截断算法上线前后，虽然KPI指标无明显变化，但是对大结果查询性能提升了一个数量级。

3. 均匀分片策略

从总体架构图中我们可以看到，如果我们将一个term的倒排链进行均分，那么相应term的拉取倒排也会被分配至各个searcher列。正是由于各个searcher列是并行计算的，这样的均分操作就可以大大减少每个查询的平均响应时间。从理论上来讲，我们采用的均匀分片策略，也有效的契合了拉取倒排、排序、在线业务处理等CPU密集型的任务。但是分片增加，会带来硬件成本增高的后果，同时集群节点间的通信成本也会增加，需要进一步权衡折衷。

4. 业务优化

京东的搜索业务并不只有上面所述的策略和工程逻辑，还必须融合很多业务逻辑。由于每一次搜索几乎都会召回很多结果，如果业务逻辑处理不好，也会导致搜索体验不好。针对这一问题并没有通用的解决方法，但是通过实践我们总结出一个基本原则：在离线阶段完成尽可能多的业务逻辑，减少在线计算量！例如进行搜索排序时，我们需要根据用户搜索历史行为（浏览、点击、购买等）对召回的结果进行排序上的调整，在工程实现上我们会先离线统计出同一个query下所有用户对每个展示商品的行为，然后建立模型，计算出该query下每个商品的权重，将其以hash结构存储；在线排序时，直接以query+商品id为key，取出权重作为反馈特征参与综合排序。

搜索技术的新发展

我们在当前的架构基础之上，正在进行一些新的探索，比如场景搜索和图像搜索。

场景搜索

随着目前京东集团的业务的扩展，用户在使用搜索时，目的不仅仅是查找商品，还可能查询促销活动信息。为了满足这些新的需求，我们在目前商品索引融合了促销系统的数据。我们首先在Query Processor中增加对应意图的识别，然后将促销等数据转换为索引数据。只要Query Processor识别出用户提出这方便的查询意图，将对应的结果返回。

图像搜索

传统搜索仅仅针对文字，但是电商系统的商品图片非常重要，很多购买决策依赖于它。目前我们利用deep learning技术离线训练图片特征，并将其做成索引。当用户使用实拍图或者网图来搜索时，采用相同的方式提取特征，然后从索引中召回最相似商品返回给用户。

文章出处：开涛的博客（订阅号ID：kaitao-1234567）

从相似度算法谈起 - Effective similarity search in PostgreSQL

Thu, 22 Dec 2016 20:41:37 CST

标签 PostgreSQL , 数组 , 相似度背景相似度分析是一个非常普遍的需求，例如根据用户提供的线索，从一堆文本数据、图片数据、视频数据中筛选一段与用户的描述相近的。我之前写过一系列的文章来介绍，文本、图片相似度搜索的技术和使用场景。《PostgreSQL 在视频、图片去重，图像搜...

【数据存储与数据库】【算法】【PostgreSQL】【图像搜索】【索引】【test】【Create】【type】【数组】

点击查看原文>

微信做搜索：未来是「微信网」还是「万维网」？

Wed, 26 Apr 2017 16:15:00 CST

看到微信要做搜索的新闻其实并不惊讶，毕竟近几个月来微信一直「小动作」不断，3月份微信指数推出之后，广告主在微信平台投放广告时就会问「你们有没有基于微信热词的广告报价啊」，似乎预示着一些零碎的出招结束之后，微信还是会踏入移动搜索领域。

动作很快，4月24日，搜狗发布公布2017年Q1财报的同一天，腾讯的微信事业群内部架构作了一些调整，微信事业群下成立搜索应用部。负责微信的搜索业务、阅读推荐业务、AI技术研究及落地、微信数据平台建设和数据能力的应用。

腾讯内部的一封邮件对大家很关注的「搜索应用部」进行了解释，其中包括四个产品中心：

1、搜索产品中心，在充分运用微信数据能力的基础上，打造微信搜索服务及精准阅读推荐服务，由基础产品部下搜索产品中心整体平移而来。

2、广告用户技术中心，为微信广告业务建设完备的用户体验评价系统及对比试验系统，负责小程序及搜索、搜索生态的建设工作，由基础产品部下广告用户技术中心整体平移而来。

3、模式识别中心，负责语音识别、图像处理、对话机器人及自然语言处理等方向的技术研究及落地等工作，由技术架构下模式识别中心整体平移而来。

4、数据中心，负责微信数据平台的建设，为各相关业务提供用户画像及数据分析、数据挖掘能力的支持，由技术架构部下数据中心整体平移而来。

看到上面四块内容， 有人说，此次架构调整标志着微信将搜索框正式上升至战略高度，而微信在移动搜索领域的野心也暴露无疑。

其实关于微信做搜索的消息从未停歇过，本文我们还是回到微信这个产品本身去聊聊布局搜索的一些可能性吧，欢迎大家留言讨论。

一、有节奏的上功能，况且同行也衬托的好

搜索入口统一，用户使用路径短，体验根据用户的需求慢慢增强。

微信在移动端的搜索没有一下子放个什么大招，基本是在根据产品的形态发展来逐步给搜索功能添砖加瓦的。

最初微信只是一个通讯工具的时候，搜索的基本是一些本地内容，比如通讯录好友、聊天记录收藏等。

在今年微信官方公布的一份《2017年微信用户&生态研究报告》里有这样一个数据：

截止到2016年12月，微信及WeChat合并月活跃用户数达8.89亿。

微信的好友规模调查显示，45%的用户微信关系超过200人。

这两个结果对比起来看基本能表明，满足了熟人关系链沟通之后，你的微信里「泛好友」越来越多了，用户关系链稳定之后，对朋友圈内容、公众号文章的消费也快速增长起来，微信在产品上也顺势提供了「朋友圈内容搜索」、「公众号账号、文章搜索」等功能。

微信顶部的一个搜索框是唯一的一个搜索入口，承载着最短的用户使用路径

当微信开拓线下场景，铺设小程序的时候，微信搜索开始支持小程序了。现在的微信搜索入口，还加入了小说、音乐、表情等垂直内容，对于靠吃微信红利的营销类用户来说，今年3月微信推出基于微信大数据的移动端指数“微信指数”，一时间刷爆朋友圈，也让人觉得微信搜索背后隐藏着搜索排名、关键词广告、竞价、广告展示、周边增值服务等巨大的商业价值。

从整个微信搜索的发展过程来看，每当用户因为满足不了需求咬牙切齿骂微信的时候，它总是能给你送上一点不大不小但确实能解决问题的功能，不免让人觉得，微信内部除了「用完即走」，是不是还有「吊你胃口」的产品哲学啊。

相反它的老对手百度在移动端的体验就比较尴尬了，光是「如何关闭手机端百度首页下的推荐？」这一需求，就有60多位知乎网友争相去提供解决方案。一个是用户盼着早点上功能，一个是用户迫不及待帮你砍功能，可以说是高下立判了。

且不说是因为微信占据了我们大部分的手机使用时间，如果微信能逐步提供一个干净的全网搜索结果（事实上2015年微信就对部分用户开放测试了站外搜索功能），作为用户，又有什么理由拒绝呢。

二、搜索即服务，微信手里的好牌越来越多

搜索引擎发展到一定阶段都会去扩展垂直内容、整合垂直资源。百度旗下就有百科、视频、文库、新闻等，视频服务有爱奇艺，O2O外卖服务有百度糯米，电影票有百度票务等等。

除搜索之外，百度在移动端提供的一些服务

搜狗在早期靠着输入法、浏览器和搜狗搜索“三驾马车”的绝杀战略风光无限，今年搜狗的Q1财报公布了，营收方面，第一季度搜狗收入达到人民币11.2亿元，较上年同期增长16%，其中移动搜索收入占比72%。 不过，再看看几乎同一时间发布的搜狐2017年Q1财报，以美元计算的话，搜狗的营收则变成了1.62亿美元，同比增长10%，环比下降5%。

除了搜狗搜索，搜狗在移动端提供的一些服务

搜狗援引CTR数据认为，在PC、WAP、APP三端总覆盖人数，以及移动端月活是行业第二，360看到对这个排名想必肯定也不会答应。而且现在搜狗变成腾讯系搜索引擎，说不定未来还得面临来自微信搜索的内部竞争。

再看看微信呢，在腾讯的支撑下，可以说是一个风口上的服务品类都没落下。

共享经济：摩拜单车和滴滴出行
生活服务：美团外卖和大众点评
消费升级：京东优选和美丽说
内容时代：阅文集团、知乎、腾讯新闻、天天日报

微信钱包里的第三方服务未来会越来越多，逐步包揽我们生活里的一切消费需求。

三、订阅号提供信息，小程序提供服务，百度没做成的微信来做

移动端一个搜索入口，用户既能搜索到信息（订阅号提供），也能搜索到服务（小程序提供），这样的一个搜索形态可能是百度在移动端上想做而没做好的。

我们在 《中国互联网的抑郁：抄与被抄都很痛》一文中提到过，移动互联网时代，一个完备的账户体系是不可或缺的资产，阿里的账户体系包含了你所有的金融生活，腾讯的账户体系中包含了你所有的社交关系。而百度呢，因为账号体系的薄弱带来的用户关系链缺失让它在日后的服务交易型业务中有些力不从心。

广告对于搜索引擎来说是一个不可或缺的盈利来源。百度搜索和微信搜索在广告方面代表着两种截然不同的方式，前者靠竞价，损害了用户体验和利益之后成了众矢之的，虽然在今日头条等一众产品的倒逼之下也做了信息流广告，但口碑这东西估计是看不到了。后者一开始就依靠用户的关系链做朋友圈的信息流广告，点赞、转发等用户行为给一些预算充足、体验良好的口碑广告带来了不少机会。

搜索推荐不分家，百度的账号体系薄弱带来的数据建模、用户画像等方面带来的影响也让他在和微信的对峙中处于下风。订阅号的内容通过朋友圈分发，大量的用户交互行为（转发、点赞、评论、打赏）都能成为一个搜索引擎中重要的排序因子。

四、面对日益壮大的微信，传统的互联网搜索引擎应该感到警惕了

这事儿在历史上已经上演过。

谷歌和必应就曾在搜索引擎里加上社交网络的信息来满足用户更多的需求。这里需要的了解的是，Google曾经的网页搜索排名会依靠200多种不同的因素来决定，比如PageRank（网页的权重）、Anchor text（超链接的文本内容）、HTML title （标签内容）等等。

我们可以假设这样一个场景，如果我在朋友圈发表了一条我很满意并且得了很多赞和评论的状态，我在微信公众号里发表了一篇我觉得质量很好的原创文章，那么即便我在微信的网页里有PageRank了，但我仍然希望能有一些SocialRank来增加一些内容的权重。

阅读数、点赞数、评论数、转载数都是很好的排序因子，百度想从网页收集这类信息就比较麻烦，还有一点就是公众号的原创识别，网页搜索做原创识别一直是个不小的难题。想象一下，如果你发布的一条内容它得到了更多的转发和点赞的话，在网页搜索里，你的这条内容将会有一个更大的权重。

「人」这个因素在互联网时代变得越发重要，这也是为什么面对日益壮大的Facebook，Google显得非常的忧伤。在国内其实也是一样的道理，如果我要搜索一些权威资料的话，传统的搜索引擎可能会给出更为准确的答案。但如果我想搜索身边发生的事情，想知道我的朋友们都在看什么玩什么，那么微信就更可能提供给我感兴趣的内容。

搜索2.0时代的PageRank在社交网络时代会演化成何种形态其实也蛮让人期待的。

五、互联网应该是开放的还是一个生态一个生态相互独立的？

互联网时代，封闭和开放是个永恒的命题。

如果未来微信搜索越做越大，它完全可以创造出一个独立于万维网之外的一个平行世界。这个平行时间里，你需要的优质信息公众号提供，你需要的娱乐社交朋友圈提供，你需要的生活服务第三方小程序提供，当他能满足你一切要求的时候，你还会怀念外面的世界么。

如果未来真的有两个世界，那么如何平衡两个世界之间的利益就只能交给张小龙和他的微信团队了。微信搜索在更好的广告模式、更高效率的内容分发以及更健康的搜索生态上仍然需要不断地改进和迭代。

所以，移动端搜索这场战役还远没有结束，PC端搜索群雄卡位割据的局面又出现了，我们仍然可以期待未来会有一个体验更好的中文搜索服务出现，到时候它是读作「微信搜索」还是「搜狗搜索」就显得没那么重要了。

更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App

ElasticSearch聚合分析API

Mon, 11 Apr 2016 11:18:17 CST

前言

说完了ES的索引与检索，接着再介绍一个ES高级功能API – 聚合(Aggregations)，聚合功能为ES注入了统计分析的血统，使用户在面对大数据提取统计指标时变得游刃有余。同样的工作，你在hadoop中可能需要写mapreduce或hive，在mongo中你必须得用大段的mapreduce脚本，而在ES中仅仅调用一个API就能实现了。

开始之前，提醒老司机们注意，ES原有的聚合功能Facets在新版本中将被正式被移除，抓紧时间用Aggregations替换Facets吧。Facets真的很慢！

1 关于Aggregations

Aggregations的部分特性类似于SQL语言中的group by，avg，sum等函数。但Aggregations API还提供了更加复杂的统计分析接口。

掌握Aggregations需要理解两个概念：

桶(Buckets)：符合条件的文档的集合，相当于SQL中的group by。比如，在users表中，按“地区”聚合，一个人将被分到北京桶或上海桶或其他桶里；按“性别”聚合，一个人将被分到男桶或女桶

指标(Metrics)：基于Buckets的基础上进行统计分析，相当于SQL中的count,avg,sum等。比如，按“地区”聚合，计算每个地区的人数，平均年龄等

对照一条SQL来加深我们的理解：

SELECT COUNT(color) FROM table GROUP BY color

GROUP BY相当于做分桶的工作，COUNT是统计指标。

下面介绍一些常用的Aggregations API。

2 Metrics

2.1 AVG

求均值。

GET /company/employee/_search
{
    "aggs" : {
        "avg_grade" : { "avg" : { "field" : "grade" } }
    }
}

执行结果

{
    "aggregations": {
        "avg_grade": {"value": 75}
    }
}

其他的简单统计API，如valuecount, max，min，sum作用与SQL中类似，就不一一解释了。

2.2 Cardinality

cardinality的作用是先执行类似SQL中的distinct操作，然后再统计排重后集合长度。得到的结果是一个近似值，因为考虑到在大量分片中排重的性能损耗Cardinality算法并不会load所有的数据。

{
    "aggs" : {
	"author_count" : {
	    "cardinality" : {"field" : "author"}
	}
    }
}

2.3 Stats

返回聚合分析后所有有关stat的指标。具体哪些是stat指标是ES定义的，共有5项。

{
    "aggs" : {
	"grades_stats" : { "stats" : { "field" : "grade" } }
    }
}

执行结果

{
    "aggregations": {
	"grades_stats": {
	    "count": 6,
	    "min": 60,
	    "max": 98,
	    "avg": 78.5,
	    "sum": 471
	}
    }
}

2.4 Extended Stats

返回聚合分析后所有指标，比Stats多三个统计结果：平方和、方差、标准差

{
    "aggs" : {
	"grades_stats" : { "extended_stats" : { "field" : "grade" } }
    }
}

执行结果

{
    "aggregations": {
	"grade_stats": {
	    "count": 9,
	    "min": 72,
	    "max": 99,
	    "avg": 86,
	    "sum": 774,
	    # 平方和
	    "sum_of_squares": 67028,
	    # 方差
	    "variance": 51.55555555555556,
	    # 标准差
	    "std_deviation": 7.180219742846005,
	    #平均加/减两个标准差的区间，用于可视化你的数据方差
	    "std_deviation_bounds": {
		"upper": 100.36043948569201,
		"lower": 71.63956051430799
	    }
	}
    }
}

2.5 Percentiles

百分位法统计，举例，运维人员记录了每次启动系统所需要的时间，或者，网站记录了每次用户访问的页面加载时间，然后对这些时间数据进行百分位法统计。我们在测试报告中经常会看到类似的统计数据

{
    "aggs" : {
	"load_time_outlier" : {
	    "percentiles" : {"field" : "load_time"}
	}
    }
}

结果是

{
    "aggregations": {
	"load_time_outlier": {
	    "values" : {
		"1.0": 15,
		"5.0": 20,
		"25.0": 23,
		"50.0": 25,
		"75.0": 29,
		"95.0": 60,
		"99.0": 150
	    }
	}
    }
}

加载时间在15ms内的占1%，20ms内的占5%，等等。

我们还可以指定百分位的指标，比如只想统计95%、99%、99.9%的加载时间

{
    "aggs" : {
	"load_time_outlier" : {
	    "percentiles" : {
		"field" : "load_time",
		"percents" : [95, 99, 99.9]
	    }
	}
    }
}

2.6 Percentile Ranks

Percentile API中，返回结果values中的key是固定的0-100间的值，而Percentile Ranks返回值中的value才是固定的，同样也是0到100。例如，我想知道加载时间是15ms与30ms的数据，在所有记录中处于什么水平，以这种方式反映数据在集合中的排名情况。

{
    "aggs" : {
	"load_time_outlier" : {
	    "percentile_ranks" : {
		"field" : "load_time",
		"values" : [15, 30]
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"load_time_outlier": {
	    "values" : {
		"15": 92,
		"30": 100
	    }
	}
    }
}

3 Bucket

3.1 Filter

先过滤后聚合，类似SQL中的where，也有点象group by后加having。比如

{
    "aggs" : {
	"red_products" : {
	    "filter" : { "term": { "color": "red" } },
	    "aggs" : {
		"avg_price" : { "avg" : { "field" : "price" } }
	    }
	}
    }
}

只统计红色衣服的均价。

3.2 Range

反映数据的分布情况，比如我想知道小于50，50到100，大于100的数据的个数。

{
    "aggs" : {
	"price_ranges" : {
	    "range" : {
		"field" : "price",
		"ranges" : [
		    { "to" : 50 },
		    { "from" : 50, "to" : 100 },
		    { "from" : 100 }
		]
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"price_ranges" : {
	    "buckets": [
		{"to": 50, "doc_count": 2},
		{"from": 50, "to": 100, "doc_count": 4},
		{"from": 100, "doc_count": 4}
	    ]
	}
    }
}

3.3 Missing

我们想找出price字段值为空的文档的个数。

{
    "aggs" : {
	"products_without_a_price" : {
	    "missing" : { "field" : "price" }
	}
    }
}

执行结果

{
    "aggs" : {
	"products_without_a_price" : {
	    "doc_count" : 10
	}
    }
}

3.4 Terms

针对某个字段排重后统计个数。

{
    "aggs" : {
	"genders" : {
	    "terms" : { "field" : "gender" }
	}
    }
}

执行结果

{
    "aggregations" : {
	"genders" : {
	    "doc_count_error_upper_bound": 0,
	    "sum_other_doc_count": 0,
	    "buckets" : [
		{"key" : "male","doc_count" : 10},
		{"key" : "female","doc_count" : 10},
	    ]
	}
    }
}

3.5 Date Range

针对日期型数据做分布统计。

{
    "aggs": {
	"range": {
	    "date_range": {
		"field": "date",
		"format": "MM-yyy",
	        "ranges": [
		    { "to": "now-10M/M" },
		    { "from": "now-10M/M" }
		]
	    }
	}
    }
}

这里的format参数是指定返回值的日期格式。

执行结果

{
    "aggregations": {
	"range": {
	    "buckets": [
		{"to": 1.3437792E+12, "to_as_string": "08-2012","doc_count": 7},
		{"from": 1.3437792E+12, "from_as_string": "08-2012","doc_count": 2}
	    ]
	}
    }
}

3.6 Global Aggregation

指定聚合的作用域与查询的作用域没有关联。因此返回结果中query命中的文档，与聚合的的统计结果是没有关系的。

{
    "query" : {
	"match" : { "title" : "shirt" }
    },
    "aggs" : {
	"all_products" : {
	    "global" : {},
	    "aggs" : {
		"avg_price" : { "avg" : { "field" : "price" } }
	    }
	}
    }
}

3.7 Histogram

跟range类似，不过Histogram不需要你指定统计区间，只需要提供一个间隔区间的值。好象不太好理解，看个例子就全明白了。

比如，以50元为一个区间，统计每个区间内的价格分布

{
    "aggs" : {
	"prices" : {
	    "histogram" : {
		"field" : "price",
		"interval" : 50
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"prices" : {
	    "buckets": [
		{"key": 0, "doc_count": 2},
		{"key": 50, "doc_count": 4},
		{"key": 100, "doc_count": 0},
		{"key": 150, "doc_count": 3}
	    ]
	}
    }
}

由于最高的价格没超过200元，因此最后的结果自动分为小于50，50到100，100到150，大于150共四个区间的值。

100到150区间的文档数为0个，我们想在返回结果中自动过滤该值，或者过滤偏小的值，可以添加一个参数”min_doc_count”，比如

{
    "aggs" : {
	"prices" : {
	    "histogram" : {
		"field" : "price",
		"interval" : 50,
		"min_doc_count" : 1
	    }
	}
    }
}

返回结果会自动将你设定的值以下的统计结果过滤出去。

3.8 Date Histogram

使用方法与Histogram类似，只是聚合的间隔区间是针对时间类型的字段。

{
    "aggs" : {
	"articles_over_time" : {
	    "date_histogram" : {
		"field" : "date",
		"interval" : "1M",
		"format" : "yyyy-MM-dd"
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"articles_over_time": {
	    "buckets": [
		{"key_as_string": "2013-02-02","key": 1328140800000, "doc_count": 1},
		{"key_as_string": "2013-03-02","key": 1330646400000, "doc_count": 2},
		...
	    ]
	}
    }
}

3.9 IPv4 range

由于ES是一个企业级的搜索和分析的解决方案，在做大量数据统计分析时比如用户访问行为数据，会采集用户的IP地址，类似这样的数据(还有地理位置数据等)，ES也提供了最直接的统计接口。

{
    "aggs" : {
	"ip_ranges" : {
	    "ip_range" : {
		"field" : "ip",
		"ranges" : [
		    { "to" : "10.0.0.5" },
		    { "from" : "10.0.0.5" }
		]
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"ip_ranges": {
	    "buckets" : [
		{"to": 167772165, "to_as_string": "10.0.0.5","doc_count": 4},
		{"from": 167772165,"from_as_string": "10.0.0.5","doc_count": 6}
	    ]
	}
    }
}

3.10 Return only aggregation results

在统计分析时我们有时候并不需要知道命中了哪些文档，只需要将统计的结果返回给我们。因此我们可以在request body中添加配置参数size。

curl -XGET 'http://localhost:9200/twitter/tweet/_search' -d '{
    "size": 0,
        "aggregations": {
	    "my_agg": {
	        "terms": {"field": "text"}
            }
    }
}
'

4 聚合缓存

ES中经常使用到的聚合结果集可以被缓存起来，以便更快速的系统响应。这些缓存的结果集和你掠过缓存直接查询的结果是一样的。因为，第一次聚合的条件与结果缓存起来后，ES会判断你后续使用的聚合条件，如果聚合条件不变，并且检索的数据块未增更新，ES会自动返回缓存的结果。

注意聚合结果的缓存只针对size=0的请求(参考3.10章节)，还有在聚合请求中使用了动态参数的比如Date Range中的now(参考3.5章节)，ES同样不会缓存结果，因为聚合条件是动态的，即使缓存了结果也没用了。

写在最后，截止到这篇文章，我们对ES的基础功能有了一个大概的认识了，作为一个进阶式的技术文章，我忽略了ES很多高级的功能(比如之前提到过的地理位置数据的检索统计，搜索推荐等)，留在以后慢慢补充吧。距离构建我们心目中的高级搜索平台仍有很长的路要走，让我们继续努力。

未完待续…

商品搜索引擎—推荐系统设计

Mon, 23 May 2016 12:10:58 CST

一、前言

结合目前已存在的商品推荐设计（如淘宝、京东等），推荐系统主要包含系统推荐和个性化推荐两个模块。

系统推荐：根据大众行为的推荐引擎，对每个用户都给出同样的推荐，这些推荐可以是静态的由系统管理员人工设定的，或者基于系统所有用户的反馈统计计算出的当下比较流行的物品。

个性化推荐：对不同的用户，根据他们的口味和喜好给出更加精确的推荐，这时，系统需要了解需推荐内容和用户的特质，或者基于社会化网络，通过找到与当前用户相同喜好的用户，实现推荐。

下面具体介绍系统推荐和个性化推荐的设计方案。

二、系统推荐

2.1、系统推荐目的

针对所有用户推荐，当前比较流行的商品（必选）或促销实惠商品（可选）或新上市商品（可选），以促进商品的销售量。
PS：根据我们的应用情况考虑是否选择推荐促销实惠商品和新上市商品。（TODO1）

2.2、实现方式

实现方式包含：系统自动化推荐和人工设置推荐。

（1）系统自动化推荐考虑因素有：商品发布时间、商品分类、库存余量、历史被购买数量、历史被加入购物车数量、历史被浏览数量、降价幅度等。根据我们当前可用数据，再进一步确定（TODO2）

（2）人工设置：提供运营页面供运营人员设置，设置包含排行位置、开始时间和结束时间、推荐介绍等等。

由于系统推荐实现相对简单，因此不作过多的文字说明，下面详细介绍个性化推荐的设计。

三、个性化推荐

3.1、个性化推荐目的

对不同的用户，根据他们的口味和喜好给出更加精确的推荐，系统需要了解需推荐内容和用户的特质，或者基于社会化网络，通过找到与当前用户相同喜好的用户，实现推荐，以促进商品的销售量。

3.2、三种推荐模式的介绍

据推荐引擎的数据源有三种模式：基于人口统计学的推荐、基于内容的推荐、基于协同过滤的推荐。

（1）基于人口统计学的推荐：针对用户的“性别、年龄范围、收入情况、学历、专业、职业”进行推荐。

（2）基于内容的推荐：如下图，这里没有考虑人对物品的态度，仅仅是因为电影A月电影C相似，因此将电影C推荐给用户A。这是与后面讲到的协同过滤推荐最大的不同。

（3）基于协同过滤的推荐：如下图，这里我们并不知道物品A和物品D是否相似，仅仅考虑人对物品的喜好进行推荐。

模式采用：这三种模式可以单独使用，也可结合使用。结合我们实际情况，采用基于协同过滤的推荐更加合适，看后期情况是否结合另外两种模式实现推荐。但基于协同过滤的推荐这种模式，会引发“冷启动”问题。关于，冷启动问题，后续会讨论解决方案。

3.3、用户喜好设计

（1）判断用户喜好因素：历史购买、历史购物车、历史搜索、历史浏览等，待确定我们可用数据再进一步细化。

（2）用户对某个商品的喜好程度，通过不同行为对应不同分值权重，如：历史购买（10）、历史购物车（8）、历史搜索（5）、历史浏览（6），确定用户喜好因素后再进一步对各个因素评分权重进行合理的设计。

（3）用户对商品的喜好程度最终体现：结合某个商品的不同行为统计出最终对该商品的喜好程度，即对商品的喜好程度，最终以一个数字体现。

3.4、Mahout介绍

目前选择采用协同过滤框架Mahout进行实现。

Mahout 是一个很强大的数据挖掘工具，是一个分布式机器学习算法的集合，包括：被称为Taste的分布式协同过滤的实现、分类、聚类等。Mahout最大的优点就是基于 Hadoop实现，把很多以前运行于单机上的算法，转化为了MapReduce模式，这样大大提升了算法可处理的数据量和处理性能。

Mahout 是一个布式机器学习算法的集合，但是这里我们只使用到它的推荐/协同过滤算法。

3.5、Mahout实现协同过滤实例

协同过滤在mahout里是由一个叫taste的引擎提供的，它提供两种模式，一种是以jar包形式嵌入到程序里在进程内运行，另外一种是MapReduce Job形式在hadoop上运行。这两种方式使用的算法是一样的，配置也类似。

这里我们采用第一种引入jar包的单机模式。

3.5.1、依赖

<dependency>
    <groupId>org.apache.mahout</groupId>
    <artifactId>mahout-core</artifactId>
    <version>0.9</version>
</dependency>
<dependency>
    <groupId>org.apache.mahout</groupId>
    <artifactId>mahout-math</artifactId>
    <version>0.9</version>
</dependency>
<dependency>
    <groupId>org.apache.hadoop</groupId>
    <artifactId>hadoop-core</artifactId>
    <version>1.2.1</version>
</dependency>

3.5.2、实现代码

public static void main(String[] args) {
    try {
        // 从文件加载数据
        DataModel model = new FileDataModel(new File("D:\\mahout\\data.csv"));
        // 指定用户相似度计算方法，这里采用皮尔森相关度
        UserSimilarity similarity = new PearsonCorrelationSimilarity(model);
        // 指定用户邻居数量，这里为2
        UserNeighborhood neighborhood = new NearestNUserNeighborhood(2,
                similarity, model);
        // 构建基于用户的推荐系统
        Recommender recommender = new GenericUserBasedRecommender(model,
                neighborhood, similarity);
        // 得到指定用户的推荐结果，这里是得到用户1的两个推荐
        List<RecommendedItem> recommendations = recommender.recommend(1, 2);
        // 打印推荐结果
        for (RecommendedItem recommendation : recommendations) {
            System.out.println(recommendation);
        }
    } catch (Exception e) {
        System.out.println(e);
    }
}

3.5.3、data.csv内容（用户id、商品id，评分）

1,101,5
1,102,3
1,103,2.5
2,101,2
2,102,2.5
2,103,5
2,104,2
3,101,2.5
3,104,4
3,105,4.5
3,107,5
4,101,5
4,103,3
4,104,4.5
4,106,4
5,101,4
5,102,3
5,103,2
5,104,4
5,105,3.5
5,106,4

3.5.4、运行结果

3.6、Mahout协同过滤算法选用

3.6.1、Mahout协同过滤自带算法介绍

Mahout算法框架自带的推荐器有下面这些：

GenericUserBasedRecommender：基于用户的推荐器，用户数量少时速度快；

GenericItemBasedRecommender：基于商品推荐器，商品数量少时速度快，尤其当外部提供了商品相似度数据后效率更好；

SlopeOneRecommender：基于slope-one算法的推荐器，在线推荐或更新较快，需要事先大量预处理运算，物品数量少时较好；

SVDRecommender：奇异值分解，推荐效果较好，但之前需要大量预处理运算；

KnnRecommender：基于k近邻算法(KNN)，适合于物品数量较小时；

TreeClusteringRecommender：基于聚类的推荐器，在线推荐较快，之前需要大量预处理运算，用户数量较少时效果好；

Mahout最常用的三个推荐器是上述的前三个，本文主要讨论前两种的使用。

3.6.2、考虑使用算法

（1）GenericUserBasedRecommender（推荐）

一个很简单的user-based模式的推荐器实现类，根据传入的DataModel和UserNeighborhood进行推荐。其推荐流程分成三步：

第一步，使用UserNeighborhood获取跟指定用户Ui最相似的K个用户{U1…Uk}；

第二步，{U1…Uk}喜欢的item集合中排除掉Ui喜欢的item, 得到一个item集合 {Item0…Itemm}

第三步，对{Item0…Itemm}每个itemj计算 Ui可能喜欢的程度值perf(Ui , Itemj) ，并把item按这个数值从高到低排序，把前N个item推荐给Ui。其中perf(Ui , Itemj)的计算公式如下：

其中是用户Ul对Itemj的喜好值。

（2）GenericItemBasedRecommender

一个简单的item-based的推荐器，根据传入的DateModel和ItemSimilarity去推荐。基于Item的相似度计算比基于User的相似度计算有个好处是，item数量较少，计算量也就少了，另外item之间的相似度比较固定，所以相似度可以事先算好，这样可以大幅提高推荐的速度。

其推荐流程可以分成三步：

第一步，获取用户Ui喜好的item集合{It1…Itm}

第二步，使用MostSimilarItemsCandidateItemsStrategy(有多种策略, 功能类似UserNeighborhood) 获取跟用户喜好集合里每个item最相似的其他Item构成集合 {Item1…Itemk}；

第三步，对{Item1…Itemk}里的每个itemj计算 Ui可能喜欢的程度值perf(Ui , Itemj) ，并把item按这个数值从高到低排序，把前N个Item推荐给Ui。其中perf(Ui , Itemj)的计算公式如下：

其中是用户Ul对Iteml的喜好值。

（3）SlopeOneRecommender

基于Slopeone算法的推荐器，Slopeone算法适用于用户对item的打分是具体数值的情况。Slopeone算法不同于前面提到的基于相似度的算法，他计算简单快速，对新用户推荐效果不错，数据更新和扩展性都很不错，预测能达到和基于相似度的算法差不多的效果，很适合在实际项目中使用。

综合考虑，我们使用GenericUserBasedRecommender（基于用户的推荐器）比较合适。3.5、Mahout实现协同过滤实例就是采用这种算法实现的。

3.7、Mahout数据源获取方式

DataModel 是用户喜好信息的抽象接口，它的具体实现支持从任意类型的数据源抽取用户喜好信息。Taste 默认提供 JDBCDataModel 和 FileDataModel，分别支持从数据库和文件中读取用户的喜好信息。

目前，Mahout为DataModel提供了以下几种实现：

org.apache.mahout.cf.taste.impl.model.GenericDataModel
org.apache.mahout.cf.taste.impl.model.GenericBooleanPrefDataModel
org.apache.mahout.cf.taste.impl.model.PlusAnonymousUserDataModel
org.apache.mahout.cf.taste.impl.model.file.FileDataModel
org.apache.mahout.cf.taste.impl.model. HBase.HBaseDataModel
org.apache.mahout.cf.taste.impl.model.cassandra.CassandraDataModel
org.apache.mahout.cf.taste.impl.model.mongodb.MongoDBDataModel
org.apache.mahout.cf.taste.impl.model.jdbc.SQL92JDBCDataModel
org.apache.mahout.cf.taste.impl.model.jdbc.MySQLJDBCDataModel
org.apache.mahout.cf.taste.impl.model.jdbc.PostgreSQLJDBCDataModel
org.apache.mahout.cf.taste.impl.model.jdbc.GenericJDBCDataModel
org.apache.mahout.cf.taste.impl.model.jdbc.SQL92BooleanPrefJDBCDataModel
org.apache.mahout.cf.taste.impl.model.jdbc.MySQLBooleanPrefJDBCDataModel
org.apache.mahout.cf.taste.impl.model.jdbc.PostgreBooleanPrefSQLJDBCDataModel
org.apache.mahout.cf.taste.impl.model.jdbc.ReloadFromJDBCDataModel

从类名上就可以大概猜出来每个DataModel的用途，但是竟然没有HDFS的DataModel，有人实现了一个，请参考MAHOUT-1579（ https://issues.apache.org/jira/browse/MAHOUT-1579）。

3.8、协同过滤实现采用技术

采用如下技术：Mahout（推荐算法） + Spark（并行计算） + Hadoop + Elasticsearch

Mahout 是一个很强大的数据挖掘工具，是一个分布式机器学习算法的集合，包括：被称为Taste的分布式协同过滤的实现、分类、聚类等。Mahout最大的优点就是基于hadoop实现，把很多以前运行于单机上的算法，转化为了MapReduce模式，这样大大提升了算法可处理的数据量和处理性能。

Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用的并行计算框架，Spark基于map reduce算法实现的分布式计算，拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的map reduce的算法。

但Spark没有提供文件管理系统，所以，它必须和其他的分布式文件系统进行集成才能运作。这里我们可以选择Hadoop的HDFS,也可以选择其他的基于云的数据系统平台。但Spark默认来说还是被用在Hadoop上面的，毕竟，大家都认为它们的结合是最好的。

PS：Mahout（推荐算法） + Spark（并行计算） + Hadoop + Elasticsearch搭配的实现方式并没有尝试，网上有一些解决方案，但是并不详细，而且英文居多，因此需要进一步学习研究。

可参考文献： https://mahout.apache.org/users/algorithms/intro-cooccurrence-spark.html

3.9、冷启动问题

所谓冷启动，是指对于很多推荐引擎的开始阶段，当一个新用户进入推荐系统或者系统添加一个新的物品后，由于还没有大量的用户数据，系统无法计算出推荐模型，从而导致系统的推荐功能失效的问题。

可考虑的解决方案有：

（1）利用用户注册信息进行初步推荐，主要包括人口统计学信息、用户描述的个人兴趣内容，预先设定好用户的偏好信息。

（2）在用户第一次访问系统时，给用户提供一些物品，让用户反馈对这些物品的评分，然后根据用户的反馈形成初始的个性化推荐。

（3）邀请行业的专家对新的用户或者新的物品
进行分类、评注。

（4）随机推荐的方法。对于冷启动问题，实际应用中最简单最直观的方法是采用随机推荐的方式。这种方法是比较冒险。

（5）平均值法。所有项目的均值，作为用户对未评价过项目的预测值，将原始评分矩阵进行填充，然后在填充后的评分矩阵上寻找目标用户的最近邻居，应用协同过滤的方法产生推荐。但是均值的方法只能说是一种被动应付的方式，新用户对项目的喜好值正好等于其他用户对此项目的平均值的概率是非常小的。

根据我们实际情况，建议使用第（1）种解决方案比较合适。

可能感兴趣的文章

百度竞价从入门到精通

Tue, 15 Sep 2015 23:29:50 CST

　　对于网上有太多关于竞价的一些文章，但是没有一套属于系统化，完整化的文章来讲解，让一些步入竞价这个行业的新手来说学起来确实挺费劲，该篇为你详解百度竞价从入门到精通实战操作系列之全过程。

　　如果你要将一个项目进行推广，那么你要做好以下充分准备工作，从而为准备进行下一阶段搭建账户进行推广。

　　首先市场分析，人群定位，整理出有关这个项目所需的所有关键词进行分类，

　　这里所建议的一点是，不同属性的关键词分类，能分多细就分多细，这也是为一个精细化的账户结构在推广前做好准备。

　　精细化账户结构划分原理：

　　这里在详细说明一点，一个精细化账户指的是，每个计划下各个推广单元内添加的关键词和关联的创意和对应的着陆页是否一一对应，这也是最终关联着账户后期上线推广所产生的问题所在。

　　往往一个推广账户没能发挥出最大的推广效果来，一半原因在于我们的账户结构搭建有关，另一半原因在于推广人员的投放策略有关。

　　所以说一个好的账户结构，也是关联着账户后期的生死存亡，（虽然夸张了点，但是这是实战所证明的），这也是一些实战多年的竞价人员对账户的搭建要求必须要进行精细化划分的原因之一，更是作为一个合格的竞价人所必备的条件之一。

　　步入sem行业的竞价人员请记住一点，好的账户结构是推广前好的开端。

　　 账户搭建实战操作讲解：

　　我们以"男科"科室为案例，以该科室中"前列腺炎"为一个病种（推广计划）进行搭建，投放设备为移动端。

　　你可能在搭建计划的过程中会遇到这些设置问题。（我们提取主要设置出来，其它忽略）

　　1，推广计划层级设置，名称，预算，时间段，投放地区。

　　a＞计划名称，"前列腺炎"为该推广计划的名称。

　　b＞计划预算，为该计划设置一个合理预算，好控制消费，往往一些竞价人员对此设置忽略，如果该计划的消费突然幅度上升的话，最终就会导致账户设置的总预算到达预期而下线推广，所以推广计划的预算是必须设置的。

　　c＞计划时间段，根据我们的推广需求进行设置。

　　d＞计划投放地区，如果你是多地区投放，可以设置为多个相同的推广计划名称，推广地区设置不同的，例如，前列腺炎-武汉，前列腺炎-其它区域。这也是账户结构搭建的一种方式，目的是监控，观察，控制好各个地区的消费情况。计划搭建如图：

　　2，推广单元层级设置，单元名称，单元移动比例出价，单元出价，否词。

　　a＞单元名称，前提我们要将有关"前列腺炎"所有的关键词进行属性分类，例如，症状，治疗，医院，费用等等进行细分；后期直接以这些不同属性的关键词类别来命名各个推广单元的名称，我们以"前列腺炎的症状"来命名该计划内的一个单元。

　　b＞单元移动比例出价，只针对移动端的出价设置，该比例设置范围为0.1-10，如果该计划只针对pc端投放，单元比例设置为0.1即可，如果只针对移动端投放，比例设置为10即可，我们将"前列腺炎的症状"单元的比例设置为10。

　　c＞单元出价，单元出价并不是关键词最终的出价，我们设置为1即可。

　　d＞否词，该设置后期结合账户中的搜索词报告来进行操作添加。

　　3，推广单元内关键词设置，关键词名称，出价，匹配模式，访问URL，移动访问URL.

　　a＞关键词名称，我们将有关"前列腺炎的症状"所有关键词添加到该单元里面即可。

　　b＞出价，该单元比例因为设置为10，我们针对的是移动端投放，此时关键词的出价并不是移动端最终的出价（移动出价=关键词出价x比例10）才是移动端最终的出价，出价我们全部设置为1，后面再去推广实况查看排名或根据账户后台中的关键词平均排名数据，来进行调整出价。

　　c＞匹配模式，关键词的匹配模式有四种，精确匹配，短语匹配中包含三类（精确，同义，核心），广泛匹配+否定匹配。我们以关键词"前列腺炎的症状"为例，解析下"前列腺炎的症状"在各种匹配模式下会触发的搜索词，如下所示：

　　精确匹配：

　　精确匹配-前列腺炎的症状（触发的搜索词与关键词字面完全相同）

　　采用该匹配模式的多为一些竞争比较激烈的词使用，出价较高的词使用。

　　短语匹配（包含3种模式）：

　　精确包含-男性前列腺炎的症状，前列腺炎的症状有哪些（触发的搜索词完全包含关键词字面，前后插入）

　　采用该匹配模式的也为一些竞争激烈的词，病种名称词和热搜词使用。

　　同义包含-前列腺症状，前列腺炎的表现及症状（触发的搜索词以颠倒，中间插入，同义等形式）

　　采用该匹配模式的多为一些短词，稳定的词使用。

　　核心包含-前列腺炎，前列腺炎肥大，前列腺炎的治疗（触发的搜索词包含关键词核心部分的，插入，颠倒形态的短语，并支持同义词匹配）

　　采用该匹配模式的多为一些长尾词使用。

　　广泛匹配：

　　广泛匹配-前列腺炎的表现，前列腺液，前列腺增大（触发的关键词多为一些相关性的变形词）

　　采用该匹配模式除非是一些很长的长尾词使用之外，这种匹配模式一般慎用。当然有一些竞价人员的投放策略是以关键词超低价跑广泛的，这种关键词出价策略除外。

　　否定匹配：

　　否定匹配-与短语匹配和广泛匹配相配合使用，对于一些可能被匹配但与推广意图不相符合的关键词可以添加到否定匹配关键词中，也就是在单元和计划层级设置中添加否词。

　　例如："前列腺炎的症状"匹配到了"狗狗前列腺炎的症状"，那么我们就要狗狗进行否掉，来阻止网民搜索这样推广信息被触发到。

　　通过对以上几种匹配模式的分析和讲解，从精确匹配到核心匹配的不同设置，可以知道关键词的流量是由多到少，由精到广，这样一个转变的过程来的。

　　不同的匹配模式设置有利也有弊，这里我们采用短语匹配模式中的同义包含来设置"前列腺炎的症状"这个单元内的关键词，当然后期还要看该单元内的关键词展现，点击，消费数据进行匹配模式的相关调整。

　　d＞访问URL和移动访问URL，该设置我们只需将关键词对应的网站文章页链接复制进来就可以。关键词搭建如图：

　　4，推广单元内的创意设置：创意标题，创意描述1，创意标题描述2，访问URL，显示URL.

　　a＞创意，百度官方给出了在撰写创意时候需要注意的一些要点，一条好的创意要包含以下这四点进去，飘红，相关，通顺，吸引。

　　飘红，一条创意中要包含2-3个通配符。

　　相关，撰写的创意要和关键词高度相关。

　　通顺，让网民看到你的创意要读得通顺。

　　吸引，能抓住网民的搜索需求，与网民的搜索需求达成共鸣。

　　前三点我想都可以完成，但最后一点就有些难度，具体撰写方案我们以网民动机分析表来进行深度分析撰写。

　　搜索词，前列腺炎的症状。

　　搜索需求，想了解前列腺这种男性疾病的症状。

　　根源目的，怀疑自己是不是得了前列腺炎，进一步了解确定这种疾病和找到有效治疗方法。

　　心理活动，患上前列腺炎的患者心理往往会表现为顾虑，紧张，恐惧，忧虑，心情低落、沉重。前列腺炎的症状往往表现为，尿频、尿急、尿不尽、尿道灼痛、患者往往因为这些可能会影响到生活的质量，严重情况下可能会导致患者的精神与肉体遭受极大的折磨，患者肯定是希望通过有效方法快点治好前例腺炎，同时也是反映出患者急迫的治疗心理。

　　社会层面，50岁以下男性。

　　扩展需求，能早日康复，治疗价格合理。

　　分析完以上，那在创意撰写的第四点要求"吸引"就容易写出来了。（注意：由于移动端的创意展现出去的字节有限制，所以创意内容一定要简言简语。）

　　由于现在患者看病的心里水平提高，创意的标题内容为"前列腺炎的症状"-男科疾病诊疗中心，来确保患者点击进入网站时占一定的权威性，信任，就是给患者一种进入官方网站的感觉，该标题也刚好可以在移动端进行全面展现，随后在描述内容中写出前列腺炎有哪些症状来满足患者的搜索需求，紧接着是将我们医院的疗法，优势，费用，案例简写出来，来紧扣患者的心理活动和满足患者的扩展需求这块。

　　b＞访问URL，由于我们已经在关键词的url填写了链接，这里就只需填写网站的推广域名名称即可，显示URL，设置也是一样。

　　以上为一个计划整体搭建流程，无论采取哪种搭建方式，我们都要遵循切记账户的搭建原则就是：

　　账户结构划分逻辑一定要清晰，精细化分组，将意义相近，结构相同的关键词放在一起。

　　以便于针对关键词所在推广单元撰写针对性的创意；保证一个单元下的所有关键词嵌入到创意里语句通顺，语义清晰，也便于

　　后期统计投放数据，为日后的账户管理优化工作打下良好基础。

　　 账户后期优化方案讲解：

　　账户上线后你可能会遇到这些情况？

　　1，关键词没有展现或者展现量很低。（不包括因出价过低而造成的无展现）

　　调整方案：

　　扩充匹配模式：广泛匹配，短语匹配（包含三种模式），精确匹配，不同的匹配模式会带来不同的效果，广泛匹配的展现量远远大于短语匹配，短语匹配远远大于精确匹配，注意；这三种匹配模式有利也有弊，因此通过扩充匹配模式之后，一定要观察展现是否有提升，点击是否有变化。

　　2，消费很多但没有转化；点击价格很高也没有转化。

　　调整方案：

　　对于这些词，可以新建一个计划在细分到多个单元里，进行统一优化，创意深度撰写优化，给这类词一个合适的出价，再持续观察关键词的表现情况。

　　3，账户消费突增或突降。

　　调整方案：

　　对于发生这种异常情况，首先我们要排除人为因素对账户进行过调整，账户计划预算，关键词价格调整，关键词增加或删除，匹配模式修改，推广地域以及推广时段的改变等等这些，如果我们忘记昨天对账户操作的整体流程，可以通过在账户的历史操作记录中作了解。

　　同时下载发生变化前后同期的数据报告，进行逐一锁定，看下异常主要集中发生在哪些计划和单元，最后锁定到具体的关键词。

　　如果账户庞大，计划单元比较多，可以选取占账户消费80%的计划和单元进行分析，锁定问题所在（二八原则：账户80%的消费可能集中在20%的计划和单元中）

　　4，关键词展现，点击数据异常情况。

　　我们可以从以下方面进行分析。

　　展现量变化，首先，查看关键词的展现量是否发生了突变，展现量变化的几种情况如下；

　　外界坏境发生了变化，一些新闻或政策导致大的坏境发生变化，导致网民的搜索量异常，可以看看百度指数的情况，是否跟关键词的变化有出现一致的变化趋势。

　　如果这些没有，要去看下搜索词报告，看看那些搜索词触发了账户中的关键词，看看是不是需要调整某些关键词的匹配模式。

　　如果展现没有问题，点击突变，要查看重点关键词的排名，是不是发生了比较大的变化，排名是不是降低了，排名位置是不是发生变化，有时pc端的广告位，只在右侧展现，移动端前面的3个广告位没有展现，只在底部几个广告位展现，还有推广状态显示不宜推广，质量度降低，推广的竞争对手变多，竞争是不是更加激烈了，这些数据和问题都要去做深度分析及了解。

　　在账户稳定期间，我们还需要对转化好、表现好的关键词进行词量上的拓展。具体做法如下；

　　a，筛选出效果好的关键词，进行关键词拓展更多优质的关键词。

　　b，及时获取搜索词报告，拓展出相关性高的优质关键词。

　　c，关注季节投放及网民热点，把握相关性高的热点关键词。

　　对于以上这些问题的分析点和调整方法，只是我们推广中要做的一部分。我们要有更多的想法和精力放在账户投放策略身上。前面我们也说到，（往往一个推广账户没能发挥出最大的推广效果来，一半原因在于我们的账户结构搭建有关，另一半原因在于推广人员的投放策略有关。）

　　这里列举两点账户上的投放策略：

　　a，推广时间段投放策略，因为每个时间段的搜索人群不一样，最终产生的转化也会有所变化，因此可以新推一个账户或新建几个计划，选择在好的时间节点进行针对性投放。

　　b，账户28原则投放策略，提取这个账户主要的关键词，重新建立一个新的账户只添加重点关键词进行投放等等；还有一些我们还未想到，待去尝试的投放方法。

　　最后总结一下：

　　做竞价最重要的是什么；热爱、专注、负责、态度、思维（投放策略），拥有这些那么我相信你在这个行业一定会走得更远。

　　来源：投稿，作者：胡文强，微信公众号：baidujingjia520

评论《百度竞价从入门到精通》的内容...

微博：新浪微博 - 微信公众号：williamlonginfo
月光博客投稿信箱：williamlong.info(at)gmail.com
Created by William Long www.williamlong.info

同样基于应用内搜索，“一览”才上线半年多，豌豆荚为什么又发布了“轻桌面”？

Sat, 30 Jan 2016 17:32:06 CST

没有安装 app，却能在 Android 手机桌面看到该 app 的图标，点击进去可以阅读内容。不同 app 还能按主题“合体”在一起，在一个有时间线的信息流页面里阅读“合体” app 的内容。

联翩科技出品、 1 月 29 日晚刚刚发布的豌豆荚轻桌面，就能做到上面说的这些“神奇的”事情。今年 1 月，豌豆荚将豌豆荚一览、Snap 效率锁屏（现已更名豌豆荚 Smart 锁屏）两款产品拆分了出来，成立一间新公司——联翩科技。

豌豆荚轻桌面发布后，爱范儿第一时间联系上豌豆荚联合创始人兼 CEO 王俊煜，联翩科技联合创始人、《Android 开发精要》作者范怀宇，以及工程师许彬，一起聊了聊豌豆荚这个新产品。

不是 app，却干着 app 的活

打开豌豆荚轻桌面，搜索感兴趣的 app，点击右上角的“+”符号，将一个预览版 app 添加在桌面。然后就能在不安装该 app 的情况下，预览阅读它提供的内容。

通过豌豆荚轻桌面添加的预览版 app，图标设计基本与原生 app 无异，不过右上角有一个“豌豆荚轻桌面”预览版的标志。

所谓预览版 app，其实相当于一个 app 的快捷方式，点击后直接跳转到轻桌面这个原生 app 的显示页面。所以，如果预览内容后觉得该 app 值得下，也可以通过豌豆荚轻桌面安装完整版。

除了能预览 app 里面的内容，豌豆荚轻桌面还有个 MixUp 功能——将 app 分成了不同话题集合，添加感兴趣的话题集合后，就能以信息流的方式，看完该话题集合下 app 的所有内容。

目前，豌豆荚桌面收录的应用数量超过 500 个，和豌豆荚一览收录的基本同步。

（豌豆荚轻桌面）

如果你用的是 Android 5.0 及以上版本的手机，还能看到预览版 app 像原生 app 一样显示在历史应用里。“这个需求是我提的，哈哈哈。”王俊煜颇为得意地打趣道。

工程师许彬告诉爱范儿：“这个功能的实现其实是基于 Android 5.0 之后的新 API，可以为 app 不同页面指定不同的 document，Chrome 就是用这个方法。”

许彬说的是，从 Android 5.0 开始，Chrome 移动浏览器有了一个新的功能——合并标签页与应用，Google 在有意模糊网页和原生 app 的边界。

此外，开发团队还“细心地为不同的应用使用了他们自己的主色调”。比如爱范儿的红色调，One·一个的蓝色调，以及 Product Hunt 的橙色调。

豌豆荚轻桌面目前还只有 Android 版本，“iOS 版本还没有具体的时间表，而且由于两个系统的差异，形态上肯定有变化”。

又一个基于应用内搜索的产品

豌豆荚轻桌面和之前的豌豆荚一览一脉相承——基于应用内搜索技术。

所谓应用内搜索，即用户可以在应用内搜索产品中检索到其它应用中的内容，这一行为打破了各个 app 之间隔离的状况，使内容在一个平台上共享。

2015 年 7 月，豌豆荚一览在 iOS 端和 Android 端同步上线。得益于应用内搜索技术，一览能把散落在手机已有 app 内的文章、图片和视频都抓取并串联起来，在同一个页面中以卡片流的形式展示给用户。

手机里还没有的 app，用户也可以选择用 “添加” 的方式发现一览收集的其他 app 内容。如果觉得内容好，想直接下载 app，一览也提供了安装按钮。

2015 年 12 月，“在打磨应用内搜索技术以及运营豌豆荚一览的过程中，发现不少需求点用另一种形态来满足会体验更好，于是逐渐萌生了做豌豆荚轻桌面的想法。”范怀宇告诉爱范儿。

（豌豆荚一览）

2016 年 1 月初，团队开始动手开发，不断地把这个想法打磨完善，“另一种形态”的产品逐渐成型。1 月 29 日晚，豌豆荚轻桌面上线，其中一种发布渠道就是豌豆荚一览。

豌豆荚团队表示，一览和轻桌面这两个产品分别满足不同的用户需求。豌豆荚一览是一个有时间线的产品，主要给内容重度用户一次刷完所有关注 app 的内容，提升效率。

“轻桌面按照兴趣和话题分组更多一点，关注细分的兴趣，让用户更好地发现 app、体验 app，在满足这些需求时候也更加直截了当。”范怀宇说道。

“现在我们实现这两个产品其实都基于同一套框架，成本还是比较小的。”许彬补充道，“通过让每个产品更加专注，而不是做一个大而全的应用，反而可以满足不同用户的特定需求，也可以让我们更好地了解到用户真正需要的东西。”

目前，轻桌面的 Android 客户端工程师也只有许彬一个人。“去年一年，不论是服务还是客户端，我们都积累了非常多内部定义的‘标准化’模块，期望有机会像乐高那样不断组织成有趣的形态。”范怀宇告诉爱范儿，“轻桌面和一览严格意义来说，很多人力是复用的。短期来看，两个产品会各有侧重独立迭代，相关重合的部分，会共同来改进。我们没有严格的划分，就是一个团队。”

“内容和服务一定会离用户越来越近”

2014 年参加一次访谈时，王俊煜这样描述豌豆荚的转型：

现在（2014）的豌豆荚像 97 年的 Yahoo！。移动互联网刚起步，用户也不知道智能手机到底能做什么，所以需要应用分发平台给用户推荐各种 app。

豌豆荚正在从 97 年的 Yahoo！向 99 年的 Google 转变。Yahoo！是一个网站，而 Google 跳过了站点（website）把一个个网页（page）连接起来，注重直接的信息、内容消费。目前移动互联网的 app 把信息隔离、分散了，像大海里的鱼缸，豌豆荚想做的事情就是要把这些分散的信息串联起来。

基于这样的理念，豌豆荚于 2014 年 3 月发布了 “应用内搜索技术协议”，规定了应用内内容的检索、收录和应用调起标准。

2015 年 1 月，豌豆荚发布基于应用内搜索的独立产品 Snap 效率锁屏（豌豆荚 Smart 锁屏），用户不需解锁就可以处理信息。没有安装相关应用，则会直接打开应用的 HTML5 页面。再接下来就是豌豆荚一览和豌豆荚轻桌面。

产品在“注重直接的信息、内容消费”和“串联分散信息”上逐渐深化的同时，豌豆荚也将豌豆荚一览、豌豆荚轻桌面和豌豆荚 Smart 锁屏这三个产品拆分开来，成立联翩科技。

王俊煜告诉爱范儿：“对于应用分发的未来，我自己不敢做太大的预言，但内容和服务一定会离用户越来越近。”而分发 app 起家的豌豆荚，在弱化 app 形态的道路上越走越远。

欧狄

长期关注虚拟现实动态，工作邮箱：oudi@ifanr.com。

邮箱

#欢迎关注爱范儿认证微信公众号：AppSolution（微信号：appsolution），发现新酷精华应用。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

404错误处理：重定向还是直接404？

Wed, 03 Aug 2016 08:00:00 CST

小型网站开发通常会使用某种Web应用框架，比如类似Spring、Express、Django等框架。这些框架会给出自定义错误页面的方式。当404发生时Web框架会渲染并返回对应的错误页面。这是最自然和直接的错误处理方式，但有时我们希望错误页面可以单独Serve，比如放到CDN上。本文档依据RFC 2616（HTTP 1.1）比较几种常见的404错误处理方法：

返回具有404信息的页面，同时给出404状态码。

Google、Github、Facebook、Amazon、Linkedin。
重定向（302/303）至错误URL，该URL给出具有404信息的页面。

百度、淘宝、腾讯

状态码及其语义

使用最广的HTTP标准当属1999年发布的HTTP/1.1， R. T. Fielding 在2000年的博士论文 “Architectural Styles and the Design of Network-based Software Architectures” 中重申如何正确使用HTTP语义以及REST架构风格。符合标准的HTTP消息拥有透明的、自描述的语义，通信方遵循一致的标准才使得整个互联网得以高效地运行。

HTTP状态码对用户不可见，因为Web页面返回给用户之后页面代码并非直接显示给用户，而是经由用户代理（User Agent，比如浏览器、爬虫等）处理。状态码的重要性在于它告诉用户代理当前页面的状态，借此用户代理才能做出正确的操作：比如刷新当前页面，或者访问另一个URL，重置或重新提交表单等等。

HTTP状态码有很多，本文档只关心其中的404，200，以及302/303状态码。

200

请求成功。对于GET，应当返回被请求资源的实体；对于POST，应当返回操作的结果。

   RFC 2616: 10.2.1

The request has succeeded. The information returned with the response
is dependent on the method used in the request, for example:

GET   an entity corresponding to the requested resource is sent in
          the response;
POST  an entity describing or containing the result of the action;

302

被请求的资源暂时位于另一个URI处，并且对于非HEAD/GET请求，用户代理在重定向前必须询问用户确认。

   RFC 2616: 10.3.3

The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.

RFC 1945 和 RFC 2068 规定客户端不允许更改请求的方法。但很多浏览器会将302当做303来处理。

303

被请求的资源暂时位于另一个URI处，并且应当以GET方法去请求那个资源。

   RFC 2616: 10.3.4

The response to the request can be found under a different URI and
SHOULD be retrieved using a GET method on that resource. This method
exists primarily to allow the output of a POST-activated script to
redirect the user agent to a selected resource. The new URI is not a
substitute reference for the originally requested resource. The 303
response MUST NOT be cached, but the response to the second
(redirected) request might be cacheable.

404

服务器未能找到URI所标识的资源。也常被用于服务器希望隐藏请求被拒绝的具体原因。例如403、401可能会被统一处理为404。

   RFC 2616: 10.4.5

The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent. 

This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other
response is applicable.

直接404

直接404是常见Web框架的通用做法：对于每一个用户请求遍历所有可能的路由，如果任何一个控制器都不处理该请求，则Web服务器返回一个具有404状态码的HTTP响应。

404状态码告诉用户代理（User Agent）请求中的URI所标识的资源不存在，用户代理将该HTTP响应的主体（往往是HTML）显示给用户，该HTML页面是终端用户可读的，通常也会包含Not Found信息，以及一些有用的链接。

爬虫是一种特殊的用户代理，通常用于搜索引擎。当搜索引擎的爬虫发现某URI返回404状态码时，会认为该URI已经失效而不对它进行索引，或者将该URI标识的已索引资源移除。所以是网站迁移时，如果一个旧的URI会位于一个新的URI处，应当使用301重定向来告知搜索引擎：该资源并未失效只是位置发生变化。

当我们无法控制服务器返回301时，也可在返回的 HTML中使用特殊标记来告知用户代理这是一个301，这在迁移静态站点时非常有用。

404的一个问题在于不支持CDN。如果为了提升性能使用CDN服务，将 404.html文件托管到CDN提供商，访问该文件显然会返回200状态码。因为CDN服务器认为你所访问的文件存在。

重定向至404页面

在国内网站中更常见的方式是将所有错误重定向至错误页面，比如 error.html。当用户代理访问 error.html时服务器返回状态码为200，这便是神奇的 200 Not Found。 200 Not Found显然不符合HTTP语义标准，下面从搜索引擎和CDN两个方面评价该方法的优劣：

搜索引擎非常不友好。当一个页面Not Found时爬虫并不知情，因为它收到的状态码是303。于是跟随重定向并索引了错误页面 error.html。这意味着该网站会有大量的URL都拥有同样的内容（404页面），网站会因此受到搜索引擎的惩罚而排名下降。

另外作为程序员吐槽一下200 Not Found给调试带来的不便：

脚本、样式或 AJAX 发生 404 时 Console 不显示任何错误；
Accept为JSON或JavaScript的AJAX请求会得到HTML响应体；
<script>标签404会使整个HTML失效。

国内不少公司选择重定向的错误处理方式也必有其优点：

固定的错误页面可以直接托管于CDN，通过CDN统计和脚本的方式来统计错误。
固定的URL可以支持更加松耦合的架构，只需约定重定向URL即可构建前后端通用的错误处理。

参考

RFC 2616: https://www.ietf.org/rfc/rfc2616.txt

冯大辉正式宣布创业：做医疗搜索，跟百度干一架

Tue, 11 Oct 2016 22:07:15 CST

7 月，从丁香园的内部邮件里，我们得知丁香园 CTO 冯大辉已经决定离职。离职期间，冯大辉还与丁香园发生了期权纠纷。作为知名的技术人员和医疗布道者，冯大辉离职后的去向一直备受关注，今天，他通过微信公众号正式宣布，接下来将开始创业。

从 2010 年加入丁香园算起，冯大辉在医疗行业工作超过 6 年，在此期间，他也不遗余力地通过个人影响力普及医疗知识，向公众推广丁香园。冯大辉这次创业同样选择了医疗，不过，是让人稍显意外的医疗搜索。

“我们准备做搜索，垂直搜索。面向医疗和健康领域。我们想提供一个值得信赖的搜索引擎，把高质量的内容和数据提供给广大用户。 简单一点描述：做个搜索，跟百度医疗搜索干一架。”

前有“血友病吧”被卖，后有“魏则西事件”，让百度在医疗信息上的竞价排名和唯利是图倍受指责。事后，尽管李彦宏说对医疗信息的调整使百度一个季度砍掉了 20 亿元的收入，但是，6 月份就有媒体发现， “魏则西事件”后曾一度消失于百度搜索结果中的医疗类“推广”再次出现，并再度出现莆田系的身影。

而一开始就号称拒绝医疗广告的 360搜索（2015 年，360搜索就被发现有大量医疗广告），也借这个事件又刷了一把存在感，再次宣布放弃一切消费者医疗商业推广业务。

市场份额第三的搜狗搜索，9 月份也曾曝出被海淀工商分局立案调查，原因是涉嫌对医疗广告未尽审查义务。

但是，搜索本身是无罪的，现在也依然有很多人把搜索引擎作为寻医问药的入口。冯大辉的目的，就是要做一个提供可信赖的医疗信息的垂直搜索引擎。

当然，这会是一条充满困难的创业路。百度在中国搜索引擎市场占据着绝对统治地位，市值百亿美元的 360 全力加码，加上腾讯重金投资的搜狗，也只拿下不到 30% 的市场份额。一个创业者进入搜索市场，困难可想而知。

PingWest品玩也在第一时间联系了冯大辉，就如在公众号文章中所说，冯大辉说目前还没有详细计划，是从头起步做事。被问到医疗搜索引擎的机会会在哪里，他的回答是，“没机会，这事情机会很小，我只是要做而已。”

今年 2 月，冯大辉曾在《南方周末》发文，阐述 2016 年移动医疗行业即将发生的变化。他认为，医疗创业，必须面对的问题是：第一，提高供给能力；第二，提升医疗资源效率；第三，优化患者对医疗的需求。但是，目前很多医疗创业公司的做法，例如通过补贴“抢夺”医生资源，每天在网上回答在线提问，以及提供线上挂号，都还属于服务流程的边缘性改进。

冯大辉当时给出的解决方法是重构医疗流程的新型诊所。其实在 1 月份，这种所谓的新兴诊所——丁香诊所已经在杭州开业。诊所主打常见病诊疗和慢病管理，有一整套基于微信的电子管理系统，除了预约看病，这套系统还能实现病历管理，医患直接沟通等功能。

从流程上彻底改进医疗体验，这可能也是冯大辉选择做医疗搜索引擎的原因，如果能够成功，或者，它能够“逼迫”百度、360搜索、搜狗们更加认真、负责地对待医疗信息，也是一个让人欣慰的结果。

360：2015年医疗行业搜索行为研究报告

Sat, 02 Jan 2016 10:29:44 CST

您可能也喜欢的文章：
360：2015年Q2化妆品行业研究报告	360：2015年Q3汽车行业研究报告	360：2015年Q3度海淘行业研究报告	360：2015年第二季度P2P行业研究报告	360：2014年Q3汽车行业搜索研究
无觅

厦门搜索分享会及百度之夜干货全解析

Fri, 22 Apr 2016 16:03:15 CST

2016年4月15日，百度搜索分享会及百度之夜在厦门成功举办。会议上,百度表示移动搜索量延续了2013、2014年高速增长的趋势，且在2015年移动搜索日导出量增加了50%，移动化的站点从百度获取流量激增。 从大方向上可以看出有个移动化的网站是从百度获取流量的先决条件。

『移动友好度——搜索排序的重要参考』

在2016年百度会把移动和PC的搜索结果排序重组，更进一步的提升移动页面重要度。百度在移动搜索排序上会更加的重视移动的页面内容。

而在移动站点友好度方面，百度搜索也做出了很多努力，移动网站友好度均值从85%提升到95%，这些变化背后的出发点是从最终用户体验上考虑的。在移动搜索场景中，因为屏幕更小，用户需要体验更好。百度也认为，用户在移动端搜索过程中希望能获得一站式全满足沉浸式搜索体验。

『移动友好度——站点该如何做？』

作为站点我们应该如何配合百度才能更好的获取流量呢？首先是从内功下手，首先是提升页面可视性：页面可读性跟访问、加载有很大的关系，具体包括：功能是否符合用户需求，文本是否清晰、有效，资源上是不是能够让用户方便的获取资源，功能是否可以和用户交互，用户获取到相关服务质量是否优质等都是百度比较关注的点。具体可以参考百度站长平台上站长工具中的移动友好度检测工具和站长学院中的Mobile Friendly1.0标准，根据工具检测结果和移动友好度标准调整页面，增强可读性。

『移动生态——百度移动搜索流量如何分发』

在移动搜索时代，有一些站长可能会抱怨我做一个移动站，百度收录不及时，排序有问题，不用担心，这些都会在短时间内得到解决！百度移动搜索会在2016年在移动生态方面重点发力，加快新站的收录，在排序方面做一些机制优化等。除此之外，在给到站点的参考标准方面除移动友好度的标准外也会开放更多标准，且增多关于站长提交资源的方式，加快后台处理进度，让站点可以和百度一起把移动搜索生态做得更好。

『H5 vs APP——站长如何抉择』

在百度之夜尖峰对话中，阿里巴巴国际站资深总监付必鹏、耐德康赛CEO渠成、最具影响力SEO人之一 Zac及前百度站长平台产品负责人王淘一致表示除了有社交属性的APP外，多数站点做H5都是一种趋势，原因是App较封闭，用户量做大后内容会乏力；检索方面很难做好；没有搜索引擎引流推广很难，从零开始推广成本非常大，所以说做好H5站点是是相对性价比最高的方式了。

『抓取收录与站点优化——站点将何去何从』

在百度之夜上，百度站长平台还强调了两个工具，『链接提交工具』和『关键词影响力工具』。等蜘蛛来抓不如主动出击，链接提交就是最好的出击工具，链接提交主动推送工具的特点就是『快』，天下武功唯快不破，链接提交主动推送工具直接将链接推送给百度，快速推送能带来两方面好处：一是及时发现，可以缩短百度爬虫发现站点新链接的时间，使新发布的页面可以在第一时间被百度收录;二是保护原创，对于新闻网站的最新原创内容，使用主动推送功能可以快速通知到百度，使内容可以在转发之前被百度发现。

『关键词影响力工具』可以帮助站长及时的了解网站关键词的情况。如关键词“新浪”，在百度搜索引擎中为你的网站带来了多少流量，展现量，点击率及排名，呈现前一天、最近7天到30天的关键词影响力指数走势。将重点关注网站关键词通过跟百度搜索的情况对比，了解自己优化该关键词的情况在百度中的地位，关键词对比的情况将以曲线的形式显示。从而更好的优化站点的关键词。

您可能也喜欢的文章：
2014年网民在百度上搜索的那些关键词	Hitwise：2013年6月百度与360占搜索市场份额88.5%	百度：2012年百度搜索热词排行榜	百度数据中心：2009年下半年中国基金行业整体搜索概况	Baidu：2009-2010年百度移动互联网搜索数据
无觅

读paper：腾讯实时推荐实践

Tue, 16 Jun 2015 17:38:51 CST

阅读TencentRec: Real-time Stream Recommendation inPractice

大数据环境下的实时推荐需求，克服三大难题：大数据，实时性，准确度；

大数据，用户数据，业务数据；实时基于storm处理；算法主要基于item-based，content-based，demographic，并且

根据实时特征，结合业务进行创新。

Highlights

1 Traditional recommender systems that analyze data and updatemodels at regular time intervals, e.g., hours or days, cannot meetthe real-time demands.

往往，实时用户意图更能真实的展现用户需求，离线计算的大多数是预测，而且大多数不准。 Traditional recommendersystems cannot make fast responses to users'preference changesand capture the users’ real-time interests, thus resulting in bad recommendationresults。这一块感同身受。

2 实时推荐系统问题，系统性能，数据稀疏性和隐式反馈，算法问题

3 腾讯实时推荐系统主要工作：

大数据环境下，实现传统item-based,content-based, demographic算法，并且将其应用到腾讯各个业务之中；

4 系统架构

（1）平台选择

支持实时计算，高可伸缩性，优秀的容错性能，选择storm

（2）数据访问接口

（3）数据存储

5 算法设计

工业应用实践考虑，易用性和准确度，ROI

（1）item-based CF

处理隐式反馈问题，增量更新，裁剪技术减少计算成本

There are various types of user behaviors in our scenario, includingclick, browse, purchase, share, comment, etc.

通过技术手段，将隐式行为转化为显式评分。

增量更新

更新流程

we utilize the Hoeffding bound theoryand develop a real-time pruning technique

（2）数据稀疏性处理

We develop two mechanisms to solve the data sparsity problem,including the demographic clustering and the demographic basedcomplement.

（3）实时过滤机制

方法1，采用时间窗口，基于session过滤数据；

方法2，根据最近的行为做推荐种子。Besides the sliding window mechanism, we propose a real-timepersonalized filtering technique to serve the individual users' realtimedemands. For each user, we record the recent k items that heis interested in.

6 系统架构

7 应用点

腾讯视频，易迅网，腾讯文学，微信，大众点评，腾讯新闻，qq空间等

参考文献：

TencentRec: Real-time Stream Recommendation inPractice

启发点：

（1）增量更新计算item-basedCF，demographic-based 剪枝

（2）系统性能

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

6月全球搜索引擎市场：百度被Bing取代排名跌至第四

Sun, 05 Jul 2015 12:01:57 CST

199IT原创编译

根据市场研究公司Net Applications最新数据显示，在6月份，全球搜索引擎市场份额冠军依然是Google – Global，占据70.80%的市场份额，环比上月，增加2.26%。Bing与Yahoo – Global分获亚季军，排名各上升1位。相比上月，全球搜索引擎市场份额排名变化较为明显。下面，请看IDC评述网对数据进行详尽分析。

（图1）6月全球搜索引擎市场份额分布图

如图1所示，6月全球搜索引擎市场份额前八强排名情况，环比上月，发生明显变化。其中，百度被Bing取代，排名下滑2位，跌至第4名，位居Yahoo – Globa之后。细究原因，IDC评述网得知，百度份额由10.18%降至7.52%，环比减少2.64%；而排名均上升1位的Bing与Yahoo – Globa，份额依次为9.83%、9.57%，环比增加0.03% 、0.31%。由此观之，百度名次下滑最主要原因是其自身降幅明显所致。

另外，Excite – Global与Lycos – Global排名互换，前者升至第7，后者跌至第8。其余四强排名保持不变。Google – Global仍居首位，环比增加2.26%，份额突破70%，达到70.80%。

（图2）2015年1月至6月全球搜索引擎市场份额走势图

根据图2对比，可知在2015年上半年期间，全球搜索引擎市场份额五强较量中，Google-Global稳居第1，整体呈上升状态。而百度的市场份额则整体呈下降趋势，值得注意的是，在6月份，百度失去了长期以来的第2名席位，滑落至第4名。另外，Bing、Yahoo – Global与AOL – Global的市场份额相对稳定，整体起伏较小，排名依次为2、3、5名。

（图3）6月全球搜索引擎版本市场份额TOP10

由图3可了解到，在6月全球搜索引擎版本市场份额中，最大的赢家依然是Google，共有6个版本进入前十强榜单。其中，Google France代替Google Brazil上榜，排在榜尾。其他5个版本名单不变，Google以23.24%的份额蝉联冠军。

其次，是Yahoo，共有2个版本入围：Yahoo! Web Sites排名第4，Yahoo! Web Sites Japan排名第9，排名均无变化。

此外，Bing与百度各自携带1个版本进入十强。环比上月，百度排名跌至第3，而Bing排名上升至第2，两者排名互换。

转自：idcps.com

SEM经验谈之数据呈现小技巧

Mon, 23 Mar 2015 00:23:45 CST

本篇文章来自我的朋友王硕，他在SEM领域沉浸多年。他将通过一系列文章与大家分享自己在SEM工作中获得的经验。如果你对他的文章感兴趣，或希望了解更多SEM的知识，又或对文章内容有任何疑问，请在本篇文章后留言。

王硕 2009年入行，有5年以上SEM从业经验，第一批通过百度中级认证的从业者。曾在多家知名大型互联网公司任SEM负责人，包括链家地产，百合网，搜狐畅游等。目前在某互联网金融公司任线上广告投放总负责人。对各搜索引擎的关键字广告和网盟等展示类广告的投放和优化工作拥有丰富的经验。

关于SEM的文章，大都在讲，如何搭建账户，如何选择关键词，如何出价等等。但这些并不是SEM工作的全部。即使这些做的都没有问题，在日常SEM工作中，我们仍然会遇到各种各样让我们棘手的困难。根据我这些年的从业经验，恰恰是这些优化之外的问题，带给我们的压力更大。所以，我的SEM文章，会抓住一些能够解决某个日常工作的痛点来写，希望大家在工作中遇到类似问题时，能更加稳妥的进行处理。比如，今天我们就来谈谈，给客户（对于甲方同学来说，老板就是你的客户）呈现数据时的一个小技巧。

大部分SEM优化师，给客户呈现投放数据时，都是把SEM整个的投放数据直接拿出来，例如下面的样子：

客户看到后，一目了然，知道10月20日当天投放总体是一个什么情况。但这样的数据呈现方法，是有隐患的。

我们都知道，SEM的关键词，主要分为，品牌词，竞品词，通用词等。这些词类的划分，本质上是面对的人群不一样。例如品牌词，都是已经知道这个品牌的人，一般来说，品牌词的点击率转化率都会较高，成本较低。竞品词，则是已经知道竞争对手品牌的人，一般竞品词的点击率较差，CPC和成本较高。通用词，是对我们的产品有需求，但没有明确品牌导向的人群，通用词的投放效果，是最考验我们优化师水平的。

既然，SEM不同的关键词对应了不同的人群，那么在不同的人群受到市场消息的刺激后，就会做出不一样的反应。这些就会体现在SEM的数据变化上。最常见的就是，客户做了电视广告。

如果客户做了电视广告，之后看到数据是这样的：

这时，当然是皆大欢喜。但是，电视广告那么贵，客户可能做了几个星期之后，不做了。那么，之后客户见到的的数据，就会是这样的：

这个时候，优化师就比较被动了。我曾经尝试过多种办法向客户解释数据下降的原因，但大多会被客户反驳或质疑，不可避免的降低客户对我们的信任感。例如，我直说是广告投放对SEM的影响，客户会说“你们效果的提升要全指着我们的广告，那你们的价值如何体现 ? ”；如果我说“这是由于新上的一部分词效果不稳定造成的（或者任何一种同类解释）”，客户就会问“何时能恢复之前的效果？”实际上，我们都很清楚，只要客户不再投放广告，无论如何也无法恢复到之前的效果了。随着客户耐心的消失，换优化师是早晚会发生的结局。

那么，怎么避免出现这种情况呢？我的经验是，从初次给客户呈现数据时，就将数据按人群进行拆分，品牌人群，通用人群，竞品人群，潜在人群，等等。并且，给客户进行形象的描述。比如，品牌人群，可以说“这是对我们的品牌已经有所认知的人，点击我们广告，产生的后续行为数据，对于这些人群我们要极力维护我们品牌正面的形象，精彩的广告语，美观的广告图是我们的有力武器”；对于通用词，可以说“这是需要我们的产品，但还不知道选择什么品牌的客户，这些客户往往会对第一次选择的品牌建立极强的品牌忠诚度，是我们极力要争取的客户，同样，他们也是我们的竞争对手极力争取的，所以我们要和敌人进行正面的厮杀，CPC就是我们的武器”。当客户听到这样的数据解读时，往往会很有代入感，也觉得你好专业，对你的信任感爆棚，之后，对你的各种解释，也会做出更加正面的判断。

如果你一直如此给客户呈现数据，那么当遇到前面说的情况时，客户看到的是品牌人群数据先好后坏，通用人群的数据是基本稳定的，那么大可以这样解释“随着我们各渠道广告的停播，对我们品牌产生认知的人群数量出现下降，导致品牌类人群的推广效果出现了下降，这是正常情况，投放前后的数据也说明线下广告对我们的品牌认知起到了预期中的促进作用”。这时客户如果质疑你的说法，大可拿通用词的数据来进行说明：“虽然针对品牌人群的推广随着广告停播出现了效果下降，但在通用人群这个战场上，我们的战绩依然保持了稳定。”

当然，以上只是我个人这些年做SEM工作的经验总结，也许有同学有更好的方法，欢迎大家讨论。

redis超时问题分析

Wed, 26 Feb 2014 22:11:19 CST

Redis在分布式应用中占据着越来越重要的地位，短短的几万行代码，实现了一个高性能的数据存储服务。最近dump中心的cm8集群出现过几次redis超时的情况，但是查看redis机器的相关内存都没有发现内存不够，或者内存发生交换的情况，查看redis源码之后，发现在某些情况下redis会出现超时的状况，相关细节如下。

1. 网络。Redis的处理与网络息息相关，如果网络出现闪断则容易发生redis超时的状况。如果出现这种状况首先应查看redis机器网络带宽信息，判断是否有闪断情况发生。

2. 内存。redis所有的数据都放在内存里，当物理内存不够时，linux os会使用swap内存，导致内存交换发生，这时如果有redis调用命令就会产生redis超时。这里可以通过调整/proc/sys/vm/swappiness参数，来设置物理内存使用超过多少就会进行swap。

int rdbSaveBackground(char *filename) {
    pid_t childpid;
    long long start;

    if (server.rdb_child_pid != -1) return REDIS_ERR;
    server.dirty_before_bgsave = server.dirty;
    server.lastbgsave_try = time(NULL);
    start = ustime();
    if ((childpid = fork()) == 0) {
        int retval;
        /* Child */
        if (server.ipfd > 0) close(server.ipfd);
        if (server.sofd > 0) close(server.sofd);
        retval = rdbSave(filename);
        if (retval == REDIS_OK) {
            size_t private_dirty = zmalloc_get_private_dirty();
            if (private_dirty) {
                redisLog(REDIS_NOTICE,
                    "RDB: %zu MB of memory used by copy-on-write",
                    private_dirty/(1024*1024));
            }
        }
        exitFromChild((retval == REDIS_OK) ? 0 : 1);
    } else {
        /* Parent */
        server.stat_fork_time = ustime()-start;
        if (childpid == -1) {
            server.lastbgsave_status = REDIS_ERR;
            redisLog(REDIS_WARNING,"Can't save in background: fork: %s",
                strerror(errno));
            return REDIS_ERR;
        }
        redisLog(REDIS_NOTICE,"Background saving started by pid %d",childpid);
        server.rdb_save_time_start = time(NULL);
        server.rdb_child_pid = childpid;
        updateDictResizePolicy();
        return REDIS_OK;
    }
    return REDIS_OK; /* unreached */
}

程序1
另外还有一些特殊情况也会导致swap发生。当我们使用rdb做为redis集群持久化时可能会发生物理内存不够的情况（aof持久化只是保持支持不断的追加redis集群变化操作，不太容易引起swap）。当使用rdb持久化时，如程序1所示主进程会fork一个子进程去dump redis中所有的数据，主进程依然为客户端服务。此时主进程和子进程共享同一块内存区域， linux内核采用写时复制来保证数据的安全性。在这种模式下如果客户端发来写请求，内核将该页赋值到一个新的页面上并标记为写，在将写请求写入该页面。因此，在rdb持久化时，如果有其他请求，那么redis会使用更多的内存，更容易发生swap，因此在可以快速恢复的场景下尽量少使用rdb持久化可以将rdb dump的条件设的苛刻一点，当然也可以选择aof，但是aof也有他自身的缺点。另外也可以使用2.6以后的主从结构，将读写分离，这样不会出现server进程上又读又写的情景发生 3. Redis单进程处理命令。Redis支持udp和tcp两种连接，redis客户端向redis服务器发送包含redis命令的信息，redis服务器收到信息后解析命令后执行相应的操作，redis处理命令是串行的具体流程如下。首先服务端建立连接如程序2所示，在创建socket,bind,listen后返回文件描述符：

server.ipfd = anetTcpServer(server.neterr,server.port,server.bindaddr);

程序2
对于redis这种服务来说，它需要处理成千上万个连接(最高达到655350)，需要使用多路复用来处理多个连接。这里redis提供了epoll,select, kqueue来实现，这里在默认使用epoll(ae.c)。拿到listen函数返回的文件描述符fd后，redis将fd和其处理acceptTcpHandler函数加入到事件驱动的链表中.实际上在加入事件队列中，程序4事件驱动程序将套接字相关的fd文件描述符加入到epoll的监听事件中。

    if (server.ipfd > 0 && aeCreateFileEvent(server.el,server.ipfd,AE_READABLE,
        acceptTcpHandler,NULL) == AE_ERR) redisPanic("Unrecoverable error creating server.ipfd file event.");

int aeCreateFileEvent(aeEventLoop *eventLoop, int fd, int mask,
        aeFileProc *proc, void *clientData)
{
    if (fd >= eventLoop->setsize) {
        errno = ERANGE;
        return AE_ERR;
    }
    aeFileEvent *fe = &eventLoop->events[fd];

    if (aeApiAddEvent(eventLoop, fd, mask) == -1)
        return AE_ERR;
    fe->mask |= mask;
    if (mask & AE_READABLE) fe->rfileProc = proc;
    if (mask & AE_WRITABLE) fe->wfileProc = proc;
    fe->clientData = clientData;
    if (fd > eventLoop->maxfd)
        eventLoop->maxfd = fd;
    return AE_OK;
}

程序3

static int aeApiAddEvent(aeEventLoop *eventLoop, int fd, int mask) {
    aeApiState *state = eventLoop->apidata;
    struct epoll_event ee;
    /* If the fd was already monitored for some event, we need a MOD
     * operation. Otherwise we need an ADD operation. */
    int op = eventLoop->events[fd].mask == AE_NONE ?
            EPOLL_CTL_ADD : EPOLL_CTL_MOD;
    ee.events = 0;
    mask |= eventLoop->events[fd].mask; /* Merge old events */
    if (mask & AE_READABLE) ee.events |= EPOLLIN;
    if (mask & AE_WRITABLE) ee.events |= EPOLLOUT;
    ee.data.u64 = 0; /* avoid valgrind warning */
    ee.data.fd = fd;
    if (epoll_ctl(state->epfd,op,fd,&ee) == -1) return -1;
    return 0;
}

程序4
在初始话完所有事件驱动后，如程序5所示主进程根据numevents = aeApiPoll(eventLoop, tvp)获得io就绪的文件描述符和其对应的处理程序，并对fd进行处理。大致流程是accept()->createclient()->readQueryFromClient()。其中readQueryFromClient()读取信息中的redis命令-> processInputBuffer()->call()最后完成命令。

void aeMain(aeEventLoop *eventLoop) {
    eventLoop->stop = 0;
    while (!eventLoop->stop) {
        if (eventLoop->beforesleep != NULL)
            eventLoop->beforesleep(eventLoop);
        aeProcessEvents(eventLoop, AE_ALL_EVENTS);
    }
}
int aeProcessEvents(aeEventLoop *eventLoop, int flags)
{-------------------------------
 numevents = aeApiPoll(eventLoop, tvp);
        for (j = 0; j < numevents; j++) {             aeFileEvent *fe = &eventLoop->events[eventLoop->fired[j].fd];
            int mask = eventLoop->fired[j].mask;
            int fd = eventLoop->fired[j].fd;
            int rfired = 0;

            /* note the fe->mask & mask & ... code: maybe an already processed
             * event removed an element that fired and we still didn't
             * processed, so we check if the event is still valid. */
            if (fe->mask & mask & AE_READABLE) {
                rfired = 1;
                fe->rfileProc(eventLoop,fd,fe->clientData,mask);
            }
            if (fe->mask & mask & AE_WRITABLE) {
                if (!rfired || fe->wfileProc != fe->rfileProc)
                    fe->wfileProc(eventLoop,fd,fe->clientData,mask);
            }
            processed++;
        }
}

程序5
从上述代码可以看出redis利用ae事件驱动结合epoll多路复用实现了串行式的命令处理。所以一些慢命令例如sort，hgetall,union,mget都会使得单命令处理时间较长，容易引起后续命令time out.所以我们第一需要从业务上尽量避免使用慢命令，如将hash格式改为kv自行解析，第二增加redis实例个数，每个redis服务器调用尽量少的慢命令。

基于Item的时序协同过滤算法

Wed, 06 Aug 2014 15:14:42 CST

基于Item的时序协同过滤算法技术方案包括两个步骤：

（1）提取用户商品点击日志、搜索点击日志和商品基本信息等基本数据。然后，去除噪音数据（譬如每天点击商品数达到数以万计的用户）和缺失值数据，构建时序点击流数据，即记录用户每天按照点击时间先后顺序排序的商品行为数据。从而得到如下数据结构：<用户id，商品id，点击时间，点击日期>；

（2）时序协同过滤算法构建模块，根据数据预处理阶段的得到的商品点击时序数据集，在ODPS平台上实现该算法算法，计算商品之间的相关性。

时序协同过滤算法

步骤1：计算商品之间相关性

Map阶段

输入：key（行记录标识）， value（用户id，商品id，点击时间，点击日期）

输出：key（用户id，点击日期，点击时间）， value（商品id，点击时间）

Reduce阶段：

输入：key（用户id，点击日期，点击时间）， value（商品id，点击时间）

输出：ODPS Record(点击日期，商品1，商品2，相关性分数)

计算相关性分数算法：

计算每个用户每天的点击时间序列对，按照升序排列，即<商品1，点击时间1>,<商品2，点击时间2>,…,<商品n，点击时间n>；
在每个用户的商品点击序列中，如果两两商品时间序列对的点击时间差小于等于两个小时，则表示这两个商品具备相关性；计算出有效时序商品序列<商品1，商品2，商品3，…，商品n>；
计算商品之间的相关性,公式如下:

，其中score表示相关性分值，delta表示任意两个商品之间的时间排序位置之差

步骤2：计算每天商品之间相关性均值，减少噪声数据，譬如用户无意图的商品点击序列

Map阶段

输入：key（行记录标识）， value（点击日期，商品1，商品2，相关性分数）

输出：key（点击日期，商品1，商品2）， value（相关性分数）

Reduce阶段

输入：key（点击日期，商品1，商品2）， value（相关性分数）

输出：ODPS Record(商品1，商品2，相关性分数均值)

步骤3：计算每月商品之间的相关性，减少噪声数据，去除异常的相关性数据

Map阶段

输入：key（行记录标识）， value（商品1，商品2，相关性分数）

输出：key（商品1，商品2）， value（相关性分数）

Reduce阶段

输入：key（商品1，商品2）， value（相关性分数）

输出：ODPS Record(商品1，商品2，相关性分数均值)

参考：

http://blog.sina.com.cn/s/blog_61c463090102uwqu.html

http://www.aliyun.com/ odps

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

从未降级的搜索技术-实时之刃

Tue, 09 Dec 2014 17:00:16 CST

流量是互联网变现的基石，而流量的资源是有限的，如何实现资源的最大化利用（买家-商品的最高效的匹配）是此次双11搜索技术深度切入的使命，也是第一次在双11通过实时把握资源流动的脉搏来控制资源的收和放。

一. 问题发现

天猫的业务团队同学，通过针对去年双11细致认真的数据分析，发现了去年双11暴露的一些问题。预热期

小部分商品预热过度，预热期吸引的加购量远超出商品库存能支撑的量，大部分用户虽然加了购物车但当天也抢不到，购物车转化率低；而大部分商品预热不足，没有充分曝光；
活动期间商品的加购行为和历史行为差别巨大，离线（ T-1）天的数据无法真实反映商品的实时受欢迎程度；

双11当天

即将售罄的热销商品仍然获得了大量流量，剩余库存无法支撑短时间内的大用户量；主售款（热销 sku）卖完的商品获得了流量，用户无法买到商品热销的 sku，转换率低;
和预热期一样，活动期间，商品离线（ T-1）天的数据无法真实反映商品的实时的受欢迎程度;

二、问题解决

问题是很明显了，那么如何来解决呢？总体来看，无论是预热期还是双11当天，就是要降低资源（流量）浪费和提升资源（流量）利用率。

降低流量浪费层面，首先来看预热期，就是如何避免一个商品由于过度曝光（pv），使得加购总量所能带来的潜在成交笔数超出其库存，导致大量交消费者即使加购，当天也无法下单；那我们就要建立一个合理调控商品展示的机制来实现。我们根据一个商品的长期，实时的加购历史，预测出它在双11当天能够拿到的成交量，当成交笔数超出该商品的库存承受能力时，降权分将会在商品排序中发挥作用，来减少该商品的曝光机会，通过有效的流量引导来减缓该商品的加购，从而减少无效加购的总量，提高双11当天购物车的转化率。

接着来看看双11当天，理性和非理性消费者的购物欲望都在这一天得以释放，流量暴增，如果一个商品即将销售一空却仍然获取大量的曝光和点击，带来的体验必然是很多消费者铩羽而归，同时浪费了宝贵的流量资源。如何来避免呢？同预热期一样，我们要建立一个合理的商品展示调控机制，我们根据商品的成交记录，预测出商品销售速度，这样根据商品的剩余库存除以销售速度，就能预判出该商品从当前时刻起还有多少时间就会售罄；系统可以根据即将售罄的时间长短建立不同粒度的降权分，从而有效的调节即将售罄商品的曝光机会。除了降权逻辑，我们也需要给那些表现突出的商品给与更多的曝光机会，提升流量转化效率。

接下来我们就从系统技术架构方面来加以阐述；算法方面具体细节不便透露

五角星的部分都是此次实时流量调控的重要核心模块：

PORA：PORA是搜索离线团队针对实时个性化业务场景打造的一套离线实时计算系统。它能实时同步海量用户日志，对每一条日志关联相关数据并驱动执行相关算法业务模块，产出数据自动更新下游在线服务。整个过程通常在秒级别完成，这样用户实时行为可以在几秒内就对搜索排序等线上服务产生影响。为灵活支持业务需要，PORA针对不同个性化场景提供了业务层的平台抽象，解决了所有算法不需要关心的工程问题，并通过接口和插件机制集成所有的算法模块。这样算法只需要遵循接口，专注于实现从输入用户数据到输出下游数据的算法逻辑本身，而无须关注数据同步、提取、存储、查询、更新等复杂的前后工程逻辑，也无须担心海量实时数据对系统的冲击，从而最大程度降低了算法开发成本。

具体到本次双11实时流量调控需求，PORA需要实时接入预热期和双11当天全网用户的所有点击、加购、成交行为日志，按商品维度累计相关行为数量，并实时关联查询商品库存信息，提供流量调控算法插件进行实时售罄率和实时转化率的计算分析，并将插件计算出的字段更新实时同步给主搜、商城、店铺内搜索引擎，天猫推荐平台，流量直播间等下游业务。其中，双11当天的用户访问压力是平常和预热期所难以想象的，业务方对此评估后给出了50w/s的预测峰值QPS，PORA需要确保在这样的高压力下仍然保持端到端秒级实时更新。

UPS：UPS是搜索技术部门提供个性化服务存储计算的在线系统，承担了包括搜索个性化在内的众多业务线上全量实时KV/KKV数据的低延迟的存储、查询和计算服务。在本次双11实时流量调控中，UPS在提供用户个性化数据等原有服务的基础上还存储了PORA实时更新的流量调控数据，供下游天猫双11直播间使用。

Isearch5: ISearch5是搜索最新一代引擎平台，服务于淘宝、天猫、B2B等各个搜索业务线，支持秒级实时索引、辅表等众多新特性。在本次双11实时流量调控中，PORA产出的实时售罄率和转化率字段正是通过Swift消息实时更新的索引字段。ISearch5引擎中还包含一个战马框架可以支持嵌入算法的排序模块，算法在对应的流量调控排序模块中可以获取到PORA实时更新至引擎的售罄率和转化率字段值，从而实时影响排序结果，达到调控流量的目的。

SP ：SP是搜索面向前端应用的统一服务接口，根据用户指定的查询条件制定查询计划，查询包括QP/UPS，ISearch5引擎在内的各个搜索后端系统，得到最终结果返回个前端。SP通过将业务逻辑从前端往后端下沉，简化了搜索调用逻辑，提升了前端系统性能。

BTS 服务：BTS是搜索的分桶测试管理服务，搜索的一次服务首先从BTS中获得自己所属的测试，BTS确保一个用户的前后多次访问获取到的始终是相同结果，测试信息作为一个查询条件通过SP传给后端各个系统，后端据此可以进行分桶测试。具体到本次双11的实时流量调控需求，引擎的战马框架中配置的算法排序模块会根据传入测试信息不同进行不同权重的流量调控排序，从而帮助算法对比和优化模型。

下面从系统层面讲一下这几个环节如何默契的配合来实现实时的流量调控的。用户无论是通过PC还是无线每次点击/加购/成交一个商品，都会产生一条对应的行为日志，这个行为日志通过集团的日志实时传输系统TT（TimeTunnel）实时进入PORA系统，PORA取到这条日志的同时会实时关联获得包括商品实时库存在内的相关商品数据，并以商品为单位累积对应的点击/加购/成交数据，提供算法插件进行实时售罄率和转化率的计算更新，得到的数据更新自动同步给下游的ISearch5引擎、UPS和天猫推荐接口。整个过程在几秒内自动完成，当新的用户再发起搜索请求时，先从BTS获得自己的测试信息，由SP将搜索请求连带测试信息传输至ISearch5引擎，引擎内部的战马框架根据测试信息选择对应的算法模型，算法模型在对引擎查询返回的商品列表进行排序时，可以获取列表中所有商品经过PORA更新过的最新售罄率和转化率数据，对即将售罄的商品进行降权，对转化率高的商品进行加权，从而完成实时流量调控的目的。其中不同测试可能对应不同的算法模型，不同模型的降权和加权力度可能各不相同，因此各个分桶测试下算法的流量调控效果也各不相同。BTS服务的高效便捷性可以允许算法同学当天根据实时报表来切换排序策略。此次实时流量调控不仅仅服务于搜索业务本身，也同时通过UPS和相关接口输出实时武器给兄弟团队（天猫推荐，直播间，店铺内搜），来共同优化业务效率。

三、双11流量调控效果

在进入效果数据review之前，需要明确指出一点，下面给出的数据都是基于AB-test机制得到实际效果，基准桶与测试桶除了在实时流量调控环节有差异外，所有其他的环节都保持一致，因此实际的效果对比数据都是能够反映算法调控的真实效果。

3.1 预热期效果

首先我们来看下预热期从以下几个指标下的对比效果；预热期加购量及其引导双11当天成交金额

	加购量提升	引导当天成交金额提升
主搜索PC	10.8%	5.3%
无线andriod	13.4%	5.5%
无线iphone	16.2%	11.4%

无效加购量对比

	无效加购减少
主搜索PC	-37.6%
无线	-12.4%

3.2 双11当天效果

接下来再看看双11当天的效果。系统运行情况：双11当天PORA在0-1点的最高峰QPS超过35万/s，主要的点击和成交行为日志平均延迟除0点后10分钟内出现波动最高到过20秒外，全天维持在正常的几秒范围内。当天累计共更新5.5亿条实时增量索引。算法效果：在双11当天我们关注的主要指标：成交相关指标

	金额提升	转换率提升	uv价值提升
主搜索PC	4.7%	6.5%	4.7%
无线andriod	7.4%	10.7%	7.4%
无线iphone	6.9%	8.3%	6.7%

四、改进和未来的发展

今年双11是我们第一次大规模的实时调控流量，数据指标给了我们很大的信心，但是模型里面的很多参数是根据去年双11的数据计算出来的，在后续的工作中我们会通过在线学习的方式，利用今年实时的数据训练实时模型，进一步提升效果。

从未降级的搜索技术

Fri, 21 Nov 2014 11:16:33 CST

在搜索我经历过全部的双11，12年和13年这2次大促，GN是开发总指挥，我是在礼台上看各种新武器实弹表演。过去6年里，我们的引擎体系每年做到100%的性能提升，以淘系搜索为例，从最初3000台机器翻倍到现在区区6000台，但搜索服务却从6千qps增长了40倍到现在的32万qps，同时还填补了算法欲壑（算法数据占用内存从最初的10%到了现在的50%），转化率持续攀升，目前大搜索GMV已经是全网的主体了。搜索工程师的双11历来是实弹各种新武器的大机遇，而常规的技术保障已经成为踩在脚下的底线。实施任何一种降级预案都被我们视为耻辱，因为预案都是以伤害用户体验为代价的。在技术保障部双11总指挥群里此起彼伏的降级通告里面，从来没有过搜索的身影！

14年双11大促总指挥是YF，搜索焦点集中在要检阅的5件新武器上：

天猫售罄率预估，商品加购和交易后及时预测它的售罄时间，通过降权或者加权提升搜索结果页每一个位置的价值，搜索GMV可提升10%。
天猫SKU搜索，颜色尺码等sku属性参与检索。引擎平台实现了子文档检索功能，将原来集群拓展五倍规模才能做到的天猫SKU在原有基础上增加60%即可实现。
Hippo引擎在线管理系统，机群变为可灵活流动的三维架构，第一维度是根据商品质量或类目划分子机群，下面才是传统的二维行列架构，这带来的好处是查询性能的巨幅优化。
离线集群HBase升级0.98，近700台机器的离线集群上各业务线分头开发累积导致集群效率底下，支持售罄率预估也要求我们把调优经验更厚实的0.98版本升级上去。
搜索分层优化GMV，借助Hippo系统主搜根据商品质量划分子机群然后在业务服务层聚合，搜索GMV可提升6%，整体性能大幅提升80%。

10/17，离双11还有段日子，下午我常规心血来潮找XD了解Hippo的进展，结果却触动了我的神经，我们都希望看到Hippo在双11上线主搜和天猫实战检验，但GD坚持把统一到A8机器的运维工作一并完成（稍显保守），因为这需要补充近300台A8的机器，而机器已经拖延几个星期了，本该9月底完成上线的Hippo到了10/17看来机会渺茫，引擎体系奔向世界级的路上焉能贻误战机！更有甚者，售罄率预估与天猫SKU搜索这两个业务项目都依赖Hippo，业务项目要是延误可是要掉脑袋的，念及此处我没有心情观礼了。要知道，主搜天猫加上这些A8升级后，还要退出来低配机器给其它搜索服务扩容，上下游一系列连锁依赖都嗷嗷待哺需要时间呀。紧急状态，不得不对搜索工程各相关团队发起动员了。Hippo必须不能够等待A8的到来尽快上线检验，要打破常规的水平分工来一场混战了。我直接请YL担任紧急状态下引擎端的负责人，飞行时更换引擎是我们起步时代的杀手锏，今天必须成为我们的底线。

10/27日，紧急状态的第10天，ZY和GD在各应用集群间辗转腾挪，终于完成了Hippo上线和天猫SKU搜索上线；插件小组完成了售罄率预估上线，把主搜性能提升了30%；LT和XY在QA小组的陪伴下解决了各组件的core与慢，CS也分批交付了A8机器。淘宝搜索、天猫搜索、店铺内搜索、店铺搜索共四个核心应用的淘系搜索达到了40万qps服务能力。这火热的十天，恰好也是CS和GD的陪产假。

现在我是不是可以高枕无忧重上观礼台了呢？此次要实弹的新武器只有Hippo和天猫SKU搜索踏实了，而售罄率预估所需离线集群HBase升级后鲜有指标超越升级以前，全链路压测未能成功。更为甚者，TM根据10月份无线端流量情况，把对搜索的要求从10万qps提升到了15万qps，也就是说现有的40万qps整体能力必须提升到45万qps！而多出来的5万qps要求又只能实打实落在最大的主搜索集群上，目前的优化手段已经用尽，降级是容易的也是耻辱的，怎么办？崩溃前奏，我冷汗直冒，尽管现在是YF担任总指挥。

搜索分层优化GMV成了救命稻草，尽管已经在无线全量上线并拿到了大部分性能成果，已经体在现有40万qps的服务能力里。但在PC端上线却因为对广告的负面影响而步伐迟缓，这里还有100台机器可以省下来。此外协同搜索是主搜的辅助引擎，这有200台机器不得已可以下线。分层优化GMV和协同检索一上一下恰好可以抵消GMV损失，同时又能节省300多台机器。紧急关头，老板给我们亮了黄灯，暂时下掉代表搜索体系技术一大进步的协同关系搜索是我此次最大的遗憾。

11/7日，紧急状态的第20天，大促准备的战场收尾之后，全淘系搜索在线服务规模达到了2500台机器，搜索服务能力推高到至45万qps，此外还有推荐服务能力到了12万qps，以及4万qps的AE引擎服务能力。已成为集团基础设施的opensearch在那个周末还有个插曲，HT应淘点点要求紧急把集群扩容到4万qps。至此万事俱备，欢度周末之后我准备上观礼台了。

11/10日21点到11日晚12点共27个小时，5种新武器实弹表演渐入佳境，事后回顾流量高峰在最初的4小时就已经到来了，尽管11日白天来势汹汹比前一天高出一倍不止，但到了晚上涨幅回落基本和10日持平了。观礼过程最为惊险的在11号上午8点到12点这段期间，对IC销量字段的更新度预估不足，导致天猫引擎有约半小时的延迟，售罄率预估也无法开启；无线推荐因为上游降级而流量大损峰值只有4万qps（上限12万qps）。在这27个小时里，搜索峰值是32万qps（上限45万qps），其中最大的份额来自手淘搜索峰值10万qps（上限15万qps）。手淘UV只到了理想目标的60%，真要是满负荷过来的话，手淘搜索峰值会突破上限15万qps而达到16.7万，那么等待我们的唯有耻辱降级一途！售罄率预估当天开启12个小时，对成交转化提升达到了10个百分点。Opensearch的服务大大低于预期只跑到了7千qps。最后AE的大促意外交出了完美的业务答卷，同时引擎后台服务真的一度达到了3.2万qps（上限4万qps）。

迄今为止的每一次大促搜索在线服务都没有任何形式的降级，无论是天猫还是淘宝还是SC/AE还是1688，这一次游走在天堂和地狱之间，我们更清醒的认识到，技术进步永无止境！

一个完整推荐系统的设计实现-以百度关键词搜索推荐为例

Wed, 17 Sep 2014 20:39:36 CST

在之前一篇博文中，有同学在评论中问了个问题：如何解决因式分解带来的推荐冷门关键词的问题。在回答这个问题的时候，想到了近几年在做搜索推荐系统的过程中，学术界和工业界的一些区别。正好最近正在做技术规划，于是写偏文章说下工业界完整推荐系统的设计。结论是： 没有某种算法能够完全解决问题，多重算法+交互设计，才能解决特定场景的需求。下文也对之前的一些博文进行梳理，构成一个完整工业界推荐系统所具有的方方面面（主要以百度关键词搜索推荐系统为例）

完整的推荐系统肯定不会只用一种推荐算法

在学术界，一般说到推荐引擎，我们都是围绕着某一种单独的算法的效果优化进行的，例如按内容推荐，协同过滤（包括item-based, user-based, SVD分解等），上下文推荐，Constraint-based推荐，图关系挖掘等。很多比较牛的单个算法，就能在某个指标上取得较好效果，例如MAE，RMSE。。。不过有自己的优点，每种算法也有自己的缺点，例如按内容推荐主要推荐和用户历史结果相似的item，一般的item-based容易推荐热门item（被更多人投票过）。。。。所以在工业界，例如各互联网公司，都会使用多种算法进行互相配合，取长补短，配合产品提升效果。而且在 完整的推荐系统中，不仅有传统的Rating推荐，还需要辅以非常多的挖掘， Ranking来达到预期效果。

推荐系统3大件：User Profile、基础挖掘推荐、Ranking

在实践中，一个完整的推荐系统会主要由3部分组成：

User Profile
基础推荐挖掘算法
Ranking

以下为整个推荐的数据流：

User Profile

用户兴趣数据
用户的基础注册信息，背景信息：例如用户出生地，年龄，性别，星座，职业等。这些信息一般从用户注册信息中获取；例如高德，百度地图注册用户，淘宝注册用户等
用户行为反馈：包括显示的反馈(explicit)和隐藏(implicit)的反馈，显示的反馈包括用户的评分，点赞等操作，百度关键词搜索推荐工具上的点赞（正向显示反馈）和垃圾桶（负向显示反馈），淘宝上的评分；隐式反馈包括用户的浏览行为，例如在百度关键词搜索推荐上搜过那些词，淘宝上点击了那些页面，在高德上点击了那些POI等
用户交互偏好：例如用户喜欢使用哪些入口，喜欢哪些操作，以及从这些操作中分析出来的偏好，比如在高德地图上根据用户行为反馈分析出来的用户对美食的偏好：更喜欢火锅，粤菜，还是快餐
用户上下文信息：这些信息有些是分析出来的，例如在LBS中分析出来的用户的家在哪儿，公司在哪儿，经常活动的商圈，经常使用的路线等

user profile经常是一份维护好的数据，在使用的时候，会直接使用该数据，或是将该数据存储在KV系统中，供Online系统实时使用。在搜索或是推荐的场景下，每次请求一般只会涉及到一次user profile的KV请求，所以online使用的时候，主要的实现困难是存储。

基础挖掘推荐算法

基础挖掘推荐算法，主要使用传统推荐算法，结合分析的item profile和user profile，建立user和item的关系，此时并不会过多考虑其他因素，例如是否冷门/热门，最主要的就是 建立user和item的关系。 在各种论文中狭义的推荐，主要就是指该部分内容。主要围绕着Rating，以及Top N进行该处的Top N（更像是直接Rating值最高的Top N）传统的推荐算法研究主要围着这块工作进行，现在已经有很多比较成熟的算法，这些算法相关的研究可参见博文：《推荐系统经典论文文献及资料》；其中也能找到业界较多成功推荐系统的实践分享主要包含以下几类：

Content Based推荐：按内容推荐，主要的工作是user profile, item profile的提取和维护，然后研究各种相似度度量方法（具体相似度度量参见博文：《推荐系统中的相似度度量》）
协同过滤：相当于应用了用户的行为进行推荐（区别于Content based算法），比较经典的算法包括传统的item-based/user-based算法（参见博文：《协同过滤中item-based与user-based选择依据》，《 collaborative-filtering根据近邻推荐时需要考虑的3要素》），SVD，SVD++(具体原理及源码参见博文：《 SVD因式分解实现协同过滤-及源码实现》)
上下文相关推荐：和传统推荐相比，考虑更多上下文因素，LBS，移动场景下使用比较多（具体参见博文：《 context-aware-recommendation》）
基于图的关系挖掘推荐：主要是利用图论原理，根据item,user之间的数据，反馈关联关系，挖掘更深层次的关系进行推荐，该类方法一般效果都不错，当然资源要求也较高。具体参见博文：《级联二步图关系挖掘关键词推荐系统》，《频繁二项集合的hadoop实现》《 itemrankrandom-walk-based-scoring-algorithm-for-recommener-system》
Constrainted-based推荐：根据限制性条件进行演绎推荐

算法效果衡量

Ranking，此部分是成熟的搜索，推荐系统具有的核心逻辑

相关性： item与用户的相关性，这是大多数搜索和推荐任务的基石，例如在搜索中判定一个query和一个document的相关性，或是一个query 和另一个query的相关性，或是在特征比较多的情况下，一个user 和一个item 记录的相关性；实现方式可以很简单，例如传统的相似度度量方式（参见博文：《推荐系统中的相似度度量》），对于文本，业界使用简单的TF*IDF，或是BM25；不过很多时候我们需要增加更多维度特征，包括推荐item本身的重要性，例如IDF，Pagerank(具体参见博文：《 pagerank的经济学效用解释》)，同时使用模型来提升相关性判断的准确性。使用模型的方式会更加复杂，但效果提升也非常明显。具体可参见博文：《集成树类模型及其在搜索推荐系统中的应用》，《分类模型在关键词推荐系统中的应用》，《 adaboost》
推荐的上下文：例如推荐产品的入口，交互方式，不同的入口，甚至同一入口的不同交互方式，推荐的结果有可能都需要不一样；在LBS生活服务中，请求发生的时间，地点也是推荐需要重点考虑的上下文因素，例如饭点对餐饮item的提权；异地情况下对酒店等结果的加权等
CTR预估：成熟的商业系统都会使用模型来完成CTR预估，或是转化预估
以及商业业务规则：例如黑白名单，或者强制调权。例如在百度关键词搜索推荐中，某些有比较高变现潜力的词，就应该加权往前排；比如在高德LBS服务中，有些海底捞的店点评评分较低，但我们也应该往前排；或是在搜索引擎中，搜国家领导人的名字，有些最相关的结果可能因为法律因素是需要屏蔽的

算法评估

系统效果监控

交互设计

一些交互的例子参见博文：

《关键词推荐工具中的用户引导机制之一：总述》

《关键词推荐工具中的用户引导机制之二：suggestion架构》

《关键词推荐工具中的用户引导机制之三：相关搜索query技术》

《关键词推荐工具中的用户引导机制之四：种子query推荐》

说了那么多，中心就是想说明，一个完整的推荐系统，远远不止是一两个rating算法能够覆盖的，而且此处还未涉及工程部分。

更多内容，也可直接访问： http://semocean.com

搜索引擎变现策略指标体系

Sun, 29 Jun 2014 18:44:20 CST

下文就百度商业变现的指标体系进行概要描述，并针对一个类似于百度LBS系统的变现思路，阐述一个商业系统变现策略指标体系的建立过程。

为什么需要商业变现策略指标体系

一般情况下，一个互联网产品，或是一个移动端产品在发展前期，主要会关注流量及用户量的增长。当流量，用户量做到一定程度时，就会考虑商业变现。例如今日头条，美丽说，高德地图这样的产品现在都开始商业化变现。而要从变现效果，效率衡量整个系统，以及监控技术策略对系统变现的贡献时，就需要建立一套完善的策略指标体系监控系统当前的状况，发现系统策略效果瓶颈并有的放矢地去提升。

之前在百度，在和一位高级技术经理聊天时，他就说过，之所以百度内部一位从Google过来的VP很受老板的重视，一个非常大的贡献，就是他推动百度凤巢指标体系建立，保证公司收入灵活可控，保证每次百度都能在华尔街交出漂亮的财报

指标体系包含的内容

广告主关心的指标

在广告界的人士都知道广告主的这样一句名言：“我知道我投入的广告费用的一半是白费钱财，但问题是，我不知道是哪一半”。而搜索引擎的搜索一大优点，就是能够监控每一次搜索点击的效果。

对百度广告主来说，他们最关心的，和所有的商业投资一样，是：投资回报率（ROI）。广告主们（商家）想知道在百度体系的广告的投入是否真的有回报，而这个回报是否能够超过投入的资金，超过的比例有多大，这一点上，搜索引擎商业变现系统是做了精心的设计的：

从商家的角度理解ROI，就要了解三个指标：

1． 广告展现次数（简称show）：当网民提供关键字，使用百度的搜索业务时候，相关的广告也会根据算法出现在页面相应的位置，用户投放的广告的展现次数，每天，每周，每月都会有统计。当然，相对于传统的广告投放模式，只要展现了就要收费，百度对展现的广告是不收费的，哪怕用户看到了广告主企业的名字和推广口号，广告主已经获得了一定的广告收益，是要用户不点击广告链接，广告主不需要支付任何费用（针对竞价排名高，和右端广告而言）。这在传统的广告界是不可想象的，因为传统媒体，例如电视，包括门户网站上的banner广告，都是按照展现收费的：看到一次收一次的费用。

2． 广告点击次数（简称clk） ：用户看到广告后，点击了广告主提供的链接。可以用每千次广告展现的点击率来计算。网民点了推广信息的链接。推广信息被点的次数被称为点击量，即Clicks，产生的费用叫做点击费用，平均到每次点击的费用被称为单次点击价格，即CPC，是Cost Per Click的缩写。推广信息点击量与展现次数之间的比值被称为点击率，即CTR，是Click-Through Rate的缩写，计算公式为：点击率=（点击量/展现量）×100%

3． 点击率到商业收益的转换：用户点击了客户的广告，就会看到客户自己的网站页面，如果被客户提供的商业服务或者产品所吸引，而付费的话，那么客户就实现了一次成功的商业收益

因为商业系统必须要保证客户（广告主）的利益，这样才能长久合作，所以商业变现策略指标体系必须包含这些指标。

在类似于百度，360，或是Google这样的搜索引擎，其能精准监控的，就是1，2，对于最终的商业转化，因为是在商家的网站上完成的，所以除非网站上内嵌了搜索引擎单独提供的独立工具（例如百度的福尔摩斯），否则搜索引擎无法了解这些信息。

投资人关心的变现策略指标

以上是百度广告主需要关心的指标。对于百度这样的上市公司，每个季度的财报中都需要有公司详细的赚钱相关财报内容及各种指标分解，以便了解当前变现系统的健康程度及瓶颈及后续的突破点。

例如百度的投资人不仅关心这个季度百度多挣了多少钱，还会关心多挣的这些钱是来自于哪个环节的提升，是否可持续，是否后续还有增长空间。就和分析公司财务报表，或是分析股权收益率一致。

为了让大家对搜索引擎变现策略指标体系有一个对比了解，以下先用股权收益率说明问题。大家可以不用有较强的金融，财务知识也能看懂这个公式，而搜索引擎变现策略的指标体系，与此公式有异曲同工之处，都是将最终的收益（率），分解为各个相对独立的因素，以便发现系统挣钱效率的优势与瓶颈。

该公式主要的目的是让大家了解如何对最终目标指标进行拆解，如果大家不感兴趣可以跳过该节。

股权收益率

即在股市中，投资人购买的股票收益率，设想一下，一个精明的投资人，在购买了某个公司大宗股票后，一方面会关注每年的股票收益，另一方面也会分析股权收益是来自于哪些因素的上涨，这样才能分析公司增长是否健康，例如，股权收益率可以简单地使用以下公式计算ROE=净利润/权益。但如果要对这个公式进行细分，将其中对股权收益率相关的影响因素均拆分出来，那可以得到以下公式：

其中

税收负担比例：反映公司的税收负担情况，例如有一个季度百度的税率为腾讯的一半，因为百度和国家有什么高新技术的合作所以税收减免（记得百度可能是7%左右，腾讯13%左右，不是精确比例），类似的情况就可以在（1）中反映
为公司向债权人负担的利息比例，借的钱越多，这个值越小
利润率：为每一块钱的销售额所带来的利润。
资产周转率：为公司资产的使用效率，例如家乐福，沃尔玛虽然利润率很低，但因为出货量大，所以照样赚钱
杠杆比例：公司资产与公司权益的比例，用于表示用于赚钱的钱中，有多少是自己的，有多少是别人的（例如银行）。例如：北京以前买房的人都发了，因为买的早，一方面房价便宜，一方面使用银行贷款，假设30%首付，那相当于剩下70%银行贷款在房产上的收益，也是自己的。

类似地，如果对百度商业变现体系的收入进行一个拆解，也能将其分解为类似的独立因子，对系统效率进行细化分析。

搜索引擎投资人关心的变现策略指标

从宏观上，我们假设投资人都是唯利是图的，收入是他们最关心的事。当然，很多投资人也会兼顾长远的收益，所以他们会关系收入是如何组成的。我们这里抛开运营，股权收益，利息支付，税收等各种公司的开销，我们仅考虑变现系统的名义收入，即搜索引擎中计费系统的计费和。此时可以将搜索引擎收入分解为以下独立因子：

**Revenue =PV * PVR * ASN * CTR2 * ACP**

以上公式就是百度，360，Google搜索广告变现收入的拆解。

要弄清楚以上公式的具体含义，需要了解下列指标的定义：

CPM1：cost per thousand1 按每千次检索收费，百度用户每使用百度一千次做搜索为百度带来的收益。也就是用户使用了百度服务一千次所带来的百度的收入。这个是衡量百度赚钱能力的重要指标。是百度变现能力的基本衡量标准。是根据每个季度的总收入除以PV（Page View）算出来的。
CPM2：cost per thousand2 按每千次展示收费，广告所在的网页被浏览了一千次，即认为该广告展示了一千次。这个指标是衡量广告客户的广告展现了一千次的时候，客户交付的费用（注意客户是在用户点击广告后才付费的）. 这个指标可以衡量用户对于广告的感兴趣程度。从广告客户的角度讲，也可以衡量在百度投放广告的费用多少，以及投放的有效性。
CPM3：cost per thousand3 表示平均每千次有广告展现的检索请求对应的广告收入，衡量单次有广告展现检索的平均收入贡献。这个指标是衡量当搜索结果的页面有广告展现的时候，每展现一千次，百度能够拿到的收入。有的搜索结果是没有广告展示的（CPM1把这些PV也计算进去了）。
CPC：cost per click 按每次点击收费，是目前最流行的搜索引擎营销的付费方式，即只有当用户点击观看了你的推广链接后，才发生费用。
CPA：cost per action 按每次用户消费行动收费，被认为将是互联网广告未来必然的发展方向，但由于不同产品的广告对action的定义和回报率有太大差异，实现过于复杂，目前在全球范围尚无搜索引擎使用CPA收费的成功先例。 CTR——点击率，在这里特指广告或推广链接出现后被用户点击的机率。CTR还将可以进一步的细分。
CTR1：表示平均每次检索请求对应的广告点击数，衡量单次广告检索的平均点击贡献。理论上 CTR1 可能大于 1。因为每次检索客户可以点击一个广告，看了后，在回去原来的检索页，点击下一个广告。
CTR2：表示平均每次广告展现对应的广告点击数，衡量单次广告展现的平均点击贡献。
CTR3：表示平均每次有广告展现的检索请求对应的广告点击数，衡量单次有广告展现检索的平均点击贡献。理论上 CTR3 可能大于 1。
ARPU：户均消费，影响它的因素包括：点击流量大小、关键词的相关性、同一关键词的竞争度，以及客户在搜索引擎广告上的预算上限等。
PV:检索量，百度搜索框的搜索次数
ADPV:出广告的检索量，即PV中，有广告展现的搜索数量
CLK：click number，广告的总点击次数
CSM：百度广告主的总广告费支出
ASN：平均展现条数。即：如果展现了搜索推广广告，每次平均展现多少条
ACP：Average Click Price 平均点击价格总消费/总点击
PVR：Page View Rates, PV比率，出广告的检索量 / 检索量

有了以上这些定义后，我们再来回顾变现系统的计算公式：

Revenue =PV * PVR * ASN * CTR2 * ACP

可以看出以上各因子表明了变现系统不同组成的效率

PV：是百度能够用于变现的流量上限，由用户体验决定，百度越好用，口碑越好， PV越高。该指标在百度类似的搜索引擎公司，主要由搜索部门负责。
PVR：就是PV中被用于变现的比例，PVR越高，说明在百度搜索中，出广告的概率越高，有可能导致用户体验的下降
ASN：单次有广告展现的PV，展现的广告数量，表明单次有广告展现时的变现利用程度。ASN越高表明单次搜索出的广告越多，可能导致用户体验的下降
CTR2：单条广告展现时，广告北点击的概率。表明广告推的是否精准，是否满足用户需求（至少是感官上是否吸引用户）
ACP：单次点击价格，相当于单价的高低

这样的指标分解非常有利于指导策略的优化，以下是几个case：

PV：搜索部门的重要指标，增加下降，都能立刻看出搜索部门的业绩，或是竞争对手带来的影响，例如，就百度而言，Google退出中国PV上升，360上了搜索， PV下降，都能直接看出来
点击率预估：假设PV,PVR,ASN，ACP都固定，则要增加收入，需要提升用户对广告的点击率，此时可以用模型来对点击率预估，提升CTR2。各大搜索引擎公司，对CTR2的预估，基本上都是商业部门的重要机密，也是最重视的技术之一
增加广告展现：在各上市公司（包括传统行业公司），都会有‘冲业绩’这么一说，就是极度末时，为了达到之前的营收计划，需要使用各种手段增加收入，例如我们经常听说的银行给高利息临时拉存款等，在百度则可以通过调参提升收入，比如增加ASN或是PVR，达到收入符合华尔街预期的效果
ASN的变化：如果收入的增长是来自于ASN的增长，则说明百度的点击卖得更贵了，广告主会不乐意。相反，ASN下降，说明点击卖便宜了，百度的收入有可能降低，所以类似于CTR2上升，ASN不变这样的策略，是最好的

有了以上定义即收入的拆解，则收入可以用其他集中形式表示：

Revenue = PV * CPM1

Revenue =PV * PVR * CPM3

Revenue =PV * PVR * ASN * CPM2

Revenue =PV * CTR1 * ACP

Revenue =PV * PVR * CTR3 * ACP

百度商业部门的工作，几乎每天都是在围绕着这些指标来进行的。每一次策略的调整，工作方式的改变，都希望在这些指标上做出正向的贡献，因为这些指标对百度的收入是直接造成影响的。从百度的收入（Revenue）的计算公式上就可以看出（每一种计算方法得到的结果都殊途同归）

如何建设LBS变现策略指标体系

拿百度地图类似的LBS产品为例，假设我们的转化漏斗路径是：推荐&搜索之后展示结果列表也，然后用户点击结果进入店家的表述页面（POI），之后如果用户感兴趣，则点击具体的团购，优惠券进行购买，搜索漏斗如下：

图：搜索漏斗

对应到线上系统，在评估衡量线上系统效果时，我们也需要分为这3阶段进行衡量，以及时发现线上策略效果的瓶颈所在，快速找到提升重点。在以上3阶段中：

搜索or 推荐：主要表明流量大小
点击详情页：表现为用户带来的流量到详情页的浏览情况
转化：最终转化action

对于商业系统，我们最重要的目标就是保证在既定流量上，转化最高。

以下为我们需要关注的所有指标：

表：策略效果指标

如后续变现系统按转化收费，则整个LBS变现系统收入可定义为：

收入= pv * pvr * easn * ctr2 * atr2 * aap

在产品的不同阶段，我们需要关注的重点不一样：

在产品上线的阶段，我们需要关注用户体验，所以ctr2和atr2需要重点关注
用户体验提升到一定程度，商户已经认可我们产品效果时，再考虑提升成单的单价（例如佣金等），同事可以考虑对商业POI进行放量，提升pvr和easn

物料召回及检索类指标

该类指标主要用于监控系统的检索量，以及系统的召回能力。检索量等指标是系统变现可以使用的所有资源，更多受用户产品影响；而召回能力相关指标则体现出CPR系统对商业物料的召回能力。

以下为重要指标说明：

检索量: 发送到系统的所有请求量；通过统计检索日志条数得到；为能够变现的流量全集。
查询用户数:所有发起请求的用户数；统计检索日志中去重后uid得到，体现参与检索的用户量。
用户平均检索量：平均每个用户发起的请求数量；体现用户检索角度的活跃度。
单次检索返回结果数：平均单次检索返回结果条数；体现系统的召回能力（准确性参见相关性评估）
商业结果检索量：出现商业结果的检索次数；
商业结果检索用户数：出现商业结果的检索用户数；体现商业结果能够覆盖的客户群体
商业检索占比：出现商业结果检索量占总体检索量占比；可根据改指标分析潜在变现流量。
商业检索用户占比：看到商业结果的用户占所有检索用户占比；可根据该指标分析潜在变现用户。
单次检索商业结果返回条数：一次出现商业结果的检索，返回的结果条数；

点击行为类指标

该类指标主要用于衡量用户浏览搜索/推荐结果后的点击行为。该过程为转化漏斗第二阶段。

以下为具体指标及含义:

点击条数：被点击的POI数量(包括自然POI和商业POI)
有点击检索次数：产生点击行为的检索次数（包括自然POI和商业POI）。
有点击用户数：产生点击的用户数量。
商业POI 点击条数：商业POI被点击的数量。
商业POI 有点击检索次数：出现商业POI，且产生商业POI点击的次数。
商业POI 点击用户数：点击商业POI的去重用户数。
单次检索点击率：平均每次检索点击POI的概率；该值理论上可能大于1
单次检索商业POI 点击率：平均每次检索，点击商业POI的概率；该值理论上可以大于1
单条商业POI 展现点击率：平均每条商业POI展现的点击概率；用于衡量每条商业POI曝光产生点击的效率。
单次有商业结果展现点击率：平均每次有商业POI展现的检索的点击概率；用于衡量出商业POI的流量产生点击的效率。

效用类指标

该类指标主要用于衡量用户点击进入POI详情页后，根据详情页信息，做出最终决策的阶段（包括点击‘预订’，‘成单’，‘下载’等行为）。该过程处于转化漏斗的第三阶段，也是最终阶段。

以下为具体指标定义：

POI 展现数：包括自然POI和商业POI的展现次数。
POI 展现用户数：浏览POI的去重用户数。
POI 详情页转化数：此处的转化根据每个入口可能有所不同。
POI 详情页转化率：POI详情页转化数/POI详情页展现数。
单次转化收费：完成单次转化后，向商户收取的平均费用。

以上密密麻麻的指标，在不同的商业变现系统中会有所差别，但基本上都是按照用户产品形态及转换漏斗进行设定，而每个策略的上线，都会使用类似的指标体系来衡量策略对不同漏斗部分的效率影响。

开源Python网络爬虫框架Scrapy

Fri, 20 Jun 2014 19:17:34 CST

介绍：

所谓网络爬虫，就是一个在网上到处或定向抓取数据的程序，当然，这种说法不够专业，更专业的描述就是，抓取特定网站网页的HTML数据。不过由于一个网站的网页很多，而我们又不可能事先知道所有网页的URL地址，所以，如何保证我们抓取到了网站的所有HTML页面就是一个有待考究的问题了。

一般的方法是，定义一个入口页面，然后一般一个页面会有其他页面的URL，于是从当前页面获取到这些URL加入到爬虫的抓取队列中，然后进入到新新页面后再递归的进行上述的操作，其实说来就跟深度遍历或广度遍历一样。

上面介绍的只是爬虫的一些概念而非搜索引擎，实际上搜索引擎的话其系统是相当复杂的，爬虫只是搜索引擎的一个子系统而已。下面介绍一个开源的爬虫框架Scrapy。

一、概述

Scrapy是一个用 Python 写的 Crawler Framework ，简单轻巧，并且非常方便，并且官网上说已经在实际生产中在使用了，不过现在还没有 Release 版本，可以直接使用他们的 Mercurial 仓库里抓取源码进行安装。

Scrapy 使用 Twisted 这个异步网络库来处理网络通讯，架构清晰，并且包含了各种中间件接口，可以灵活的完成各种需求。整体架构如下图所示：

绿线是数据流向，首先从初始 URL 开始，Scheduler 会将其交给 Downloader 进行下载，下载之后会交给 Spider 进行分析，Spider 分析出来的结果有两种：一种是需要进一步抓取的链接，例如之前分析的“下一页”的链接，这些东西会被传回 Scheduler ；另一种是需要保存的数据，它们则被送到 Item Pipeline 那里，那是对数据进行后期处理（详细分析、过滤、存储等）的地方。另外，在数据流动的通道里还可以安装各种中间件，进行必要的处理。

二、组件

1、Scrapy Engine（Scrapy引擎）

Scrapy引擎是用来控制整个系统的数据处理流程，并进行事务处理的触发。更多的详细内容可以看下面的数据处理流程。

2、Scheduler（调度）

调度程序从Scrapy引擎接受请求并排序列入队列，并在Scrapy引擎发出请求后返还给他们。

3、Downloader（下载器）

下载器的主要职责是抓取网页并将网页内容返还给蜘蛛( Spiders)。

4、Spiders（蜘蛛）

蜘蛛是有Scrapy用户自己定义用来解析网页并抓取制定URL返回的内容的类，每个蜘蛛都能处理一个域名或一组域名。换句话说就是用来定义特定网站的抓取和解析规则。

蜘蛛的整个抓取流程（周期）是这样的：

首先获取第一个URL的初始请求，当请求返回后调取一个回调函数。第一个请求是通过调用start_requests()方法。该方法默认从start_urls中的Url中生成请求，并执行解析来调用回调函数。
在回调函数中，你可以解析网页响应并返回项目对象和请求对象或两者的迭代。这些请求也将包含一个回调，然后被Scrapy下载，然后有指定的回调处理。
在回调函数中，你解析网站的内容，同程使用的是Xpath选择器（但是你也可以使用BeautifuSoup, lxml或其他任何你喜欢的程序），并生成解析的数据项。
最后，从蜘蛛返回的项目通常会进驻到项目管道。

5、Item Pipeline（项目管道）

项目管道的主要责任是负责处理有蜘蛛从网页中抽取的项目，他的主要任务是清晰、验证和存储数据。当页面被蜘蛛解析后，将被发送到项目管道，并经过几个特定的次序处理数据。每个项目管道的组件都是有一个简单的方法组成的Python类。他们获取了项目并执行他们的方法，同时他们还需要确定的是是否需要在项目管道中继续执行下一步或是直接丢弃掉不处理。

项目管道通常执行的过程有：

清洗HTML数据
验证解析到的数据（检查项目是否包含必要的字段）
检查是否是重复数据（如果重复就删除）
将解析到的数据存储到数据库中

6、Downloader middlewares（下载器中间件）

下载中间件是位于Scrapy引擎和下载器之间的钩子框架，主要是处理Scrapy引擎与下载器之间的请求及响应。它提供了一个自定义的代码的方式来拓展 Scrapy的功能。下载中间器是一个处理请求和响应的钩子框架。他是轻量级的，对Scrapy尽享全局控制的底层的系统。

7、Spider middlewares（蜘蛛中间件）

蜘蛛中间件是介于Scrapy引擎和蜘蛛之间的钩子框架，主要工作是处理蜘蛛的响应输入和请求输出。它提供一个自定义代码的方式来拓展Scrapy的功能。蛛中间件是一个挂接到Scrapy的蜘蛛处理机制的框架，你可以插入自定义的代码来处理发送给蜘蛛的请求和返回蜘蛛获取的响应内容和项目。

8、Scheduler middlewares（调度中间件）

调度中间件是介于Scrapy引擎和调度之间的中间件，主要工作是处从Scrapy引擎发送到调度的请求和响应。他提供了一个自定义的代码来拓展Scrapy的功能。

三、数据处理流程

Scrapy的整个数据处理流程有Scrapy引擎进行控制，其主要的运行方式为：

引擎打开一个域名，时蜘蛛处理这个域名，并让蜘蛛获取第一个爬取的URL。
引擎从蜘蛛那获取第一个需要爬取的URL，然后作为请求在调度中进行调度。
引擎从调度那获取接下来进行爬取的页面。
调度将下一个爬取的URL返回给引擎，引擎将他们通过下载中间件发送到下载器。
当网页被下载器下载完成以后，响应内容通过下载中间件被发送到引擎。
引擎收到下载器的响应并将它通过蜘蛛中间件发送到蜘蛛进行处理。
蜘蛛处理响应并返回爬取到的项目，然后给引擎发送新的请求。
引擎将抓取到的项目项目管道，并向调度发送请求。
系统重复第二部后面的操作，直到调度中没有请求，然后断开引擎与域之间的联系。

安装：

Scrapy是一个快速,高层次的屏幕抓取和web抓取框架，用于抓取web站点并从页面中提取结构化的数据。Scrapy用途广泛，可以用于数据挖掘、监测和自动化测试。Scrapy吸引人的地方在于它是一个框架，任何人都可以根据需求方便的修改。它也提供了多种类型爬虫的基类，如 BaseSpider、sitemap爬虫等，最新版本又提供了web2.0爬虫的支持。

下面介绍Scrapy在windows下的安装:

首先下载windows版： Scrapy-0.15.0.2842.win32.exe，直接安装。

安装之后不能直接运行scrapy提供的test，会提示错误，因为scrapy基于其他一些python库，需要把这些库都安装才行。

Twisted：Twisted Matrix 是一种用来进行网络服务和应用程序编程的纯 Python 框架，虽然 Twisted Matrix 中有大量松散耦合的模块化组件，但该框架的中心概念还是非阻塞异步服务器这一思想。Twisted的安装也非常简单，在这里直接下载windows平台下的相应版本即可： http://pypi.python.org/packages/2.7/T/Twisted/，

zope.interface：在这里下载 http://pypi.python.org/pypi/zope.interface/3.8.0#downloads。zope.interface没有提供windows平台下的exe版，只提供了windows平台下的egg包。

ez_setup：下载 http://pypi.python.org/pypi/ez_setup，安装。将egg文件放置在{python安装目录}\Scripts目录下。

打开CMD并切换至scripts目录，easy_install zope.interface-3.8.0-py2.6-win32.egg安装。

w3lib：zope.interface问题解决之后还会提示缺少w3lib，下载 http://pypi.python.org/pypi/w3lib后安装即可

libxml2：使用scrapy的html解析功能时，会提示你缺少libxml2，所以我们先把这个也装上，地址 http://xmlsoft.org/sources/win32/python/，下载相应的版本即可。

至此就可以使用Scrapy玩spider了，大家可以根据文档写一个简单的爬虫试试，实际上使用scrapy做一个简易的爬虫甚至只需要几行代码就可以了，以后有空再详细说说使用方法，本文不做更多描述。

入门：

本文参考Scrapy Tutorial里面的文档，翻译出来加上自己的理解，供大家学习。

在本文中，我们将学会如何使用Scrapy建立一个爬虫程序，并爬取指定网站上的内容，这一切在Scrapy框架内实现将是很简单轻松的事情。

本教程主要内容包括一下四步：

1. 创建一个新的Scrapy Project
2. 定义你需要从网页中提取的元素Item
3. 实现一个Spider类，通过接口完成爬取URL和提取Item的功能
4. 实现一个Item PipeLine类，完成Item的存储功能

新建工程

首先，为我们的爬虫新建一个工程，首先进入一个目录（任意一个我们用来保存代码的目录），执行：

[python] view plain copy

scrapy startproject Domz

最后的Domz就是项目名称。这个命令会在当前目录下创建一个新目录Domz，结构如下：

[python] view plain copy

dmoz/
scrapy.cfg
dmoz/
__init__.py
items.py
pipelines.py
settings.py
spiders/
__init__.py

scrapy.cfg: 项目配置文件

items.py: 需要提取的数据结构定义文件
pipelines.py: 管道定义，用来对items里面提取的数据做进一步处理，如保存等
settings.py: 爬虫配置文件
spiders: 放置spider的目录

定义Item

在items.py里面定义我们要抓取的数据：

[python] view plain copy

from scrapy.item import Item, Field
class DmozItem(Item):
title = Field()
link = Field()
desc = Field()

这里我们需要获取dmoz页面上的标题，链接，描述，所以定义一个对应的items结构，不像Django里面models的定义有那么多种类的Field，这里只有一种就叫Field()，再复杂就是Field可以接受一个default值。

实现Spider

spider只是一个继承字scrapy.spider.BaseSpider的Python类，有三个必需的定义的成员

name: 名字，这个spider的标识
start_urls: 一个url列表，spider从这些网页开始抓取
parse(): 一个方法，当start_urls里面的网页抓取下来之后需要调用这个方法解析网页内容，同时需要返回下一个需要抓取的网页，或者返回items列表

所以在spiders目录下新建一个spider，dmoz_spider.py:

[python] view plain copy

class DmozSpider(BaseSpider):
name = "dmoz.org"
start_urls = [
"http://www.dmoz.org/Computers/Programming/Languages/Python/Books/",
"http://www.dmoz.org/Computers/Programming/Languages/Python/Resources/"
]
def parse(self, response):
filename = response.url.split("/")[-2]
open(filename, 'wb').write(response.body)

提取Item

提取数据到Items里面，主要用到XPath提取网页数据：

scrapy有提供两个XPath选择器，HtmlXPathSelector和XmlXPathSelector，一个用于HTML，一个用于XML，XPath选择器有三个方法

select(xpath): 返回一个相对于当前选中节点的选择器列表（一个XPath可能选到多个节点）
extract(): 返回选择器（列表）对应的节点的字符串（列表）
re(regex): 返回正则表达式匹配的字符串（分组匹配）列表
一种很好的方法是在Shell里面对XPath进行测试：

[python] view plain copy

scrapy shell http://www.dmoz.org/Computers/Programming/Languages/Python/Books/

现在修改parse()方法看看如何提取数据到items里面去：

[python] view plain copy

def parse(self, response):
hxs = HtmlXPathSelector(response)
sites = hxs.select('//ul/li')
items = []
for site in sites:
item = DmozItem()
item['title'] = site.select('a/text()').extract()
item['link'] = site.select('a/@href').extract()
item['desc'] = site.select('text()').extract()
items.append(item)
return items

实现PipeLine

PipeLine用来对Spider返回的Item列表进行保存操作，可以写入到文件、或者数据库等。

PipeLine只有一个需要实现的方法：process_item，例如我们将Item保存到一个文件中：

[python] view plain copy

def __init__(self):
self.file = open('jingdong.txt', 'wb')
def process_item(self, item, spider):
self.file.write(item['title'] + '\t'+ item['link'] + '\t' + item['desc']+'\n')

到现在，我们就完成了一个基本的爬虫的实现，可以输入下面的命令来启动这个Spider:

[python] view plain copy

scrapy crawl dmoz.org

Scrapy之URL解析与递归爬取：

前面介绍了Scrapy如何实现一个最简单的爬虫，但是这个Demo里只是对一个页面进行了抓取。在实际应用中，爬虫一个重要功能是”发现新页面”，然后递归的让爬取操作进行下去。

发现新页面的方法很简单，我们首先定义一个爬虫的入口URL地址，比如Scrapy入门教程中的start_urls，爬虫首先将这个页面的内容抓取之后，解析其内容，将所有的链接地址提取出来。这个提取的过程是很简单的，通过一个html解析库，将这样的节点内容提取出来，href参数的值就是一个新页面的URL。获取这个URL值之后，将其加入到任务队列中，爬虫不断的从队列中取URL即可。这样，只需要为爬虫定义一个入口的URL，那么爬虫就能够自动的爬取到指定网站的绝大多数页面。

当然，在具体的实现中，我们还需要对提取的URL做进一步处理:

1. 判断URL指向网站的域名，如果指向的是外部网站，那么可以将其丢弃
2. URL去重，可以将所有爬取过的URL存入数据库中，然后查询新提取的URL在数据库中是否存在，如果存在的话，当然就无需再去爬取了。

下面介绍一下如何在Scrapy中完成上述这样的功能。

我们只需要改写spider的那个py文件即可，修改parse()方法代码如下：

[python] view plain copy

from scrapy.selector import HtmlXPathSelector
def parse(self, response):
hxs = HtmlXPathSelector(response)
items = []
newurls = hxs.select('//a/@href').extract()
validurls = []
for url in newurls:
#判断URL是否合法
if true:
validurls.append(url)
items.extend([self.make_requests_from_url(url).replace(callback=self.parse) for url in validurls])
sites = hxs.select('//ul/li')
items = []
for site in sites:
item = DmozItem()
item['title'] = site.select('a/text()').extract()
item['link'] = site.select('a/@href').extract()
item['desc'] = site.select('text()').extract()
items.append(item)
return items

全文转载自： http://blog.csdn.net/zbyufei/article/details/7554322

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

IT瘾搜索推荐

Google搜索引擎架构Caffeine

什么是 Google Caffeine？

Google Caffeine的产生背景

Google Caffeine 的核心特性

Caffeine 的技术优势

Google Caffeine的影响

Google Caffeine后更新

RankBrain（2015 年）

BERT（2019 年）

移动优先索引（Mobile-First Indexing，2016 年启动，2021 年完成）

Page Experience Update（页面体验更新，2021 年）

MUM（Multitask Unified Model，2021 年）

实时搜索与增强数据呈现

神经匹配（Neural Matching，2018 年）

AI 驱动的改进（2023 年及之后）

数据隐私与安全性改进

相关文章:

浅谈有赞搜索QP架构设计

一、有赞搜索平台整体设计

二、QP的作用

三、QP应用整体设计

四、QP应用分层设计

五、QP算法插件设计

5.1 预处理Preprocess插件

样例

5.2 纠错Correction插件

样例

5.3 细粒度分词Tokenizer插件（基础分词）

样例

5.4 语义分词sementicSegment插件

样例

5.5 实体识别Tagging插件

样例

实体识别方法

5.6 类目预测categoryPredict插件

样例

5.7 同近义词插件

样例

六、总结与展望

4个步骤，小结搜索系统

一、需求识别

二、用户搜索输入分析

三、排序计算方式

四、展现

Google 发布了一个全新的搜索引擎和两个文字游戏

一个完整推荐系统的设计实现-以百度关键词搜索推荐为例

关键词推荐工具中的用户引导机制

基于Elasticsearch实现搜索建议

问题描述

搜索建议实现

SuggestionDiscovery

SuggestionCounter

SuggestionIndexRebuiler

SuggestionService

实现效果和后续改进

参考资料

基于Elasticsearch实现搜索推荐

背景介绍

设计思路

实现细节

整体设计

搜索建议词索引

商品数据索引

关键词映射索引

爬虫数据爬取

全量爬虫

增量爬虫

爬虫数据关键词提取

管理关键词映射

搜索推荐服务的实现

小结与后续改进

基于word2vec和Elasticsearch实现个性化搜索

背景介绍

设计思路

实现细节

商品向量的计算

用户向量的计算

搜索服务时增加个性化评分

elasticsearch-feature-vector-scoring插件

6月全球搜索引擎市场：百度被Bing取代排名跌至第四