ES八大最佳实践.pdf

目录目录Elasticsearch对垒8大产品技术，孰优孰劣？04ES既是搜索引擎又是数据库？真的有那么全能吗？15DB 与 Elasticsearch 混合之应用系统场景分析探讨26初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理34Transforms数据透视让Elasticsearch数据更易分析45Observability：使用 Elastic Stack 分析地理空间数据59阿里云 Elasticsearch 向量检索，轻松玩转29个业务场景79阿里云 Elasticsearch 索引数据生命周期管理86PB级数据量背后阿里云 Elasticsearch 的内核优化实践96一次有趣的Elasticsearch+矩阵变换聚合实践108简介：简要用Elasticsearch与其它8种数据产品做了个对比，基于很多业务场景对比，代表了笔者对于Elasticsearch优胜劣汰的看法Elasticsearch对垒8大产品技术，孰优孰劣？Elasticsearch对垒8大产品技术，孰优孰劣？竞争产品竞争产品Elasticseach 从做搜索引擎开始，到现在主攻大数据分析领域，逐步进化成了一个全能型的数据产品，在 Elasticsearch 诸多优秀的功能中，与很多数据产品有越来越多的交叉竞争，有的功能很有特色，有的功能只是附带，了解这些产品特点有助于更好的应用于业务需求。1、LuceneLucene 是一个搜索的核心库，Elastic 也是在 Lucene 基础之上构建，它们之间的竞争关系是由 Lucene 本身决定的。在互联网 2.0 时代，考验各互联网公司最简单的技术要求，就是看他们的搜索做的怎么样，那时大家的做法几乎一样，都基于 Lucene 核心库构建一套搜索引擎，剩下的就看各公司的开发者们的水平。笔者有幸在 2012 年之前，基于 Lucene 做过垂直行业的搜索引擎，遇到很多问题有必要说一下：Elasticsearch对垒8大产品技术，孰优孰劣？Elasticsearch对垒8大产品技术，孰优孰劣？2、SolrSolr 是第一个基于 Lucene 核心库功能完备的搜索引擎产品，诞生远早于Elasticsearch，早期在全文搜索领域，Solr 有非常大的优势，几乎完全压倒 Elastic，在近几年大数据发展时代，Elastic由于其分布式特性，满足了很多大数据的处理需求，特别是后面 ELK 这个概念的流行，几乎完全忘记了 Solr 的存在，虽然也推出了 Solr-Coud 分布式产品，但已经基本无优势。接触过几个数据类公司，全文搜索都基于 Solr 构建，且是单节点模式，偶然出现一些问题，找咨询顾问排查问题，人员难找，后面都迁移到 Elasticsearch 之上。现在市面上几乎大大小小公司都在使用 Elasticsearch，除了老旧系统有的基于 Solr的，新系统项目应该全部是 Elasticsearch。个人认为有以下几个原因：ES 比 Solr 更加友好简洁，门槛更低。ES 比 Solr 产品功能特点更加丰富，分片机制，数据分析能力。ES 生态发展，Elastic-stack 整个技术栈相当全，与各种数据系统都很容易集成。ES 社区发展更加活跃，Solr 几乎没有专门的技术分析大会。本次竞争中，本次竞争中，Elasticsearch 完胜。完胜。Elasticsearch对垒8大产品技术，孰优孰劣？Elasticsearch对垒8大产品技术，孰优孰劣？4、OpenTSDBOpenTSDB 内部基于 HBase 实现，属于时间序列数据库，主要针对具有时间特性和需求的数据，进行过数据结构的优化和处理，从而适合存储具有时间特性的数据，如监控数据、温度变化数据等，小米公司开源监控体系 open-falcon 的就是基于 OpenTSDB 实现。Elastic 产品本身无意时间序列这个领域，随着 ELK 的流行，很多公司采用 ELK 来构建监控体系，虽然在数值类型上不像时间序列数据库做过特别处理，但由于其便利的使用，以及生态技术栈的优势，我们也接受了这样的事实。Elasticsearch 构建时间序列很简单，性能也相当不错：索引创建规则，可以按年、按月、按周、按星期、按天、按小时等都创建索引，非常便利。数据填充方面，定制一个时间字段做区分排序，其余的字段无需。数据查询方面，除了按实际序列查询外，还可以有更多的搜索条件。除非对于时间序列数据有非常苛刻的监控需求，否则选择 Elasticsearch 会更加合适一些。5、HBaseHBase 是列式数据库的代表，其内部有几个致命设计大大限制了它的应用范围：访问 HBase 数据只能基于 Rowkey，Rowkey 设计的好坏直接决定了 HBase 使用优劣。本身不支持二级索引，若要实现，则需要引入第三方。Elasticsearch对垒8大产品技术，孰优孰劣？Elasticsearch对垒8大产品技术，孰优孰劣？超出这个定位，则 Elasticsearh 相比 MongoDB 有如下优点：文档查询性能，倒排索引/KDB-Tree 比 B+Tree 厉害。数据的聚合分析能力，ES本身提供了列式数据 doc_value，比 Mongo 的行式要快不少。集群分片副本机制，ES架构设计更胜一筹。ES 特色功能比 MongoDB 提供的更多，适用的场景范围更宽泛。文档数据样例，ObjectId 由 MongoDB 内置自动生成。公司刚好有个项目，原来数据层基于 MongoDB 设计构建的，查询问题不少，后面成功迁移到 Elasticsearch 平台上，服务器数据量从15台降低到3台，查询性能还大幅度提升十倍，详细可阅读笔者另一篇文章从 MongoDB 迁移到 ES 后，我们减少了80%的服务器抛开数据事务隔离，Elasticsearch 可以完全替代 MongoDB。Elasticsearch对垒8大产品技术，孰优孰劣？Elasticsearch对垒8大产品技术，孰优孰劣？8、DruidDurid 是一个大数据 MPP 查询型数据产品，核心功能 Rollup，所有的需要 Rollup 原始数据必须带有时间序列字段。Elasticsearch 在 6.3.X 版本之后推出了此功能，此时两者产品形成竞争关系，谁高谁下，看应用场景需求。Druid 样本数据，必须带有 time 时间字段。笔者之前负责过公司所有 Elasticsearch 技术栈相关数据项目，当时也有碰到一些实时聚合查询返回部分数据的需求，但我们的需求不太一样，索引数据属于离线型更新，每天都会全部删除并重新创建索引插入数据，此时使用 Elastic 的版本是 6.8.X，仅支持离线型数据 Rollup，所以此功能没用上，Elastic 在 7.2.X 版本之后才推出实时 Rollup 功能。Druid 更加专注，产品设计围绕 Rollup 展开，Elastic 只是附带；Druid 支持多种外接数据，直接可以对接 Kafka 数据流，也可以直接对接平台自身内部数据；而 Elastic 仅支持内部索引数据，外部数据需要借助三方工具导入到索引里；Druid 在数据 Rollup 之后，会丢弃原始数据；Elastic 在原有索引基础之后，生成新的Rollup 之后的索引数据；Druid 与 Elastic 的技术架构非常类似，都支持节点职责分离，都支持横向扩展；Druid 与 Elastic 在数据模型上都支持倒排索引，基于此的搜索与过滤。Elasticsearch对垒8大产品技术，孰优孰劣？ES既是搜索引擎又是数据库？真的有那么全能吗？ES既是搜索引擎又是数据库？真的有那么全能吗？作者介绍：李猛(ynuosoft)，Elastic-stack产品深度用户，ES认证工程师，2012年接触Elasticsearch，对Elastic-Stack开发、架构、运维等方面有深入体验，实践过多种Elasticsearch项目，最暴力的大数据分析应用，最复杂的业务系统应用；业余为企业提供Elastic-stack咨询培训以及调优实施。ES认知认知1、ES是什么是什么1）Elasticsearch是搜索引擎是搜索引擎Elasticsearch在搜索引擎数据库领域排名绝对第一，内核基于Lucene构建，支持全文搜索是职责所在，提供了丰富友好的API。个人早期基于Lucene构建搜索应用，需要考虑的因素太多，自接触到Elasticsearch就再无自主开发搜索应用。普通工程师要想掌控Lucene需要一些代价，且很多机制并不完善，需要做大量的周边辅助程序，而Elasticsearch几乎都已经帮你做完了。2）Elasticsearch不是搜索引擎不是搜索引擎说它不是搜索引擎，估计很多从业者不认可，在个人涉及到的项目中，传统意义上用Elasticsearch来做全文检索的项目占比越来越少，多数时候是用来做精确查询加速，查询条件很多，可以任意组合，查询速度很快，替代其它很多数据库复杂条件查询的场景需求；甚至有的数据库产品直接使用Elasticsearch做二级索引，如HBase、Redis等。Elasticsearch由于自身的一些特性，更像一个多模数据库。ES既是搜索引擎又是数据库？真的有那么全能吗？ES既是搜索引擎又是数据库？真的有那么全能吗？2应用查询应用查询Elasticsearch最擅长的就是查询，基于倒排索引核心算法，查询性能强于B-Tree类型所有数据产品，尤其是关系型数据库方面。当数据量超过千万或者上亿时，数据检索的效率非常明显。个人更看中的是Elasticsearch在通用查询应用场景，关系型数据库由于索引的左侧原则限制，索引执行必须有严格的顺序，如果查询字段很少，可以通过创建少量索引提高查询性能，如果查询字段很多且字段无序，那索引就失去了意义；相反Elasticsearch是默认全部字段都会创建索引，且全部字段查询无需保证顺序，所以我们在业务应用系统中，大量用Elasticsearch替代关系型数据库做通用查询，自此之后对于关系型数据库的查询就很排斥，除了最简单的查询，其余的复杂条件查询全部走Elasticsearch。3）大数据领域大数据领域Elasticserach已经成为大数据平台对外提供查询的重要组成部分之一。大数据平台将原始数据经过迭代计算，之后结果输出到一个数据库提供查询，特别是大批量的明细数据。这里会面临几个问题，一个问题是大批量明细数据的输出，如何能在极短的时间内写到数据库，传统上很多数据平台选择关系型数据库提供查询，比如MySQL，之前在这方面吃过不少亏，瞬间写入性能极差，根本无法满足要求。另一个问题是对外查询，如何能像应用系统一样提供性能极好的查询，不限制查询条件，不限制字段顺序，支持较高的并发，支持海量数据快速检索，也只有Elasticsearch能够做到比较均衡的检索。从官方的发布版本新特性来看，Elasticseacrch志在大数据分析领域，提供了基于列示存储的数据聚合，支持的聚合功能非常多，性能表现也不错，笔者有幸之前大规模深度使用过，颇有感受。Elasticsearch为了深入数据分析领域，产品又提供了数据Rollup与数据Transform功能，让检索分析更上一层楼。在数据Rollup领域，Apache Druid的竞争能力很强，笔者之前ES既是搜索引擎又是数据库？真的有那么全能吗？ES既是搜索引擎又是数据库？真的有那么全能吗？6）机器学习机器学习机器学习最近几年风吹的很大，很多数据产品都集成了，Elasticsearch也必须有，而且做的更好，真正将机器学习落地成为一个产品，简化使用，所见所得；而不像其它数据产品，仅仅集成算法包，使用者还必须开发很多应用支持。Elasticsearch机器学习提供了两种方式，一种是异常检测类型，属于无监督学习，采用聚类模型，通常应用在安全分析领域，检测异常访问等；一种是数据帧分析，属于分类与回归，属于监督学习，可用于在业务模型领域，如电商行业，价格模型分析。Elasticsearch本身是数据平台，集成了部分机器学习算法，同时又集成了Kibana可视化操作，使得从数据采集、到模型训练、到模型预测应用都可以一键式完成Elasticserach提供的机器学习套件，个人认为最应该应用在数据质量这个领域，帮助大数据平台自动检测数据质量，从而降低人力提供效率。ES既是搜索引擎又是数据库？真的有那么全能吗？ES既是搜索引擎又是数据库？真的有那么全能吗？图示：Elasticsearch核心概念2、开发开发开发工程师的职责是将需求变成可以落地运行的代码。Elasticsearch的应用开发工作总结起来就是增删改查，掌握必备的ES REST API，熟练运用足以。笔者之前任职某物流速运公司，负责Elasticsearch相关的工作，公司Elasticsearch的需求很多，尤其是查询方面，ES最厉害的查询是DSL，这个查询语法需要经常练习使用，否则很容易忘记，当每次有人询问时，都安排一个工程师专门负责各种解答，他在编写DSL方面非常熟练，帮助了很多的工程师新手使用Elasticsearch，屏蔽了很多细节，若有一些难搞定的问题，会由我来解决，另外一方面作为负责人的我偶然还要请他帮忙编写DSL。Elasticsearch后面提供了SQL查询的功能，但比较局限，复杂的查询聚合必须回到DSL。ES既是搜索引擎又是数据库？真的有那么全能吗？ES既是搜索引擎又是数据库？真的有那么全能吗？如果把Elasticsearch比喻为一件军事武器，对于士兵来说，熟练运用才是最重要的，至于改造应该是武器制造商的职责，一个士兵可以使用很多武器装备，用最佳的组合才能打赢一场战争，而不是去深入原理然后造轮子，容易本末倒置。6、算法、算法算法应该算是数据产品本质的区别，关系型数据库索引算法主要是基于B-Tree，Elasticserach索引算法主要是倒排索引，算法的本质决定了它们的应用边界，擅长的应用领域。通常掌握一个新的数据产品时，个人的做法是看它的关键算法。早期做过一个地理位置搜索相关的项目，基于某个坐标搜索周边的坐标信息，开始的时候采用的是三角函数动态计算的方式，数据量大一点，扫描一张数据表要很久；后面接触到Geohash算法，按照算法将坐标编码，存储在数据库中，基于前缀匹配查询，性能高效几个数量级，感叹算法的伟大；再后面发现有专门的数据库产品集成了Geohash算法，使用起来就更简单了。Elasticsearch集成很多算法，每种算法实现都有它的应用场景。拥抱拥抱ES的方法的方法1、官方文档、官方文档Elasticsearch早期出过一本参考手册Elastic权威指南，是一本很好的入门手册，从概念到实战都有涉及，缺点是版本针对的2.0，过于陈旧，除去核心概念，其余的皆不适用，当前最新版本已经是7.7了，跨度太大，Elasticsearch在跨度大的版本之间升级稍微比较麻烦，索引数据几乎是不兼容的，升级之后需要重建数据才可。Elasticsearch当前最好的参考资料是官方文档，资料最全，同步发布版本，且同时可以参考多个版本。Elasticsearch官方参考文档也是最乱的，什么资料都有，系统的看完之后感觉仍在此山中，有点类似一本字典，看完了字典，依然写不好作文；而且资料还是英文的，至此就阻挡了国内大部分程序进入。但想要学习Elasticsearch，官方文档至少要看过几遍，便于迅速查询定位。ES既是搜索引擎又是数据库？真的有那么全能吗？ES既是搜索引擎又是数据库？真的有那么全能吗？日志领域的需求会让你对于数据写入量非常的关心，不断的调整优化策略，提高吞吐量，降低资源消耗；业务系统的需求会让你对数据一致性与时效性特别关心，从其它数据库同步到ES，关注数据同步的速度，关注数据的准确性，不断的调整你的技术方案与策略；大数据领域的需求会让你对于查询与聚合特别关注，海量的数据需要快速的检索，也需要快速的聚合结果。项目实战的过程，就是一个挖坑填坑的过程，实战场景多了，解决的问题多了，自然就掌握得很好了。之前笔者在前公司任职时，所有涉及到的Elasticsearch疑难杂症都会找我解决，有一些项目采用别的数据产品问题比较多，也来找我评估更换ES是否合适，以及给出相关建议。笔者认为最好的学习方式是找到组织，找到经验丰富的大咖，持续交流学习，成长最快也最好。简介：从技术、业务两个层面探讨，为什么要使用 DB 结合 ES 混用的模式。DB 与 Elasticsearch 混合之应用系统场景分析探讨 DB 与 Elasticsearch 混合之应用系统场景分析探讨索引：索引：在关系型数据库中是指数据检索的算法，在 Elasticsearch 是指数据存储的虚拟空间概念，类同数据库中的表。背景需求背景需求 为什么单一 DB 不能满足应用系统？为什么单一 ES 不能满足应用系统？为什么要使用 DB 结合 ES 混用的模式？而不是结合其它 NoSQL？比如 MongoDB？下面从技术层面与业务层面分析探讨。技术层面技术层面DB 局限性局限性关系型数据库索引基于最左优先原则，索引要按照查询需求顺序提前创建，不具备任意字段组合索引能力比如 某 xxx 表有 30 个字段，若要求依据任意字段组合条件查询，此时关系型数据库显然无法满足这种灵活需求，包括当下很受欢迎的 NoSQL 明星产品Mongodb 也不能满足。关系型数据库支持有限度的关联查询，一般在业务应用系统中，关联表会控制在 23 个表（个人观点：有 3 个表关联的业务场景需要由技术架构师评估是否容许，开发工程师只容许 2 个表关联），且单表的数据量是要平衡考虑才可以，跨同构数据库源关联就更加不容许。那跨异构数据库源呢？不是不容许，实在是有心无力。关系型数据库普遍采用 B+树数据结构实现索引查询，面对超大数据量处理有天然的瓶颈，数据量超过百万千万级，复杂点的查询，性能下降很快，甚至无法运行。DB 与 Elasticsearch 混合之应用系统场景分析探讨 DB 与 Elasticsearch 混合之应用系统场景分析探讨业务层面业务层面业务领域复杂度业务领域复杂度在进入互联网/移动互联网/物联网之后，业务系统数据量的几何倍数增长，传统应当策略当然是采用分库分表机制，包括物理层面分库分表，逻辑层面分区等。非重要数据可以采用非关系型数据库存储，重要的业务数据一定是采用关系数据库存储，比如物流速运行业的客户订单数据，不容许有丢失出错。面对复杂业务系统需求，当下最流行的解决方式是采用微服务架构模式，微服务不仅仅局限上层应用服务，更深层次的是底层数据服务（微服务不在本次讨论之内），基于领域模型思维拆分分解。应用服务拆分成大大小小数个可以几十个几百个，也可以更多，数据服务也拆分成大大小小数个。业务查询复杂度业务查询复杂度分库分表解决了数据的存储问题，但需要做合并查询却是个很麻烦的事，业务系统的查询条件一般是动态的，无法固定，更加不可能在分库分表时按照所有动态条件设计，这似乎代价太大。一般会选择更强大的查询数据库，比如 Elasticsearch 就非常合适。微服务架构模式解决了业务系统的单一耦合问题，但业务系统的查询复杂度确实提高不少，复杂点的应用服务执行一次查询，需要融合多个领域数据服务才能完成，特别是核心领域数据服务，几乎贯穿一个系统所有方面，比如物流速运行业订单领域。DB 与与 ES 结合结合业务数据存储由关系型数据库负责，有强事务隔离机制，保障数据不丢失、不串乱、不覆盖，实时可靠。业务数据查询由 Elasticsearch 负责，分库分表的数据合并同步到 ES 索引；跨领域库表数据合并到同步 ES 索引，这样就可以高效查询。DB 与 Elasticsearch 混合之应用系统场景分析探讨 单索引单索引31 DB 与 Elasticsearch 混合之应用系统场景分析探讨1）一对一映射关系，关系数据库有多少个表，Elasticsearch 就有多少个索引；2）关系数据库提供原始数据源，Elasticsearch 替代数据库成为查询引擎，替代列表查询场景；3）单数据表为水平分库分表设计，需要借助Elasticsearch 合并查询，如图：电商行业订单场景，日均订单量超过百万千万级，后端业务系统有需求合并查询；4）单数据表业务查询组合条件多，数据库索引查询能力局限，需要借助 Elasticsearch 全字段索引查询能力，主要替代列表查询场景。如：电商行业商品搜索场景，商品基础字段超过几十个，几乎全部都可以组合搜索。单数据表单数据表-多索引多索引1）一对多映射关系，单数据表映射到多个索引中；2）单数据表即作为 A索引的主体对象，一对一映射；3）单数据表也作为 B索引的子对象，嵌入到主体对象下面；4）基于微服务架构设计，在业务系统中，业务系统划分多个子领域，子领域也可以继续细分，如电商行业，订单领域与商品领域，订单表需要映射到订单索引，也需要与商品索引映射。DB 与 Elasticsearch 混合之应用系统场景分析探讨 多索引多索引1）多对多映射关系，多个数据表映射到多个索引，复杂度高；2）一个中型以上的业务系统，会划分成多个领域，单领域会持续细分为多个子领域，领域之间会形成网状关系，业务数据相互关联；3）数据库表关联查询效率低，跨库查询能力局限，需要借助 Elasticsearch 合并；4）按照领域需求不同，合并为不同的索引文件，各索引应用会有差异，部分是通用型的，面向多个领域公用；部分是特殊型的，面向单个领域专用。33 DB 与 Elasticsearch 混合之应用系统场景分析探讨多源数据表多源数据表-多索引多索引1）多源多表，多对多映射关系，数据表与索引之间的映射关系是交叉型的，复杂度最高；2）一个大中型业务系统，不同的业务场景会采用不同的数据存储系统；3）关系型数据库多样化，如 A 项目采用 MySQL，B 项目采用 PostgreSQL，C 项目选用 SQLServer，业务系统通用型的查询几乎不能实现；4）非关系型数据库多样化，如 A 项目采用键值类型的 Redis，B 项目选用文档型的MongoDB，业务系统同样也不能实现通用型查询；5）基于异构数据源通用查询的场景需求，同样需要借助 Elasticsearch 合并数据实现。结语结语Elasticsearch 虽然早期定位是搜索引擎类产品，后期定位数据分析类产品，属于 NoSQL阵营，且不支持严格事务隔离机制，但由于其先进的特性，在应用系统中也是可以大规模使用，能有效弥补了关系型数据库的不足。本文主旨探讨了 DB 与 ES 混合的需求背景与应用场景，目的不是评选 DB 与 ES 谁更优劣，是要学会掌握 DB 与 ES 平衡，更加灵活的运用到应用系统中去，满足不同的应用场景需求，解决业务需求问题才是评判的标准。简介：命名有包含搜索关键词的文档，但结果却没有？存进去的文档被分成哪些词(term)了？自定义分词规则，但感觉好麻烦呢，无从下手？初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理 初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理然后我们做一个查询，我们试图通过搜索 eat这个关键词来搜索这个文档1.1.POST test/_search2.3.query:4.match:5.msg:eat6.7.8.9.ES的返回结果为0。这不太对啊，我们用最基本的字符串查找也应该能匹配到上面新建的文档才对啊！各位不要急，我们先来看看什么是分词。二、二、分词分词搜索引擎的核心是倒排索引（这里不展开讲），而倒排索引的基础就是分词。所谓分词可以简单理解为将一个完整的句子切割为一个个单词的过程。在 es 中单词对应英文为term。我们简单看个例子初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理 初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理三、三、写时分词结果写时分词结果回到上手阶段，我们来看下写入的文档最终分词结果是什么。通过如下 api 可以查看：1.POST test/_analyze2.3.field:msg,4.text:Eating an apple a day keeps doctor away5.其中 test为索引名，_analyze 为查看分词结果的 endpoint，请求体中 field 为要查看的字段名，text为具体值。该 api 的作用就是请告诉我在 test 索引使用 msg 字段存储一段文本时，es 会如何分词。返回结果如下:6.7.tokens:8.9.token:eating,10.start_offset:0,11.end_offset:6,12.type:,13.position:014.,15.16.token:an,17.start_offset:7,18.end_offset:9,19.type:,20.position:121.,22.23.token:apple,初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理 3824.start_offset:10,25.end_offset:15,26.type:,27.position:228.,29.30.token:a,31.start_offset:16,32.end_offset:17,33.type:,34.position:335.,36.37.token:day,38.start_offset:18,39.end_offset:21,40.type:,41.position:442.,43.44.token:keeps,45.start_offset:22,46.end_offset:27,47.type:,48.position:549.,50.51.token:doctor,52.start_offset:28,53.end_offset:34,54.type:,55.position:656.,39 初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理57.58.token:away,59.start_offset:35,60.end_offset:39,61.type:,62.position:763.64.65.返回结果中的每一个 token即为分词后的每一个单词，我们可以看到这里是没有 eat 这个单词的，这也解释了在上手中我们搜索 eat 没有结果的情况。如果你去搜索 eating，会有结果返回。写时分词器需要在 mapping 中指定，而且一经指定就不能再修改，若要修改必须新建索引。如下所示我们新建一个名为ms_english 的字段，指定其分词器为 english：1.PUT test/_mapping/doc2.3.properties:4.msg_english:5.type:text,6.analyzer:english7.8.9.四、四、读时分词结果读时分词结果由于读时分词器默认与写时分词器默认保持一致，拿 上手 中的例子，你搜索 msg 字段，那么读时分词器为 Standard，搜索 msg_english 时分词器则为 english。这种默认设定也是非常容易理解的，读写采用一致的分词器，才能尽最大可能保证分词的结果是可以匹配的。初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理 40然后 ES 允许读时分词器单独设置，如下所示：1.POST test/_search2.3.query:4.match:5.msg:6.query:eating,7.analyzer:english8.9.10.11.如上 analyzer 字段即可以自定义读时分词器，一般来讲不需要特别指定读时分词器。如果不单独设置分词器，那么读时分词器的验证方法与写时一致；如果是自定义分词器，那么可以使用如下的 api 来自行验证结果。1.POST _analyze2.3.text:eating,4.analyzer:english5.返回结果如下：1.2.tokens:3.4.token:eat,5.start_offset:0,6.end_offset:6,7.type:,41 初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理8.position:09.10.11.由上可知 english分词器会将 eating处理为 eat，大家可以再测试下默认的 standard分词器，它没有做任何处理。五、五、解释问题解释问题现在我们再来看下 上手 中所遇问题的解决思路。1、查看文档写时分词结果2、查看查询关键词的读时分词结果3、匹对两者是否有命中我们简单分析如下：由上图可以定位问题的原因了。六、六、解决需求解决需求由于 eating只是 eat的一个变形，我们依然希望输入 eat时可以匹配包含 eating的文档，那么该如何解决呢？初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理 初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理由上图可见 english分词器会将 eating分词为 eat，此时我们搜索 eat或者 eating肯定都可以匹配对应的文档了。至此，需求解决。七、七、深入分析深入分析最后我们来看下为什么english分词器可以解决我们遇到的问题。一个分词器由三部分组成：char filter、tokenizer 和 token filter各部分的作用我们这里就不展开了，我们来看下 standard和english分词器的区别。初次使用 Elasticsearch 遇多种分词难题？那是你没掌握这些原理 Transforms数据透视让Elasticsearch数据更易分析Transforms数据透视让Elasticsearch数据更易分析本文作者：Elastic 中国社区布道师刘晓国准备数据准备数据在今天的练习中，我们将以 eCommerce 订单的样本例子来做练习。首先，准备阿里云elasticsearch 6.7 版本环境，并使用创建的账号密码登录Kibana，将数据导入到 Elasticsearch 中：Transforms数据透视让Elasticsearch数据更易分析 Transforms数据透视让Elasticsearch数据更易分析这样我们就完成了 eCommerce 数据的导入。如果您还不熟悉kibana_sample_data_ecommerce索引，请使用Kibana中的 Revenue仪表板浏览数据。考虑一下你可能想从此电子商务数据中获得什么见解:Transforms数据透视让Elasticsearch数据更易分析 Transforms数据透视让Elasticsearch数据更易分析我们点击上面的 Create your firset transform：点击上面的 eCommerce Orders:Transforms数据透视让Elasticsearch数据更易分析 Transforms数据透视让Elasticsearch数据更易分析我们点击当前页面的 Next 按钮：点击上面的 Next：我们点击上面的 Create and start 按钮：Transforms数据透视让Elasticsearch数据更易分析 Transforms数据透视让Elasticsearch数据更易分析我们可以看到所有的转换的细节。我们接下来到 Discover 中去查看我们最新生产的一个索引：ecommerce-customer-sales我们选中 ecommerce-customer-sales 索引：Transforms数据透视让Elasticsearch数据更易分析 Transforms数据透视让Elasticsearch数据更易分析执行上面的指令。然后执行下面的指令：1.PUT _transform/ecommerce_transform2.source:3.index:kibana_sample_data_ecommerce,4.query:5.term:6.geoip.continent_name:7.value:Asia8.9.10.11.,12.pivot:13.group_by:14.customer_id:15.terms:16.field:customer_id17.18.19.,20.aggregations:21.max_price:22.max:23.field:taxful_total_price24.25.26.27.,28.description:Maximum priced ecommerce data by customer_id in Asia,29.dest:Transforms数据透视让Elasticsearch数据更易分析 Transforms数据透视让Elasticsearch数据更易分析从上面我们可以看出来这个 transform 已经被启动，而且是一种在运行的状态。我们可以点击 Stop 来停止这个 transform，如果我们不想运行的话。由于上面的命令没有为新创建的索引 kibana_sample_data_ecommerce_transform 创建一个index pattern，我们需要自己手动来创建一个 index pattern。等我们创建完后，打开 Discover 来查看新的 transform 索引：Transforms数据透视让Elasticsearch数据更易分析 Observability：使用 Elastic Stack 分析地理空间数据Observability：使用 ElasticStack 分析地理空间数据本文作者：Elastic 中国社区布道师刘晓国在之前的文章“Elastic Stack 实现地理空间数据采集与可视化分析”，我详述了如何从OpenSky Network API 接口把数据导入到 Elasticsearch，并对这些数据进行可视化分析。也许针对很对的情况这个已经很满足了，因为它确实可以帮我们从很多实时数据中提取很多有用用用的东西。在今天的文章中，我们将参考之前的文章“如何使用 Elasticsearch ingest 节点来丰富日志和指标”。我们可以利用 Elasticsearch ingest 节点来更加丰富我们的数据，并对这些数据做更进一步的的分析。为了达到这个目的，我们必须首先了解在之前索引中的 icao 字段。这个字段的意思是：ICAO 机场代码或位置指示器是由四个字母组成的代码，用于指定世界各地的机场。这些代码由国际民用航空组织定义并发布在国际民航组织7910号文件：位置指示器中，供空中交通管制和航空公司运营（例如飞行计划）使用。我们之前的每个文档是这样的：Observability：使用 Elastic Stack 分析地理空间数据 Observability：使用 Elastic Stack 分析地理空间数据在上面的表格中，我们发现有一个叫做 icao24 的字段。这个字段和我们之前的文档可以进行关联，从而我们可以得到更多关于某个航班的更多信息。创建创建 enrich index由于下载的文档时一个是一个 csv 的文件。我们可以使用 data visualizer 来导入。Observability：使用 Elastic Stack 分析地理空间数据 Observability：使用 Elastic Stack 分析地理空间数据点击上面的 Import 按钮：我们把这个索引的名字称作为 aircraft。点击 Advaned:Observability：使用 Elastic Stack 分析地理空间数据 Observability：使用 Elastic Stack 分析地理空间数据等完成后，我们可以在 Elasticsearch 中找到一个叫做 aircraft 的索引：GET _cat/indices上面显示有一