ElasticSearch

Logstash

Beats

ElasticSearch

Kibana

Es-Hadoop

Elasticsearch基于Lucene打造，全文索引支持多种文本/语言（中文，英文，数字，特殊符号）分词（插入：整个中文搜索领域是非常难的，国内语义搜索方面做的最好的是百度），关键词文本搜索——可应用在企业知识库、电商商品搜索、以及其它垂直搜索业务领域。也就是说，用ES来做的话，只能做到比较初级的----基于分词来做；

如果你要做的更高一层的话,需要了解另外一个领域---机器学习排序模型(LTR)

电商关键词商品搜索，这种引导式的查询，ES已经做得非常好了

目前，在搜索领域，专门做分词的这个领域，项目需求是越来越少，不建议在该领域深挖。当然，这里整理了一下，文本分词涉及到的技术点--文本分词深入探查：

地理位置应用搜索，集成Geohash算法，支持大规模的地理位置搜索，结合自生的分布式特性，可以满足海量数据Geo检索。应用在大规模的轨迹项目上，如：物流汽车运输领域，快速检索出汽车历史轨迹路径范围。 据了解，早期，滴滴用的是MongDB来进行大规模的Geo查询，现在，有了ES之后，完全没有必要

向量检索，跟机器学习或人工智能有点挂钩，Elasticsearch内置Dense Vector字段类型，借助三方向量产品可以将文字、语音、图片、视频等转换为一个向量坐标，存储在ES中，供业务进行相似性与相关度检索，应用在图片相似、类似语音、问答系统、推荐系统领域。

关系型数据库有严格的事务特性，能保证数据的可靠性，但在应对海量数据查询方面比较弱，分库分表只是解决了存储的问题，并没有解决分库分表合并查询，海量数据查询，复杂条件组合查询等关系型数据库的查询性能瓶颈问题。业界通用的做法会采用DB+ES混合的策略，将数据实时同步到Elasticserch中。
另外，在关系型数据库里面，比如有张表，数据量已经有几千万了，这张表有几百个字段，我要基于任何字段都可以自由组合查询，并且顺序不定，此时索引不管你怎么优化，关系型数据库都是无能为力的。此时，就可以用ES来解决，所有的字段，都给你建立索引--全量索引。

关系数据库与ES怎么结合的呢？

大数据领域，其实算是ES发展的一个方向吧。其强大的数据处理能力，提供Hadoop对外的数据查询服务；通过其自带的大数据处理能力---聚合，转换，上卷， 大规模明细查询。ES非常擅长海量数据查询，大数据计算平台将海量数据经过计算之后，需要把最终的结果数据或者半结果数据存储起来，提供外部查询，传统的做法会选择关系型数据库承载，很容易到达性能瓶颈，此时会搭配Elasticsearch替代；另外ES自有生态也可以进行数据的计算，如：简单场景的数据实时计算，可以直接基于聚合实现。
下面用一副Hadoop+Es混合大数据解决方案场景图，来表明一下ES的地位。

统一日志平台，采集所有日志，系统日志，程序日志，业务日志；也可以存储所有类型日志----因为ES它是不限制表类型的，可以自由组织架构的这种结构，不限制表的这种结构类型的；查询所有日志----因为它的索引算法相当厉害；分析所有日志----因为它有自带的大数据的处理能力，可以做一些简单的分析图表，告警之类的工作；ES非常适合海量日志存储查询，早已成为业界通用日志平台的代名词，只要遇到日志查询分析需求，第一时间想到的就是ELK。

下面是一些ES已经支持的一些基础中间件的日志采集，都自带可以直接采集的组件，不需要我们过多的去编写规则，只需要指定目录文件位置，命名就可以啦。

在基础监控领域，有很多成熟有名的产品，Elastic Stack作为后期之秀快速崛起，得益于其通用数据平台能力，其它基础监控产品多数仅支持指标数据，不支持其它类型，而ES几乎一网打尽，尽量使用一个通用平台搞定所有的监控需求。ES进行指标采集之后， 又可以通过设置字段的排序，把它变成一个时序数据库。如下图用的是ES自带的产品的基础监控指标

