让用户关注程度弱的“冷”数据分散到普通磁盘对应节点上？也就是说“冷热”数据分离是本文讨论的内容。
提到冷热集群架构，通常我们关注的问题如下：
什么是冷热集群架构，Elasticsearch支持吗？
Elasticsearch集群如何设置冷热节点？
Elasticsearch集群如何根据数据冷热度写入到不同的节点？
当数据不“热”时，如何将数据迁移到“冷”节点？
本文在Elasticsearch7.3版本上一 一给出解答。
1、什么是冷热架构？
官方叫法：热暖架构——“Hot-Warm” Architecture。
通俗解读：热节点存放用户最关心的热数据；温节点或者冷节点存放用户不太关心或者关心优先级低的冷数据或者暖数据。
图片来源cnblog 毛台的博客
1.1 官方解读冷热架构
冷热架构是一项十分强大的功能，能够让您将 Elasticsearch 部署划分为“热”数据节点和“冷”数据节点。
热数据节点处理所有新输入的数据，并且存储速度也较快，以便确保快速地采集和检索数据。
冷节点的存储密度则较大，如需在较长保留期限内保留日志数据，不失为一种具有成本效益的方法。
将这两种类型的数据节点结合到一起后，您便能够有效地处理输入数据，并将其用于查询，同时还能在节省成本的前提下在较长时间内保留数据。
此架构对日志用例来说尤其大有帮助，因为在日志用例中，人们的大部分精力都会专注于近期的日志（例如最近两周），而较早的日志（由于合规性或者其他原因仍需要保留）则可以接受较慢的查询时间。
1.2 典型应用场景
一句话：在成本有限的前提下，让客户关注的实时数据和历史数据硬件隔离，最大化解决客户反应的响应时间慢的问题。
业务场景描述：
每日增量6TB日志数据，高峰时段写入及查询频率都较高，集群压力较大，查询ES时，常出现查询缓慢问题。
ES集群的索引写入及查询速度主要依赖于磁盘的IO速度，冷热数据分离的关键为使用SSD磁盘存储热数据，提升查询效率。
若全部使用SSD，成本过高，且存放冷数据较为浪费，因而使用普通SATA磁盘与SSD磁盘混搭，可做到资源充分利用，性能大幅提升的目标。
2、最最核心的实现原理
借助：Elasticsearch的分片分配策略，确切的说是：
第一：集群节点层面支持规划节点类型，这是划分热暖节点的前提。
第二：索引层面支持将数据路由到给定节点，这为数据写入冷、热节点做了保障。
Shard allocation awareness
https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-awareness.html
Index-level shard allocation filtering
https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-allocation-filtering.html#
3、7.X版本ES实践一把
第一：搭建一个两个节点的集群，划分热、热节点用。
节点层面设置节点类型。
热节点指定：
node.attr.hotwarm_type: hot
1
暖节点或冷节点指定：
node.attr.hotwarm_type: warm
1
第二：写入操作
方案一：索引层面指定路由。
PUT /logs_2019-10-01
{
"settings": {
"index.routing.allocation.require.hotwarm_type": "hot",
"number_of_replicas": 0
}
}
PUT /logs_2019-08-01
{
"settings": {
"index.routing.allocation.require.hotwarm_type": "warm",
"number_of_replicas": 0
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
方案二：通过模板指定索引的冷热存储。
PUT _template/logs_2019-08-template
{
"index_patterns": "logs_2019-08-*",
"settings": {
"index.number_of_replicas": "0",
"index.routing.allocation.require.hotwarm_type": "warm"
}
}
PUT _template/logs_2019-10-template
{
"index_patterns": "logs_2019-10-*",
"settings": {
"index.number_of_replicas": "0",
"index.routing.allocation.require.hotwarm_type": "hot"
}
}
第三：效果图详见附件图。
第四：借助curator定期迁移数据
随着时间发展，当前数据会成为历史数据。
历史数据要自动切换到普通磁盘的节点存储，可以借助curator实现。
cuator的安装不再追溯，详细请参考官方文档。
https://www.elastic.co/guide/en/elasticsearch/client/curator/5.8/command-line.html
步骤1：定义cuator.yml，填写Elasticsearch集群配置信息。
步骤2：定义action.yml。
actions:
1:
action: allocation
description: >-
Apply shard allocation routing to 'require' 'tag=cold' for hot/cold node
setup for logstash- indices older than 3 days, based on index_creation
date
options:
key: hotwarm_type
value: warm
allocation_type: require
disable_action: false
filters:
- filtertype: pattern
kind: prefix
value: logs_
- filtertype: age
source: name
direction: older
timestring: "%Y-%m-%d"
unit: days
unit_count: 3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
步骤3：执行迁移。
C:\Program Files\elasticsearch-curator>curator.exe --config .\conf\curator.yml .\conf\action.yml
2019-10-13 22:28:31,662 INFO Preparing Action ID: 1, "allocation"
2019-10-13 22:28:31,662 INFO Creating client object and testing connection
2019-10-13 22:28:31,668 INFO Instantiating client object
2019-10-13 22:28:31,668 INFO Testing client connectivity
2019-10-13 22:28:31,675 INFO Successfully created Elasticsearch client object with provided settings
2019-10-13 22:28:31,677 INFO Trying Action ID: 1, "allocation": Apply shard allocation routing to 'require' 'tag=cold' f....
2019-10-13 22:28:31,706 INFO Updating 2 selected indices: ['logs_2019-08-01', 'logs_2019-10-01']
2019-10-13 22:28:31,706 INFO Updating index setting {'index.routing.allocation.require.hotwarm_type': 'warm'}
2019-10-13 22:28:32,559 INFO Action ID: 1, "allocation" completed.
2019-10-13 22:28:32,560 INFO Job completed.
4、坑：
node.attr.hotwarm_type:
1
单纯搜索官网你是找不到的。
因为：node.attr.*，你可以指定type类型、各种结合业务场景你的需要指定的值。
包括：官方的：按照磁盘大小设定。和咱们的冷热节点。
白话文：就是标定节点划分分类的一个属性类型值。
这个坑网友也有疑惑：node属性(tag)如何设置，查资料看到了好几种方法很混乱 - Elastic 中文社区，官方文档说的不是特别清楚。
5、线上使用场景
来自星友的线上实战反馈如下：
我们现有的架构也是冷热分离。
热节点使用的是ssd，indexing和search性能都不错，其中保存4天的数据，4天之后数据推到warm节点。
warm节点使用的是hdd。
在运维过程中，能体会到这种架构的特点是：
冷节点或者热节点的离群不会影响另外一个种类型节点的功能；
但是如果整个集群中有节点产生stw（Java中一种全局暂停现象，全局停顿，所有Java代码停止，native代码可以执行，但不能与JVM交互；这些现象多半是由于gc引起。），整个集群的性能都会被影响；
这种架构能在相对节约成本的前提下极大的提升性能，但是不能完全做到一种类型节点的故障对其他类型节点是无感的。
6、小结
Elasticsearch6.6版本后已推出索引生命周期管理ilm功能。涵盖了冷热集群的部署和自动化实现。
最新实现参考：https://www.elastic.co/guide/en/elasticsearch/reference/7.4/index-lifecycle-management.html
官方最早2015年的博客就提到了冷热集群架构的实现，但“再显而易见的道理，也有80%的人可能不知道”并考虑到大家使用场景的参差不齐，才梳理出本篇文章。
你的集群使用冷热架构了吗？ 欢迎交流。
7、Good 参考深入学习
1）最新冷热架构官方文档：
https://www.elastic.co/cn/blog/deploying-a-hot-warm-logging-cluster-on-the-elasticsearch-service
2）最多参考冷热架构文档：
https://www.elastic.co/cn/blog/hot-warm-architecture-in-elasticsearch-5-x
3）国内最佳实践：elasticsearch冷热数据读写分离
