作者：来自 Elastic Jon Avezbaki
在 Elasticsearch 9.5 中，数据流生命周期中的 frozen_after 会自动将索引迁移到对象存储上的可搜索快照中，同时保持索引可查询，并与降采样和保留策略协同工作。
在 Elasticsearch 9.5 中，数据流生命周期可以将后备索引移动到冻结层，作为对象存储上的可搜索快照，而无需配置 ILM 策略。在几行 JSON 中，将frozen_after添加到data_retention和可选的降采样旁边，或者在 Kibana 中进行设置。该功能已在 9.5 中正式发布。
如何在数据流生命周期中配置 frozen_after
frozen_after位于生命周期的顶层，与data_retention和downsampling并列。
PUT _data_stream/my-data-stream/_lifecycle{ "data_retention": "90d", "frozen_after": "30d" }在 API 层面，这就是整个功能。my-data-stream中的索引会在热层保留 30 天，然后移动到冻结层，继续保留 60 天。90 天后，它们会被删除，相应的后备快照也会随之删除。
它可以与生命周期的其他功能组合使用，包括降采样：
PUT _data_stream/my-data-stream/_lifecycle{ "data_retention": "90d", "frozen_after": "30d", "downsampling": [ { "after": "1d", "fixed_interval": "1h" } ] }索引模板中也可以使用相同的配置：
PUT _index_template/my-index-template{ "index_patterns": ["my-data-stream*"], "data_stream": {}, "template": { "lifecycle": { "data_retention": "90d", "frozen_after": "30d" } } }这些值的顺序会受到强制约束：frozen_after必须小于data_retention，并且大于任何downsampling.after。对于没有实际意义的配置，API 会拒绝。
冻结层数据存储在哪里：默认快照仓库
冻结层数据以部分挂载的可搜索快照形式保存，这意味着 DLM（Data Lifecycle Management） 需要一个快照仓库来写入数据。9.5 引入了集群级默认快照仓库，而不再要求你为每个生命周期选择一个仓库。
PUT _cluster/settings{ "persistent": { "repositories.default_repository": "my-snapshot-repo" } }DLM 会将这个仓库用于集群中每个冻结层索引。在 Elastic Cloud Hosted（ECH）上，默认仓库会预先设置为found-snapshots，因此现有集群开箱即用。如果你希望将冻结数据保存在自己控制的存储桶中，也可以将其修改为你自己管理的仓库。这对于希望使用对象版本控制、将生命周期备份到 Glacier，或者其他需要存储桶级访问权限的场景很有用。
无论你在 Kibana 中哪里设置frozen_after，界面都会直接显示当前默认仓库，并提供修改位置的链接，因此你可以清楚地看到冻结数据将写入哪里。
如果集群没有配置默认仓库，你仍然可以使用frozen_after创建生命周期。API 会接受该配置，但返回警告：
{ "acknowledged": true, "warnings": [ { "message": "No default snapshot repository has been configured. Data will not be moved to the frozen tier until a default snapshot repository is configured." } ] }在配置默认仓库并且仓库可用之前，数据会一直保留在热层。如果集群没有有效的 Enterprise 许可证，也采用相同的逻辑。错误会显示在该数据流的数据流生命周期状态 API中。
在 Kibana 中配置 frozen_after
Kibana 9.5 允许你直接在界面中设置frozen_after和默认快照仓库。在Streams中，Retention选项卡会在生命周期时间线上显示冻结阶段，以及热阶段和任何降采样步骤。点击时间线即可打开数据生命周期弹出窗口，设置frozen_after，并在保存之前查看时间线更新后的效果。Index Management的Data Streams页面也会打开相同的弹出窗口。
数据流生命周期中的冻结层转换如何工作
当后备索引的年龄超过frozen_after后，DLM 会依次执行以下五个步骤：
克隆。将索引标记为只读，并将其克隆为一个零副本副本，这样在转换过程中原始索引仍然可用。
强制合并。将克隆索引合并为单个段。完成后会写入一个集群状态标记；重复的强制合并请求，例如发生主节点故障转移之后的请求，会被去重，因此重启不会重复执行已经完成的工作。
快照。将合并后的克隆写入默认仓库，并在成功后将快照名称记录到集群状态中。如果检测到之前尝试产生的停滞快照，DLM 会将其删除并重新执行该步骤。
挂载。根据快照创建一个部分挂载的可搜索快照索引。
交换并删除。一旦挂载索引的分片全部完成分配，就在数据流中以原子方式将其替换原始索引，然后删除原始索引。交换过程是原子的，因此查询结果不会在转换过程中看到数据量下降。
如果某个步骤失败，DLM 会在下一次运行时从最后一个成功的步骤继续重试。
每个步骤都是幂等的，集群状态标记可以确保在主节点故障转移后，已经完成的工作不会被重复执行。并发转换数量会受到限制，因此即使生命周期变更覆盖数千个索引，也不会使集群不堪重负。错误会显示在数据流生命周期状态 API中，并汇总到生命周期健康指标中。
frozen_after 的范围和限制
仅适用于数据索引。
frozen_after适用于数据流的数据索引。故障存储索引目前不支持冻结层，仍然由自身的data_retention设置管理。需要 Enterprise 许可证。DLM 中的冻结层通过可搜索快照实现，因此需要 Enterprise 许可证。你可以在任何许可证级别上写入
frozen_after，但在许可证有效之前，数据不会移动到冻结层。Serverless 会忽略该字段。在 Elastic Cloud Serverless 中，
frozen_after会被接受但被忽略 —— Serverless 会代表你管理分层。内置模板可能包含该字段，因此系统不会拒绝它，但会跳过这一步。
开始使用 frozen_after
在 Kibana 中打开Streams或Index Management，选择一个由数据流生命周期管理的数据流。
打开Edit data lifecycle弹出窗口，设置冻结时间，然后保存。生命周期时间线会显示新的阶段。
在自管理集群中，将
repositories.default_repository设置为你控制的仓库。在 ECH 上，如果你希望零配置，found-snapshots已经配置好。对于声明式工作流，将相同的配置写入索引模板，这样新创建的数据流就会自动采用该生命周期。
了解更多
数据流生命周期
冻结层概览
可搜索快照
管理 Streams 的数据保留
本文中所描述的任何功能或特性的发布时间和推出时间均由 Elastic 自行决定。任何当前尚未提供的功能或特性可能无法按时交付，也可能根本不会交付。
原文：Frozen tier without ILM: data stream lifecycle in Elasticsearch | Elasticsearch Labs