1.下面简述下如何根据explain解释TFIDF和BM25的评分计算
2.首先是TFIDF
使用ik_smart分词器，ES为2.3.3
文档是：分词结果是
"伟业我爱我家"     分词结果：【伟业，我，爱我，家】
"我爱我家"     【我，爱我，家】
这两个。
multi_match  匹配，query=我爱我家
排名如下
-----------------------------------------------------------
"伟业我爱我家"    "_score": 6.8563557,
详细参数 
"我"：tf=1,idf=6.7638364,fieldNorm=0.5，queryNorm=0.07292504,
“爱我”： tf=1,idf=6.7638364,fieldNorm=0.5，queryNorm=0.07292504
“家”： tf=1,idf=6.278329,fieldNorm=0.5，queryNorm=0.07292504
----------------------------------------------------------
"我爱我家"          "_score": 6.7839246,
"我"：tf=1,idf=6.9336233,fieldNorm=0.5，queryNorm=0.07370365,
“爱我”： tf=1,idf=6.9336233,fieldNorm=0.5，queryNorm=0.07370365
“家”： tf=1,idf=6.9336233,fieldNorm=0.5，queryNorm=0.07370365
---------------------------------------------------------
其中queryNorm是由每个term词项的idf综合计算而来，所以在每个文档中，他都是一样的。
然后仔细比较得分，觉得每个得分都可以被推算出来
但是排序结果不符合期望：
queryNorm 官方文档也说了基本没有什么用
tf=1没什么可说
idf有些问题，比如"爱我"在这两个文档中是不同的(这是因为这两个文档在不同的分片中引起的)
那这么说来，TFIDF的得分就仅仅受tf,idf，fieldNorm控制，
而idf因为分片不均匀可能会出现一点差异，fieldNorm又犹由于精度让长度为3或者4 的文档值都为0.5
。综上：tfidf在这种量不多(200万)的短文本检索下，效果很差。
这种情况下，我该怎么优化这个排序呢（让“我爱我家”，排在"伟业我爱我家"前面呢？）
 
 
 
------------------BM25的详情稍后补上-------------------------
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  收起阅读 »

一直想找一个数据库用于存储各种的代码片段

mysql会一点 mongodb也看过

但是最终都没有弄成（或许是我性格的原因，想的太多，做的太少（算是过度设计的一种吧））

后来发现了ElasticSearch

觉得他能够实现我的想法（或许只是他简介里的一句话，大致的意思是：多看看数据，而非让他们躺在仓库里）

我会将过程记录下来，希望对后来人有帮助

（不过一切都是在Emacs环境下的，知道的人应该不多，所以能帮到的人也就更少了（其实他们也不用我帮）） 收起阅读 »

      大家好，我是重构人生，很开心能在这里和大家分享我的免费Elasticsearch 视频教程。 我是一个Elasticsearch 的DevOps ，使用了很久的开源软件，在开源社区也获得过很多小伙伴的帮助。我希望自己能为社区贡献自己的一份力。
 
      我应该算是个热心肠的人吧，喜欢乐于助人，不过有些人的提问方式让我非常反感，甚至是厌恶，什么样的人呢，第一种，官方文档，或者百度，或者GOOGLE，等方式轻易的就可以找到解决方案却仍然拿出来提问的人。 第二种就是什么条件、环境都不描述，背景也不说上来就问，怎么样最好，如何性能最快，怎么做才能最稳定的人，我说话比较直，勿怪，对于这类人，你至少要让他知道一些概念，不然根本没法交流。  
 
       为了解决这些问题，我想提供一种快速让一些没有经验或者经验不足的朋友去快速了解Elasticsearch，了解ES能做什么，了解ES怎么做才能达到你的要求，带着这些问题，我在头脑里构思了 两个系列的视频，第一个是ES-教程篇， 第二个是ES-实战篇,把实际的生产环境中的一些场景，剥离业务相关的，保密性的东西，以纯技术的方式与大家分享下，看我们是如何踩坑，填坑的。

由于视频是个人行为，非商业性质，所以不可能做到定时更新，这点还请大家见谅，不过我肯定会用心去做。
 
所有的视频会以两个方式去提供，一个是百度云盘里下载完整的压缩包，里面包含了视频、PPT、以及配置文件信息。另一种是通过优库视频直接看视频，PPT和配置文件到百度云上去下载。
 
 
百度云： https://pan.baidu.com/s/1i4ZsORF
优酷：http://i.youku.com/rickywag
 
 
感谢你们的支持，如果觉得不错可以打赏我哟。 收起阅读 »

看得出来是踩了不少坑总结出来的，推荐下： 基于ElasticSearch的亿级实时日志系统实践
  收起阅读 »

POST test_index/type1/?refresh=true

{

  "foo": "bar"

}

POST /test_index/_search

