1. 京东到家订单中心 Elasticsearch 演进历程。
   [http://t.cn/E4MXmyD](http://t.cn/E4MXmyD)
   
   
2. 机器学习在solr,es,vespa上的应用（需翻墙）。
   [http://t.cn/E46pLF4](http://t.cn/E46pLF4)
   
   
3. 将Firestore数据导入到es教程。
   [http://t.cn/E46OPrz](http://t.cn/E46OPrz)
   
   
   • 编辑：bsll
     
     
   • 归档：https://elasticsearch.cn/article/6217
     
     
   • 订阅：https://tinyletter.com/elastic-daily

作者：杨振涛 搜索引擎架构师@vivo 
首次发布：Elasticsearch中文社区
发布日期：2018-12-22

搜索引擎作为互联网发展历史中一个非常典型的产品/业务形态，时至今日并没有太大的突破性变化；主流形态可以划分为大搜、垂搜、企业级搜索和站内/app内搜索等。除了Google, Yahoo, Bing, Ask 等以及国内百度、搜狗、360、神马等是人们熟识的大搜之外，非业内人士还真不知道其他还有哪些公司以及有哪些搜索产品或业务场景。 实际上，在信息爆炸的时代，几乎每家有点儿规模的公司都或多或少要涉及到搜索引擎，最起码你需要接触SEO/SEM。本文将从非大搜企业的搜索需求出发，并基于开源技术栈来介绍和探讨搜索引擎在实践中的几个核心任务及其主要解决思路。同时为了避免重复，本文以外链形式引用了大量网络已有的国内外公开资料，方便大家参考，需要注意的是部分内容可能会随着时间推移而过期或链接失效。

提到开源搜索引擎，在Java技术栈里以Lucene, Solr/SolrCloud及Elasticsearch为代表的几个项目可能最为流行。本文的写作初衷是解答”熟练使用ES等开源搜索引擎解决方案以后，要如何才能做好搜索产品/业务？“ 希望对你有所帮助，如果你有关于此话题的更多实践经验或不同见解，欢迎留言评论交流。 
 
1. 做好搜索引擎意味着什么？
 
有一位同行的文章总结了好的搜索引擎的衡量维度：

• 相关性
• 体验
• 性能

其中相关性是非常重要的一个维度，这里我将通过引用一篇文章来介绍什么是”相关性工程“以及”相关性工程师“ http://www.flax.co.uk/blog/201 ... ound/ 。

相关性工程中的“相关性”，主要是指代用户的Query与索引库中的Doc之间的相关性，所以可以分别从索引数据和Query两个方面来考虑。

相关性工程考虑的第一个特征就是基于已有索引数据的文本相关度计算，通常有TF-IDF、BM25、BM25F等。Elasticsearch早期的版本默认都是TF-IDF，目前已更改为BM25。对于中文数据，分词方法和策略也会直接影响到文本相关度的计算；其次匹配方式也非常重要；最后就是基于此的相关性算分了。

相关性工程还可以考虑更多的特征，尤其是从索引数据之外来挖掘出的特征，比如索引文档的权威性、时效性、专业性、质量与口碑评分、热度与流行度等。结合NLP技术，相关性工程还可以考虑语义距离等特征，丰富召回结果。当然这些特征的处理与机器学习中的特征工程基本一致，比如涉及归一化问题、权重问题、稀疏性问题、非典型分布等等。

相关性工程考虑的另一个重要特征是用户点击反馈数据，即对于用户所看到的搜索结果列表，点击行为被看作是对当前搜索结果的一种认可，用户点了哪个位置的doc对于继续优化相关性至关重要。这两天有个著名案例就是Google的劈柴在听证会上解释为什么在Google搜索Idiot出现的都是特朗普的照片。


体验涉及的方面较多，最重要的就是产品功能和交互方面的体验了，比如一个典型的搜索产品，C端可能具备以下功能：

• 搜索前：搜索框，搜索入口，热搜榜/飙升榜/大家都在搜，搜索发现，默认搜索词，历史搜索记录，猜你想搜，分类搜索，语音输入搜索/图片搜索； 广告位
• 搜索中：搜索联想直达，搜索联想词，输入纠错，关键词匹配高亮
• 搜索后：搜索结果列表，列表页推荐/广告，特形展示，列表穿插，搜了还搜，搜索详情页，详情页搜索推荐，无结果及少结果填充 ，筛选条件/筛选器，自主排序，列表样式切换（宫格 | 列表）

除了产品功能，还需要考虑搜索引擎的可运营性，比如搜索运营管理系统，至少要具备基本功能的各种黑白灰名单，包括人工干预，优化分词的自定义词典、同义词典、停用词典，以及对查询词的强制改写或者升降权；对索引内容的管控，比如对检索字段的；对召回和排序的相关参数的优化和调整等等；此外，还有配套的SEO或ASO系统，以及各种数据指标相关的看板系统。

而搜索结果中的特形展示，也是目前比较主流的产品形式，不管是自然结果还是搜索广告，都可以提供更快捷的体验，甚至一度成为知识图谱在搜索产品中应用的代表性功能。另外搜索联想中的直达服务，也是目前比较流行的，可以进一步缩短用户的操作路径，直达目标内容或服务。

更多关于产品体验和设计类问题可以参考  http://www.woshipm.com/tag/搜索功能 

性能方面，搜索引擎的每一次查询理论上都是实时运算，大部分搜索引擎系统都是实时或准实时的，这就要求在用户感知上要有基本的响应时间（RT）保障，比如在国内公网环境下，200ms是比较优秀的体验，300ms-500ms是正常的体验，500ms+就需要尽快去优化。除去其中的网络I/O等开销，对于后端搜索服务的RT，一般是T99在100ms以内，T90在50ms以内，具体标准取决与当事业务和产品。除了RT，可用性也是非常重要的，一般要求99.9%以上；另外，索引数据的生效时间也很重要，比如新加入的索引，或者已有索引的更新和删除，秒级生效是比较好的体验。需要明确的一点是，这里的性能指标我们针对的是To C用户，如果是企业级搜索甚至是基于ES的一个即时查询分析系统，可能复杂查询的秒级响应也是很正常的。

延伸阅读：

阿里云-开放搜索-最佳实践-功能篇-相关性实践 https://help.aliyun.com/document_detail/29186.html 
Defining relevance engineering 什么是相关性工程 http://www.flax.co.uk/blog/201 ... ound/ 
 
2. 搜索引擎是典型的机器学习问题
 
云计算、大数据、AI 先后成为IT与互联网行业的热点，三者经常被称为CBA或ABC技术，而这些都与一家公司密切相关，那就是 Google !   众所周知 Google 是一家著名的全球搜索引擎公司，但其产品远不止搜索引擎。从Google的三驾马车 GFS, MapReduce, BigTable开始，后来有了 Yahoo牵头的开源实现Hadoop（Hadoop最早来自于Nutch，是的，没错，就是那个开发了 Lucene 的 Doug Cutting所开源的Nutch，他被称作Hadoop之父），到后来的云计算与大数据技术蓬勃，到今天的AI热潮，各种深度学习各种NN， Google Brain，开源的Tensorflow，对Google来说这一切都是搜索引擎业务驱动的水到渠成的发展轨迹。 可以说搜索引擎是天生的机器学习问题，有着诸多的机器学习/深度学习应用场景。这里顺便DISS下一些眼高手低的迷糊党，互联网圈儿曾有人遇到求职者表示想做AI，却不做搜索不做推荐不做广告！（本人内心：你咋不上天呢！请记住AI is a buzzword. ）当今的互联网或移动互联网，搜索、推荐与广告是三大典型的所谓AI应用落地方向，其他的也有但并未发展成熟，至少还没有成熟的变现模式；而这三者或多或少有些交集，搜索几乎是最基础的一个，比如推荐也需要建立索引，需要检索TOP N，搜索广告也需要做召回和排序。

如果我们把搜索引擎的核心模型简化下，其实主要是在解决三大类问题： 

- 数据： 内容侧的爬虫，预处理，内容分析和理解，索引建立和存储 ；用户侧的Query理解，改写，意图识别等
- 算法/模型 ：把相关性和排序等业务问题抽象为回归或分类/聚类问题，特征工程，离线训练模型，在线预测
- 策略：为满足业务需求而制定并持续优化的一系列规则、模型或模型组合、参数优化等活动，并通过工程化实现体现到线上系统，以及配套的试验和评估系统 
 
2.1 Ranking  排序

常见的排序策略有：

• 单维度排序：顾名思义按照单个维度来排序，没有任何复杂性可言，在召回结果集不太大的情况下实时排序即可。
• 优先级排序：相对单维度排序而已一般是先按维度A排，当A的排序依据一样或相等时再按维度B排序，以此类推。
• 加权排序   ：针对多个维度或特征，赋予不同权重，并按求和之后的得分来排序；实践中通常会采用分层加权排序（第一层加权排序之后，得到不少于2个得分，继续加权后排序），或者分组加权排序（第一层分组来加权排序后，对所得到的得分可能按业务需求进行非求和类的运算比如乘法，再按最终得分排序）的策略。 加权排序的难点在于，如何设置并持续优化这些权重，通常会建模为典型的机器学习问题来拟合。
• 机器学习排序 ：即所谓LTR，根据用户点击或人工标注数据集建立学习目标，然后通过特征工程来挖掘与目标有关系的一系列特征，并建立学习模型，通过训练集获得模型参数，以该组参数为基准做预测，上线后再基于用户点击数据持续优化该模型的参数。LTR是一个通用方法的称谓，不是某一个具体算法的名称，具体算法名称参见下文。

排序问题可以简单抽象成为预测用户点击列表中对象的概率问题。
 
2.2 ES生态内的 LTR 

关于LTR的理论和方法学，已经有很多论文和资料了 ( 参考 wikipedia , LTR简介-微软亚研院， LTR Pairwise to Listwise ,  大规模LTR-Google，LTR书籍 )，感兴趣的可以阅读，这里主要提供几个JAVA和ES生态的工程实现参考。

es-ltr插件  http://es-learn-to-rank.labs.o19s.com/ 

Set of command line tools for Learning To Rank https://github.com/SeaseLtd/ltr-tools

es的ranking evaluation api https://www.elastic.co/guide/e ... .html 

Java LTR类库： RankLib  https://sourceforge.net/p/lemur/wiki/RankLib/

支持算法如下：

• MART (Multiple Additive Regression Trees, a.k.a. Gradient boosted regression tree) 
• RankNet 
• RankBoost 
• AdaRank 
• Coordinate Ascent 
• LambdaMART 
• ListNet 
• Random Forests  

延伸阅读：

• vivo互联网技术： 搜索引擎与其他机器学习有何不同   https://mp.weixin.qq.com/s/uWg3m5xIGBAKNqqDmxzw2Q
• InfoQ：在 Elasticsearch 中应用机器学习排序 LTR https://www.infoq.cn/article/w ... earch
• InfoQ：认识机器学习排序 LTR https://www.infoq.cn/article/m ... g-ltr
• InfoQ：机器学习排序 LTR 入门——线性模型 https://www.infoq.cn/article/2 ... model

 
2.3 典型垂搜

电商与O2O搜索

案例： 天猫，淘宝，京东，美丽说蘑菇街，有赞 ，美团点评，饿了么 

阿里研究员徐盈辉：在线AI技术在搜索与推荐场景的应用 https://yq.aliyun.com/articles/107941  
阿里巴巴资深算法专家三桐：人工智能在搜索中的应用 https://yq.aliyun.com/articles/288065  
阿里巴巴年度技术总结 - 人工智能在搜索的应用和实践 http://www.sohu.com/a/214123235_680198
 电子商务搜索系统架构参考 （京东） https://blog.csdn.net/hongseji ... 08067  
电商搜索之动态属性值（特征值）聚合 （举例 京东和solr实现）  https://blog.csdn.net/hu948162 ... 80071  
劈开迷雾，蘑菇街电商搜索架构及搜索排序实现 https://blog.csdn.net/huangshu ... 46694
有赞搜索引擎实践(工程篇)  https://www.cnblogs.com/hsydj/p/5303050.html
有赞搜索引擎实践(算法篇)  https://www.cnblogs.com/hsydj/p/5402945.html 
有赞搜索系统的架构演进   https://tech.youzan.com/search-tech-1/   
有赞搜索系统的技术内幕  https://tech.youzan.com/search-tech-2/  

电商系统如何做搜索引擎？ https://blog.csdn.net/zysgdhf4 ... 53999  

电商检索系统总结——功能篇 https://www.cnblogs.com/wanghuaijun/p/7112952.html 

App搜索 

案例：Google Play, 应用宝，各种手机助手，Apple App Store及各大其他手机厂商的应用商店/应用市场以及互联网电视/机顶盒等的应用商店/应用市场  
 
3. 搜索引擎的效果评价

我们在团队内有句戏言：看一个搜索团队是否专业，就看他们是否做效果评价。 在与国内外的搜索工程师交流和学习过程中，还有一个说法是：搜素引擎的优化就像一个打地鼠游戏，你解决一类bad case的同时很难确认其是否会带来新的bad case以及会带来多少。

需要区别的是，搜索引擎中使用到的机器学习/深度学习算法本身的效果评估（如分类算法的Accuracy、Precision、Recall、F1、ROC、AUC 等）并不能直接代替搜索引擎的效果评价。通常我们分为人工主观评测和业务指标评测。

参考：

• 搜索质量概述 https://opensourceconnections. ... lity/ 
• nDCG排序打分工具  https://opensourceconnections. ... epid/
• 百度众测任务： Query与广告之间的相关性评估规则  http://test.baidu.com/mark/task/view/id/2584923 
• Search Quality Evaluation Tool for Apache Solr & Elasticsearch search-based infrastructures https://github.com/SeaseLtd/ra ... uator 

 
4. NLP 自然语言处理

我们知道搜索引擎的上游学科是信息检索（IR），这也是搜索引擎的理论基础。而自然语言处理（NLP）在信息检索领域尤其是搜索引擎中有着至关重要的地位和作用。一方面我们对于被搜索的内容数据的理解，需要借助NLP来提升语义性和智能程度，另一方面我们对于用户Query和意图的理解，也需要借助NLP相关方法和技术来完成。

实际上ES的很多特性已经非常强大， 可以作为基本的文本分析和挖掘工具使用，这也是解释了ES官方博客以及其他博客有分享一些文章，主题是关于使用ES来进行文本分类或者实现推荐系统。


总结一下，想要做好一个典型的搜索引擎产品，除了熟练使用ES，还需要考虑搜索产品的功能完备性、体验优劣、性能以及相关性，而相关性涉及对内容数据的理解和挖掘、对用户Query的理解和意图识别，以及检索过程中的特征选取和权重优化、算分、排序，最后是比较重要的效果评价。这个过程中NLP的应用也非常多，除了基本的分词，还可能涉及非必留、词性识别、纠错、繁简体、多语言、文本向量化及语义距离计算等。


最后推荐一本搜索必读书籍—— 吴军的《数学之美》第二版 https://book.douban.com/subject/26163454/   

第1 章　文字和语言 vs 数字和信息
第2 章　自然语言处理 — 从规则到统计
第3 章　统计语言模型
第4 章　谈谈分词
第5 章　隐含马尔可夫模型
第6 章　信息的度量和作用
第7 章　贾里尼克和现代语言处理
第8 章　简单之美 — 布尔代数和搜索引擎
第9 章　图论和网络爬虫
第10章　PageRank — Google的民主表决式网页排名技术
第11章　如何确定网页和查询的相关性
第12章　有限状态机和动态规划 — 地图与本地
第13章　Google AK-47 的设计者 — 阿米特· 辛格博士
第14章　余弦定理和新闻的分类
第15章　矩阵运算和文本处理中的两个分类问题
第16章　信息指纹及其应用
第17章　由电视剧《暗算》所想到的 — 谈谈密码学的数学原理
第18章　闪光的不一定是金子 — 谈谈搜索引擎
第19章　谈谈数学模型的重要性
第20章　不要把鸡蛋放到一个篮子里 — 谈谈最
第21章　拼音输入法的数学原理
第22章　自然语言处理的教父马库斯和他的优秀弟子们
第23章　布隆过滤器
第24章　马尔可夫链的扩展 — 贝叶斯网络
第25章　条件随机场、文法分析及其他
第26章　维特比和他的维特比算法
第27章　上帝的算法 — 期望最大化算法
第28章　逻辑回归和搜索广告
第29章　各个击破算法和Google 云计算的基础
第30章　Google 大脑和人工神经网络
第31章　大数据的威力——谈谈数据的重要性
 
 
 
 
 

对，你一定看过一个电影，情节是这样的，他们拿着长矛去狩猎异形怪物，它们比人类强健，它们的脸部的器官布置得出奇丑陋。它们的身上总是带了一堆很先进的狩猎武器，它们喜欢在杀死猎物后将尸体剥皮，还会将猎物头骨加工成工艺品，当成战利品收藏。对，这部电影系列就叫Predator。好了，言归正传，我们今天讲的故事其实非常简单，讲述的是elasticsearch引擎在安全领域的简单应用，如何通过elasticsearch来搜索一个病毒，我们开发了一个小小的工具来帮我做跨集群查询，以及SQL-DSL转换接口，我们把这个小工具叫做predator。

背景

我司主要是做病毒相关工作的，近年来，数据爆炸，病毒软件也成几何级数倍数增长，大数据病毒出现自然需要对应的大数据工具来处理它们，简单来讲，就是我们可以把病毒样本的一些属性剥离到elasticsearch中，就和日志来描述一个用户的行为一样，本质来说，它们都是数据，然后，我们研究病毒的一些特征属性，通过简单的搜索，就可以快速分析出一堆可能的病毒样本，再然后，通过一系列的测试，过滤，我们就可以真正的找到我们想要的病毒样本，并且通过这些规则持续的追踪它们，是不是很简单?

问题

事情是那么简单，但是在使用elasticsearch作为特征库的过程中，我们也有这样的问题：
1，多种维度特征
由于存在多种维度特征的病毒，不通模块剥离出不通病毒属性，所以存在多张表来存属性，那么在query的时候就需要跨表，甚至跨集群查询。
2，DSL的复杂度
由于内部研究员们对elasticStack并不熟悉，加上DSL语言相对复杂，我们需要使用更加接近hunman特性的SQL来转换DSL语言。

数据处理架构

我们有一个类似的数据处理架构

Predator和它的Spear

因此，我们开发了一个小工具，其实，这个小工具非常简单，只是简单的解决了上述2个问题：
使用Elasticsearch-SQL插件来包装一个restful的DSL转换SQL接口，当然，目前ES6已经完全支持SQL接口了，哈哈，早点出来我们就不用做那么工作了:) :):)。
简单的写个跨集群的查下聚合器就可以实现跨表查下，其实，这个功能只是简单的查下封装，只是针对特殊的业务场景，没啥参考价值。
至于Spear，它其实就是个predator service的客户端，哈哈，像不像铁血战士拿着长矛开着非常去狩猎的样子:) 。

