用ElasticSearch搭建本身的搜索和分析引擎

做者：robben，腾讯高级工程师 
商业转载请联系腾讯WeTest得到受权，非商业转载请注明出处。 

---

导语：互联网产品中的检索功能随处可见。当你的项目规模是百度大搜|商搜或者微信公众号搜索这种体量的时候，本身开发一个搜索引擎，加入各类定制的需求和优化，是很是天然的事情。但若是只是普通的中小型项目甚至创业团队|创业项目，直接拿轮子则是更合理的选择。
ElasticSearch就是这样一个搜索引擎的轮子。更重要的是，除去常规的全文检索功能以外，它还具备基础的统计分析功能（最多见的就是聚合），这也让他变得更增强大和实用。
还在用数据库的like来实现产品的全文检索吗？抛弃她，用ElasticSearch吧~

 

ElasticSearch（下简称ES）是基于Lucene的一个开源搜索引擎产品。Lucene是java编写的一套开源文档检索的基础库，包括词、文档、域、倒排索引、段、相关性得分等基本功能，而ES则是使用了这些库，搭建的一个能够直接拿来使用的搜索引擎产品。直观地理解，Lucene提供汽车零部件，而ES直接卖车。

 

提及ES的诞生，也是个颇有意思的故事。ES的做者Shay Banon——“几年前他仍是一个待业工程师，跟随本身的新婚妻子来到伦敦。妻子想在伦敦学习作一名厨师，而本身则想为妻子开发一个方便搜索菜谱的应用，因此才接触到Lucene。直接使用Lucene构建搜索有不少问题，包含大量重复性的工做，因此Shay便在Lucene的基础上不断地进行抽象，让Java程序嵌入搜索变得更容易，通过一段时间的打磨便诞生了他的第一个开源做品Compass，中文即'指南针'的意思。以后，Shay找到了一份面对高性能分布式开发环境的新工做，在工做中他渐渐发现愈来愈须要一个易用的、高性能、实时、分布式搜索服务，因而他决定重写Compass，将它从一个库打形成了一个独立的server，并将其更名为Elasticsearch。“

引自（http://www.infoq.com/cn/news/2014/12/elasticsearch-birth-development）。

 

可见鼓捣起来的程序员是多么有爱，虽然听说Shay Banon承诺给妻子的菜谱搜索还没问世......

 

本文大概地介绍了ES的原理，以及Wetest在使用ES中的一些经验总结。由于ES自己涉及的功能和知识点很是普遍，因此这里重点挑出了实际项目中可能会用到，也可能会踩坑的一些关键点进行了阐述。

 

重要概念

集群（Cluster）： ES是一个分布式的搜索引擎，通常由多台物理机组成。这些物理机，经过配置一个相同的cluster name，互相发现，把本身组织成一个集群。

节点（Node)：同一个集群中的一个 Elasticearch主机。

主分片（Primary shard）：索引（下文介绍）的一个物理子集。同一个索引在物理上能够切多个分片，分布到不一样的节点上。分片的实现是Lucene 中的索引。

注意：ES中一个索引的分片个数是创建索引时就要指定的，创建后不可再改变。因此开始建一个索引时，就要预计数据规模，将分片的个数分配在一个合理的范围。

副本分片（Replica shard）：每一个主分片能够有一个或者多个副本，个数是用户本身配置的。ES会尽可能将同一索引的不一样分片分布到不一样的节点上，提升容错性。对一个索引，只要不是全部shards所在的机器都挂了，就还能用。主、副本、节点的概念以下图：

 

 

索引（Index)：逻辑概念，一个可检索的文档对象的集合。相似与DB中的database概念。同一个集群中可创建多个索引。好比，生产环境常见的一种方法，对每月产生的数据建索引，以保证单个索引的量级可控。索引->类型->文档，ES中的文档以这样的逻辑关系组织了起来。

类型（Type）：索引的下一级概念，大概至关于数据库中的table。同一个索引里能够包含多个 Type。 我的感受在实际使用中type这一级经常用的很少，直接就在一个索引中建一个type，在这个type下去创建文档集合和进行搜索了。

文档（Document)：即搜索引擎中的文档概念，也是ES中一个能够被检索的基本单位，至关于数据库中的row，一条记录。

字段（Field）：至关于数据库中的column。ES中，每一个文档，实际上是以json形式存储的。而一个文档能够被视为多个字段的集合。好比一篇文章，可能包括了主题、摘要、正文、做者、时间等信息，每一个信息都是一个字段，最后被整合成一个json串，落地到磁盘。