{

  "query": {

    "wildcard": {

      "foo": {

        "value": "*在迪士尼乐园，点亮心中奇梦。它是一个充满创造力、冒险精神与无穷精彩的快地。您可在此游览全球最大的迪士尼城堡——奇幻童话城堡，探索别具一格又令人难忘的六大主题园区——米奇大街、奇想花园、梦幻世界、探险岛、宝藏湾和明日世界，和米奇朋友在一起，感觉欢乐时光开业于2016年上海国际旅游度假区秀沿路亚朵酒店位于上海市浦东新区沪南公路（沪南公路与秀沿路交汇处），临近周浦万达广场、地铁11号线秀沿路站，距离上海南站、人民广场约20公里，距离迪线距*"

      }

    }

  }

}

{

  "took": 3445,

  "timed_out": false,

  "_shards": {

    "total": 5,

    "successful": 5,

    "failed": 0

  },

  "hits": {

    "total": 0,

    "max_score": null,

    "hits": 

  }

}

public static Automaton toAutomaton(Term wildcardquery) {

    List<Automaton> automata = new ArrayList<>();

    

    String wildcardText = wildcardquery.text();

    

    for (int i = 0; i < wildcardText.length();) {

      final int c = wildcardText.codePointAt(i);

      int length = Character.charCount(c);

      switch(c) {

        case WILDCARD_STRING: 

          automata.add(Automata.makeAnyString());

          break;

        case WILDCARD_CHAR:

          automata.add(Automata.makeAnyChar());

          break;

        case WILDCARD_ESCAPE:

          // add the next codepoint instead, if it exists

          if (i + length < wildcardText.length()) {

            final int nextChar = wildcardText.codePointAt(i + length);

            length += Character.charCount(nextChar);

            automata.add(Automata.makeChar(nextChar));

            break;

          } // else fallthru, lenient parsing with a trailing \

        default:

          automata.add(Automata.makeChar(c));

      }

      i += length;

    }

    

    return Operations.concatenate(automata);

  }

/**

   * Determinizes the given automaton.

   * <p>

   * Worst case complexity: exponential in number of states.

   * @param maxDeterminizedStates Maximum number of states created when

   *   determinizing.  Higher numbers allow this operation to consume more

   *   memory but allow more complex automatons.  Use

   *   DEFAULT_MAX_DETERMINIZED_STATES as a decent default if you don't know

   *   how many to allow.

   * @throws TooComplexToDeterminizeException if determinizing a creates an

   *   automaton with more than maxDeterminizedStates

   */

  public static Automaton determinize(Automaton a, int maxDeterminizedStates) {

  /**

   * Default maximum number of states that {@link Operations#determinize} should create.

   */

  public static final int DEFAULT_MAX_DETERMINIZED_STATES = 10000;

[携程旅行网： 吴晓刚]
 许多有RDBMS/SQL背景的开发者，在初次踏入ElasticSearch世界的时候，很容易就想到使用(Wildcard Query)来实现模糊查询（比如用户输入补全)，因为这是和SQL里like操作最相似的查询方式，用起来感觉非常舒适。然而近期我们线上一个搜索集群的故障揭示了，滥用wildcard query可能带来灾难性的后果。

故障经过
线上有一个10来台机器组成的集群，用于某个产品线的产品搜索。数据量并不大，实时更新量也不高，并发搜索量在几百次/s。通常业务高峰期cpu利用率不超过10%，系统负载看起来很低。 但最近这个集群不定期（1天或者隔几天)会出现CPU冲高到100%的问题，持续时间从1分钟到几分钟不等。最严重的一次持续了20来分钟，导致大量的用户搜索请无求响应，从而造成生产事故。

问题排查
细节太多，此处略过，直接给出CPU无故飙高的原因: 研发在搜索实现上，根据用户输入的关键词，在首尾加上通配符，使用wildcard query来实现模糊搜索，例如使用"*迪士尼*"来搜索含有“迪士尼”关键字的产品。 然而用户输入的字符串长度没有做限制，导致首尾通配符中间可能是很长的一个字符串。 后果就是对应的wildcard Query执行非常慢，非常消耗CPU。

复现方法
1. 创建一个只有一条文档的索引

POST test_index/type1/?refresh=true

{

  "foo": "bar"

}

2. 使用wildcard query执行一个首尾带有通配符*的长字符串查询

POST /test_index/_search

{

  "query": {

    "wildcard": {

      "foo": {

        "value": "*在迪士尼乐园，点亮心中奇梦。它是一个充满创造力、冒险精神与无穷精彩的快地。您可在此游览全球最大的迪士尼城堡——奇幻童话城堡，探索别具一格又令人难忘的六大主题园区——米奇大街、奇想花园、梦幻世界、探险岛、宝藏湾和明日世界，和米奇朋友在一起，感觉欢乐时光开业于2016年上海国际旅游度假区秀沿路亚朵酒店位于上海市浦东新区沪南公路（沪南公路与秀沿路交汇处），临近周浦万达广场、地铁11号线秀沿路站，距离上海南站、人民广场约20公里，距离迪线距*"

      }

    }

  }

}

