转载 http://www.infoq.com/cn/articles/let-data-talk-itself-shaybanon

嘉宾｜Shay Banon , 作者｜谢然／ InfoQ

随着互联网数据规模的爆炸式增长，如何从海量的历史、实时数据中快速获取有用的信息，变得越来越具有挑战性。而这其中，搜索作为获取信息最高效的途径之一，已经越来越受到人们的青睐。

一款优秀的搜索引擎，它连接了普通用户和网站网页，用户可以轻而易举且免费地搜索到想看的网站和内容，而这些网站的内容被搜索引擎检索到，通过搜索引擎技术呈现给用户。

10 月 13 日，在 2017 杭州云栖大会上，Elasticsearch 与阿里云宣布达成战略合作，共同研发及发布阿里云上提供托管的 Elasticsearch，为中国市场提供崭新的用户体验。Elasticsearch 挺进中国市场面临的机遇和挑战如何？阿里云 Elasticsearch 为中国用户提供了哪些新服务？为此，InfoQ 采访了 Elasticsearch 的创始人兼首席执行官 Shay Banon。

经过短短一个小时的交流，能明显感觉 Shay Banon 有着灵敏的商业嗅觉。他在搜索的领域深耕了 18 年，差不多 8 年前创立了 Elasticsearch，他说，创业最重要的是找到自己擅长的地方，并且保持激情和热爱，创业，意味着你要寻找生活中的问题，然后用创造性思维去解决它们。

Elasticsearch 源于一个食谱的应用

在谈及当年接触 Lucene 并开发 Elasticsearch 的初衷的时候， Shay Banon 认为自己参与 Lucene 完全是一种偶然，当年他还是一个待业工程师，跟随自己的新婚妻子来到伦敦，妻子想在伦敦学习做一名厨师，而自己则想为妻子开发一个方便搜索菜谱的应用，所以才接触到 Lucene。直接使用 Lucene 构建搜索有很多问题，包含大量重复性的工作，所以 Shay Banon 便在 Lucene 的基础上不断地进行抽象，让 Java 程序嵌入搜索变得更容易，经过一段时间的打磨便诞生了他的第一个开源作品“Compass”，中文即“指南针”的意思。之后，他找到了一份面对高性能分布式开发环境的新工作，在工作中他渐渐发现越来越需要一个易用的、高性能、实时、分布式搜索服务，于是决定重写 Compass，将它从一个库打造成了一个独立的 server，并创建了开源项目。

第一个公开版本出现在 2010 年 2 月，在那之后 Elasticsearch 已经成为 Github 上最受欢迎的项目之一。

Elasticsearch 的成功源自开源

经过八年，Elasticsearch 在中国也颇受广大工程师欢迎， Shay Banon 说 Elasticsearch 成功的关键因素就是开源还有除了搜索之外的不同用例，如 日志管理、安全和分析。

他认为，开放源代码搜索引擎为人们学习、研究并掌握搜索技术提供了极好的途径与素材，推动了搜索技术的普及与发展，使越来越多的人开始了解并推广使用搜索技术。使用开源搜索引擎，可以大大缩短构建搜索应用的周期，并可根据应用需求打造个性化搜索应用，甚至构建符合特定需求的搜索引擎系统。搜索引擎的开源，无论是对技术人员还是普通用户，都是一个福音。

Shay Banon 有一个愿景，使世界上每个开发人员能够使用搜索作为基础来简单地解决他们最复杂的用例。通过实时和大规模提供数据，Elastic 的产品已经下载了超过 1.5 亿次累积的时间，用于构建现代搜索，日志记录，安全性，指标和分析应用程序。

技术助推力量

当今世界，技术的日新月异加剧了市场竞争力的此消彼涨过程，企业越来越重视技术创新所带来的竞争力量的增强以及由此创造的短期和长期市场利益，逐步形成以技术创新为核心的发展战略。企业之间的竞争，不仅仅是规模上的竞争，更重要的是企业间的技术创新实力的较量。

马云在云栖大会上演讲时，谈到技术对于未来的重要性，“在未来面前我们都是孩子，未来没有专家”，他认为未来发展得好的公司一定是能将互联网技术用得最好的公司。