这是一个规则：

这是规则的查询结果：

长矛的sample code:
```python

cross cluster search by dsls

import json
from spear import Spear
sp = Spear()
dsl_1 = {}
dsl_2 = {}
query_dict = {
json.dumps(dsl_1): {
"cluster": "es_cluster_1",
"type":"xxx"
},
json.dumps(dsl_2): {
"cluster": "es_cluster_2",
"type": "yyy"
}
}
sp.cross_count_by_dsl(query_dict, is_show_help=False)
```
当然长矛也支持SQL接口

总结

其实，这个只是一个user case的工程实践，可以看到的是，伟大的ElasticStack在各行各业，各种大数据领域，如果抛开领域的概念，一切都是数据，那么理论上来说我们可以使用elasticsearch处理任何类型的数据，当然目前业界典型的应用场景还是搜索，日志，甚至于APM，总之，紧跟社区可以学到很多东西啦。

1、Mongodb同步Elasticsearch演示
http://t.cn/EUu5RI3
2、Elasticsearch7.0计算向量距离新特性抢先看
http://t.cn/EUB4vbo
3、Kubernetes上部署高可用和可扩展的Elasticsearch
http://t.cn/ELhogLr

编辑：铭毅天下
归档：https://elasticsearch.cn/article/6214
订阅：https://tinyletter.com/elastic-daily

