使用数据层进行数据生命周期管理

作者：来自 Elastic Stef Nestor

Elasticsearch 7.10 使配置数据生命周期变得不再那么复杂。在这篇博文中，我将介绍一些变化、如何使用它们以及一些最佳实践。

数据生命周期可以包含很多阶段，因此我们将涉及：

• 将集群划分为层（hot、warm、cold），确保新数据到达正确的位置。
• 在索引生命周期管理 (index lifecycle management - ILM) 中使用这些层在层之间迁移数据。
• 使用 Elastic 可搜索快照（Elastic searchable snapshots）增加冷层内的数据密度。
• 将所有内容与数据如何流经层的真实示例结合起来。

放弃属性，加入节点角色 

处理时间序列数据时，一个常见用例是将集群拓扑分成不同的层。这些层被命名为 hot 层（新数据被提取和查询）、warm 层（中期数据被保存和查询）和 cold 层（数据通常被保存很长时间，查询频率较低）。

用户通常会使用不同的硬件配置这些层，以便将最强大、最昂贵的硬件用于 hot 层，而将较便宜、存储密度更高的硬件用于 warm 层或 cold 层。

在 7.10 之前，配置不同节点层的最常见方法之一是使用节点属性，因此用户可以配置以下内容：

# On hot nodes 
node.attr.node_type: hot# On warm nodes 
node.attr.node_type: warm # On cold nodes: 
node.attr.node_type: cold

然后可以将这些与集群和索引级别分配参数一起使用。例如，可以使用以下命令创建索引：

PUT /myindex 
{ "settings": { "index.routing.allocation.include.node_type": "hot" } 
}

这创建了一个分配给热节点的索引。

让我们来看看新的做事方式。

正式化流程

在 7.10 中，这种类型的配置已经正式化，我们现在拥有与 hot 、warm 和 cold 层（以及另一个层，我们将介绍）相对应的特定角色。这意味着，我们无需添加 node.attr.node_type 属性，而是可以将 data_hot、data_warm 或 data_cold 节点角色之一添加到 node.roles 设置中：

# On hot nodes 
node.roles: ["data_hot"] # On warm nodes 
node.roles: ["data_warm"] # On cold nodes 
node.roles: ["data_cold"]

记得将你可能需要的任何其他角色添加到列表中！例如，对于较小的集群，数据节点可能如下所示：

node.roles: ["master", "ingest", "ml", "data_hot", "data_content"]

（本文后面将进一步解释 data_content 角色。）

注意：你可能想知道现有数据角色发生了什么。好吧，数据角色的作用就像已指定所有层一样，因此它同时成为 hot 层、warm 层和 cold 层的一部分。这意味着已升级到 7.10 或更高版本但未使用 node.roles 设置指定自定义节点角色的节点是每个数据层的一部分。

在层级间移动数据

设置这些角色后，可以使用与之前相同的集群和索引级分配过滤器在集群间移动数据：

• cluster.routing.allocation.require._tier
• cluster.routing.allocation.include._tier
• cluster.routing.allocation.exclude._tier
• index.routing.allocation.require._tier
• index.routing.allocation.include._tier
• index.routing.allocation.exclude._tier

还有一个新参数，其行为与常规的包含（include）、排除（exclude）和需要（require）过滤略有不同。这是 _tier_preference 索引级设置：index.routing.allocation.include._tier_preference。

要了解其工作原理，让我们看一个例子：

PUT /myindex 
{ "settings": { "index.routing.allocation.include._tier_preference": "data_cold,data_warm,data_hot" } 
}

此代码段创建一个索引，该索引优先位于 cold 层，然后是 warm 层，最后是 hot 层。

如果集群不包含冷节点，则必须将其分配给 warm 节点。 如果集群中没有 warm 节点，则必须将其分配给 hot 节点。 此配置允许策略或模板设置首选项，而不必担心每个层都是集群的一部分 - 它可以指定其首选层。

要确切了解此新设置的行为方式，请查看此流程图：

节点属性（node attributes）和正式化数据层角色（formalized data tier roles）之间还有最后一个区别 —— 索引在最初创建时分配的位置。这里有一个简单的规则，它决定了索引最初放在何处：

任何作为数据流一部分的索引在创建时都会自动添加 “index.routing.allocation.include._tier_preference: data_hot” 设置。

这意味着所有数据流支持索引将默认分配在热 (data_hot) 节点上。

对于不属于数据流的索引：

任何不属于数据流的索引在创建时都会自动添加 “index.routing.allocation.include._tier_preference: data_content” 设置。