同样的问题，研发人员不仅需要应用程序的监控信息，也需要采集应用程序的运行日志，而这又是Elasitc Stack的优势。在APM应用性能监控方面，ES不是最强的，但是作为一个平台级生态应用，ES可以将监控方面的工作一网打尽，在后面的工作中，在一个平台我就可以完成所有的监控。支持Java/Go/Python/.Net/Node.js/JavaScript。下图展示了Java的接口API调用,，一直到数据库的性能情况。

网络安全分析预测，通过机器学习算法训练，分析预测潜在的网络安全风险。例如，公司有很多人访问很多机器，但是有黑客进来了，我们不知道，但是黑客的行为比较怪异，我们就可以通过ES监测到，从而限制它。Elastic Stack支持多种数据采集，指标数据、文本数据、网络数据等，这些数据组合在一起，可以进行机器学习分析，依据机器学习算法（聚类算法），可以分析出异常点，这个特性非常完美的契合网络安全，可以自动的发现潜在的安全威胁。下图是通过过往数据分析发现某一段时间，数据存在异常行为的异常事件检测分析图。

索引创建规范约束

索引文档数据模型设计

索引设计经验建议

常用字段类型

索引mapping

字段类型自动检测

字段模式设计运用

索引字段设计限制

关联字段类型应用

辅助字段类型应用

地理与图形类型应用

特殊行业字段应用

特殊字段类型应用注意事项

常用数据字段属性应用

高级数据字段属性应用

AQ

索引元数据字段

索引字段静态映射

索引字段动态映射

tips

概述

索引别名深入解读

别名高级使用

索引模板深度使用

索引设计注意事项

索引创建设计总结

索引别名

索引模版

索引mapping

索引写入数据

索引删除数据

运用ElasticStack快速导入数据

数据写入与删除注意事项

参考

了解数据更新过程与内部机制

常用数据更新方式

数据更新并发冲突问题

高级数据更新方式

数据更新注意事项

参考

重建索引的需求背景

常用重建索引的方式

重建任务管控

高级重建索引

远程重建索引

重建索引注意事项

参考

Ingest介绍

常用数据加工Ingest

高级数据加工Ingest

Enrich处理运用

注意事项

参考

GET查询模式

SEARCH查询模式

DSL查询方式

查询注意事项

参考

组合查询

范围查询

关联查询

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

参考

ES日志设置

ES审计日志

ES slowlog

filebeat日志采集

基础环境启动检查

CAT接口

CAT-Shard接口

集群分布explain接口

分片修复移除

和关系型DB的对比

集群Cluster

节点Node

索引

分片

Segment分段

文档

字段

词项

借鉴参考

1. 倒排索引（Inverted Index）

2. Doc Value列式存储

3. FST有限状态转换

4. Skip List跳表

5. BKD_Tree多维空间树

6. 压缩位图（RoaringBitmap）

7. TF/IDF/BM25分值计算

8. Raft分布式共识

延迟写策略

refresh

flush

虽然通过延时写的策略可以减少数据往磁盘上写的次数，提升了整体的写入能力，但是我们知道文件缓存系统也是内存空间，属于操作系统的内存，只要是内存都存在断电或异常情况下丢失数据的危险。

为了避免丢失数据，Elasticsearch 添加了事务日志（Translog），事务日志记录了所有还没有持久化到磁盘的数据。添加了事务日志后整个写索引的流程如下图所示。

一个新文档被索引（动词）之后，先被写入到内存中，但是为了防止数据的丢失，会追加一份数据到事务日志中。不断有新的文档被写入到内存，同时也会不断被记录到事务日志中。这时新数据还不能被检索和查询。

当达到默认的刷新时间或内存中的数据达到一定量后，会触发一次 refresh，将内存中的数据以一个新段形式刷新到文件缓存系统中并清空内存。这时虽然新段未被提交到磁盘，但是可以提供文档的检索功能且不能被修改。