映射（Mapping）：至关于数据库中的schema，用来约束字段的类型，不过 Elasticsearch 的 mapping 能够不显示地指定、自动根据文档数据建立。

 

Elasticsearch很友好地提供了RestFul的API，能够经过HTTP请求直接完成全部操做。好比下面官方的一个例子，往索引twitter添加文档，type是tweet，文档的id是1：

 

 

相应地，根据user字段检索文档：

 

 

关键配置项

一、索引的shards个数:
shards的个数，最好是和节点数相关的。理论上对同一个索引，单机上的shards个数最好不要超过两个，这样每一个查询尽量并行。但由于ES中shards的个数是肯定了就没办法再调整的，因此若是考虑到数据会高速增加，一开始分配多些也能够。另外一个常见思路是按时间纬度（如月）去定义ES索引——由于能够动态调整新加的索引的shards个数。其余的一些状况，好比下面举到的Wetest聚合的例子，由于须要数据尽可能地按照渠道切分开，因此定义了不少个shards（200个），但太多的shards一般是不推荐的，ES管理起来也有开销。

 

二、heap内存:官方建议是可用内存的一半，是经过启动ES的环境中，定义环境变量的方式完成的。如export ES_HEAP_SIZE=10g

三、cluster.name:集群的逻辑名称。只有cluster name相同的机器，才会在逻辑上组成一个集群。好比，内网中有5台ES机器的实例，是能够构成几个互不干扰的ES集群的。

四、discovery.zen.minimum_master_nodes:
这个是用于集群的分布式决策的最少master机器个数。和常见的分布式协调算法同样，为了不脑裂现象，建议超过一半的机器，n/2+1

五、discovery.zen.ping.unicast.hosts:
ES集群的机器列表。注意ES单点不用配置集群中的全部机器列表，像一个连通图同样，只要每台机器配置了其余机器，而这些配置又是互相能够链接的，那ES最终就会发现全部机器，构成集群。如['111.111.111.0','111.111.111.1','111.111.111.2']

 

mapping

mapping相似于数据库里的表结构，定义个mapping就意味着建立了一个索引。与数据库不一样的是，一个索引并不须要显示地创建mapping，好比，上面那个在twitter索引插入文档数据的例子，若是执行的时候尚未定义索引，ES便会根据文档的字段和内容，自动建立索引和mapping。然而，这样建立的索引字段，每每可能不是咱们所须要的。因此，仍是本身预先经过手动定义mapping来建立索引比较好。下面是建立mapping的例子，这个例子在my_index这个目录下，为user、blogpost这些type建立了mapping。其中properties下面是各类字段的定义，包括了string、数值、日期等类型的定义。

 

如图中的红框部分，这个例子中有两个须要注意的地方：

一、user_id是string类型的，但它的index被定义为了“not_analzyed"，这个须要搞清其中的意义：一般，搜索引擎中全文检索的功能简单说是这样实现的：对原始文档进行分词后用这些词去创建倒排索引，在线上检索时，再将用户的查询词进行分词，用分词结果去拉取多个倒排索引的拉链结果、归并、相关性排序等，获得最终结果。可是，对于有些string类型的字段，其实并不想建倒排，就只想精确匹配，好比用户的名字，只想查到name字段精确为“张三”的人，而不是分词后获得的“张四”和“李三”两我的，这个时候，就须要定义index类型字段。这个字段有no、analyzed、not_analyzed三种类型，no是压根儿不给这字段建索引，analyzed是分析和按全文检索的方式建，not_analyzed是彻底匹配的关键词查询方式。

 

二、date类型，建立mapping时须要经过“format”指定录入的多种可能时间格式。这样建立文档的时候，ES会根据输入文档的字段自动去肯定是哪种。不过直观地想象下，在建立文档时，指定明确的时间格式，省去ES动态判断的开销，应该会提高些微小的性能。此外，要注意，epoch_second（秒单位时间戳）和epoch_millis（毫秒单位）尽可能不要混用，若是非要混用也要在插入的时候明确指明是哪一个。曾经踩过坑，插入epoch_second的是秒级时间戳，但ES优先认为是毫秒，致使时间被缩小1000倍，最近的时间变成了1970年当年的某个时间。

 

 

 

下图列出了ES当前版本中能够进行mapping的数据类型、内置的字段、mapping操做能够携带的参数。由于篇幅缘由这里就不详细解释了：

 

 