这两个设置都可以被覆盖。只需将 _tier_preference 索引设置为 null，或在创建期间设置任何其他索引级分配过滤设置即可。

但请稍等：这个新的 data_content 角色是什么？让我们考虑另一种不适合生命周期模型的数据：不适合时间序列模型的数据。

不符合时间序列的数据

某些数据被编入索引，然后仅被查询，但在概念上没有年龄或时间戳。这包括企业搜索数据、电子商务数据或用户信息数据库。

对于此类数据，有一个特定角色：data_content 角色。此角色的配置与其他角色一样，使用 node.roles 设置。

值得一提的是，这些角色都不是互斥的，因此如果你希望非时间序列数据和 hot 数据位于同一节点上，你可以像这样配置节点：

# This node can hold either "hot" tier data, or "content" tier data 
node.roles: ["data_hot", "data_content"]

而且，你可能已经猜到了，现有的默认数据角色也是 content 层的一部分。这意味着数据角色与将 data_hot、data_warm、data_cold 和 data_content 角色添加到 node.roles 设置相同。

如上一节所述，Elasticsearch 确定时间序列数据和非时间序列数据的方式是该索引是否属于数据流。

最佳实践：确保你的集群始终至少有一个 data_hot 节点和一个 data_content 节点，即使它们是同一个节点。如果没有这两个节点角色，则无法分配不同类型的索引。

现在我们了解了所有不同的层级并配置了一些，让我们看看 ILM 如何利用这些层级。

数据层世界中的 ILM

与旧的基于属性的分配相比，单独配置层并没有太大变化。但是，现在我们有了内置且一致的方式来识别 Elasticsearch 中的层，ILM 可以利用这些设置在层之间自动迁移数据。

在 7.10 之前，可以使用以下策略完成分层配置：

{ "phases" : { "hot" : { "actions" : { "rollover" : { "max_age" : "30d", "max_size" : "50gb" } } }, "warm" : { "min_age" : "45d", "actions" : { "allocate" : { "include" : { "node_type" : "warm" } }, "forcemerge" : { "max_num_segments" : 1 } } }, "cold" : { "min_age" : "60d", "actions" : { "allocate" : { "include" : { "node_type" : "cold" } } } }, "delete" : { "min_age" : "90d", "actions" : { "delete" : { } } } } 
}

此策略依赖于索引模板将数据分配到热层，然后在每个 ILM 阶段内使用“分配”操作更新 node_type 以移动数据。

但在 7.10 中，有更好的方法！

由于 Elasticsearch 现在能够优先选择特定层，因此 ILM 可以通过在进入新阶段时自动设置 index.routing.allocation.include._tier_preference 来利用此偏好。以下是使用与上述相同策略的示例，但删除了分配步骤：

{ "phases" : { "hot" : { "actions" : { "rollover" : { "max_age" : "30d", "max_size" : "50gb" } } }, "warm" : { "min_age" : "45d", "actions" : { "forcemerge" : { "max_num_segments" : 1 } } }, "cold" : { "min_age" : "60d", "actions" : { } }, "delete" : { "min_age" : "90d", "actions" : { "delete" : { } } } } 
}

当使用此策略创建新数据流时，最初首选项将设置为 index.routing.allocation.include._tier_preference: data_hot。

当索引进入 warm 阶段时，设置将更新为 index.routing.allocation.include._tier_preference: data_warm,data_hot。

进入 cold 阶段后，它将更新为 index.routing.allocation.include._tier_preference: data_cold,data_warm,data_hot，然后索引最终将在删除阶段被删除。

此自动迁移不适用于 hot 阶段，因为它在索引创建时自动管理。

当集群拓扑也包含该层的节点时，此自动迁移允许数据位置自动匹配当前 ILM 阶段。

此行为会自动应用，但有两个注意事项：

• 如果 "migrate": {"enabled": false} action 添加到阶段的操作列表中，则自动迁移不会生效。
• 如果 ILM 阶段操作包含设置 include、require 或 exclude 过滤器的分配步骤，则自动迁移不会生效。

这两个阶段都不会自动迁移数据：

"warm": { "actions": { "migrate": { "enabled": false } } 
}

或者：

"warm": { "actions": { "allocate": { "include": { "node_type": "warm" } } } 
}

最佳实践：在集群拓扑中采用了新角色后，请确保从使用节点属性依赖默认数据层迁移的 ILM 策略中删除任何先前的分配操作。

使用可搜索快照将数据保存更长时间

创建和维护数据的生命周期可让你控制新数据与旧数据的硬件属性和性能特征。