随着新文档索引不断被写入，当日志数据大小超过 512M 或者时间超过 30 分钟时，会触发一次 flush。内存中的数据被写入到一个新段同时被写入到文件缓存系统，文件系统缓存中数据通过 fsync 刷新到磁盘中，生成提交点，日志文件被删除，创建一个空的新日志。

与添加文档的过程类似

删除，由于不可修改，所以对于删除操作，不会把文档从旧的段中移除，而是通过新增一个 .del 文件，文件中会列出这些被删除文档的段信息。

更新，不能修改旧的段来进行反映文档的更新，其实更新相当于是删除和新增这两个动作组成。

先写入内存 buffer，在 buffer 里的时候数据是搜索不到的；同时将数据写入 translog 日志文件。

如果 buffer 快满了，或者到一定时间，就会将内存 buffer 数据 refresh 到一个新的 segment file 中，但是此时数据不是直接进入 segment file 磁盘文件，而是先进入 os cache。这个过程就是 refresh。

每隔 1 秒钟，es 将 buffer 中的数据写入一个新的 segment file，每秒钟会写入一个新的 segment file，这个 segment file 中就存储最近 1 秒内 buffer 中写入的数据。

由于自动刷新流程（refresh）每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦，比如每一个段都会消耗文件句柄、内存和 cpu 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段然后合并查询结果，所以段越多，搜索也就越慢。

Elasticsearch 通过在后台定期进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档不会被拷贝到新的大段中。合并的过程中不会中断索引和搜索。

段合并在进行索引和搜索时会自动进行，合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中，这些段既可以是未提交的也可以是已提交的。合并结束后老的段会被删除，新的段被 flush 到磁盘，同时写入一个包含新段且排除旧的和较小的段的新提交点，新的段被打开可以用来搜索。

段合并的计算量庞大， 而且还要吃掉大量磁盘 I/O，段合并会拖累写入速率，如果任其发展会影响搜索性能。Elasticsearch 在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。

Flink它是一个实时的计算流引擎，那我们在做很多数据处理的时候，把上游的数据都存到Kafka，通过Flink做一些大规模的数据解析，解析完之后，要存储起来，供外界查询，这时候，可以选择用ES来承载，ES的分布式存储能力非常强

nifi它是一个平台化的ETL数据处理产品，跟ES官方自己的Logstash对比的化，它的好处就是可视化，平台化，可以采用多线程，多并行的这种策略，去做很多工作，比原来的Logstash，要复杂一点，但是要强大不少。现已经被Hadoop这个生态，集成到里面去了

支持很多种数据源，可以直接连接ES，它本身是一个UI界面，连接ES之后，可以去做一些告警；当然它最重要的一点是，图形化做的非常的漂亮。现在业界，做监控的非常漂亮的图表，基本都会用Grafana去做。

我们知道Hive是FaceBook开发，做纯离线的数据处理的，速度比较慢，随便运行个脚本（一个Sql查询）都要很久。为了解决这个问题，FaceBook又开发了一个presto这样一个查询引擎，它是一个纯内存式的，交互式的，很方便的去跟很多种数据源交互，假设我们需要把ES两个表的数据，做一些join分析，那怎么办呢？你可以用Spark，需要写很多Spark的代码，然后去编译，编译后还要上传，然后还要调度运行，这个过程是很麻烦的，如果我们用presto的话，直接可以去连接ES集群，连接之后，把它的表映射过来，当成两张不同的表映射，非常的快。

和nifi非常相似，也是一个可视化的ETL产品，现在有很多大数据工程师，它做的一个工作，就是利用nifi或者StreamSets来做。

ES和Cassandra的混合，Cassandra是一个非常强大的列式数据库，再做key-value查询是非常快的，但是再做条件式查询时，性能不行。所以业界会选择用ES来承载。传统来说，你得搭建一个Cassandra/Hbase的集群，第二个你得搭建一个ES的集群，中间你还得写个程序把数据同步过来，这个过程对大多数人来说，非常痛苦，要掌握两个数据产品，另外，同步也是一个非常头痛的事情。通过这套产品，这些问题，都解决了。当然，功能上，可能会有一些限制，ES的更新，升级并没有那么快。