1. 如何使用Elasticsearch下载字段的所有独特术语。 http://t.cn/RQGh4wl 

2. 如何在Elasticsearch中找到相似的术语。 http://t.cn/RQGz6Pt 

3. (自备梯子)想成为一名数据科学家？尝试费曼技术。 http://t.cn/RQGwPhu 

• 编辑：至尊宝

• 归档：https://elasticsearch.cn/article/454

• 订阅：https://tinyletter.com/elastic-daily

1. ES6.1新特性：利用机器学习进行按需预测 http://t.cn/RQ4GZll

2. 利用ES为推荐的产品定制评分（需翻墙） http://t.cn/RQ45Wva

3. 一周热点：冲顶大会等答题类游戏的辅助决策开源代码，各位道友可以试试 http://t.cn/RQAxiCr

• 编辑：bsll

• 归档：https://elasticsearch.cn/article/453

• 订阅：https://tinyletter.com/elastic-daily

能有影响elasticsearch score的方法有很多，官方推荐的是使用内置的painless脚本语言结合function_score来重新定义score。由于本人开发的项目其算法是由java语言开发的，于是决定尝试原生脚本开发。 elasticsearch脚本由plugin-descriptor.properties文件以及运行jar包组成，plugin-descriptor.properties主要用来定义版本信息、对应es的版本信息等属性。

官方的例子

public class ExpertScriptPlugin extends Plugin implements ScriptPlugin {
    @Override
    public ScriptEngineService getScriptEngineService(Settings settings) {
        return new MyExpertScriptEngine();
    }
    /** An example {@link ScriptEngineService} that uses Lucene segment details to implement pure document frequency scoring. */
    // tag::expert_engine
    private static class MyExpertScriptEngine implements ScriptEngineService {
        @Override
        public String getType() {
            return "expert_scripts";
        }
        @Override
        public Function<Map<String,Object>,SearchScript> compile(String scriptName, String scriptSource, Map<String, String> params) {
            // we use the script "source" as the script identifier
            if ("pure_df".equals(scriptSource)) {
                return p -> new SearchScript() {
                    final String field;
                    final String term;
                    {
                        if (p.containsKey("field") == false) {
                            throw new IllegalArgumentException("Missing parameter [field]");
                        }
                        if (p.containsKey("term") == false) {
                            throw new IllegalArgumentException("Missing parameter [term]");
                        }
                        field = p.get("field").toString();
                        term = p.get("term").toString();
                    }
                    @Override
                    public LeafSearchScript getLeafSearchScript(LeafReaderContext context) throws IOException {
                        PostingsEnum postings = context.reader().postings(new Term(field, term));
                        if (postings == null) {
                            // the field and/or term don't exist in this segment, so always return 0
                            return () -> 0.0d;
                        }
                        return new LeafSearchScript() {
                            int currentDocid = -1;
                            @Override
                            public void setDocument(int docid) {
                                // advance has undefined behavior calling with a docid <= its current docid
                                if (postings.docID() < docid) {
                                    try {
                                        postings.advance(docid);
                                    } catch (IOException e) {
                                        throw new UncheckedIOException(e);
                                    }
                                }
                                currentDocid = docid;
                            }
                            @Override
                            public double runAsDouble() {
                                if (postings.docID() != currentDocid) {
                                    // advance moved past the current doc, so this doc has no occurrences of the term
                                    return 0.0d;
                                }
                                try {
                                    return postings.freq();
                                } catch (IOException e) {
                                    throw new UncheckedIOException(e);
                                }
                            }
                        };
                    }
                    @Override
                    public boolean needsScores() {
                        return false;
                    }
                };
            }
            throw new IllegalArgumentException("Unknown script name " + scriptSource);
        }

        @Override
        @SuppressWarnings("unchecked")
        public SearchScript search(CompiledScript compiledScript, SearchLookup lookup, @Nullable Map<String, Object> params) {
          Function<Map<String,Object>,SearchScript> scriptFactory = (Function<Map<String,Object>,SearchScript>) compiledScript.compiled();
          return scriptFactory.apply(params);
        }

        @Override
        public ExecutableScript executable(CompiledScript compiledScript, @Nullable Map<String, Object> params) {
            throw new UnsupportedOperationException();
        }