但你的集群实际上可以容纳多少数据？

这个问题的答案几乎总是决定数据的保留期限，因为磁盘空间有限，必须从集群中删除最旧的数据以腾出空间容纳新数据。这需要在保留洞察和监管原因所需的数据量之间取得微妙的平衡，而不会耗尽集群磁盘资源或为集群磁盘资源支付过多费用。

但如果我们可以将数据保存更长时间，而对集群资源的影响却很小，那会怎样？

这正是可搜索快照可以提供帮助的地方。7.10 版引入的可搜索快照允许 Elasticsearch 在集群本地保留一份数据副本，而另一份副本（充当副本）则驻留在快照存储库中。这意味着不需要副本，因为任何本地副本的丢失都可以从存储库快照中自动本地恢复。

我们也可以在 ILM 中使用此功能，当索引达到冷阶段时，自动将其转换为可搜索的快照，使可存储的数据密度加倍，因为不需要副本来实现冗余。

使用此功能非常简单，只需使用 searchable_snapshot 操作配置冷阶段即可：

"cold": { "min_age": "90d", "actions": { "searchable_snapshot": { "snapshot_repository" : "backing_repo" } } 
}

在内部，当达到此操作时，Elasticsearch 将：

• 强制将索引合并到单个段
• 在 backing_repo 存储库中创建索引的新快照
• 以新名称将索引挂载为可搜索快照支持的索引
• 将原始索引交换为可搜索快照支持的索引

瞧！我们现在不再需要本地副本，因为我们有一个快照，可以在数据的主要副本丢失时使用。

注意：如果你是 Elastic Cloud 用户，你甚至可以在可搜索快照操作配置中使用已配置的 “found-snapshots” 存储库（或配置你自己的单独存储库）。

整合所有部分

数据生命周期的数据层配置包含许多不同的移动部分，以构成一个有效的生命周期。让我们将这些部分整合成一个有效的示例。

首先，我们需要一些节点。在此示例中，我们将使用四个节点，分别表示为 a、b、c 和 d：

NodeA：

node.name: node-a-hot 
node.roles: ["master", "data_hot", "data_content", "ingest"]

NodeB:

node.name: node-b-hot 
node.roles: ["master", "data_hot", "data_content", "ingest"]

NodeC:

node.name: node-c-cold 
node.roles: ["master", "data_cold", "ingest"]

NodeD:

node.name: node-d-cold 
node.roles: ["master", "data_cold", "ingest"]

集群启动后，我们来配置一个快照存储库：

PUT /_snapshot/my-repository 
{ "type": "fs", "settings": { "location": "my-backup-location" }
}

并添加我们的 ILM 策略，利用一些常见的操作和新的 searchable_snapshot 操作：

PUT /_ilm/policy/my-data-lifecycle 
{"policy" : { "phases" : { "hot" : { "actions" : { "rollover" : { "max_size" : "50gb", "max_age" : "3d" } } }, "warm" : { "min_age" : "5d", "actions" : { "shrink" : { "number_of_shards" : 1 } } }, "cold" : { "min_age" : "7d", "actions" : { "searchable_snapshot" : { "snapshot_repository" : "my-repository" } } }, "delete" : { "min_age" : "365d", "actions" : { "delete" : { } } } } } 
}

还有一个先决条件：索引模板（index template），以便索引可以是数据流并自动使用我们之前创建的 ILM 策略。确保每个节点至少有两个以容纳副本，或者将 index.number_of_replicas 设置为 0 以进行测试。

PUT /_index_template/my-lifecycle-template 
{ "index_patterns": ["test-index"], "data_stream" :{}, "template": { "settings": { "index.lifecycle.name": "my-data-lifecycle", "index.number_of_shards": 2 } } 
}

现在可以通过将文档直接索引到测试索引数据流来将数据发送到这个新索引：

POST /test-index/_doc?op_type=create 
{ "message": "test document", "@timestamp": "2020-01-12" 
}

现在，随着更多数据的发送，它将自动从集群中的热节点移动到 cold 节点，最终进入可搜索的快照，并在一年后最终被删除。

开始使用 Elastic Cloud

我们希望从技术角度介绍数据层对你有所帮助。请试用这些功能，并在我们的讨论论坛中告诉我们你对它们的喜好！

你还可以通过 Elastic Cloud 的 14 天免费试用版试用这些测试版功能。敬请期待 7.11，届时我们的数据层功能将全面推出。

原文：Elasticsearch data lifecycle management with data tiers | Elastic Blog