专栏亮点
-
本专栏采用最新的 ElasticSearch7.x 版本
同市面上大部分的 ElasticSearch6.x 教程相比较，7 版本更新改动很大，比如新增 KQL（Kibana Query Language），内部索引类型限定为 _doc ，还是 ES for python API 接口的改变等。
众所周知，在技术更新如此快的年代，掌握最新的技术就能够在未来使用它的时候不会那么快就被淘汰。比如从 Java 的 iBatis 到 MyBatis ，从 Struts2 到 Spring MVC 再到 Spring Boot 。虽然你不能够停止学习的脚步，但是你可以选择插队学习，弯道超越，直接学习最新的最流行的技术，这样就比别人更领先一步。
-
本专栏将针对 ES 在业务中的核心概念进行解析，让你不仅明白为什么使用它还能了解该怎样选择。
ES 作为目前大数据方向必须掌握的技能，主要是作为工具分析挖掘业务数据，因此专栏会有大量的实践案例，涵盖了工作中常见的业务场景，无论你是初入职场的小白，还是即将毕业的学生党，专栏能够给你提供各种实践操作，手把手带你玩转起 ES 。而且我也将在专栏里针对大厂面试中常见的问题给出正确的解答思路。
-
本专栏将介绍在 Java 和 Python 框架下如何运用 ElasticSearch。
本专栏讲究变学边做，把学的到东西能够立即投入到公司实际业务中，所以会介绍如何在 Python 与 Java 框架下使用 ES。同时，比如制作业务分析表、Dashboard、检测异常值、筛选数据、分组统计数据等功能，本专栏中不会单纯贴几个 Demo，而是会以一个更系统的案例来演示。
-
专栏将针对 ES 的重要搜索功能 DSL 进行业务分析。
DSL 之于 ES 的重要性不言而喻，就相当于 SQL 对于传统数据库而言。关于如何使用 DSL，对查询效率较差语句如何进行提高查询效率，本专栏将针对 DSL 的查询结合不同的业务需求进行实现，从简单到深入一步步理解 DSL 。
-
专栏前部分偏重理论，后部分偏实践。
实践是检验真理的唯一标准，职场中讲究的是效率，先把工具用起来，当使用一段时间后，再去理解不同的概念，相信你会有醍醐灌顶的感觉。就像在大学里上关于数据库的课，老师会先让你做个学生数据库，在慢慢告诉你什么是索引、表连接、范式等。
-
丰富的图片展示进行原理和案例讲解。
🔺 如何查看相应数据
🔺 如何范围查询
🔺 饼状图开发案例
🔺 数据可视化案例
专栏目录
我们首先会介绍 ElasticSearch 的基本原理概念，对 ES 有个整体的把控。
实践是最好的学习方式，专栏之后会用 Kibana 对常见的业务需求进行分析，作为学习 ES 的开始，然后到进阶 ES 分析，对 ES 高阶的分析组件进行学习。
然后会详细介绍 ES 开发的核心部分 DSL 的详细介绍讲解，结合目前主流的开发语言，Python 与 Java 模拟工作中常见的业务进行开发分析。
为了加强对 ES 的理解，专栏最后会结合多种需求案例进行系统的学习。
一 ElasticSearch 基本原理与环境搭建
-
关系型数据库与 ElasticSearch 对比
-
ElasticSearch 搜索原理之倒排索引
-
ElasticSearch 不同角色分工
-
分片及副本原理
-
基于 Docker 部署单节点 ElasticSearch
-
基于 Docker 安装 Kibana
-
基于 Docker 一键式部署分布式 ElasticSearch
二 运用 ElasticSearch 做业务分析
-
Discover 如何查看相应的业务数据
-
如何筛选只包含某个字段的业务数据
-
如何自定义的查看某个时间段的数据
-
折线图绘制过程与应用场景
-
柱状图绘制过程与应用场景
-
饼状图绘制过程与应用场景
三 ElasticSearch 高级数据分析可视化
-
热力图在数据分析中的应用
-
主题分析之标签云图
-
业务分析进阶之脚本字段
-
高阶时间序列数据可视化
-
Timelion 在时间序列中的应用
-
Dashboard 专题数据分析可视化
四 深入理解 ElasticSearch 之搜索
-
基于 Rest API 的 ElasticSearch 增删改查（1）
-
基于 Rest API 的 ElasticSearch 增删改查（2）
-
基于 Rest API 的 ElasticSearch 增删改查（3）
-
如何运用强大的 ElasticSearch 核心 DSL
-
组合查询怎么玩
-
如何根据聚合求取各种数值指标
-
什么是深入嵌套聚合的万用套法
-
优化 Query 查询效率之 Scroll 查询
-
优化聚合数据查询效率之 Partition
五 基于 Python/Java 开发案例解析
-
Python Elasticsearch Client 实战
-
天气指标监控数据实战
-
天气指标数据筛选实战
-
结合指标数据场景优化查询效率实战
-
Java Elasticsearch Client 实战
-
基于 Java 进行天气指标数据筛选实战
-
基于Java 优化效率查询
六 ElasticSearch 实战业务案例上手
-
基于 ELK 天气指标监控在线实时监控案例
-
基于机器学习的 ElasticSearch 异常值检测案例
-
基于 MovieLens 的电影搜索案例
你将获得什么？
-
最新的 ElasticSearch 特性运用
-
ElasticSearch 业务核心技能比如 Kibana 业务分析方法，这些方法将会满足绝大多数公司需求，饼图，折线图，柱状图，聚合分析，分桶等。
-
ElasticSearch 大数据搜索分析高级玩法比如 DSL 查询语法的基础与高级用法，了解如何使用 DSL 为全文检索服务，了解如何把 ES 当做数据库，使用 DSL 实现各种 SQL 操作。
-
Java 和 Python 框架下如何运用 ElasticSearch
-
ElasticSearch 环境部署和搭建比如集群搭建，了解分片，实例，节点角色概念，什么是倒排索引，对 ES 有个整体的把握。
适读人群
-
ElasticSearch 爱好者，对 ES 有强烈的好奇心
-
大数据工程师，Java/Python/ES 运维工程师，数据分析与挖掘工程师
-
初入职场的或者即将找工作面试的同学
-
急需 ES 解决当前公司的业务需求
作者介绍
作者 zhupc，有丰富的大数据与机器学习工作经验。目前在某上市外企公司研发中心任职，负责 ES 数据分析与机器学习开发工作。
擅长 Java、Python、机器学习、Kafka 和 ES 等项目开发与管理。
购买须知
- 本专栏为图文内容，共计 38 篇。每周更新 2 篇，预计从 2020 年 4 月 8 日至 2020 年 6 月 15 日左右更新完毕。
- 本专栏为虚拟产品，一经付费概不退款，敬请谅解。
- 本专栏可在 GitChat 服务号、App 及网页端 gitbook.cn 上购买，一端购买，多端阅读。
订阅福利
-
订购本专栏可获得专属海报（在 GitChat 服务号领取），分享专属海报每成功邀请一位好友购买，即可获得 25% 的返现奖励，多邀多得，上不封顶，立即提现。
-
提现流程：在 GitChat 服务号中点击「我-我的邀请-提现」。
-
购买本专栏后，服务号会自动弹出入群二维码和暗号。如果你没有收到那就先关注微信服务号「GitChat」，或者加我们的小助手「GitChatty6」咨询。（入群方式可查看第 4 篇文末说明）。
课程内容
ElasticSearch 是什么？
为什么要学习 ElasticSearch ？
ElasticSearch（ES）作为一款优秀的分布式搜索分析引擎，越来越受到许多互联网公司的关注，像小米、滴滴出行、携程旅游、阿里云和腾讯云等都在使用 ElasticSearch 。
最知名的应用公司就是 GitHub，它采用 ES 作为搜索引擎对代码进行搜索。虽然它是一款优秀的分布式搜索引擎，但是它强大的查询、分析、聚合能力使得它与数据库的边界越来越模糊。因此很多大公司都喜欢用 ES 作为数据库来存储日志或者其他业务数据，最常见的结合就是通过 Kafka 、 Redis 来作为数据源，logstash 进行转化，ES 对数据存储，kibana 对数据进行展示， ES+logstash+kibana（ELK）一体化的日志分析、业务指标分析。
越来越多的公司使用 ElasticSearch ，这门技术已经不仅仅是大数据工程师必须要掌握的了，ES 还提供了 Java ，python 等 API，因此 ES 将会成为 Java 工程师与 Python 工程师必不可缺的工具，灵活应用 ES 将会成为你未来最有竞争力的能力。
为什么不使用 MySQL，Oracle 或者 Hbase
传统数据库优点是结构化查询，查询速度快、安全。但是当数据量较大时候，无论是查询还是插入都会变的十分缓慢，当然 MySQL 也可以做成分布式，但是部署以及维护成本较高。Oracle 查询速度是很快的，即使数据量较大，查询速度也不会很慢，但是有多少公司愿意负担这个费用呢？
为什么不使用 Redis 或者 Hbase 呢？
对于文档数据库，每个数据库都有其应对的需求，就 Redis 而言，Redis 更适合做缓存数据库，查询速度非常快，但是它的数据结构是键值对，不能够进行复杂的需求查询，只能给一个 key 然后返回结果。Hbase 是基于Hadoop 的数据库，它的特点是能够存储海量数据，并且扩展起来简单，因为底层是基于 HDFS 的。对于实时需求任务，以及在线分析就比较困难，不可能把所有数据都加载出来，或者写一个 MapReduce job 来进行任务分析，这样的工程是比较耗费资源的。
ES 是分布式的，并且在数据量超大的情况下其查询速度也嗖嗖的快。另外对象中无论是怎样的复杂关系，都可以用 JSON 格式表达出来，可读性较高，ES 就是以 JSON 数据格式存储数据。并且支持在线分析、实时分析。ES 是基于存储、查询、聚合分析和可视化于一体的解决方案。
什么样的数据适合存进去呢？
日志数据，一般如果程序遇到什么问题都可以通过查询日志分析来定位错误的地方，这种需求肯定是能够过关键字查询，能够在线可视化分析。这个需求就不合适放在传统数据库中，因为日志冗余大，而且涉及很多文本查询，使用传统数据库是非常不方便的，Redis 等文档数据库更不适合。ES 正好就是全文本检索系统，且是分布式的适合这个需求。另外指标数据也是适合存进去的，指标实时在线监控、报警等，ES 提供了一整套解决方案。
所以说不同的数据库或者全文检索系统都有其专门的应用场景，当涉及到实时，文本检索，数据量大，可视化分析，聚合分析的时候都可以考虑使用 ES 来作为解决方案。
ElasticSearch 能够做什么？
从数据获取，存储计算到可视化，ES 开发了一整套解决方案，Logstash 、Beat 负责数据抓取，ES 负责存储计算，kibana 对数据进行展示分析。另外还有收费的 X-Pack 可以实现安全、告警、监控和 ML 等更丰富的功能。ES 在搜索、日志分析、指标分析和安全分析等领域应用广泛。从前端到后端到数据分析，从云服务到最流行的机器学习，ES 都提供了一整套解决方案。
ElasticSearch 项目的起源是什么？
ES 起源于一款优秀的基于 Java 开发的搜索引擎类库——Lucene。Lucene 具有高性能、易扩展的优点，但是它只是一个类库，与业务结合的比较紧密。笔者曾使用过 C# 的 Lucene.net ，当时的业务场景是对农村宅地基信息进行搜索，我那时候研究类库的使用方法，首先如何对文本分词，分词后如何建立索引……之后终于完成了一个全文搜索功能，踩了很多坑，学习曲线很陡峭。
另外如果有其他的项目也需要全文搜索功能，那你只能重新写全文搜索功能业务。全文搜索只是一个功能，不应该跟业务耦合的这么紧密，因此将这个功能单独抽离出来作为一个服务，只需要提供一个接口，就可以实现这个功能。因此出现了 Solr（Apache 开源项目），Elastic Inc（开源软件/上市公司）的 ES ，Splunk（商业上市公司）。
图（a）是使用 Lucene 开发项目，与业务耦合紧密，不同的项目需要重新开发全文搜索功能。
图（b）是将全文搜索业务抽离出来作为一个云服务。
ElasticSearch 在互联网开发中有多火爆？多流行？
市场上存在很多搜索引擎，相对于 Java 工程师来说 Solr 应该是最为熟悉的，当然 Solr 也火爆了很多年，而 Splunk 鲜为人知些，因为它是收费的。查看最近几年搜索引擎的排名情况，可以看出，2016 年是个分水岭，2013 年到 2016 年 Solr 都远远超过 ES，但是 ES 在 2016 年之后，开始飞速的增长，以至超过 solr 跟 Splunk ，成为最受欢迎的一款搜索引擎。
伴随而来就是 ElasticSearch 相关的岗位在招聘市场中陡然大增，一度出现供不应求的现象。平均薪资水平也远高于行业内其他工种。
关系型数据库与 ElasticSearch 对比
基本概念对比
关系型数据库，像最常见的 Mysql , SqlServer 都是属于关系型数据库，关系型数据中有这几种概念：数据库、表、行、列、Schema，还有 SQL 查询语句。
以学生数据库为例，回忆一下数据库过程：
- 建学生数据库
- 见一个学生表
- 配置学生字段，如名称 varchar、性别 char 等
- 一行代表一个学生，不同的列代表这个学生不同的属性
ES 也与关系型数据库如出一辙，只是叫法不同，在 ES 中建一个学生数据库步骤如下：
在 ES 中启动一个 ES 实例，这个实例就相当于数据库，表在 ES 中被称为索引 Index，行称为文档 Document，列称为字段 Field ，Schema 被称为 Mapping ，数据库中查询语句 SQL 在 ES 中有相应的 DSL 查询语句。
因此建学生索引：
- 配置 ES，启动一个 ES 实例
- 新建一个学生索引
- 不需要配置字段属性，ES 会自动识别
- 一个 JSON 字符串代表一个学生，JSON 字符串中有学生属性字段 Field
具体对应关系如下表：
| RDBMS | ES |
|---|---|
| Table | Index(Type) |
| Row | Document |
| Column | Field |
| Schema | Mapping |
| SQL | DSL |
创建 Table/Index 对比
传统数据创建方式如下，使用简单的 SQL 语句就能够轻松创建，但是前提是要定义好表结构以及数据类型。
CREATE TABLE Student( name varchar(20), sex char(2), age int);ES 基于 Http 协议的，增删改查的接口都基于 Http ,因此它需要使用 ES 的 Rest API 才能够创建，只需要将 JSON 格式的学生数据利用 Rest API PUT 给 ES 即可自动创建，并且可以选择性的更改 ES 自动创建好的数据字段的类型 ，后面的课时中有详细的介绍如何对 ES 进行增删改查。
下面的这个语法，是基于 ES 的可视化界面 Kibana 来做的，使用 PUT 的方式，索引是 student，操作是 _create 创建。这样的话就会自动创建好索引，以及数据字段的类型，比如 name 是 text 类型，age 是 数字类型。
PUT student/_create/1{ "name":"xiaoming", "sex":"male", "age":18}Row/Document 对比
传统数据库中，row 就是一行数据，每行数据是一条记录。查询结果如下：
name | sex |age xiaoming | male | 18但是在 ES 中数据记录的方式是 documet ，插入数据是将数据看做 documet 然后以 JSON 的格式插入进行，因此查询返回的结果也是 JSON。
{ "took" : 10, "timed_out" : false, "_shards" : { "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value" : 1, "relation" : "eq" }, "max_score" : 1.0, "hits" : [ { "_index" : "student", "_type" : "_doc", "_id" : "1", "_score" : 1.0, "_source" : { "name" : "xiaoming", "sex" : "male", "age" : 18 } } ] }}Column/ Field 对比
传统数据的话每列代表一个属性，name 列都是都是姓名并且类型是 varchar(20)。
ES 根据字段类型自动创建，会给 name 字段自动定义为 String 类型。
Schema /Mapping 对比
传统数据库 Schema 说明了表之间的联系结构，字段关系主外键等。
而 ES 是没有这么多复杂的关系，不存在主外键，表与表之间相互联系，因此 ES 是将一个对象的 JSON 实体直接存到 ES 中，通过 mapping 来查看具体结构。
{ "mapping": { "properties": { "age": { "type": "long" }, "name": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "sex": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } } } }}SQL/DSL 对比
两者都是一种语法，SQL 是针对传统数据库的，DSL 是针对 ES 的。在 “创建 Table/Index 对比” 这个部分已经能够很好的说明了两者的区别与联系，语法不通，但是应用场景非常的相似，像增删改查，分组等，两者都具备这样的功能。
小结
本节我们明白了两者之间的异同，就能够很好的理解ES各个概念，本课时对传统数据库与 ES 做了一个粗略的对比，只通过本课时想要把握两者的具体与联系是比较困难的，想要了解更多的 ES 特性请多关注后面的实战课时。
ElasticSearch 搜索原理之倒排索引
倒排索引作用
试想一下这个情景，你也记不清什么时候读过这个一段话：“老刘,老刘,食量大似牛,吃一个老母猪不抬头.”，只记得是红楼梦里面的台词，上学的时候语文老师还解读过，现在觉得特别有意思，想看看完整的这个故事。
于是你买了一本《红楼梦》，打开目录，定位不同章节的位置，然后按照顺序一章一章的遍历，找找哪一章里面有这么一句话。终于经过你不懈的努力终于找到这句话来自于“刘姥姥进大观园”哪一章。
这个检索的过程，映射关系是从文档到关键词，因为我们是翻阅不同的章节文档来检索哪里出现了这么一句话。
这都能忍？也是服了。如何解决这个问题呢？为了查找某一个或多个关键词，不得不查询遍历所有文档，得出这些关键词出现在哪些文档中。这种方式未免也太耗时耗力了，有没有一种方法能够快速检索到呢？
思考一下，我们要避免根据章节一章章的取遍历查询，能不能够根据词来定位到章节呢？像新华字典那样，查找某个词，然后定位到某个词的页数，如果也对《红楼梦》这本书也建立那样的索引，起步不是非常的方便？
这个建索引的过程，就是所谓的倒排索引，是从关键词到文档，这是一个反过程。英文叫 invert index ，你也可以理解为反索引，或者逆索引，只不过这种索引方式，大部分译为倒排索引。
创建倒排索引
针对《红楼梦》这本书，我们搭建一个搜索引擎，因此人为的查找实在是太变态了。
首先以章节为 ID 建立一个《红楼梦》数据库。
| ID | Text |
|---|---|
| 0 | 老刘,老刘,食量大似牛,吃一个老母猪不抬头 |
| 1 | 女儿是水作的骨肉，男人是泥作的骨肉。 |
| 2 | 必得两个女儿伴着我读书，我方能认得字 |
常规的检索方法，遍历 ID ，通过 ID 查找对应的 Text 是否包含”老刘,老刘,食量大似牛,吃一个老母猪不抬头“这句话。如果使用倒排索引该怎么做呢？
- 首先对文档分词，并统计词在哪个章节 ID 里面
- 生成一张"词-章节"映射表
- 对查找句子进行分词，拿着这些词到映射表中查找，在哪个章节里面
- 计算并排序相似度，相似度的 topN 推荐给用户
建设倒排索引映射表（为了减少冗余，这里分词结果没有被全部列出）：
| Word | ID |
|---|---|
| 老刘 | 0 |
| 食量 | 0 |
| 老母猪 | 0 |
| 女儿 | 1，2 |
| 男人 | 1 |
| 骨肉 | 1 |
| 读书 | 2 |
| 方能 | 2 |
| 两个 | 2 |
基于倒排索引查询
假设映射表如上，我们再对”老刘,老刘,食量大似牛,吃一个老母猪不抬头“这句话进行检索，首先这句话会被分词处理成”老刘，食量，老母猪“。
得到了这三个词，到索引表中检索，得到的结果是（0，3，100%），0代表章节的ID，4代表词在对应章节中命中的次数，100%代表通过某种相似度计算方法得出的相似度（这里相似度的计算方法，假设为”相似度=检索语句命中的词个数/检索语句总的词个数“），因此就能轻易的得出，这句话很有可能出现在《红楼梦》的第一章中。
再对一句话进行检索”女儿一定要学会读书写字“，这句话将会被分词处理成”女儿，读书，写字“。
再到索引表中去检索，得到
- （1，1，33%），第一个1代表章节ID，第二个1代表三个词在这个章节中只命中了一个，33%代表我使用相似度方法计算的相似度。
- （2，2，66%），第一个2代表章节ID，第二个2代表三个词在第2章节中命中了2个，66%是计算的相似度。
对相似度进行排序，自然搜索引擎将会把文档2推荐出来。这里可能会有个疑问，为什么把2推荐出来呢？这句话在红楼梦中并不存在啊？从这里就可以看出，搜索引擎只是根据相似度进行推荐，而并不能保证推荐的一定是对的。搜索引擎只是将数据库中相似的案例推荐给你。
小结
通过本小节我们明白了，什么是倒排索引，以及如何建立倒排索引。对搜索引擎原理有个大致的了解，明白了搜索引擎原理，原来搜索引擎是通过相似度的指标将文档推荐出来，怪不得使用百度搜索关键词是总是出来很多链接，并且越往后的链接越是跟想要搜索的内容不相关。
ElasticSearch 不同角色分工
节点作用
ES 是一个分布式全文检索引擎，既然是分布式那一定是设计多个节点甚至多个集群。为什么需要分布式呢？试想一下，如果 ES 节点只设计成一个，那么这个节点会涉及哪些工作呢？
- 首先该节点应该具备响应用户的读写操作
- 该节点应该具备存储数据的能力
- ES应该具备协调多个用户集体请求的操作
- 另外 ES 会自动映射用户输入的数据类型，因此ES应该具备自动映射数据类型的操作
节点优化
当然这些只是这个节点最基本，最应该做到的功能，节点应该具备的功能绝不会仅限于此。这么多工作都让这个单个节点来做，服务器撑得住恐怕这个节点也不乐意了。当多个用户触发写操作，节点会协调多个用户的请求，然后再把写的数据进行类型转换，然后再把数据写到磁盘中。整个过程，可以说任何一个过程都能够轻易的达到瓶颈。
- 请求响应瓶颈：这个不难理解，如果请求过多，服务器宕机也不为过
- 读写瓶颈：磁盘的写入能力是有限的，也就是经常说的 I/O 瓶颈
- 协调请求以及自动映射数据类型：这个瓶颈来自于服务器 CPU 性能，CPU 需要协调多个线程来做这些事
节点分工
这个单个节点可以把它比喻为牛批的全栈工程师，啥都会，啥都干，但是一个的精力总是有限的，现在不是一个人单打独斗就能解决问题，需要有一个好的 Team 才能够成就伟大的事。ES 也是如此，既然单个节点不能够满足需求，那就按照任务多分配几个节点，将任务具体到节点，不同的节点负责不同的任务。
因此 ES 为分配不同的任务，定义了以下几个节点角色：Master,Data Node,Coordinating Node,Ingest Node
Master 节点：每个 ES 节点启动之前都会有个默认配置 node.master:true ,也就是说每个节点都有可能成为 Master 节点，这些节点被称作 Master-eligible nodes ，就是合格的有资格成为 Master 节点的节点。
当然 Master 只能有一个，所以会通过选举的方法对这启动的节点选举，被选中的节点才会成为 Master 节点。 Master 节点主要是负责维护集群的状态，像所有节点的信息，所有的索引和它相关的 Mapping 关系，配置信息，分片的路由等。既然 Master 节点维护了这么重要的信息，玩意它挂了怎么办？
挂了的话，将会对其他的有资格成为 Master 节点的节点重新选举出另一个 Master 节点，因此这就说明了其他 Master-eligible nodes 也会保存集群信息，但是只有 Master 节点有权限能够修改，试想如果其他节点也能修改的话，这将会导致数据不一致的问题。
Data Node 节点：这个节点从字面上就很容易理解，数据节点，这个节点主要负责数据的存储，在数据扩展上起到了至关重要的作用。也就是说读写数据都会找到相应的 Data Node 节点。
Coordinating Node 节点：协调节点主要负责协调客户端的请求，将接收到的请求分发给合适的节点，并把结果汇集到一起。比如客户端请求查询某个索引的数据，协调节点将会把请求分发给保存相关的数据的 DataNode 节点，找到相应的分片，并把查询到的结果都汇集返回。并且每个节点都默认起到了 Coordinating Node 的职责。
Ingest Node: Ingest node 专门对索引的文档做预处理,发生在对真实文档建立索引之前。在建立索引对文档预处理之前，先定义一个管道（pipeline），管道里指定了一系列的处理器。每个处理器能够把文档按照某种特定的方式转换。比如在管道里定义一个从某个文档中移除字段的处理器，紧接着一个重命名字段的处理器。集群的状态也会被存储到配置的管道内。
定义一个管道，简单的在索引或者bulk request(一种批量请求方法)操作上定义 pipeline 参数,这样 ingest node 就会知道哪个管道在使用。这个节点在使用过程中用的也不多，所以大概了解一下就行。
小结
本次课讲述了 ES 的不同节点角色功能，从简单的单节点 ES 可能会遇到的问题，引述到需要分布式才能解决这些问题，然后分布式需要不同的角色功能协助才能够完成，因此我们明白了为什么 ES 节点需要哪些角色，以及这些角色能起到什么作用？
分片及副本原理
基于 Docker 部署单节点 ElasticSearch
基于 Docker 安装 Kibana
基于 Docker 一键式部署分布式 ElasticSearch
Discover 如何查看相应的业务数据
如何筛选只包含某个字段的业务数据
如何自定义的查看某个时间段的数据
折线图绘制过程与应用场景
柱状图绘制过程与应用场景
饼状图绘制过程与应用场景
热力图在数据分析中的应用
主题分析之标签云图
业务分析进阶之脚本字段
高阶时间序列数据可视化
Timelion 在时间序列中的应用
Dashboard 专题数据分析可视化
基于 Rest API 的 ElasticSearch 增删改查（1）
基于 Rest API 的 ElasticSearch 增删改查(（2）
基于 Rest API 的 ElasticSearch 增删改查（3）
如何运用强大的 ElasticSearch 核心 DSL
组合查询怎么玩
如何根据聚合求取各种数值指标
什么是深入嵌套聚合的万用套法
优化 Query 查询效率之 Scroll 查询
优化聚合数据查询效率之 Partition
Python Elasticsearch Client 实战
天气指标监控数据实战
天气指标数据筛选实战
结合指标数据场景优化查询效率实战
Java Elasticsearch Client 实战
基于 Java 进行天气指标数据筛选实战
基于Java 优化效率查询实战
基于 ELK 天气指标监控在线实时监控案例
基于机器学习的 ElasticSearch 异常值检测案例
基于 MovieLens 的电影搜索案例
阅读全文: http://gitbook.cn/gitchat/column/5e8553f36a28093c950e1614