Elastic Cloud Enterprise 出来也有一年多的时间了。对于这类的开源软件企业版本，基本都是在可管理性和稳定性上面下功夫。但是新产品免不了需要经历一下bug的打磨才会变得成熟。

下面分享的这个案例是当我们在把集群从5.4.1 升级到5.6.12 的过程中，遇到节点关闭受阻，升级不完整等情景。以及对应的处理方法。
首先在ECE中，版本是通过stack的方式管理
 

Ref : https://www.elastic.co/guide/e ... .html

这些版本都是以docker images的形式存储


因此，ECE根据不同的版本,然后选择对应的docker image就可以创建一个节点了. 那么升级的过程就可以简单分成几个步骤

1.exclude准备升级的节点。

2.停止节点ES进程，更换container 版本。

3.重新启动节点，加入集群。

4.在其他节点上重复以上流程。

在这个过程中, 实际使用的时候发现有一些需要注意的雷区.
扫雷一：使用UI触发升级，必须保证集群没有自定义插件和bundles

ECE 里面的集群操作是通过plan来控制的


任何的集群操作最终都会生成一个plan的diff。如上图，把集群从5.4.1 升级到 5.6.12 会产生以上diff.

正常情况下是没有问题的.

如果集群配置了自定义bundles, 比如LDAP bundles, ref:https://www.elastic.co/guide/e ... .html

