10月5日，Elastic 正式在纽交所上市了，股票代码 ESTC，当日股票涨幅超过100%，超越14年阿里巴巴，开盘价创有史以来新高。

Elastic这么受欢迎，说明大家手里的 Elastic 技术更值钱了，那么在国内的年度开发者交流大会更是不能错过啦，并且现在福利来了，大会门票抢购中，https://www.bagevent.com/event/1654662?discountCode=50OFF 手快有，手慢无啊！

知道 ELK 么？知道 Elasticsearch 么？目前最流行的开源数据库及分析类软件，目前已新晋级到数据库兵器谱排名第七位，搜索引擎排行榜长期霸占第一位，想要了解更多他的本事，快来了解一下他的官方用户大会：Elastic 中国开发者大会，时间2018年11月10日周六，地点深圳金茂 JW 万豪酒店。届时，将有来自 Elastic、eBay、暴雪、Grab、华为、阿里巴巴、顺丰等公司的25位各领域的专家大拿为你带来围绕 Elastic 开源技术的各自精彩干货分享。

Elastic Stack 作为目前全球最流行的数据搜索与实时分析引擎套件，其产品累计下载次数已超过三亿五千万次，各行各业从一线互联网公司到传统的行业都能找到使用 Elasticsearch 的身影。Elastic 的开源技术正越来越受到众多开发者的青睐，已然成为大数据领域分析工具的最佳选择。

[来自 db-engines.com的最新综合排名]

Elastic 中国开发者大会 2018（Elastic Developers China 2018）是由 Elastic 官方在中国举办的第二次开发者大会，主要围绕 Elastic 的开源产品: Elasticsearch、Logstash、Kibana 和 Beats，探讨在搜索、数据实时分析、日志分析、安全等领域的实践与应用。

举办 Elastic 开发者大会的目的是为中国广大的 Elastic 开发者提供一个技术交流和学习切磋的地方，汇集业界众多的成功案例，集思广益，发散思维，促进社区和行业的进步。

不管您是 Elasticsearch 的初学者还是资深的用户，您都应该参加！

大会亮点

01 部分精彩议题

1. Beats 创始人 Monica Sarbu 带来的运维分析的三连击

2. 新产品 Codesearch（原 Insight.io） 的初次亮相

3. Elastic 内部是如何使用 Elastic 产品的案例

4. 暴雪中国借助 ELK 运营游戏的经验分享

5. 东南亚打车软件 Grab 的 POI 搜索平台迁移史

6. 东半球对 Kibana 二次开发最多团队带来的经验分享

7. 千亿数据规模下的 Elasticsearch 深度应用

8. Elasticsearch 和 AI 的深度结合与用户画像系统

更多在互联网、证券、快递、新零售、安全等领域的分享，点击这里了解更多

02 部分嘉宾阵容

03 Elastic AMA 展台

AMA 即 Ask Me Anything，意思是尽管随便问，您可以在大会当天，尽情的在现场咨询 Elastic 官方工作人员任意的问题，可以是技术的咨询，可以是特性的讲解，可以是最佳实践，可以是商务合作。AMA 展台，您一定不要错过。

04 Elastic Demo 展台

如果您对 Elastic 能够帮您做哪些事情比较感兴趣，最直观的方式就是来到 Elastic 的 Demo 展台，现场有 Elastic 技术专家为您讲解各种酷炫的 Demo 以及具体的如何使用 Elastic Stack 来完成特定的任务。 Demo 展台有趣又好玩，记得打卡。

05 闪电演讲

您也来讲讲，大会的最后一个环节名叫闪电演讲，参会者可以现场报名，每位分享者可以有5分钟的时间来进行分享，可以是任何相关的话题，可以是 Demo 演示，可以是技术脱口秀，或是您的一个开源的项目，名额有限，先报先得。

最后，赶紧报名吧！ https://www.bagevent.com/event/1654662?discountCode=50OFF

在 Elasticsearch 中处理字符串类型的数据时，如果我们想把整个字符串作为一个完整的 term 存储，我们通常会将其类型 type 设定为 keyword。但有时这种设定又会给我们带来麻烦，比如同一个数据再写入时由于没有做好清洗，导致大小写不一致，比如 apple、Apple两个实际都是 apple，但当我们去搜索 apple时却无法返回 Apple的文档。要解决这个问题，就需要 Normalizer出场了。废话不多说，直接上手看！