这里要详细介绍的，是上图中红框标出的，咱们建立mapping时实际用到的比较关键的两个内置类型，和两个mapping参数。这几个都会直接影响最后索引访问的性能：

1）_source： es会把全部字段拼成一个原始的json落入磁盘，因此这个能够理解为全量原始数据，他不能用来索引，却能够在须要的时候返回。注意尽可能不要禁用，好比禁用后，用script去update就不支持了。

2）_all：一个“伪”字段，用来实现模糊的全文索引。能够这样理解：在建索引的时候，把全部字段拼成一个字符串，而后对这个“大”字段进行切词，建倒排，而后这个字段就被丢弃了，没有真正落入磁盘。当全文检索时，若是没有指明查询的域，好比标题、正文（这种是很常见的），就从这个大的倒排中拉取文档拉链。能够想象，一些标记或值类型的字段，如日期、得分，这种在全文检索时是没意义的，就能够不包含在_all内，而文本域，如title、doc，就包含在_all之中。这些都是在建mapping时能够、并且最好指定的。

3）doc_values： doc_values和下面的field_data都是在聚合（后面会介绍）、排序这些统计时用的参数，默认都是开启的。排序、聚合，这种在文档全局进行的工做，用倒排索引确定不合适。因此，对not_analyzed（即不建倒排）的字段，doc_values用一种列模式的方式（能够参考hbase）来存储文档的正排，方便在文档全局作统计。doc_values是存储在磁盘的，若是你明确有些字段只是展现，不用于统计的话，能够把这个禁用掉。Doc_values必定不会对analyzed域建索引（都切词了，想一想也不合适，怎么建列索引嘛），而是用下面的field data。

4）field_data：对analyzed的文本域，好比正文，其实也会有统计的需求（好比ES也支持按一些关键词对文档进行聚合统计，但这种任务经常使用的方法是经过离线工具，如hadoop或者单机的分析，作好了后推送到在线索引，直接在ES去算其实感受有些奇怪）。虽然并不适合在搜索引擎中作，但你真的作了，es也会把这个数据动态地load内存的一个field data中进行运算。因此，想一想就知道，这是个很是耗内存的操做，极可能把jvm heap吃完了！！es默认是只打开，但不load，只是在你须要进行analyzed域的排序和聚合的时候，才去动态load这个内存（lazy的方式）。因此，尽可能不要在查询的时候去打开这个潘多拉魔盒，或者干脆就把这个选项关掉吧。

 

聚合

谁说搜索引擎只能用来搜索？ES不只能搜索，还能在搜索的结果集合上直接进行统计，很强大吧。ES目前稳定的非实验阶段聚合主要分两种：Metrics Aggregation（指标聚合）和Bucket Aggregation（桶聚合）。

指标聚合主要指常规的集合数学统计类运算，如官方guide的这个例子：找到交易的全部红色的车，而后求它们的平均价格：

 

 

 

 

结果大概是这样的：

 

神奇吧~指标运算还包括其余，如最大、最小、求和、个数、地理坐标运算等。然而咱们今天要进行实例讲解的则主要是Bucket Aggregation，桶聚合。桶聚合是指把文档，按照某个给定字段分红不一样的组，而后在组内进行进一步聚合运算，并返回桶级的结果。比较直观的理解，如：直方图、分时间段统计等等。以下面这个例子，是桶聚合中的term聚合，即按照color这个字段，精确匹配后进行分桶，而后桶内还进一步嵌套了平均价格聚合、和按制造商进一步的分桶聚合。

 

 

 

 

统计的结果相似下面这样，红色的车共有4辆，平均价格是32500，而且又包含了3辆本田和1辆宝马：

 

 

上面是简单的例子。在咱们的WeTest舆情中，有论坛热帖这样一个功能，即，实时统计某个数据源中（如百度贴吧），某个论坛里（如王者荣耀吧），一段时间内（如3个月），回复数最多的TopN个帖子。

 

 

这个功能如今在线上的实现方法就不详细介绍了，大体是从数据库和Hbase中扫描对应的数据，维持一个堆，获取出TOP N的思路。一方面是稍微有些耗时，另外一方面是请求量很大时可能对DB和Hbase的访问带来压力，因此也想找一种备选的方案，咱们想到了用ES。

 

