网上学习资料一大堆，但假如学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化资料的朋侪，可以戳这里获取
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、口试辅导），让我们一起学习发展！
官方定义：
数据节点保存包含您已索引的文档的分片。数据节点处置惩罚数据相干操作，比方 CRUD、搜索和聚合。这些操作是 I/O、内存和 CPU 麋集型操作。监视这些资源并在过载时添加更多数据节点非常重要。
拥有专用数据节点的主要好处是主角色和数据角色的分离。
要创建专用数据节点，请设置：node.roles: [ data ]
在多层部署体系结构中，您可以利用专门的数据角色将数据节点分配到特定层：data_content、data_hot、data_warm、 data_cold或data_frozen。一个节点可以属于多个层，但具有专用数据角色之一的节点不能具有通用data角色。
1.2.1.3 Coordinate Node协调节点的功能
官方定义：
诸如搜索哀求或批量索引哀求之类的哀求，它们可能涉及差别数据节点上保存的数据。比方，搜索哀求分两个阶段实验，这两个阶段由吸收客户端哀求的节点（协调节点）协调。
- 在分散阶段，协调节点将哀求转发到保存数据的数据节点。每个数据节点在本地实验哀求并将其结果返回给协调节点
- 在收集阶段，协调节点将每个数据节点的结果缩减为单个全局结果集
每个节点都是隐式的协调节点。这意味着具有显式空角色列表的节点node.roles将仅充当协调节点，无法禁用。因此，如许的节点需要有充足的内存和 CPU 才能处置惩罚收集阶段。
1.2.1.4 Ingest Node协调节点的功能
官方定义：
在实际的文档索引发生之前，利用摄取节点对文档进行预处置惩罚。摄取节点拦截批量和索引哀求，应用转换，然后将文档传递回索引或批量api。
默认环境下，全部节点都启用摄取，因此任何节点都可以处置惩罚摄取使命。您还可以创建专用的摄取节点。假如要禁用节点的摄取，请在elasticsearch. conf中配置以下配置。yml文件：node.ingest: false
要在索引之前对文档进行预处置惩罚，请定义一个指定一系列处置惩罚器的管道。每个处置惩罚器都以某种特定的方式转换文档。比方，管道可能有一个处置惩罚步伐从文档中删除字段，然后有另一个处置惩罚步伐重命名字段。然后，集群状态存储配置的管道。
要利用管道，只需在索引或批量哀求上指定pipeline参数。如许，摄取节点就知道要利用哪个管道。比方：
- PUT my-index/my-type/my-id?pipeline=my_pipeline_id
- {
- "foo": "bar"
- }
其他节点相对来说利用的比力少，不做先容了
1.2.1.6 Master Node主节点选举流程
ES的选举流程也很简单，如下：
- 通常集群启动时，第一个启动的节点会被选为主节点。当主节点挂了的时间，进行下一步
- 互相Ping对方，Node ld 低的会成为被选举的节点
- 其他节点会加入集群，但是不负担Master节点的角色。一旦发现被选中的主节点丢失，就会重新选举出新的Master节点
在我们的生产过程中，Master Node的最佳实践方案
- Master节点非常重要，在部署上需要思量办理单点的问题
- 为一个集群设置多个Master节点，每个节点只负担Master 的单一角色
1.2.2 分片
分片是ES中一个比力重要的概念。ElasticSearch是一个分布式的搜索引擎，索引可以分成一份或多份，多份分布在差别节点的分片当中。ElasticSearch会主动管理分片，假如发现分片分布不均衡，就会主动迁移。
分片又有【主分片】、【副本分片】之分。它们的区别如下：
- 主分片（Primary Shard）
- 用以办理数据水平扩展的问题。通过主分片，可以将数据分布到集群内的全部节点之上
- 一个分片是一个运行的Lucene的实例
- 主分片数在索引创建时指定，后续不允许修改，除非Reindex
- 副本分片
- 用以办理数据高可用的问题。 副本分片是主分片的拷贝（备份）
- 副本分片数，可以动态调解
- 增长副本数，还可以在一定程度上提高服务的可用性（读取的吞吐）
- # 指定索引的主分片和副本分片数
- PUT /csdn_blogs
- {
- "settings": {
- "number\_of\_shards": 3,
- "number\_of\_replicas": 1
- }
- }
如上图是某个集群的分片架构，它有如下特征：
通常都是奇数，所谓【集群奇数法则】。但其实只是名字很唬人，本质上也没那么神奇。你自己想想，假如是偶数的话，是不是很有可能出现选举平票的时间？根据我的经验，选举算法通常都盼望快速选举一个master或者leader出来，以便能够快速提供服务，以是没空扯皮
高可用之——故障转移
- 主副分片之间交叉存储（node1的副本放在node3，node2放在node1，node3放在node2）
利用【cat API查看集群信息】
- GET /_cat/nodes?v #查看节点信息
- GET /_cat/health?v #查看集群当前状态：红、黄、绿
- GET /_cat/shards?v #查看各shard的详细环境
- GET /_cat/shards/{index}?v #查看指定分片的详细环境
- GET /_cat/master?v #查看master节点信息
- GET /_cat/indices?v #查看集群中全部index的详细信息
- GET /_cat/indices/{index}?v #查看集群中指定index的详细信息 `
1.3 搭建三节点ES集群
1.3.1 ES集群搭建步调
下面是在Linux环境，centos7下面的集群搭建步调：
1）系统环境准备
起首创建用户，因为es不允许root账号启动
安装版本：elasticsearch-7.17.3。接着切换到root用户，修改/etc/hosts：
- vim /etc/hosts
- 192.168.66.150 es-node1
- 192.168.66.151 es-node2
- 192.168.66.152 es-node3
注意配置里面的注释，里面有一些细节。比如：
- 注意集群的名字，3个节点的集群名称必须一直
- 给每个节点指定名字，比如这里是node1/2/3
- 是否要开启外网访问，跟redis的配置差不多
- # 指定集群名称3个节点必须一致
- cluster.name: es-cluster
- #指定节点名称，每个节点名字唯一
- node.name: node-1
- #是否有资格为master节点，默认为true
- node.master: true
- #是否为data节点，默认为true
- node.data: true
- # 绑定ip,开启远程访问,可以配置0.0.0.0
- network.host: 0.0.0.0
- #用于节点发现
- discovery.seed_hosts: ["es-node1", "es-node2", "es-node3"]
- #7.0新引入的配置项,初始仲裁，仅在整个集群首次启动时才需要初始仲裁。
- #该选项配置为node.name的值，指定可以初始化集群节点的名称
- cluster.initial_master_nodes: ["node-1","node-2","node-3"]
- #解决跨域问题
- http.cors.enabled: true
- http.cors.allow-origin: "\*"
3) 启动每个节点的ES服务
- # 注意：如果运行过单节点模式，需要删除data目录， 否则会导致无法加入集群
- rm -rf data
- # 启动ES服务
- bin/elasticsearch -d
正常来说，假如我们先启动了192.168.66.150，那么它就是这个集群当中的主节点，以是我们验证集群的话，只需要访问http://192.168.66.150:9200即可看到如下界面：
1.3.2 安装客户端
先容完了ES的集群部署，我们再来看看ES客户端的部署。这里有两个可选方案，它们分别是Cerebro和Kibana，它们的区别与联系如下：
Cerebro和Kibana都是用于Elasticsearch的开源工具，但它们在功能和利用场景上存在一些区别。
功能：
- Cerebro：Cerebro是Elasticsearch的图形管理工具，可以查看分片分配和实验常见的索引操作，功能集中管理alias和index template，非常快捷。别的，Cerebro还具有实时监控数据的功能。
- Kibana：Kibana是一个强大的可视化工具，可以用于Elasticsearch数据的探索、分析和展示。它提供了丰富的图表类型，包括折线图、直方图、饼图等，可以方便地展示基于时间序列的数据。别的，Kibana还提供了日记管理、分析和展示的功能
利用场景：
- Cerebro：Cerebro适合用于生产和测试环境的Elasticsearch集群管理，尤其适用于需要快速查看和实验索引操作的环境。由于Cerebro轻量且适用于实时监控，它可能更适用于较小的集群和实时监控的场景。
- Kibana：Kibana适合对Elasticsearch数据进行深入的分析和探索，以及对日记进行管理和分析。它提供了丰富的可视化功能和机动的数据展示方式，适用于各种规模的数据分析和监控场景。
Cerebro安装
Cerebro 可以查看分片分配和通过图形界面实验常见的索引操作，完全开源，并且它允许添加用户，密码或 LDAP 身份验证问网络界面。Cerebro 基于 Scala 的Play 框架编写，用于后端 REST 和 Elasticsearch 通讯。 它利用通过 AngularJS 编写的单页应用步伐（SPA）前端。
安装包下载地址如下：https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.zip
下载安装之后，用以下命令启动即可：
- cerebro-0.9.4/bin/cerebro
- #后台启动
- nohup bin/cerebro > cerebro.log &
输入ES集群节点：http://192.168.66.150:9200，建立毗连。然后会出现以下界面：
kibana安装
1）修改kibana配置
- vim config/kibana.yml
- server.port: 5601
- server.host: "192.168.66.150"
- elasticsearch.hosts: ["http://192.168.66.150:9200","http://192.168.66.151:9200","http://192.168.66.152:9200"]
- i18n.locale: "zh-CN"
3）访问
访问http://192.168.66.150:5601/验证
二、生产环境最佳实践
2.1 一个节点只负担一个角色的配置
我们在上面的先容中知道，节点有多种差别的类型（角色），有：Master eligible / Data / Ingest / Coordinating /Machine Learning等。不过跟之前学习的各种集群架构差别的是，ES一个节点可负担多种角色。
不过，在生产环境中尽量照旧一个节点一种角色比力好，长处是：极致的高可用；缺点是：可能有点费钱
想要一个节点只负担一个角色，只需要修改如下配置：
- #Master节点
- node.master: true
- node.ingest: false
- node.data: false
- #data节点
- node.master: false
- node.ingest: false
- node.data: true
- #ingest 节点
- node.master: false
- node.ingest: true
- node.data: false
- #coordinate节点
- node.master: false
- node.ingest: false
- node.data: false
在实际生产中，我们可能会遇到需要水平扩展容量的场景，通常来说，以下是几个常见的场景：
- 当磁盘容量无法满足需求时，可以增长数据节点
- 磁盘读写压力大时，增长数据节点
- 当系统中有大量的复杂查询及聚合时间，增长Coordinating节点，增长查询的性能
2.3 异地多活架构
下面是一个多集群架构。集群处在三个数据中心，数据三写，利用GTM分发读哀求
全局流量管理（GTM）和负载均衡（SLB）的区别：
GTM 是通过DNS将域名解析到多个IP地址，差别用户访问差别的IP地址，来实现应用服务流量的分配。同时通过健康检查动态更新DNS解析IP列表，实现故障隔离以及故障切换。终极用户的访问直接毗连服务的IP地址，并不通过GTM。
而 SLB 是通过代理用户访问哀求的形式将用户访问哀求实时分发到差别的服务器，终极用户的访问流量必须要经过SLB。 一样平常来说，相同Region利用SLB进行负载均衡，差别region的多个SLB地址时，则可以利用GTM进行负载均衡。
2.4 Hot & Warm 架构
热节点存放用户最关心的热数据；温节点或者冷节点存放用户不太关心或者关心优先级低的冷数据或者暖数据。
它的典型的应用场景如下：
在资本有限的条件下，让客户关注的实时数据和汗青数据硬件隔离，最大化办理客户反应的响应时间慢的问题。业务场景形貌：每日增量6TB日记数据，高峰时段写入及查询频率都较高，集群压力较大，查询ES时，常出现查询迟钝问题。
- ES集群的索引写入及查询速度主要依赖于磁盘的IO速度，冷热数据分离的关键为利用SSD磁盘存储热数据，提升查询效率。
- 若全部利用SSD，资本过高，且存放冷数据较为浪费，因而利用普通SATA磁盘与SSD磁盘混搭，可做到资源充分利用，性能大幅提升的目标。
ES为什么要设计Hot & Warm 架构呢？
- ES数据通常不会有 Update操作;
- 适用于Time based索引数据，同时数据量比力大的场景。
- 引入 Warm节点，低配置大容量的机器存放老数据，以低落部署资本
两类数据节点，差别的硬件配置：
- Hot节点(通常利用SSD)︰索引不断有新文档写入。
- Warm 节点（通常利用HDD)︰索引不存在新数据的写入，同时也不存在大量的数据查询
Hot Nodes：用于数据的写入
- lndexing 对 CPU和IO都有很高的要求，以是需要利用高配置的机器
- 存储的性能要好，建议利用SSD
Warm Nodes
用于保存只读的索引，比力旧的数据。通常利用大容量的磁盘
配置Hot & Warm 架构
利用Shard Filtering实现Hot&Warm node间的数据迁移
- node.attr来指定node属性：hot或是warm。
- 在index的settings里通过index.routing.allocation来指定索引（index)到一个满足要求的node
利用 Shard Filtering，步调分为以下几步：
- 标志节点(Tagging)
- 配置索引到Hot Node
- 配置索引到 Warm节点
1）标志节点
需要通过“node.attr”来标志一个节点
- 节点的attribute可以是任何的key/value
- 可以通过elasticsearch.yml 或者通过-E命令指定
- # 标记一个 Hot 节点
- elasticsearch.bat -E node.name=hotnode -E cluster.name=tulingESCluster -E http.port=9200 -E path.data=hot_data -E node.attr.my\_node\_type=hot
- # 标记一个 warm 节点
- elasticsearch.bat -E node.name=warmnode -E cluster.name=tulingESCluster -E http.port=9201 -E path.data=warm_data -E node.attr.my\_node\_type=warm
- # 查看节点
- GET /_cat/nodeattrs?v
创建索引时间，指定将其创建在hot节点上
- # 配置到 Hot节点
- PUT /index-2022-05
- {
- "settings":{
- "number\_of\_shards":2,
- "number\_of\_replicas":0,
- "index.routing.allocation.require.my\_node\_type":"hot"
- }
- }
- POST /index-2022-05/_doc
- {
- "create\_time":"2022-05-27"
- }
- #查看索引文档的分布
- GET _cat/shards/index-2022-05?v
Index.routing.allocation是一个索引级的dynamic setting，可以通过API在后期进行设定
- # 配置到 warm 节点
- PUT /index-2022-05/_settings
- {
- "index.routing.allocation.require.my\_node\_type":"warm"
- }
- GET _cat/shards/index-2022-05?v
一个集群总共需要多少个节点?一个索引需要设置几个分片？规划上需要保持一定的余量，当负载出现波动，节点出现丢失时，还能正常运行。做容量规划时，一些需要思量的因素：
- 机器的软硬件配置
- 单条文档的大小│文档的总数据量│索引的总数据量（(Time base数据保存的时间)|副本分片数
- 文档是如何写入的(Bulk的大小)
- 文档的复杂度，文档是如何进行读取的(怎么样的查询和聚合)
评估业务的性能需求：
- 数据吞吐及性能需求
- 数据写入的吞吐量，每秒要求写入多少数据?
- 查询的吞吐量?
- 单条查询可接受的最大返回时间?
- 了解你的数据
- 数据的格式和数据的Mapping
- 实际的查询和聚合长的是什么样的
ES集群常见应用场景：
- 搜索: 固定大小的数据集
- 日记: 基于时间序列的数据
- 利用ES存放日记与性能指标。数据天天不断写入，增长速度较快
- 结合Warm Node 做数据的老化处置惩罚
硬件配置：
- 选择合理的硬件，数据节点尽可能利用SSD
- 搜索等性能要求高的场景，建议SSD
- 日记类和查询并发低的场景，可以思量利用机械硬盘存储
- 单节点数据建议控制在2TB以内，最大不建议超过5TB
- JVM配置机器内存的一半，JVM内存配置不建议超过32G
- 不建议在一台服务器上运行多个节点
内存大小要根据Node 需要存储的数据来进行估算
- 搜索类的比例建议: 1:16
- 日记类: 1:48——1:96之间
假设总数据量1T，设置一个副本就是2T总数据量
- 假如搜索类的项目，每个节点31*16 = 496 G，加上预留空间。以是每个节点最多400G数据，至少需要5个数据节点
- 假如是日记类项目，每个节点31*50= 1550 GB，2个数据节点即可
部署方式：
- 按需选择合理的部署方式
- 假如需要思量可靠性高可用，建议部署3台单一的Master节点
- 假如有复杂的查询和聚合，建议设置Coordinating节点
集群扩容：
- 增长Coordinating / Ingest Node
- 办理CPU和内存开销的问题
- 增长数据节点
- 办理存储的容量的问题
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比力多，这里只是将部门目录截图出来，全套包含大厂面经、学习条记、源码课本、实战项目、大纲路线、解说视频，并且后续会持续更新
需要这份系统化资料的朋侪，可以戳这里获取
空间。以是每个节点最多400G数据，至少需要5个数据节点
- 假如是日记类项目，每个节点31*50= 1550 GB，2个数据节点即可
部署方式：
- 按需选择合理的部署方式
- 假如需要思量可靠性高可用，建议部署3台单一的Master节点
- 假如有复杂的查询和聚合，建议设置Coordinating节点
集群扩容：
- 增长Coordinating / Ingest Node
- 办理CPU和内存开销的问题
- 增长数据节点
- 办理存储的容量的问题
[外链图片转存中…(img-DXvphPcC-1715596415677)]
[外链图片转存中…(img-Y6aR1PmZ-1715596415678)]
[外链图片转存中…(img-MKhzYcjL-1715596415678)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比力多，这里只是将部门目录截图出来，全套包含大厂面经、学习条记、源码课本、实战项目、大纲路线、解说视频，并且后续会持续更新
需要这份系统化资料的朋侪，可以戳这里获取
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