1. 上手

我们先来重现一下开篇的问题

PUT test_normalizer
{
  "mappings": {
    "doc":{
      "properties": {
        "type":{
          "type":"keyword"
        }
      }
    }
  }
}

PUT test_normalizer/doc/1
{
  "type":"apple"
}

PUT test_normalizer/doc/2
{
  "type":"Apple"
}

# 查询一 
GET test_normalizer/_search
{
  "query": {
    "match":{
      "type":"apple"
    }
  }
}

# 查询二
GET test_normalizer/_search
{
  "query": {
    "match":{
      "type":"aPple"
    }
  }
}

大家执行后会发现 查询一返回了文档1，而 查询二没有文档返回，原因如下图所示：

1. Docs写入 Elasticsearch时由于 type是 keyword,分词结果为原始字符串
2. 查询 Query 时分词默认是采用和字段写时相同的配置，因此这里也是 keyword，因此分词结果也是原始字符
3. 两边的分词进行匹对，便得出了我们上面的结果

2. Normalizer

normalizer是 keyword的一个属性，可以对 keyword生成的单一 Term再做进一步的处理，比如 lowercase，即做小写变换。使用方法和自定义分词器有些类似，需要自定义，如下所示：

DELETE test_normalizer
# 自定义 normalizer
PUT test_normalizer
{
  "settings": {
    "analysis": {
      "normalizer": {
        "lowercase": {
          "type": "custom",
          "filter": [
            "lowercase"
          ]
        }
      }
    }
  },
  "mappings": {
    "doc": {
      "properties": {
        "type": {
          "type": "keyword"
        },
        "type_normalizer": {
          "type": "keyword",
          "normalizer": "lowercase"
        }
      }
    }
  }
}

PUT test_normalizer/doc/1
{
  "type": "apple",
  "type_normalizer": "apple"
}

PUT test_normalizer/doc/2
{
  "type": "Apple",
  "type_normalizer": "Apple"
}
# 查询三
GET test_normalizer/_search
{
  "query": {
    "term":{
      "type":"aPple"
    }
  }
}

# 查询四
GET test_normalizer/_search
{
  "query": {
    "term":{
      "type_normalizer":"aPple"
    }
  }
}

我们第一步是自定义了名为 lowercase的 normalizer，其中filter 类似自定义分词器中的 filter ，但是可用的种类很少，详情大家可以查看官方文档。然后通过 normalizer属性设定到字段type_normalizer中，然后插入相同的2条文档。执行发现，查询三无结果返回，查询四返回2条文档。

问题解决了！我们来看下是如何解决的

1. 文档写入时由于加入了 normalizer,所有的 term都会被做小写处理
2. 查询时搜索词同样采用有 normalizer的配置，因此处理后的 term也是小写的
3. 两边分词匹对，就得到了我们上面的结果

3. 总结

本文通过一个实例来给大家讲解了 Normalizer的实际使用场景，希望对大家有所帮助！

初次接触 Elasticsearch 的同学经常会遇到分词相关的难题，比如如下这些场景：

1. 为什么明明有包含搜索关键词的文档，但结果里面就没有相关文档呢？
2. 我存进去的文档到底被分成哪些词(term)了？
3. 我得自定义分词规则，但感觉好麻烦呢，无从下手

如果你遇到过类似的问题，希望本文可以解决你的疑惑。

1. 上手

让我们从一个实例出发，如下创建一个文档：

PUT test/doc/1
{
  "msg":"Eating an apple a day keeps doctor away"
}

然后我们做一个查询，我们试图通过搜索 eat这个关键词来搜索这个文档

POST test/_search
{
  "query":{
    "match":{
      "msg":"eat"
    }
  }
}

ES的返回结果为0。这不太对啊，我们用最基本的字符串查找也应该能匹配到上面新建的文档才对啊！

各位不要急，我们先来看看什么是分词。

2. 分词

搜索引擎的核心是倒排索引（这里不展开讲），而倒排索引的基础就是分词。所谓分词可以简单理解为将一个完整的句子切割为一个个单词的过程。在 es 中单词对应英文为 term。我们简单看个例子：