3. 查看结果

{

  "took": 3445,

  "timed_out": false,

  "_shards": {

    "total": 5,

    "successful": 5,

    "failed": 0

  },

  "hits": {

    "total": 0,

    "max_score": null,

    "hits": 

  }

}

即使no hits，耗时却是惊人的3.4秒 (测试机是macbook pro, i7 CPU)，并且执行过程中，CPU有一个很高的尖峰。
 
线上的查询比我这个范例要复杂得多，会同时查几个字段，实际测试下来，一个查询可能会执行十几秒钟。 在有比较多长字符串查询的时候，集群可能就DOS了。

探查深层次根源
为什么对只有一条数据的索引做这个查询开销这么高？ 直觉上应该是瞬间返回结果才对!

回答这个问题前，可以再做个测试，如果继续加大查询字符串的长度，到了一定长度后，ES直接抛异常了，服务器ES里异常给出的cause如下:

 
Caused by: org.apache.lucene.util.automaton.TooComplexToDeterminizeException: Determinizing automaton with 22082 states and 34182 transitions would result in more than 10000 states. at org.apache.lucene.util.automaton.Operations.determinize(Operations.java:741) ~[lucene-core-6.4.1.jar:6.4.1
 

该异常来自org.apache.lucene.util.automaton这个包，异常原因的字面含义是说“自动机过于复杂而无法确定状态： 由于状态和转换太多，确定一个自动机需要生成的状态超过10000个上限"

网上查找了大量资料后，终于搞清楚了问题的来龙去脉。为了加速通配符和正则表达式的匹配速度，Lucene4.0开始会将输入的字符串模式构建成一个DFA (Deterministic Finite Automaton)，带有通配符的pattern构造出来的DFA可能会很复杂，开销很大。这个链接的博客using-dfa-for-wildcard-matching-problem比较形象的介绍了如何为一个带有通配符的pattern构建DFA。借用博客里的范例，a*bc构造出来的DFA如下图:



Lucene构造DFA的实现
看了一下Lucene的里相关的代码，构建过程大致如下:
1. org.apache.lucene.search.WildcardQuery里的toAutomaton方法，遍历输入的通配符pattern，将每个字符变成一个自动机(automaton)，然后将每个字符的自动机链接起来生成一个新的自动机

public static Automaton toAutomaton(Term wildcardquery) {

    List<Automaton> automata = new ArrayList<>();

    

    String wildcardText = wildcardquery.text();

    

    for (int i = 0; i < wildcardText.length();) {

      final int c = wildcardText.codePointAt(i);

      int length = Character.charCount(c);

      switch(c) {

        case WILDCARD_STRING: 

          automata.add(Automata.makeAnyString());

          break;

        case WILDCARD_CHAR:

          automata.add(Automata.makeAnyChar());

          break;

        case WILDCARD_ESCAPE:

          // add the next codepoint instead, if it exists

          if (i + length < wildcardText.length()) {

            final int nextChar = wildcardText.codePointAt(i + length);

            length += Character.charCount(nextChar);

            automata.add(Automata.makeChar(nextChar));

            break;

          } // else fallthru, lenient parsing with a trailing \

        default:

          automata.add(Automata.makeChar(c));

      }

      i += length;

    }

    

    return Operations.concatenate(automata);

  }

2. 此时生成的状态机是不确定状态机，也就是Non-deterministic Finite Automaton（NFA)。
3. org.apache.lucene.util.automaton.Operations类里的determinize方法则会将NFA转换为DFA  

