Elasticsearch Data tiers数据分层介绍与展望

前言

最近Elasticsearch 7.10版本发布，该版本除了有Searchable Snapshots可搜索快照这个重磅特性之外，还有Data tiers数据层功能。数据层实际上就是先定义好数据节点的角色，比如热节点、温节点等，然后可以在ILM索引生命周期管理中实现索引由热节点迁移到温节点，再迁移到冷节点，达到数据冷热分离的目的。

在Data tiers功能之前，我们通常是通过在elasticsearch.yml中定义节点的属性(node.attrs)来实现集群的冷热分离架构，而Data tiers，需要在elasticsearch.yml中通过新增的node.roles定义节点的角色，同样角色的节点理应有用相同的物理属性，比如热节点为SSD云盘，温节点为SATA盘，定义节点角色的配置如下所示：

node.roles: ["data_hot", "data_content"]

相比较通过node.attr来定义节点的类型，通过node.roles定义节点类型则更清晰，我们可以清楚的知道每个节点在集群中所处于的位置，并且方便管理。

数据层次介绍

Content tier

Content内容层面向的是数据本身一成不变或者极少发生变化的场景，比如搜索场景，或者是本身因为数据量不大而不需要切分索引的场景，在这种场景中，数据写入或者查询都由Content层的节点承担。新建的索引默认就分配在Content层(面向时序数据的Data stream的索引除外)。

Hot tier

在面向时序数据的日志或者监控场景，往往只需要保证最近比较新的数据的写入能够及时落地，以及满足对比较新的数据近实时的查询，这些数据可以放在Hot层，使用SSD盘、较高的节点规格保证写入和查询的性能。

使用Data stream新创建的索引，默认放在Hot层。

Warm tier

在面向时序数据的日志或者监控场景，对于写入或者查询频率较低的索引，在允许写入或者查询性能相对差一些的情况下，可以把索引从Hot层移动到Warm层，使用成本相对低廉的SATA存储数据，从而节省成本。

Cold tier

当索引已经足够老时，可以把索引移动到Cold层，这些索引可能极少会写入或者查询，因此可以在该层中对索引进行forcemerge节省一些磁盘空间，或者进行shrink降低索引的分片数量。另外，可以在该层中先把数据备份到廉价的存储介质比如S3中，然后把索引副本调低为0，从而减少一半的存储空间。

数据层次展望

社区里为什么要重新开发Data tiers功能，而不是继续沿用之前给节点设置node.attr属性的方式实现节点的冷热分离呢，从社区里Data tiers的issue可以窥探出一些设计初衷：

• 通过把数据分层规范化，可以避免出现多种不同的通过定义节点属性实现冷热分离的最佳实践，从而使得实践方式统一
• 对于使用ES存储时序数据的用户来说非常友好
• 用户可以非常方便地使用冷热分离架构，无需过多的配置，数据可以自动地在节点间迁移
• 因为数据分层的方式统一了，后续可以在ILM中使用Data tiers开发更多的功能，比如索引迁移到Frozen层后就可以自动地把索引冻结等
• 副本数量的自动扩缩容可以由数据层次驱动了，在不同的层次，可以根据需要自动的调节副本的数量

既然把集群数据分层或者说冷热分离的架构都规范化了，我们自然可以有更多的设想，利用数据分层做更多的事情：

• 数据智能分层：可以根据索引的读写频率，智能的进行数据分层存储，比如在索引读写频率都比较低时把索引从Hot层移动到Warm层，从而降低成本；如果某段时间该索引的读写频率又突然增加了，则再自动地把索引从Warm层移动到Hot层，从而提高读写性能。
• 利用好数据分层提高集群的稳定性：可以结合Searchable snapshots功能， 对于Warm、Cold以及尚未开发的Frozen层的索引，自动地把数据转储到S3等廉价存储介质中，集群中无需保留过多的Warm、Cold、Frozen层的节点，从而从整体上减少集群的节点数量，提高集群的稳定性。