ES 的倒排索引即是根据分词后的单词创建，即 我、爱、北京、天安门这4个单词。这也意味着你在搜索的时候也只能搜索这4个单词才能命中该文档。

实际上 ES 的分词不仅仅发生在文档创建的时候，也发生在搜索的时候，如下图所示：

读时分词发生在用户查询时，ES 会即时地对用户输入的关键词进行分词，分词结果只存在内存中，当查询结束时，分词结果也会随即消失。而写时分词发生在文档写入时，ES 会对文档进行分词后，将结果存入倒排索引，该部分最终会以文件的形式存储于磁盘上，不会因查询结束或者 ES 重启而丢失。

ES 中处理分词的部分被称作分词器，英文是Analyzer，它决定了分词的规则。ES 自带了很多默认的分词器，比如Standard、 Keyword、Whitespace等等，默认是 Standard。当我们在读时或者写时分词时可以指定要使用的分词器。

3. 写时分词结果

回到上手阶段，我们来看下写入的文档最终分词结果是什么。通过如下 api 可以查看：

POST test/_analyze
{
  "field": "msg",
  "text": "Eating an apple a day keeps doctor away"
}

其中 test为索引名，_analyze 为查看分词结果的 endpoint，请求体中 field 为要查看的字段名，text为具体值。该 api 的作用就是请告诉我在 test 索引使用 msg 字段存储一段文本时，es 会如何分词。

返回结果如下:

{
  "tokens": [
    {
      "token": "eating",
      "start_offset": 0,
      "end_offset": 6,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "an",
      "start_offset": 7,
      "end_offset": 9,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "apple",
      "start_offset": 10,
      "end_offset": 15,
      "type": "<ALPHANUM>",
      "position": 2
    },
    {
      "token": "a",
      "start_offset": 16,
      "end_offset": 17,
      "type": "<ALPHANUM>",
      "position": 3
    },
    {
      "token": "day",
      "start_offset": 18,
      "end_offset": 21,
      "type": "<ALPHANUM>",
      "position": 4
    },
    {
      "token": "keeps",
      "start_offset": 22,
      "end_offset": 27,
      "type": "<ALPHANUM>",
      "position": 5
    },
    {
      "token": "doctor",
      "start_offset": 28,
      "end_offset": 34,
      "type": "<ALPHANUM>",
      "position": 6
    },
    {
      "token": "away",
      "start_offset": 35,
      "end_offset": 39,
      "type": "<ALPHANUM>",
      "position": 7
    }
  ]
}

返回结果中的每一个 token即为分词后的每一个单词，我们可以看到这里是没有 eat 这个单词的，这也解释了在上手中我们搜索 eat 没有结果的情况。如果你去搜索 eating ，会有结果返回。

写时分词器需要在 mapping 中指定，而且一经指定就不能再修改，若要修改必须新建索引。如下所示我们新建一个名为ms_english 的字段，指定其分词器为 english：

PUT test/_mapping/doc
{
  "properties": {
    "msg_english":{
      "type":"text",
      "analyzer": "english"
    }
  }
}

4. 读时分词结果

由于读时分词器默认与写时分词器默认保持一致，拿 上手 中的例子，你搜索 msg 字段，那么读时分词器为 Standard ，搜索 msg_english 时分词器则为 english。这种默认设定也是非常容易理解的，读写采用一致的分词器，才能尽最大可能保证分词的结果是可以匹配的。

然后 ES 允许读时分词器单独设置，如下所示：

POST test/_search
  {
    "query":{
      "match":{
        "msg":{
          "query": "eating",
          "analyzer": "english"
        }
      }
    }
  }

如上 analyzer 字段即可以自定义读时分词器，一般来讲不需要特别指定读时分词器。

如果不单独设置分词器，那么读时分词器的验证方法与写时一致；如果是自定义分词器，那么可以使用如下的 api 来自行验证结果。

POST _analyze
  {
    "text":"eating",
    "analyzer":"english"
  }

返回结果如下：

{
  "tokens": [
    {
      "token": "eat",
      "start_offset": 0,
      "end_offset": 6,
      "type": "<ALPHANUM>",
      "position": 0
    }
  ]
}

由上可知 english分词器会将 eating处理为 eat，大家可以再测试下默认的 standard分词器，它没有做任何处理。