任何一种新兴技术，都必然要经历螺旋式上升的发展轨迹，也必须符合技术生命周期的发展规律，即从概念提出、泡沫、破灭、冷静、成熟、应用兴起，再到重生与再创新。对于企业来讲，在企业方向和研发战略上，一定要把握和尊重技术产业领域的发展规律。

Shay Banon 介绍了 Elasticsearch 里的几项关键技术处于的趋势。

Shay Banon 说他及他的团队会不断在技术之路上不断创新，让 Elasticsearch 争取可以为不同的用户解决各种问题。

Elasticsearch 和阿里云合作 大步迈进中国市场

当谈及 Elasticsearch 挺进中国市场的战略时， Shay Banon 表示：“中国对我们来说是一个不断增长的市场，过去几年间，我们看到 Elasticsearch 的社区版图扩展至超过 5000 多位开发人员。中国也是全球最大的市场之一，差不多有 1.9 亿的开发者，希望这 1.9 亿开发者都能用到开源的 Elasticsearch 的产品，并且取得成功。今天 Elasticsearch 选择与阿里云合作，并配合 Elasticsearch 的实时处理能力、强大的 X-Pack 功能，如 security，alerting 和 machine learning，共同加快中国广大开发者生态的创新步伐，构建、托管及管理更多不同的应用。”除此之外，Shay Banon 认为 Elasticsearch 接下来会针对中国市场，大力推广其商业化产品 X－Pack，让越来越多的人了解与使用。

“阿里云 Elasticsearch” 现已正式上线，简单配置即可添加到客户的云计算服务之上。通过 Elasticsearch 实时搜索的能力与客户应用相结合，以 Logstash 或 Beats 将数据导入阿里云 Elasticsearch 里，使用 Kibana 仪表板把实时及历史数据可视化，加上 X-Pack 的一系列功能如 security、alerting、monitoring、reporting、Graph 分析及 machine learning，为开发人员提供一站式产品的体验。

阿里云 Elasticsearch 的新服务能让阿里巴巴的客户随心所欲地运用 Elasticserach 强大的实时搜索、采集及数据分析功能，是一站式而且主导性的解决方案。

此外，阿里云和 Elasticsearch会着力于技术提升，确保阿里云 Elasticsearch 与时并进，拥有最新的功能。在未来，日志导入功能及其他服务也将相继可用。

搜索引擎的数据挖掘优势

大数据时代，也是信息爆炸的时代，是否拥有信息已经不再重要，重要的是如何能够快速的找到所需信息，而搜索引擎在这方面有着天然优势，搜索引擎的数据挖掘将产生更加明显的效果。

很多搜索技术的改进都离不开大数据技术。搜索引擎从本质上看，就是一种典型的大数据应用。目前，搜索在大数据领域已经跨进了一大步，人们可以实时搜索到想要的信息。

根据最新的数据库引擎排名显示，Elasticsearch，Solr 和 Splunk 分别占据了数据库搜索引擎的前三位。

从趋势上来看，Elasticsearch 和 Splunk 上升明显，Elasticsearch 更是表现出了非常强劲的势头。

在生产环境记录应用的运行日志已经成为惯例，但日志需要经过处理和分析才有意义，第三方日志管理工具的出现正旨在解决这个问题。当下比较有代表性的日志管理工具有 Splunk 和 Logstash （注：Logstash 用途在于将数据插入到 Elasticsearch 和 Kibana 中可视化日志）。

Shay Banon 表示在日志分析领域，Elasticsearch 最大的竞争对手就是 Splunk ，在商业软件付钱与开源软件免费之间选择，Elasticsearch 是全世界最受欢迎的开源解决方案，而且会以灵活性，实时能力和规模地处理大量数据，所以如果你在内地问开发者，大部分开发者倾向于 Elastic Stack。

他举例, 类似于 Netflix，Facebook，Microsoft 以及 Linkedln 公司在日志基础架构上会选择运行大型 Elasticsearch 集群。此外，Elastic Stack 能够在不同范畴使用，比如欺诈检测和特定领域的业务分析，这将使 Elastic 不继扩张。

机器学习赋能用户解决复杂问题