那么在集群的plan里面就会存在这么一段配置


那么当我们在按下升级按钮的时候


ECE 只在plan中修改了集群大版本的配置, 但是并没有修改自定义bundles中的版本号(仍然是5.4.1).

在这种情况下去执行升级,会直接产生报错.


界面上没有显示原因, 但是这是因为plan里面大版本和bundle中的版本不一致,然后会导致新增的节点无法启动. 于是ECE 就认为集群升级失败了.
解决方法是手动编辑plan,把自定义bundles中的版本号改成和集群版本一致


然后使用ECE 提供的一种手动使用plan进行集群升级的方式进行升级.

扫雷二：节点无法关闭

ECE 控制container 是通过一个叫做 constructor的服务。constructor 通过接收集群的更改需求，制定具体的更改计划与步骤，指导allocator对container进行操作。同时也负责保证集群高可靠性，通过Availability Zone的数量在不同的AZ上面部署节点。

当Allocator接受到关闭container命令的时候，会尝试去关闭container，如果container处于一个阻塞状态无法响应, 那么关闭命令无法执行成功。这个时候constructor会等待节点关闭，但是allocator又认为节点已经接受到关闭命令了。又或者constructor发送给allocator的过程中网络丢包, 这个时候allocator 没有正确接受关闭container的命令. 整个升级进程就卡住了。 这种情况十分罕见,通常发现一个container如果处于”正在关闭”时间太久了, 那么通常就是中间的通信出现问题了.