5. 解释问题

现在我们再来看下 上手 中所遇问题的解决思路。

1. 查看文档写时分词结果
2. 查看查询关键词的读时分词结果
3. 匹对两者是否有命中

我们简单分析如下：

由上图可以定位问题的原因了。

6. 解决需求

由于 eating只是 eat的一个变形，我们依然希望输入 eat时可以匹配包含 eating的文档，那么该如何解决呢？

答案很简单，既然原因是在分词结果不匹配，那么我们就换一个分词器呗~ 我们可以先试下 ES 自带的 english分词器，如下：

# 增加字段 msg_english，与 msg 做对比
PUT test/_mapping/doc
{
  "properties": {
    "msg_english":{
      "type":"text",
      "analyzer": "english"
    }
  }
}

# 写入相同文档
PUT test/doc/1
{
  "msg":"Eating an apple a day keeps doctor away",
  "msg_english":"Eating an apple a day keeps doctor away"
}

# 搜索 msg_english 字段
POST test/_search
{
  "query": {
    "match": {
      "msg_english": "eat"
    }
  }
}

执行上面的内容，我们会发现结果有内容了，原因也很简单，如下图所示：

由上图可见 english分词器会将 eating分词为 eat，此时我们搜索 eat或者 eating肯定都可以匹配对应的文档了。至此，需求解决。

7. 深入分析

最后我们来看下为什么english分词器可以解决我们遇到的问题。一个分词器由三部分组成：char filter、tokenizer 和 token filter。各部分的作用我们这里就不展开了，我们来看下 standard和english分词器的区别。

从上图可以看出，english分词器在 Token Filter 中和 Standard不同，而发挥主要作用的就是 stemmer，感兴趣的同学可以自行去看起它的作用。

8. 自定义分词

如果我们不使用 english分词器，自定义一个分词器来实现上述需求也是完全可行的，这里不详细讲解了，只给大家讲一个快速验证自定义分词器效果的方法，如下：

POST _analyze
{
  "char_filter": [], 
  "tokenizer": "standard",
  "filter": [
    "stop",
    "lowercase",
    "stemmer"
  ],
  "text": "Eating an apple a day keeps doctor away"
}

通过上面的 api 你可以快速验证自己要定制的分词器，当达到自己需求后，再将这一部分配置加入索引的配置。

至此，我们再看开篇的三个问题，相信你已经心里有答案了，赶紧上手去自行测试下吧！

1. ES6.4发布。 http://t.cn/RkHPfV6

2. 在Django项目中使用es。 http://t.cn/RkR2as4

3. ElasticHQ: 基于python的es监控管理插件。 http://t.cn/Rk8ioV0

活动预告

1、Elastic 中国开发者大会最后一波早鸟票发售进行中

https://conf.elasticsearch.cn/2018/shenzhen.html

2、Elastic Meetup 9月8日 北京线下沙龙正在报名中

https://elasticsearch.cn/article/759

• 编辑：bsll

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

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

• 汇集 Elastic Stack 的奇巧赢技
• 随手可得的小技巧，温故知新
• 分享和学习，共同进步
• 积少成多，知识库

• 贴士的内容要小且精要，简单，适合阅读和分享（限制为Twitter长度）
• 大家都可以发表贴士，社区一起参与贡献内容
• 贴士需要标识适用的版本号和对应的开源项目，如：Elasticsearch 6.x
• 贴士在得到3个赞之后，表示受到大家的认可，可以提供出现分享功能
• 分享功能要支持外部引用，生成 JS 脚本，随机显示一条贴士，可以挂在个人博客和网站上
• 可以对单条贴士生成一个图片，嵌入二维码，方便微信微博分享，显示贡献者和贡献者的个人签名
• 贴士不单独存储，还是在社区的文章模块，只不过发布的时候，需要选择分类为 “ElasticTips” 目录
• 搞一个微信小程序，方便分享传播贴士内容

• API 模块：Golang 编写，负责读取数据库内容和生成 JS，RSS 订阅
• JS 渲染模块：Golang 编写，负责渲染生成 JS
• 静态图片生成：Golang 编写，基于图片模板，渲染分享用的图片
• 单独的页面来展示贴士，主要要求是要酷炫
• 微信小程序：貌似没得选，再者我也不懂