为了用ES的桶聚合，咱们首先设计如何存储文档（即全部用户评论）的方案。因为数据量很是大（十亿级），因此咱们首先想到了把文档按时间分红不一样的索引（如按月），而后在指定月份（如3个月）的索引上，聚合出评论最多的Top帖子。然而这样是有问题的：当在多个ES索引上聚合时，ES不会把全部索引的结果放在一块儿聚合TopN，而是单独在每一个索引求得TopN后，再放在一块儿聚合。这是个使用时要注意的小坑。这样致使的结果是，直接在多个索引上聚合出的TopN，并非真正的TopN（好比3个月中，每月都是否是Top 1，但三个月加起来就是Top了 1。局部最优不等于全局最优）。

 

因此，从时间上切分，这条路基本被堵死了。那只能从空间上切分了（您问能不能不切分？十亿级的数据量，上百个GB，不切分的话，乖乖，每次都要从这几百GB的文件里找东西，想一想也知道有多慢了...）。从空间切分，一样须要考虑两个问题：1）如何将数据hash到shards。2）切分多少个shards。对于第一个问题，由于咱们的聚合统计是在每一个渠道（能够理解为论坛）下的，不会跨渠道，因此，按照渠道ID进行shards分配，把相同论坛的数据hash到一个shard便可。这样，每次请求某个渠道的聚合结果，把请求按渠道ID routing到对应的shard去运算。对于第二个问题，要看具体的规模了。咱们的数据量有上百G，数据源上千个，因此咱们但愿每一个shard上的内容尽可能少，保证在单个shard上聚合的时候会更快，固然shards个数又不能太多，不然会给ES引入很是大的管理开销。综合下来，咱们选择的shards个数是200个。

 

遗憾的是，ES只能根据你指定的key（论坛ID）去作hash后进行路由，这就致使了不一样的shards上数据不是彻底平均的，最多的能超过10GB，最少的只有几十MB。若是哪一天，ES若是开放自定义routing规则或者对shards数据进行均衡的方法，那就行了。

ES常常为人诟病的一个地方是建索引比较慢，10亿数据的索引构建时间要花几天。这也容易理解，天下没有免费的午饭，读写的性能每每是互斥的，快速读取和检索意味着大量索引和辅助数据的预先创建，那写入时势必会慢。如何取舍，须要看实际的业务场景而定了。下面就是建好索引后，去聚合某论坛内指定时间段内Top帖子的接口调用方式。

 

 

而后，咱们按连续统计最热的TopN（N为不一样的个数）个渠道内的Top30热帖结果的方式分别对ES和线上已有的服务进行了测试：

 

 

上面的五个结果图直观地反应了用如今Wetest舆情线上的常规统计方式和ES聚合统计的方式获取结果的耗时。

 

从结果中，咱们大概推断出了ES统计聚合运算的作法：先把全部符合过滤条件的数据所有检索出来，而后在内存中进行排序和聚合运算。也就是说，符合条件的数据量级越大，聚合运算越慢。本着这个原则，结果图也就比较好理解了：

1）在连续对最热的Top1000个渠道去进行热帖聚合时，ES的表现大部分都优于现有实现。这是由于Top1000的渠道中，大部分渠道被分在了很是小的shards上，有的只有几MB，数据量很小，在这样的shards中聚合，是很快的。

2）时间纬度上，统计3个月的数据，ES大部分状况下都比现有方法慢，而1个月或1天的状况下，ES都要快。这是由于3个月的条件下，符合条件的数据量级增大（最大的一个话题下有3万跟帖），ES的运算效率降低比较厉害。

3）从Top1000到Top10，ES的总时间逐渐变差于现有方法。这是由于，空间纬度上，Top10渠道符合条件的数据量级很是大，因此ES的运算效率降低比较厉害。

 

作了这个实验后，ES在WeTest头部数据源上的聚合速度并不比如今快，但在中部和长尾上的效果更优，这说明ES的聚合受候选集数据量的影响很是大，因此是否切换这种方式也还没最终决定。不过，这个实验证实了ES聚合的强大能力，至少，不用本身写什么代码，只经过接口调用就能把这样海量数据的统计运算完成了，仍是很方便的一件事情，同时性能也不错。若是自行实现的统计运算中会增大DB的压力，那么经过ES聚合分离这部分请求，也是一个很是好的选择。

---

WeTest产品舆情，一站式了解你的产品口碑和用户喜爱。

点击 http://wetest.qq.com/bee 当即体验！

亲爱的读者，为了可以提供更好的网站内容，但愿您填写咱们的问卷，咱们会随机抽取读者回馈20Q币以示感谢！问卷入口：https://wj.qq.com/s/1221194/26ad