Elaticsearch基本概念及架构原理
Posted 金融大数据分析应用
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Elaticsearch基本概念及架构原理相关的知识，希望对你有一定的参考价值。
“ Elaticsearch基本概念及架构原理。”
一、ES概述
Elaticsearch，简称为ES， ES是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据;本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。ES也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。
Elaticsearch是面向文档的，这意味着它可以存储整个对象或文档(document)。然而它不仅仅是存储，还会索引(index)每个文档的内容使之可以被搜索。在Elasticsearch中，你可以对文档(而非成行成列的数据)进行索引、搜索、排序、过滤。
ES设计的理念是分布式搜索引擎，底层实现基于Lucene，核心思想是在多台机器上启动多个ES进程实例，组成一个ES集群。
二、ES 分布式架构原理
最底层Gateway是ES用来存储索引的文件系统，支持多种类型。Gateway的上层是一个分布式的lucene框架。
Lucene之上是ES的模块，包括：索引模块、搜索模块、映射解析模块等。ES模块之上是 Discovery、Scripting和第三方插件。
Discovery是ES的节点发现模块，不同机器上的ES节点要组成集群需要进行消息通信，集群内部需要选举master节点，这些工作都是由Discovery模块完成。支持多种发现机制，如 Zen 、EC2、gce、Azure。
Scripting用来支持在查询语句中插入javascript、python等脚本语言，scripting模块负责解析这些脚本，使用脚本语句性能稍低。ES也支持多种第三方插件。
再上层是ES的传输模块和JMX。传输模块支持多种传输协议，如 Thrift、memecached、http，默认使用http。JMX是java的管理框架，用来管理ES应用。最上层是ES提供给用户的接口，可以通过RESTful接口和ES集群进行交互。
Elasticsearch核心概念
接近实时：ES是一个接近实时的搜索平台，这就意味着，从存入一个文档直到文档能够被搜索到有一个轻微的延迟。
集群（cluster）：一个集群由多个节点（服务器）组成，所有节点一起保存全部数据，每一个集群有一个唯一的名称标识
节点（node）：一个节点是一个单一的服务器，是集群的一部分，它存储数据并且参与集群的搜索功能，一个节点可以通过配置特定的名称来加入特定的集群，在一个集群中，你想启动多少个节点就可以启动多少个节点。
索引（index） ：一个索引是含有某些共有特性的文档的集合，一个索引被一个名称唯一的标识，通过这个名称去文档中进行搜索、更新和删除操作。
类型（type）：一个index里可以有多个type，一个type就相当于数据库中的一张表。
文档（document） ：一个文档是一个基本的搜索单元。
总结：
ES中存储数据的基本单位是索引，比如说ES中存储了一些订单系统的销售数据，就应该在ES中创建一个索引order_index，所有的销售数据都会写到这个索引里面去，一个索引就像一个数据库，而type就相当于库里的表，一个index里面可以有多个type，而mapping就相当于表的结构定义，定义了字段的类型等，往index的一个type里添加一行数据，这行数据就叫做一个document，每个document有多个filed，每一个filed就代表这个document的一个字段的值。
分片（shards）：在一个搜索引擎里存储的数据，潜在的情况下可能会超过单个节点的硬件存储限制，为了解决这个问题，ES便提供了分片的功能，它可以将索引划分为多个分片，当创建一个索引的时候，可以简单的定义你想要的分片的数量，每一个分片本身是一个全功能的完全独立的索引，每个分片可以部署到集群中的任何一个节点。分片的主要原因：
它允许水平切分你的内容卷。
它允许通过分片和并行操作来应对日益增长的执行量。
复制（replica）：在一个网络情况下，故障可能随时会发生，有一个故障恢复机制是必须的，为了达到这个目的，ES允许你制作一个或多个拷贝放入一个叫做复制分片或短暂的复制品中。复制带来的好处：
高可用：它可以防止分片或者节点宕机，为此，需要注意绝对不要将一个分片的拷贝放在跟这个分片相同的机器上
高并发：它允许你的分片可以提供超出自身吞吐量的搜索能力，搜索行为可以在所有的分片拷贝中并行执行
总之，一个完整的流程：
ES客户端将一份数据写入primary shard，然后将数据同步到replica shard中去。ES客户端取数据的时候就会在replica或primary的shard中去读ES集群有多个节点，会自动选举一个节点为master节点，这个master节点干一些管理类的操作，比如维护元数据，负责切换primary shard和replica shard的身份，要是master节点宕机了，那么就会重新选举下一个节点为master为节点。
如果primary shard所在的节点宕机了，那么就会由master节点将那个宕机的节点上的primary shard的身份转移到replica shard上，如果修复了宕机的那台机器，重启之后，master节点就会将缺失的replica shard分配过去，同步后续的修改工作，让集群恢复正常。
三、ES写入数据的过程
客户端发送任何一个请求到任意一个node，这个节点就成为协调节点（coordinate node）。
协调节点
对document（可以手动设置doc id，也可以由系统分配）进行hash路由，将请求转发给对应的node。
node上的primary shard处理请求，然后将数据同步到replica node。
协调节点如果发现primary shard所在的node和所有的replica shard所对应的node都搞定之后，就会将请求返回给客户端。
四、ES读数据过程
可以通过doc id来查询，根据doc id进行hash，判断当时写这个document时是分配到哪个shard上去了，然后就去那个shard上查询。
客户端发送任何一个请求到任意一个node，这个节点就成为协调节点（coordinate node）。
协调节点对doc id进行hash路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及所有的replica shard中随机选择一个，让读请求负载均衡。
接受请求的node，返回document给协调节点。
协调节点再将数据返回给客户端。
五、ES搜索数据过程
客户端发送一个请求给协调节点（coordinate node）。
协调节点将搜索的请求转发给所有shard对应的primary shard或replica shard。
query phase：每一个shard将自己搜索的结果（其实也就是一些唯一标识），返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最后的结果。
fetch phase ：接着由协调节点，根据唯一标识去各个节点进行拉取数据，最总返回给客户端。
六、ES写入数据的底层原理
七、倒排索引
倒排索引：建立分词与文档之间的映射关系，在倒排索引中，数据是面向分词的而不是面向文档的。
在搜索引擎中，每个文档都有一个对应的文档ID（即doc id），文档内容被表示为一系列关键词的集合。例如，文档1经过分词，提取了20个关键词，每个关键词都会记录它在文档中出现的次数和出现的位置。
IDF（inverse document frequency）：包含这个关键词的所有文档（document）的数量
TF（term frequency）：这个关键词在每个文档（document）中出现的次数
那么，倒排索引就是关键词（word）到文档ID的映射，每个关键词都对应着一系列的文档。
倒排索引不可变的优缺点：
优点：
不需要锁、提升并发能力，避免锁的问题。
可以一直保存在os cache中，只要cache内存足够。
filter cache可以一直驻留在内存中。
可以压缩，节省cpu和io。
缺点：
每次都要重新构建整个索引。
八、在海量数据中提高效率的几个手段
filesystem cache：ES的搜索引擎严重依赖底层的filesystem cache，如果给filesystem cache更多的内存，尽量让内存可以容纳所有的index segment file索引数据文件。
数据预热：对于那些你觉得比较热的数据，即经常会有人访问的数据，最好做一个专门的缓存预热子系统，对于热数据，每隔一段时间，系统本身就提前访问一下，让数据进入filesystem cache里面去，这样下次访问的时候，性能会更好一些。
冷热分离：
冷数据索引：查询频率低，基本无写入，一般为当天或最近2天以前的数据索引，这种数据可以存储在机械硬盘HDD中。
热数据索引：查询频率高，写入压力大，一
般为当天的数据索引，这种数据可以存储在SSD中。
document的模型设计：不要在搜索的时候去执行各种复杂的操作，尽量在document模型设计和数据写入的时候就将复杂操作处理掉
分页性能优化：翻页的时候，翻得越深，每个shard返回的数据越多，而且协调节点处理的时间越长，此时，要用scroll，scroll会一次性的生成所有数据的快照，然后每次翻页都是通过移动游标来完成。
九、ElasticSearch使用案例
2013年初，GitHub抛弃了Solr，采取ElasticSearch来做PB级的搜索。“GitHub使用ElasticSearch搜索20TB的数据，包括13亿文件和1300亿行代码”。
维基百科：启动以ElasticSearch为基础的核心搜索架构。
SoundCloud：“SoundCloud使用ElasticSearch为1.8亿用户提供即时而精准的音乐搜索服务”。
百度：百度目前广泛使用ElasticSearch作为文本数据分析，采集百度所有服务器上的各类指标数据及用户自定义数据，通过对各种数据进行多维分析展示，辅助定位分析实例异常或业务层面异常。目前覆盖百度内部20多个业务线(包括casio、云分析、网盟、预测、文库、直达号、钱包、风控等)，单集群最大100台机器，200个ES节点，每天导入30TB+数据。
新浪使用ES分析处理32亿条实时日志。
阿里使用ES构建自己的日志采集和分析体系。
以上是关于Elaticsearch基本概念及架构原理的主要内容，如果未能解决你的问题，请参考以下文章