        @Override
        public boolean isInlineScriptEnabled() {
            return true;
        }

        @Override
        public void close() {}
    }
}

代码解读： 本例在elasticsearch源码中，https://github.com/elastic/elasticsearch/tree/master/plugins/examples/script-expert-scoring

MyExpertScriptEngine类是其中最重要的类，用于实现脚本参数定义，编译，以及打分机制的实现。其中compile方法返回我们定义好打分逻辑的java function。search方法用于我们在搜索过程中实施定义好的打分逻辑。 怎奈笔者对于函数式编程知道的不多（后续需要补课），其实评分逻辑也可以在search方法中实现，于是有了下面的一段代码。

public class fieldaddScriptPlugin extends Plugin implements ScriptPlugin {
    @Override
    public ScriptEngineService getScriptEngineService(Settings settings) {
        return new MyExpertScriptEngine();
    }
    private static class MyExpertScriptEngine implements ScriptEngineService {
        @Override
        public String getType() {
            return "expert_scripts";
        }

        @Override
        public Object compile(String scriptName, String scriptSource, Map<String, String> params) {
            if ("example_add".equals(scriptSource)) {
                return scriptSource;
            }
            throw new IllegalArgumentException("Unknown script name " + scriptSource);
        }

        @Override
        @SuppressWarnings("unchecked")
        public SearchScript search(CompiledScript compiledScript, SearchLookup lookup, @Nullable Map<String, Object> vars) {

            /**
             * 校验输入参数，DSL中params 参数列表
             */
            final long inc;
            final String fieldname;
            if (vars == null || vars.containsKey("inc") == false) {
                inc = 0;
            } else {
                inc = ((Number) vars.get("inc")).longValue();
            }

            if (vars == null || vars.containsKey("fieldname") == false) {
                throw new IllegalArgumentException("Missing parameter [fieldname]");
            } else {
                fieldname = (String) vars.get("fieldname");
            }

            return new SearchScript() {
                @Override
                public LeafSearchScript getLeafSearchScript(LeafReaderContext context) throws IOException {
                    final LeafSearchLookup leafLookup = lookup.getLeafSearchLookup(context);

                    return new LeafSearchScript() {
                        @Override
                        public void setDocument(int doc) {
                            if (leafLookup != null) {
                                leafLookup.setDocument(doc);
                            }
                        }

                        @Override
                        public double runAsDouble() {
                            long values = 0;
                            /**
                             * 获取document中字段内容
                             */
                            for (Object v : (List<?>) leafLookup.doc().get(fieldname)) {
                                values = ((Number) v).longValue() + values;
                            }
                            return values + inc;
                        }
                    };
                }

                @Override
                public boolean needsScores() {
                    return false;
                }
            };
        }

     这段代码的逻辑是把给定的字段(字段类型long)的每个元素相加后再加上给定的增量参数最后形成score分值。为了实现上述逻辑需要实现参数获取、根据给定的字段名获取内容列表量的关键件。下面结合代码说说这两个步骤如何实现的。

search方法中Map<String, Object> vars参数对应DSL中"params"参数，用于接受实际给定的运行时参数。SearchLookup lookup参数由系统传入，通过lookup.getLeafSearchLookup(context)获取LeafSearchLookup通过该对象可以获取给定字段的值。

对于elasticsearch 2.x以前的版本可以通过NativeScriptFactory实现原生脚本。

public class MyNativeScriptPlugin extends Plugin implements ScriptPlugin {
    private final static Logger LOGGER = LogManager.getLogger(MyFirstPlugin.class);

    public MyNativeScriptPlugin() {
        super();
        LOGGER.warn("This is MyNativeScriptPlugin");
    }

    @Override
    public List<NativeScriptFactory> getNativeScripts() {
        return Collections.singletonList(new MyNativeScriptFactory());
    }

    public static class MyNativeScriptFactory implements NativeScriptFactory {
        @Override
        public ExecutableScript newScript(@Nullable Map<String, Object> params) {

//            return new MyNativeScript();
            return new AbstractDoubleSearchScript(){

                @Override
                public double runAsDouble() {
                    int b=0;
                    if(params.get("add")!=null){
                        b= (int) params.get("add");
                    }

                    String s =  source().get("last").toString();
                    double a = s.length()+b;
                    return a;                }
            };
        }