云计算的发展，使得数据的采集、处理和分析都变得容易，大数据得以存在于各行各业各种数据体系中，人工智能因此成为了一个火爆的领域。

而其中的机器学习就是基于搜索技术建立起来的，而搜索带来的海量数据积累，又能够构建一套基于海量数据的数据统计分析，从而能够为一些应用场景下的关键决策带来指导和支撑。

Shay Banon 强调机器学习在数据搜索领域的重要价值：“以后不是跟数据讲我们要什么，而是数据主动告诉我们这边有什么，这就是机器学习的力量。

一点小小的担忧

搜索引擎知道我们的出行路线、地理位置、工作信息、日常行为模式和交际圈子，它比任何保险公司或银行都了解我们的风险状况，随着可穿戴智能设备的兴起，它也可能比医生更了解我们自身的身体状况。或者说，搜索引擎将变得比我们自己更了解自己。

这是信息时代独特的背景，对于效率的追求使我们不可避免的享受互联网搜索引擎等服务带给我们的信息服务，同时也不可避免的享受个人信息外泄的苦恼。搜索引擎的机器学习势必需要越来越多的用户信息，这与我们的隐私权存在本质上的冲突。或许，我们已经意识到这一点，但在效率面前对此无能为力。

给广大工程师的建议：

计算机世界变化的速度是惊人的。程序员被认为是最接近计算机世界的职业，几乎所有的科技新产品都得由程序员来写代码。

Shay Banon 建议广大程序员要不断地学习新的技能，并且铭记在过往使用那些技能时得到的经验。有激情，并且热爱这份职业，时刻站在终端用户的角度去评估自己所编写的软件，而不是在封闭的空间里编写代码。

除此之外，程序员还要擅于借助工具，开发过程中选择适合自己和项目开发所需要的工具。正所谓工欲善其事, 必先利其器。

写在最后：

Shay Banon 非常喜欢马云说过的这句话，“帮助年轻人，帮助弱小的人，因为小树苗也可能成长为参天大树。你将种子埋入这些年轻人的脑中，等他们成长起来，就可以改变世界。”

帮助别人，让别人强大，你才能更强大。这才是生命的意义。

-END-

【携程旅行网 吴晓刚】

注：本文是针对Elastic中文社区问题question#2484 的分析和总结。

问题概述

一个线上集群，执行的Query DSL都是一样的，只是参数不同。 统计数据显示98-99%的查询响应速度都很快，只需要4 -6ms， 但有1%左右的查询响应时间在100ms - 200ms。 集群硬件配置较高，使用的SSD，系统可用内存远高于索引文件大小总和，并且线上已经运行有一段时间，数据应该已经充分预热。

诊断过程及结论

比较巧的是，问题提出者刚好是我们自家公司的开发者，因此内部联系沟通了下，为问题的快速诊断提供了不少便利。

首先用公司的监控系统排查了一遍集群所有关键数据，未发现任何可能引起查询耗时高的性能瓶颈问题。 因此初步怀疑就是有查询本身比较慢。 幸好公司有应用埋点系统和日志系统，因此很方便的拿到了应用端发出的一些慢查询样例，包括请求体以及耗时。

以下是埋点系统里记录的一个耗时150ms的查询 (隐去了敏感信息，去掉了非关键部分):

POST /xxxindex/xxxdb/_search?routing=Mxxxxxxx
{
  "from": 0,
  "size": 100,
  "query": {
    "bool": {
      "filter": [
        {
          "bool": {
            "must": [
              {
                "bool": {
                  "must": [
                    {
                      "bool": {
                        "should": [
                          {
                            "match_phrase": {
                              "ord_orders_uid": {
                                "query": "Mxxxxxxx",
                                "slop": 0,
                                "boost": 1
                              }
                            }
                          }
                        ],
                        "disable_coord": false,
                        "adjust_pure_negative": true,
                        "boost": 1
                      }
                    },
                    {
                      "range": {
                        "ord_orders_orderdate": {
                          "from": "1405032032",
                          "to":   "1504014193",
                          "include_lower": true,
                          "include_upper": true,
                          "boost": 1
                        }
                      }
                    },
                    {
                      "term": {
                        "ord_orders_ispackageorder": {
                          "value": 0,
                          "boost": 1
                        }
                      }
                    },
                    {
                      "bool": {
                        "must_not": [
                          {
                            "exists": {
                              "field": "ord_hideorder_orderid",
                              "boost": 1
                            }
                          }
                        ],
                        "disable_coord": false,
                        "adjust_pure_negative": true,
                        "boost": 1
                      }
                    }
                  ],
                  "disable_coord": false,
                  "adjust_pure_negative": true,
                  "boost": 1
                }
              }
            ],
            "disable_coord": false,
            "adjust_pure_negative": true,
            "boost": 1
          }
        }
      ],
      "disable_coord": false,
      "adjust_pure_negative": true,
      "boost": 1
    }
  }
}