解决办法是可以通过手动停止container, 在对应的allocator上面找到container，使用

docker stop <container_name>

停止container，这样可以出发allocator更新container的健康状态,上报这个container已经关闭了, 从而打通流程并执行下一步。
扫雷三: 多版本并存

如果使用上面的方式强行关闭docker container, 虽然可以让升级进程继续进行下去. 但是被手动关闭的节点会保留原来的版本。于是在升级后查看各个节点的版本，会发现部分节点是5.4.1， 部分是5.6.12.

因为节点是强制关闭的, ECE直接认为节点已经完成升级,并重新启动这个container. 而在这个处理中,跳过了升级docker image的一步.

为什么不是生成一个新的container呢? 因为从plan里面可以看到


在默认情况下, ECE 处理版本升级是使用rolling 策略 Ref: https://www.elastic.co/guide/e ... .html

在这个策略下，ECE会停止当前container并直接修改重启。

如果ECE集群容量允许, 可以改成grow_and_shrink 策略, 这样ECE 会创建新的container并且销毁旧的container, 避免集群出现多版本.
如果出现了多版本的集群,可以通过更改集群任意一个配置来触发 grow_and_shrink 同样可以使到版本回归一致.
总结来说ECE 在版本升级方面还是有很多需要改进的地方. 对于ECE用户再说在使用ECE的版本升级功能的时候主要有以下建议

1. 自己学会手动修改plan. 这也是每一个ECE support engineer 都会干的事情.

2.如果集群容量允许,尽量使用 grow_and_shrink的策略来进行集群操作.