        @Override
        public boolean needsScores() {
            return false;
        }

        @Override
        public String getName() {
            return "my_script";
        }
    }
}

工程组织 elasticsearch工程使用gradle进行依赖管理和生命周期管理，为此es项目自己也开发了esplugin的gradle插件，但不兼容gradle4.2以上的版本。参考github中的成熟插件，使用maven组织工程。

主要涉及两个文件 pom.xml plugin.xml 工程利用maven-assembly-plugin打包jar。

本例github地址：https://github.com/jiashiwen/elasticsearchpluginsample 欢迎点赞或拍砖

活动介绍

本期邀请了几位ES大咖做主题分享，并以Demo show和Workshop的形式介绍Elastisearch及其相关组件在搜索、日志分析和监控领域的应用，帮助用户更好的理解Elastisearch及其相关组件，在更多的搜索和分析场景中应用。Workshop环节请务必携带个人电脑参加。

活动安排

时间：2018年1月20日周六 13：30-17：00

地点：北京市海淀区中关村大街46号院-众海加速器（阿里巴巴创新中心）

活动主题

• 13:30—14:00 签到
• 14:00—14:30 主题分享《Elasticsearch在智能运维领域的应用》 Elastic布道师 曾勇
• 14:30—14:40 Q&A
• 14:40—15:10 Demo show《使用X-Pack和Kibana实现Elasticsearch 的监控与报警》 阿里云技术专家 李靖威
• 15:10—15:20 Q&A
• 15:20—15:50 Workshop《基于阿里云Elasticsearch构建网站日志处理系统》 阿里云产品专家 洪阳
• 15:50—16:00 Q&A
• 16:00—16:30 主题分享《ELK在运维工作中应用两三事》 上海安畅运维专家 韩军辉
• 16:30—17:00 现场快闪分享
• 17:00—17:30 现场专家一对一交流

报名通道

活动报名通道：

https://yq.aliyun.com/event/193/join

可提前报名现场快闪分享(5分钟/位），讲讲自己的ELK实践心得，报名链接：

https://survey.aliyun.com/survey/kMXx0zCfB

也可使用钉钉扫描，加入Elasticsearch技术交流群：

嘉宾介绍

曾勇 Elastic布道师

Elastic开发工程师与布道师，在分布式搜索、高性能、高可用架构、自动化运维等方面积累了超过七年的经验。曾勇是Elasticsearch国内首批用户，自2010年起就开始接触Elasticsearch并投入到生产环境中使用，并编写过一系列的中文处理相关的插件。

演讲主题：《Elasticsearch在智能运维领域的应用》

分享Elasticsearch和X-Pack组件在智能运维领域的技术原理和应用实践，如非监督型机器学习在自动的异常检测、高级关联和分类、根源问题诊断、早期故障预测等方面的应用等。

李靖威 阿里云技术专家

全栈程序员，精通前后端，在Web微服务系统架构上有深入研究。3年搜索产品相关经验，现负责阿里云Elasticsearch的产品业务部分的开发。

演讲主题：《使用X-Pack和Kibana实现Elasticsearch 的监控与报警》

以开源 Elasticsearch、阿里云 Elasticsearch和X-Pack的Demo show的形式， 对 Elasticsearch 集群监控和报警的内部原理进行讲解和使用方法演示。

洪阳 阿里云产品专家

阿里云搜索产品经理，从事多年大数据及搜索相关产品工作，在离线数据加工、离线调度系统、在线搜索等场景深入研究，对大数据和搜索相关产品有丰富的经验。

演讲主题：《基于阿里云Elasticsearch构建网站日志处理系统》

基于阿里云的Elasticsearch，离线数仓加工工具，数据同步工具等一些列产品来快速构建一个日志处理系统，从离线数据加工到在线数据搜索和分析展现诠释数据加工在阿里云产品上如何快速展开。

韩军辉 上海安畅运维专家

上海安畅网络运维主管，热衷于开源技术的学习和深入研究，从事多年的ELK运维相关工作，对ELK Stack有深入研究，对ELK相关运维有丰富的经验。

演讲主题：《ELK在运维工作中应用两三事》

基于ELK Stack、sflow技术、sflowtool工具、kafka消息队列等开源技术构建一套流量分析、DDOS告警系统。从流量收集、分析、存储、展现、告警一套流程来诠释ELK在流量分析中的应用。

【携程旅行网 吴晓刚】

上周，在某多多搬砖的一位朋友在微信上找我咨询，说他们公司一个ES集群从2.4升级到5.5以后，一个很简单的Query查询耗时突然从几十毫秒，变成800-1000毫秒，几十倍的性能下降！原始问题链接:# Why my search slow?

这个查询非常简单，就是3个过滤条件求交集而已:

{
      "from": 0,
      "size": 10,
      "query": {
      "bool": {
      "filter": [
        {
          "terms": {
            "goods_id": [
              "262628158"
            ],
            "boost": 1.0
          }
        },
        {
          "terms": {
            "status": [
              "2",
              "4"
            ],
            "boost": 1.0
          }
        },
        {
          "range": {
            "create_time": {
              "from": "1514027649",
              "to": "1514632449",
              "include_lower": true,
              "include_upper": true,
              "boost": 1.0
            }
          }
        }
      ],
      "disable_coord": false,
      "adjust_pure_negative": true,
      "boost": 1.0
    }
  },
  "sort": [
    {
      "create_time": {
        "order": "desc"
      }
    }
  ]
}

通过profile查看，发现耗时主要在status字段的build_scorer这个阶段。

对方同时提到，只要去掉"status":["2", "4"]这个查询条件，速度就会恢复正常。进一步询问后得知，查询的索引文档总量相当巨大，达到16亿条，而status字段只有几个不同的数字，在mapping里被定义为数值型short。

我的第一反应，status只有几个值，意味着该字段的filter得到的结果集是海量的。可能是处理这个大结果集的代价很高造成的缓慢，但是具体什么原因我一时也说不上来。

脑子里开始翻查ES 2.x -> 5.x升级对于数值类型和Term Query有何重大变化？想起来两点:

1. Lucene6.0引入了重新设计的数值类型的索引结构，不再采用倒排索，而是使用了更适合范围查找的Block K-d Tree。 ES从5.0开始引入这种新结构。(参考: searching-numb3rs-in-5.0）
2. Term Query由于通常非常快，从5.1.1开始不再被缓存到Query Cache

显然这个status字段不用于范围查找，字段类型设置上keyword比number更合理。 但我也没想明白为何number在这场景下查询会慢这么多，所以我也稍稍有些怀疑2.x缓存了Term Query是造成性能差异的原因。 当时让朋友做了个测试，将TermQuery换成RangeQuery，被告知速度飞快，只要几十个毫秒，并且多执行几次后更是快到只有几个毫秒了。(因为RangeQuery反复执行会被Cache起来)。

隔天，朋友根据建议将status先改为keyword，重新索引数据后，查询性能奇迹般的恢复到正常，所以基本可以确定和缓存无关了。

恰巧社区也有人在经历同样的问题: Elastic对类似枚举数据的搜索性能优化 ，看起来是个普遍现象，值得研究找出问题根源。

花了几天的时间参阅技术文档，也粗略读了一下ES/Lucene相关代码后，总算搞清楚了问题的来龙去脉。 本文将对相关技术细节做分析，然后回答下面3个问题:

1. 为什么ES5.x里对数值型字段做TermQuery可能会很慢?
2. 为何Profile里显示的耗时几乎全部在build_scorer?
3. 为什么对同样的数值型字段做RangeQuery却又很快了？

为更好的理解这个问题，先谈一下几点预备知识:

• ES2.x和5.x的数值类型分别是如何索引的
• Block k-d tree的基本概念和Lucene实现
• Queries/filters执行的先后顺序及结果合并是怎样做的

ES2.x和5.x的数值类型分别是如何索引的

ES5.x之前用到的Lucene版本，实际上只能够索引文本类型的数据，表面上被定义为数值类型的字段，在暗地里都被转换成了字符串，编排成了倒排索引。例如:

这种结构对于精确的数值查询速度还是比较快的，直接从倒排索引根据查找的term拿到postings list就好了。 但类似range: [50, 100]这样的范围查找就比较麻烦了，Lucene在找到对应的term后，只能将其转换成类似50 OR 51 OR 52 ... OR 100这样的Bool查询。可想而知，这个多条件OR查询开销很高，执行很慢。所以Lucene在创建索引的时候，会自动产生一些类似50x75 这样的特殊Term，指向包含在该范围的文档列表，从而可以将查询优化成类似50x75 OR 76x99 OR 100 这种形式。但是这种优化在字段的不同值很多，查询范围很大的时候，依然很无力。 因此早期版本的Lucene和ES的范围查询性能一直被诟病。

Lucene从6.0开始引入了Block k-d tree来重新设计数值类型的索引结构，其目标是让数值型数据索引的结构更紧凑，搜索速度更快。这种数据结构是为多维数值字段设计的，可以高效的用于诸如地理位置这类数据的快速过滤，但同样适用于单维度的数值型。

Block k-d tree的基本概念和Lucene实现

基本思想就是将一个N维的数值空间，不断选定包含值最多的维度做2分切割，反复迭代，直到切分出来的空间单元(cell)包含的值数量小于某个数值。 对于单维度的数据，实际上就是简单的对所有值做一个排序，然后反复从中间做切分，生成一个类似于B-tree这样的结构。和传统的B-tree不同的是，他的叶子结点存储的不是单值，而是一组值的集合，也就是是所谓的一个Block。每个Block内部包含的值数量控制在512- 1024个，保证值的数量在block之间尽量均匀分布。 其数据结构大致看起来是这样的:

Lucene将这颗B-tree的非叶子结点部分放在内存里，而叶子结点紧紧相邻存放在磁盘上。当作range查询的时候，内存里的B-tree可以帮助快速定位到满足查询条件的叶子结点块在磁盘上的位置，之后对叶子结点块的读取几乎都是顺序的。

要注意一点，不是简单的将拿到的所有块合并就可以得到想要的docID结果集，因为查询的上下边界不一定刚好落在两端block的上下边界上。 所以如果需要拿到range filter的结果集，就要对于两端的block内的docid做扫描，将他们的值和range的上下边界做比较，挑选出match的docid集合。

Queries/filters执行的先后顺序及结果合并是怎样做的

ES的Queries/filters执行顺序比较复杂，并非按照Query里条件的排列顺序来挨个执行；也不是某些人想象的那样，每个filter/Query都独立执行，拿到各自的结果集以后，再做结果集的合并。 在elasticsearch-query-execution-order 这篇博客里对这个主题做了比较详细的介绍。

简单来说，ES会先通过调用每个查询的cost()函数估算一下该查询的代价，然后选择代价最小的查询作为起点，在其圈定的docid集合上生成一个迭代器。然后反复迭代，根据和其他条件之间是AND还是OR的关系，再去决定结果集合并的方式。

这个结果集的迭代，以及合并，就是上面链接里提到的nextdoc()和advance()等操作。 比较复杂的地方是这些操作根据数据类型的不同和查询类型的不同，ES都有针对性的进行操作优化，同样的操作有些可能是在内存中进行，有些则可能直接在磁盘上进行。

以最常见的keyword字段做TermQuery为例，其cost就是Term Frequency，这个值可以直接从倒排索引读取。 Frequency越高的Term，其postings list就越长，迭代起来的代价就越高。 所以如果对多个TermQuery做AND合并，就会选择Frequency最低的Term，以其postings list为起点做迭代(nextdoc)。 Postings list是按照docid顺序存放的，并且在数据结构上还增加了跳表来加快advance()操作。因此多个postings list的合并可以直接操作磁盘上的数据而不会引起过多的随机IO，加上ES5.0以后对于索引数据采取了mmap file的方式访问，热数据读取引发的磁盘IO愈发的少。 这也是为什么5.1.1之后取消了TermQuery的cache，因为在跳表和OS page cache的加持下，直接合并磁盘上的postings list已经非常快了。 取消对其cache后，可以减少构造cache的开销，并且将宝贵的cache空间留给代价更高的filter，一定程度上可以提升ES整体性能。

有了这些预备知识，再来解答文首抛出的3个问题。

1. 为什么ES5.x里对数值型字段做TermQuery可能会很慢?

首先，用户范例查询里还有其他更加结果集更小的TermQuery，cost更低，因此迭代器从选择从这个低代价的Query作为起点开始执行; 其次，因为数值型字段在5.x里没有采用倒排表索引， 而是以value为序，将docid切分到不同的block里面。对应的，数值型字段的TermQuery被转换为了PointRangeQuery。这个Query利用Block k-d tree进行范围查找速度非常快，但是满足查询条件的docid集合在磁盘上并非向Postlings list那样按照docid顺序存放，也就无法实现postings list上借助跳表做蛙跳的操作。 要实现对docid集合的快速advance操作，只能将docid集合拿出来，做一些再处理。 这个处理过程在org.apache.lucene.search.PointRangeQuery#createWeight这个方法里可以读取到。 这里就不贴冗长的代码了，主要逻辑就是在创建scorer对象的时候，顺带先将满足查询条件的docid都选出来，然后构造成一个代表docid集合的bitset，这个过程和构造Query cache的过程非常类似。 之后advance操作，就是在这个bitset上完成的。

2. 为何Profile里显示的耗时几乎全部在build_scorer?

回答第一个问题的时候提到了，如果查看PointRangeQuery的源码，构造scorer对象的构造过程包含了bitset的生成过程，所以耗时的实际上是构造一个巨大的bitset并在上面生成一个迭代器。

3. 为什么对同样的数值型字段做RangeQuery却又很快了?

从上面数值型字段的Block k-d tree的特性可以看出，rangeQuery的结果集比较小的时候，其构造bitset的代价很低，不管是从他开始迭代做nextdoc()，或者从其他结果集开始迭代，对其做advance，都会比较快。 但是如果rangeQuery的结果集非常巨大，则构造bitset的过程会大大延缓scorer对象的构造过程，造成结果合并过程缓慢。
这个问题官方其实早已经意识到了，所以从ES5.4开始，引入了indexOrDocValuesQuery作为对RangeQuery的优化。（参考: better-query-planning-for-range-queries-in-elasticsearch）。 这个Query包装了上面的PointRangeQuery和SortedSetDocValuesRangeQuery，并且会根据Rang查询的数据集大小，以及要做的合并操作类型，决定用哪种Query。 如果Range的代价小，可以用来引领合并过程，就走PointRangeQuery，直接构造bitset来进行迭代。 而如果range的代价高，构造bitset太慢，就使用SortedSetDocValuesRangeQuery。 这个Query利用了DocValues这种全局docID序，并包含每个docid对应value的数据结构来做文档的匹配。 当给定一个docid的时候，一次随机磁盘访问就可以定位到该id对应的value，从而可以判断该doc是否match。 因此它非常适合从其他查询条件得到的一个小结果集作为迭代起点，对于每个docid依次调用其内部的matches()函数判断匹配与否。也就是说， 5.4新增的indexOrDocValuesQuery将Range查询过程中的顺序访问任务扔给Block k-d Tree索引，将随机访任务交给doc values。 值得注意的是目前这个优化只针对RangeQuery！对于TermQuery，因为实际的复杂性，还未做类似的优化，也就导致对于数值型字段，Term和Range Query的性能差异极大。

小结:

1. 在ES5.x里，一定要注意数值类型是否需要做范围查询，看似数值，但其实只用于Term或者Terms这类精确匹配的，应该定义为keyword类型。典型的例子就是索引web日志时常见的HTTP Status code。
2. 如果RangeQuery的结果集很大，并且还需要和其他结果集更小的查询条件做AND的，应该升级到ES5.4+，该版本在底层引入的indexOrDocValuesQuery，可以极大提升该场景下RangeQuery的查询速度。

1. 如何使用Elasticsearch构建“Did You Mean”。 http://t.cn/RHBw74U

2. 使用基于上下文的自动完成功能让Elasticsearch自动完成更强大。 http://t.cn/RHB2SEi

3. (自备梯子)Elasticsearch:构建自动完成功能。 http://t.cn/RHBytRS

• 编辑：至尊宝

• 归档：https://elasticsearch.cn/article/444

• 订阅：https://tinyletter.com/elastic-daily