拿到查询后，自己手动执行了一下，0 hits，耗时1ms。  心里明白，命中了Query Cache，所以才会这么快。 

于是用clear api清掉Query Cache，然后再执行几次，有以下发现：

• 头两次查询耗时38ms左右。 这是因为没有cache，需要访问倒排索引，耗时符合预期。 之所以两次同样耗时，是因为索引有1个复制片，两次查询分别分配到主和副片上。
• 接下来两次查询耗时150ms左右。  这里要打一个大大的问号？？？
• 之后不管再查询多少次， 耗时全部是1ms，因为又开始命中Cache。

至此，大致明白，埋点系统里记录到的高耗时查询，是步骤2的两次操作。 什么操作耗时这么久呢？ 根据经验，我判断主要是用于为range filter生成缓存，也就生成生成文档列表的bitmap，然后存放到Query Cache里。 

这个集群版本是5.1.1， 而我记得ES某个5版本开始，去掉了对term filter的cache，理由是term filter速度足够快，缓存term filter往往得不偿失。 查了官方release notes，证实这个改变正好是从5.1.1开始的#21566，因此上面查询里的term filters被排除掉，注意力集中到了查询里唯一的一个range filter。 

单独执行了一下这个range filter，match的文档是千万数量级的。 询问用户，为何这个range filter会hit这么多文档，得知用户主要就是查询从当前时间开始至过去1年的数据，类似于做了一个now-1y  TO now这样的过滤。至此初步得出结论，因为这个range filter匹配的文档太多了，在Query Cache里为这个filter构建bitmap耗时会有些高，应该就是它带来了那额外的100多个ms。

但是还有一个待解释的问题，这种高耗时查询比例为何这么高？ 再仔细想想也就明白了：因为这个集群的搜索并发量还是有点高，300 -400/s的样子，加上时间字段的精度是秒，所以，在某一秒刚开始的时候，头2次查询因为没有cache，耗时可能在38ms左右，之后会有2次查询因为需要缓存range filter，耗时会增加到150-200ms的样子，之后这1秒里剩余的查询都会命中cache，全部是几个ms， 直到下一秒开始， 周而复始。 因为每秒钟都产生2个这样需要构建缓存的查询，耗时较高，对比每秒几百次的查询量，换算成百分比就有点高了。

那么怎么解决这个问题？ 对于大量含有从now-xxx TO now这样的range查询，实际上官方的文档有对应的加速技巧介绍：tune-for-search-speed.html#_search_rounded_dates 。也就是说，将查询时间的上下限round到整分钟，或者整小时，让range filter可以缓存得更久，避免出现这种过于频繁重建cache的情况。

{
   "range": {
       "my_date": {
       "gte": "now-1y/h",
        "lte": "now-1y/h"
      }
    }
}

在原始Query里，将range filter写成上述形式，手动测试证实可行，range filter有效期延长到1小时，从而每个小时里，只需要为range filter重建2次Cache，至此问题解决。

总结:

1. Cache并非建得越多越好，因为Cache的生成和Evict会带来额外的开销。特别是结果集非常大的filter，缓存的代价相对查询本身可能非常高。
2. ES 5.1.1开始取消了Terms filter Cache，因为Terms filter执行非常快，取消缓存多数情况下反而可以提高性能。
3. 大量用到Now-xxxd To Now这样的Range filter时，可以借助round date技巧，提高Cache的有效期，减轻频繁重建Cache带来的性能问题。