/**

   * Determinizes the given automaton.

   * <p>

   * Worst case complexity: exponential in number of states.

   * @param maxDeterminizedStates Maximum number of states created when

   *   determinizing.  Higher numbers allow this operation to consume more

   *   memory but allow more complex automatons.  Use

   *   DEFAULT_MAX_DETERMINIZED_STATES as a decent default if you don't know

   *   how many to allow.

   * @throws TooComplexToDeterminizeException if determinizing a creates an

   *   automaton with more than maxDeterminizedStates

   */

  public static Automaton determinize(Automaton a, int maxDeterminizedStates) {

 代码注释里说这个过程的时间复杂度最差情况下是状态数量的指数级别！为防止产生的状态过多，消耗过多的内存和CPU，类里面对最大状态数量做了限制

  /**

   * Default maximum number of states that {@link Operations#determinize} should create.

   */

  public static final int DEFAULT_MAX_DETERMINIZED_STATES = 10000;

在有首尾通配符，并且字符串很长的情况下，这个determinize过程会产生大量的state，甚至会超过上限。
 
至于NFA和DFA的区别是什么？ 如何相互转换？ 网上有很多数学层面的资料和论文，限于鄙人算法方面有限的知识，无精力去深入探究。 但是一个粗浅的理解是: NFA在输入一个条件的情况下，可以从一个状态转移到多种状态，而DFA只会有一个确定的状态可以转移，因此DFA在字符串匹配时速度更快。 DFA虽然搜索的时候快，但是构造方面的时间复杂度可能比较高，特别是带有首部通配符+长字符串的时候。

回想Elasticsearch官方文档里对于wildcard query有特别说明，要避免使用通配符开头的term。

" Note that this query can be slow, as it needs to iterate over many terms. In order to prevent extremely slow wildcard queries, a wildcard term should not start with one of the wildcards * or ?."

结合对上面wildcard query底层实现的探究，也就不难理解这句话的含义了！

总结： wildcard query应杜绝使用通配符打头，实在不得已要这么做，就一定需要限制用户输入的字符串长度。 最好换一种实现方式，通过在index time做文章，选用合适的分词器，比如nGram tokenizer预处理数据，然后使用更廉价的term query来实现同等的模糊搜索功能。 对于部分输入即提示的应用场景，可以考虑优先使用completion suggester, phrase/term suggeter一类性能更好,模糊程度略差的方式查询，待suggester没有匹配结果的时候，再fall back到更模糊但性能较差的wildcard, regex, fuzzy一类的查询。
 
-----------
补记： 有同学问regex, fuzzy query是否有同样的问题，答案是有，原因在于他们底层和wildcard一样，都是通过将pattern构造成DFA来加速字符串匹配速度的。  收起阅读 »

活动时间
2017年5月13日14：00-17：00

活动场地
杭州市拱墅区丰潭路430号丰元国际大厦A座B1楼硬趣空间（城西银泰对面）
 
报名链接
http://t.cn/RX8xsh6
 
活动流程
13:30-14:00 签 到

14:00-14:10 开 场

14:10-15:00 无 相 蘑菇街稳定性 & 性能工作负责人  《蘑菇街稳定性实践》

15:00-15:50 民 达 美丽联合集团图像算法技术专家 《电商中的图像算法与应用》

15:50-16:00 茶 歇

16:00-16:50 吴 邪 美丽联合集团无线应用团队工程师 《无线端面向数据设计实践与可视化编程语言Dson》

16:50-17:30 自由交流
 
讲师介绍
无相 蘑菇街稳定性&性能工作负责人
2014年底加入蘑菇街，一直参与稳定性工具和平台的开发与建设，包括全链路监控和压测系统的设计和开发。
《蘑菇街稳定性实践》
本次分享主要介绍：蘑菇街大促保障流程，稳定性平台和工具支持：开关预案系统、限流降级系统、全链路监控系统、强弱依赖系统、全链路压测系统、单机压测系统、容量规划系统、业务全息监控系统、java性能在线分析系统等内容。
 
民达 美丽联合集团图像算法技术专家
2015年加入蘑菇街，现任美丽联合集团（美丽说X蘑菇街）图像算法技术专家，负责图像技术研发工作，带领算法团队与工程和业务团队合作，为集团提供图像技术支持。主要工作包括：图像搜索、图像识别、商品图像内容分析等；业务涉及电商导购、直播等场景。在加入蘑菇街之前，分别在NEC中国研究院、阿里巴巴集团，从事图像技术和机器学习的研究和应用。
《电商中的图像算法与应用》
本次分享主要介绍从电商业务中发现图像算法的价值和利用图像算法，提升电商业务中的用户体验。
 
吴邪，美丽联合集团无线应用团队工程师
2013年毕业于浙江大学，并加入淘宝从事服务端相关开发工作，后加入阿里云rds团队从事数据库云平台建设。2016年加入美丽联合集团，目前主要负责无线网关数据聚合层。对服务端高性能、高可用设计与编码比较感兴趣。
《无线端面向数据设计实践与可视化编程语言Dson》
本次分享主要介绍mwp-dsl、无线领域前后端开发现状、业界相关内容、mwp-dsl目标、dsl的挑战与核心设计（业务建模，性能与稳定性、安全、易用性）、数据可视化语言Dson、周边配套（开发、测试、管理、运维后台，相关运维体系）、适合的业务场景、后续工作等内容。
 
往期讲稿/视频回顾
https://opentalk.upyun.com 收起阅读 »

oracle由于是商用软件，协议并不公开，而且相比mysql等开源数据库软件，协议复杂度加了不止一个量级。
出于版权考虑，packetbeat并没有加入oracle协议的支持，只能自己动手。
好在beats充分考虑了扩展性，把公共的基础工作抽象成框架，新协议的扩展只需要专注于协议的分析和解码。
tns协议是oracle客户端和服务端通信协议，应用可以通过OCI、JDBC等接口去访问数据库。
tns协议有多个版本，不同版本之间差异也比较大，11g是主流tns版本为314。
目前完成308、310、313、314、315版本的解析
 
packetbeat支持pcap、pf_ring等抓包方式，通过kafka+es+kibana展示，效果如图
  收起阅读 »

主办：Elastic 中文社区



协办：HULU 北京研发中心




时间：2017-05-21 13:30PM-18:00PM
地点：北京市朝阳区望京大科技园浦项中心b座21楼  hulu
 
分享主题：


个人介绍：倪顺，Hulu软件工程师，ELK粉。主要负责用户播放日志数据的收集，处理和可视化，以及服务监控。
主题：Elasticsearch 和 Kibana 在 Hulu视频的应用实践
内容介绍：Elasticsearch作为优秀的开源工具，很早就在Hulu内部使用。Hulu是一家视频公司，我们在用Elastic stack优化视频播放体验。本次分享中，主要包括：1）Kibana可视化视频播放日志数据；2）Elastic Stack使用的经验tips。
 


 
个人介绍：黄鑫，运维开发工程师，Pythonista，在监控和部署领域耕耘多年，一年前接触了 ELK。
主题：ELK CI/CD 部署实践
内容介绍：
使用 SaltStack 对 ELK 维护。配置管理，持续集成和持续部署的设计和实施。日常运维管理。
- 背景介绍
- 可用性设计
- 配置管理和持续集成
- 持续部署
- 发现的问题和未来展望
 


 
个人介绍：罗喆，最早加入快手的视频技术工程师，负责移动直播系统的构建和调优，并且搭建了基于大数据的质量监测系统，之前曾在腾讯从事实时视音频传输优化工作。
主题：Elastic Stack驱动的直播体验优化
内容介绍：
移动端视频直播业务经过2016年的井喷期，已经进入下半场，大家的关注点已经从如何构建完善的直播平台的粗放增长阶段，转入精细化运营阶段。如何在巨大的流量、复杂的应用场景、复杂的网络条件下，持续优化用户体验，是我们亟待回答的问题。构建大数据驱动的直播优化体系是快手为应对这一难题所提出的解决方案。
为此，我们基于完善的Elastic Stack建立了流媒体大数据分析和可视化平台。一切优化均围绕着数据进行：找到用户痛点，指导优化方向，评估优化效果，走出了一条行之有效的数据驱动之路。
演讲提纲：
1.     快手直播的业务背景，移动直播体验优化的方法论
2.     Elastic Stack系统构建历程和真实优化案例 收起阅读 »

1. 主办方
Elastic中文社区  趋势科技



2. 时间地点
 活动时间：2017年6月10日 13:30 - 18:00 
 活动地点：雨花区软件大道48号苏豪国际广场B座 趋势科技中国研发中心（靠花神庙地铁站）

3. 主题

分享一：The State of Elastic Stack
演讲者简介：



曾勇（Medcl） Elastic工程师与布道师
Elasticsearch爱好者，2015年加入Elastic，Elastic 中文社区的发起人，Elastic在中国的首位员工。

主题简介：
Elastic Stack是Elastic公司的开源产品：Elasticsearch、Logstash、Kibana和Beats的统称，这些产品发布速度貌似有点快，在最近已经发布了的版本中有哪些值得关注的特性，然后Elastic的工程师手头上又在忙着码哪些新的特性呢?
机器学习、AI目前非常火，Elastic在最近的5.0也发布了一个机器学习的模块，这次也会带来demo演示。

分享二： Elastic Stack的容器化使用与Alert

演讲者简介：



瞿盛熙 嘀哒物流科技有限公司运维组组长

主题简介：
介绍嘀哒物流在公有云上的Elastic Stack部署以及日志分析与监控
1.目的和环境 
2.部署：自动化，容器化下kubernetes与single mode的考量
3.日志分析与alert
4.监控：prometheus与docker

分享三：Elasticsearch辅助的智能客服机器人 

演讲者简介：



杨文俊 趋势科技个人消费者部机器学习工程师
从2013年开始投入大数据处理与机器学习，目前依托Elasticsearch的搜索能力构建了一系列的智能服务。

主题简介：
1. 将原始的日文记录导入Elasticsearch之中
2. 使用Elasticsearch对原始内容进行初次过滤
3. 在过滤的基础之上，调用wmd + word2vec进行rerank，并综合进行判定

分享四： Elastic在华为电信软件运维中的应用简介

演讲者简介：



肖曙旭 华为电信软件业务云运维开发部软件工程师
华为日志服务特性负责人。从2015年起开始接触Elasticsearch并使用至今。先后负责服务调用链和日志服务特性的设计和开发，依托Elasticsearch实现搜索相关能力。

主题简介：
1. 日志采集代理。提供按正则表达式匹配或者分隔符的逻辑行分割方式；支持逻辑行内按分隔符提取字段，或者按正则表达式提取字段；支持一些简易算子对字段进行处理。
2. 日志汇聚。不同的日志类型通过不同的Topic区分
3. 流式处理。日志数据二次处理，或者一些实时分析的逻辑处理。
4. 参考kibana开发搜索和可视化能力，同时支持关键词告警，环比告警等告警能力，以及整个日志服务通道的自身监控能力。

分享五：基于ES的SQL报警引擎

演讲者简介：



张立丹 南京云利来软件科技有限公司
2010年参加工作，工作内容包括：Windows音频驱动及声卡固件；Linux高并发服务器；数据采集及分析。自2015年开始接触Elasticsearch，在工作中使用ES进行网络数据（TCP/HTTP/DNS等）的安全分析。

主题简介：
1. SQL：将ES的DSL抽象成 SQL
2. RDL：规则描述语言
3. 报警规则 收起阅读 »

主办：Elastic 中文社区



协办：众安保险



时间：2017-05-14 13:30PM-18:00PM
地点：上海市虹口区四川北路859号中信广场42楼
 
PPT 下载：https://pan.baidu.com/s/1eS157 ... %252F
 
分享主题：




个人介绍：杨智健, 众安保险搜索组负责人。
主题：es在众安保险的实践
内容介绍： es在众安保险业务线和日志类的实践，和相关平台化建设。
录像：https://v.qq.com/x/page/x0509wkr513.html 
 



个人介绍：Medcl, Elastic工程师与布道师，2015年加入Elastic公司, Elastic中文社区的发起人。
主题：ElasticStack 5.x 最新进展
内容介绍：ElasticStack 5.x 新增了很多新的激动人心的特性，本次分享将为大家一一解读。
录像：https://v.qq.com/x/page/m0509dt9f80.html





个人介绍：魏彬, rockybean，穿衣助手技术负责人，Elastic Stack 粉丝。
主题：用 Elastic Stack 来诊断下你的redis slowlog
内容介绍：
1. Elastic Stack 之 ElasticSearch Beats Kibana 简介
2. redis 和 slowlog 简介
3. 实现原理介绍
4. Kibana图形化结果展示介绍
5. 代码解析
6. 开源过程中的几点心得分享
录像：https://v.qq.com/x/page/m0509j6kyzj.html 




个人介绍: 柯诗豪，携程旅行网高级软件工程师。
主题：基于Docker的ES PaaS云平台
内容介绍：伴随着公司越来越多的团队开始使用ES，部署和管理ES集群成本增加。所以建立了基于Docker通过Mesos提供的资源管理机制的ES PaaS平台，用户可以在平台上快捷的创建、配置和管理ES集群。
录像：https://v.qq.com/x/page/n0509pzjgxq.html 
 



个人介绍: 彭科，13年从武汉理工毕业 ，16年进入斗鱼大数据基础架构组，主要负责日志监控平台和一些大数据技术的预研。目前已经从斗鱼离职，接下来会去一家云计算创业公司，从事大数据产品研发和AI方向研究。
主题：基于Elastic Stack+Kafka的日志监控平台架构演进
内容介绍：基于在斗鱼的工作经验，基于Elastic Stack和kafka做TB级日志监控平台搭建，架构演讲，踩过哪些坑，如何调优，与大数据组件技术对比，如何结合使用，如何监控基础组件与业务，分享一些自己的心得。
录像：https://v.qq.com/x/page/m05099qj8f9.html 收起阅读 »

ES5.2.2真的 支持geo排序+聚合
具体查询条件，这里不写了；
查询结果如下：

{ "took": 90, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 10, "max_score": null, "hits": [ { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000000", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000000", "equipName": "灭火剂0", "equipValue": 73, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000003", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000003", "equipName": "灭火剂3", "equipValue": 47, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000001", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000001", "equipName": "灭火剂1", "equipValue": 12, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000004", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000004", "equipName": "灭火剂4", "equipValue": 2, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "1-1000002", "_score": null, "_source": { "comId": 1, "comName": "佛山消防支队", "elemetType": 2, "equipCode": "1000002", "equipName": "灭火剂2", "equipValue": 57, "location": { "lat": 23.027237, "lon": 113.123618 }, "phone": "15986190299", "userName": "李成龙" }, "sort": [ 3740.583503580435 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000018", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000018", "equipName": "灭火剂8", "equipValue": 61, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000014", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000014", "equipName": "灭火剂4", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000016", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000016", "equipName": "灭火剂6", "equipValue": 81, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000015", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000015", "equipName": "灭火剂5", "equipValue": 87, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] }, { "_index": "testindex", "_type": "testdoc07", "_id": "2-1000017", "_score": null, "_source": { "comId": 2, "comName": "禅城大队", "elemetType": 2, "equipCode": "1000017", "equipName": "灭火剂7", "equipValue": 90, "location": { "lat": 23.057237, "lon": 113.103618 }, "phone": "13925403119", "userName": "郭武斌" }, "sort": [ 7648.2045946025555 ] } ] }, "aggregations": { "aggEquip": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "1000000", "doc_count": 1, "sumEquipValue": { "value": 73 } }, { "key": "1000001", "doc_count": 1, "sumEquipValue": { "value": 12 } }, { "key": "1000002", "doc_count": 1, "sumEquipValue": { "value": 57 } }, { "key": "1000003", "doc_count": 1, "sumEquipValue": { "value": 47 } }, { "key": "1000004", "doc_count": 1, "sumEquipValue": { "value": 2 } }, { "key": "1000014", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000015", "doc_count": 1, "sumEquipValue": { "value": 87 } }, { "key": "1000016", "doc_count": 1, "sumEquipValue": { "value": 81 } }, { "key": "1000017", "doc_count": 1, "sumEquipValue": { "value": 90 } }, { "key": "1000018", "doc_count": 1, "sumEquipValue": { "value": 61 } }, { "key": "10000210", "doc_count": 1, "sumEquipValue": { "value": 70 } }, { "key": "10000211", "doc_count": 1, "sumEquipValue": { "value": 55 } }, { "key": "1000027", "doc_count": 1, "sumEquipValue": { "value": 19 } }, { "key": "1000028", "doc_count": 1, "sumEquipValue": { "value": 25 } }, { "key": "1000029", "doc_count": 1, "sumEquipValue": { "value": 3 } }, { "key": "10000311", "doc_count": 1, "sumEquipValue": { "value": 97 } }, { "key": "10000312", "doc_count": 1, "sumEquipValue": { "value": 79 } }, { "key": "10000313", "doc_count": 1, "sumEquipValue": { "value": 95 } }, { "key": "10000314", "doc_count": 1, "sumEquipValue": { "value": 6 } }, { "key": "10000315", "doc_count": 1, "sumEquipValue": { "value": 8 } } ] } } }
  收起阅读 »

https://vastxiao.github.io/zabbixMonitorES/

我经过实际测试es5.2.2，发现_source/_all特性很好用：
1. _source可用通过配置includes、excludes获取应用需要的field
"_source": {
          "enabled": true,
          "includes": [
            "comId",
            "name",
            "userName",
            "equips.name",
            "equips.amount"
          ],
          "excludes": [
            "phone",
            "equips.code"
          ]
        },
2.设置enabled=false关闭_source功能，关闭后，查询结果只返回doc的ID，而不会返回_source
 "_source": {
          "enabled": false,
3._all、include_in_all结合使用，是用户可用通过_all分词查询多个字段，而不需要写多个查询条件
 "mappings": {
      "testdoc03": {
        "_all": {
          "enabled": true
        },
        "_source": {
          "enabled": false,
          "includes": [
            "comId",
            "name",
            "userName",
            "equips.name",
            "equips.amount"
          ],
          "excludes": [
            "phone",
            "equips.code"
          ]
        },
        "properties": {
          "comId": {
            "type": "long"
          },
          "equips": {
            "properties": {
              "amount": {
                "type": "double",
                "include_in_all": true
              },
              "code": {
                "type": "text"
              },
              "name": {
                "type": "text",
                "include_in_all": true
              }
            }
          },
          "name": {
            "type": "text",
            "include_in_all": true
          },
          "phone": {
            "type": "keyword"
          },
          "userName": {
            "type": "text",
            "include_in_all": true
          }
        }
      }
    }
  }
  收起阅读 »

出大事了，Elastic Stack 今日发布 5.4 版本，X-Pack 新增机器学习模块！
https://www.elastic.co/cn/blog ... stack
 今天，我们非常荣幸地宣布，首次发布通过 X-Pack 提供的 Elastic Stack Machine Learning 功能。加入 Elastic 就像跳上了火箭船，但是经过 7 个月不可思议的工作，我们现已将 Prelert Machine Learning 技术完全集成到 Elastic Stack。这让我们很激动，而且我们非常迫切地想要收到用户的反馈。

温馨提示：请注意，不要太过激动，这项功能在 5.4.0 版本中尚标记为 beta。

Machine Learning

我们的目标是通过一系列工具为用户赋能，让他们可以从自己的 Elasticsearch 数据中获取价值和洞察。与此同时，我们将 Machine Learning 视为 Elasticsearch 搜索和分析能力的自然延伸。举例来说，Elasticsearch 能够让您在大量数据中，实时地搜索用户“steve”的交易，或者利用聚合和可视化，展示一段时间以来的十大畅销产品或交易趋势。而现在有了 Machine Learning 功能，您就可以更加深入地探究数据，例如 “有没有哪项服务的行为发生了变化？” 或者 “主机上是否运行有异常进程？” 那么要想回答这些问题，就必须要利用 Machine Learning 技术，通过数据自动构建主机或服务的行为模式。

不过， Machine Learning 目前是软件行业最被夸大其词的术语之一，因为从本质上来讲，它就是用来实现数据驱动型预测、决策和建模的一系列广泛的算法和方法。因此，我们有必要隔绝干扰信息，具体说说我们所做的工作。

时间序列异常检测

目前，X-Pack Machine Learning 功能的着眼点是，利用无监督式机器学习，提供 “时间序列异常检测” 功能。

随着时间的推移，我们计划增加更多 Machine Learning 功能，但是我们目前只专注于为用户存储的时间序列数据（例如日志文件、应用程序和性能指标、网络流量或 Elasticsearch 中的财务/交易数据）提供附加值。

示例 1 - 自动提醒关键绩效指标值的异常变化

要说这项技术最直观的用例，那就是可以识别指标值或事件速率偏离正常行为的情况。例如，服务响应时间有没有显著增加？网站访客预期数量与同一时段正常情况相比，是否存在明显差异？传统情况下，人们会利用规则、阈值或简单的统计方法来进行此类分析。但遗憾的是，这些简单的方法鲜少能够高效地处理实际数据，原因在于此类方法往往是基于无效的统计假设（例如：高斯分布），因此不支持趋势分析（长期性或周期性趋势），或者在信号发生变化时缺乏稳定性。

所以说， Machine Learning 功能的首个切入点是单一指标作业，您可以借此了解该产品如何学习正常模式，如何识别单变量时间序列数据中存在的异常。如果您发现的异常是有意义的，您就可以连续地实时运行这项分析，并在发生异常时发出警报。

尽管这看上去像是一个比较简单的用例，但是产品后台包含大量复杂的无监督式机器学习算法和统计模型，因此我们对于任意信号具有鲁棒性，并且能够准确反映。

此外，为了让该功能可以在 Elasticsearch 集群中像原生程序一样运行，我们对功能实现进行了优化，因此几秒钟即可分析数以百万计的事件。




示例 2 - 自动追踪数以千计的指标

Machine Learning 产品可以扩展到数十万指标和日志文件，那么下一步就是要同时分析多个指标。这些指标可能是来自同一个主机的多个相关指标，可能是来自同一个数据库或应用程序的性能指标，也可能是来自多个主机的多个日志文件。在这种情况下，我们可以直接单独分析，再将结果聚合到同一个窗口，展示整体的系统异常情况。

例如，假设我要处理来自一大组应用程序服务的响应时间，我可以直接分析各个服务一段时间以来的响应时间，分别确认各个行为异常的服务，同时展示整体的系统异常情况：



示例 3 - 高级作业

最后，我们的产品还有大量更高级的用途。比方说，如果您想找出与整体相比行为异常的用户、异常的 DNS 流量，或者伦敦街头的拥堵路段，这时您就可以利用高级作业，灵活地分析 Elasticsearch 中存储的任何时间序列数据。

Elastic Stack 整合

Machine Learning 是 X-Pack 中的一项功能。这就意味着，安装 X-Pack 之后，就可以使用 Machine Learning 功能实时分析 Elasticsearch 中的时间序列数据。 Machine Learning 作业与索引和分片基本类似，能够跨 Elasticsearch 集群自动分布和管理。这还意味着 Machine Learning 作业对节点故障有很好的适应性。从性能角度看，紧密集成意味着数据永远不需要离开集群，而且我们可以利用 Elasticsearch 聚合极大地提高某些作业类型的性能。而紧密集成带来的另外一个好处就是，您可以直接从 Kibana 创建异常检测作业并查看结果。

由于这种方法对数据进行原位分析，数据从不离开集群，因此与将 Elasticsearch 数据集成到外部数据科学工具相比，这种方法能够带来显著的性能和运维优势。随着我们在这个领域开发出越来越多的技术，这种架构的优势将会更加显著。





立即试用并反馈

这些 Machine Learning 功能是 X-Pack 5.4 中的 beta 功能，现已可用。我们急切地想要听听您的使用体会，所以请下载 5.4 版本，安装 X-Pack，然后直接联系我们，或者通过我们的讨论论坛联系我们。
下载地址：https://www.elastic.co/cn/downloads
  收起阅读 »

index.mapping.single_type: true

尽管之前在很多地方都提到过，不过还是有必要单独开篇文章提醒一下大家！
Type 已经打算在6.0移除了，所以在设计 elasticsearch 的数据结构的时候，要注意到后面版本的变化。
之前在很多的文章和 PPT 都有介绍Elasticsearch 的几个核心概念，Index 对应 DB，Type 对应表，Document 对应记录，然后就真的按数据库的路子用，一个 index 里面 n 个 type 的情况大有存在，但是在 Lucene 里面其实有很多问题，所以现在es移除也是考虑了很久的。

新增参数：

index.mapping.single_type: true

 
UID 也会移除掉 _type 的值。

Type 移除大概分为两个阶段：
第一步，不支持新的索引创建多个 type，一个索引只有一个 type，名称也是固定的，不能修改。
第二步，移除。
 
相应的 PR 已经 merge 了。
https://github.com/elastic/ela ... 24317
  收起阅读 »