Elasticsearch集群如何实现冷热数据分离

问题导读

1.什么是冷热集群架构，Elasticsearch支持吗？
2.Elasticsearch集群如何设置冷热节点？
3.Elasticsearch集群如何根据数据冷热度写入到不同的节点？
4.当数据不“热”时，如何将数据迁移到“冷”节点？


0、题记
Elasticsearch实战数据量级少的时候，单节点就能玩的很6，但是随着数据量的增长，多节点分布式横向扩展集群是大势所趋。

当集群硬件资源有限，尤其SSD磁盘更紧俏的业务场景下，最大化集群的性能，如何让用户最关心的“热”数据分布到SSD磁盘对应的节点上，

让用户关注程度弱的“冷”数据分散到普通磁盘对应节点上？也就是说“冷热”数据分离是本文讨论的内容。
提到冷热集群架构，通常我们关注的问题如下：

什么是冷热集群架构，Elasticsearch支持吗？
Elasticsearch集群如何设置冷热节点？
Elasticsearch集群如何根据数据冷热度写入到不同的节点？
当数据不“热”时，如何将数据迁移到“冷”节点？
本文在Elasticsearch7.3版本上一 一给出解答。


1、什么是冷热架构？

官方叫法：热暖架构——“Hot-Warm” Architecture。
通俗解读：热节点存放用户最关心的热数据；温节点或者冷节点存放用户不太关心或者关心优先级低的冷数据或者暖数据。


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实践一把

第一：搭建一个两个节点的集群，划分热、热节点用。
节点层面设置节点类型。
热节点指定：
[mw_shl_code=bash,true]node.attr.hotwarm_type: hot
[/mw_shl_code]
暖节点或冷节点指定：
[mw_shl_code=bash,true]node.attr.hotwarm_type: warm
[/mw_shl_code]

第二：写入操作
方案一：索引层面指定路由。
[mw_shl_code=bash,true]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
  }
}
[/mw_shl_code]

方案二：通过模板指定索引的冷热存储。
[mw_shl_code=bash,true]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
  }
}
[/mw_shl_code]

方案二：通过模板指定索引的冷热存储。
[mw_shl_code=bash,true]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"
  }
}
[/mw_shl_code]

第三：效果图详见附件图。




第四：借助curator定期迁移数据
随着时间发展，当前数据会成为历史数据。
历史数据要自动切换到普通磁盘的节点存储，可以借助curator实现。
cuator的安装不再追溯，详细请参考官方文档。
https://www.elastic.co/guide/en/elasticsearch/client/curator/5.8/command-line.html
步骤1：定义cuator.yml，填写Elasticsearch集群配置信息。
步骤2：定义action.yml。


[mw_shl_code=bash,true]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
[/mw_shl_code]

步骤3：执行迁移。
[mw_shl_code=bash,true]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.
[/mw_shl_code]




4、坑：

[mw_shl_code=bash,true]node.attr.hotwarm_type:[/mw_shl_code]
单纯搜索官网你是找不到的。
因为：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/ ... cle-management.html

最新经典文章，欢迎关注公众号

原文链接：
https://blog.csdn.net/laoyang360/article/details/102539888?utm_source=app

感谢分享