用两行 JSON 替换你的 ILM 策略:数据流生命周期新增冻结层支持

作者:来自 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_retentiondownsampling 并列。

bash 复制代码
`PUT _data_stream/my-data-stream/_lifecycle` AI写代码
json 复制代码
`

1.  {
2.    "data_retention": "90d",
3.    "frozen_after": "30d"
4.  }

`AI写代码

在 API 层面,这就是整个功能。my-data-stream 中的索引会在热层保留 30 天,然后移动到冻结层,继续保留 60 天。90 天后,它们会被删除,相应的后备快照也会随之删除。

它可以与生命周期的其他功能组合使用,包括降采样:

bash 复制代码
`PUT _data_stream/my-data-stream/_lifecycle` AI写代码
json 复制代码
`

1.  {
2.    "data_retention": "90d",
3.    "frozen_after": "30d",
4.    "downsampling": [
5.      { "after": "1d", "fixed_interval": "1h" }
6.    ]
7.  }

`AI写代码

索引模板中也可以使用相同的配置:

arduino 复制代码
`PUT _index_template/my-index-template` AI写代码
bash 复制代码
`

1.  {
2.    "index_patterns": ["my-data-stream*"],
3.    "data_stream": {},
4.    "template": {
5.      "lifecycle": {
6.        "data_retention": "90d",
7.        "frozen_after": "30d"
8.      }
9.    }
10.  }

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

这些值的顺序会受到强制约束:frozen_after 必须小于 data_retention,并且大于任何 downsampling.after。对于没有实际意义的配置,API 会拒绝。

冻结层数据存储在哪里:默认快照仓库

冻结层数据以部分挂载的可搜索快照形式保存,这意味着 DLM(Data Lifecycle Management) 需要一个快照仓库来写入数据。9.5 引入了集群级默认快照仓库,而不再要求你为每个生命周期选择一个仓库。

bash 复制代码
`PUT _cluster/settings` AI写代码
json 复制代码
`

1.  {
2.    "persistent": {
3.      "repositories.default_repository": "my-snapshot-repo"
4.    }
5.  }

`AI写代码

DLM 会将这个仓库用于集群中每个冻结层索引。在 Elastic Cloud Hosted(ECH)上,默认仓库会预先设置为 found-snapshots,因此现有集群开箱即用。如果你希望将冻结数据保存在自己控制的存储桶中,也可以将其修改为你自己管理的仓库。这对于希望使用对象版本控制、将生命周期备份到 Glacier,或者其他需要存储桶级访问权限的场景很有用。

无论你在 Kibana 中哪里设置 frozen_after,界面都会直接显示当前默认仓库,并提供修改位置的链接,因此你可以清楚地看到冻结数据将写入哪里。

如果集群没有配置默认仓库,你仍然可以使用 frozen_after 创建生命周期。API 会接受该配置,但返回警告:

markdown 复制代码
`

1.  {
2.    "acknowledged": true,
3.    "warnings": [
4.      {
5.        "message": "No default snapshot repository has been configured. Data will not be moved to the frozen tier until a default snapshot repository is configured."
6.      }
7.    ]
8.  }

`AI写代码

在配置默认仓库并且仓库可用之前,数据会一直保留在热层。如果集群没有有效的 Enterprise 许可证,也采用相同的逻辑。错误会显示在该数据流的**数据流生命周期状态 API**中。

在 Kibana 中配置 frozen_after

Kibana 9.5 允许你直接在界面中设置 frozen_after 和默认快照仓库。在 Streams 中,Retention 选项卡会在生命周期时间线上显示冻结阶段,以及热阶段和任何降采样步骤。点击时间线即可打开数据生命周期弹出窗口,设置 frozen_after,并在保存之前查看时间线更新后的效果。Index ManagementData Streams 页面也会打开相同的弹出窗口。

数据流生命周期中的冻结层转换如何工作

当后备索引的年龄超过 frozen_after 后,DLM 会依次执行以下五个步骤:

  1. 克隆。将索引标记为只读,并将其克隆为一个零副本副本,这样在转换过程中原始索引仍然可用。

  2. 强制合并。将克隆索引合并为单个段。完成后会写入一个集群状态标记;重复的强制合并请求,例如发生主节点故障转移之后的请求,会被去重,因此重启不会重复执行已经完成的工作。

  3. 快照。将合并后的克隆写入默认仓库,并在成功后将快照名称记录到集群状态中。如果检测到之前尝试产生的停滞快照,DLM 会将其删除并重新执行该步骤。

  4. 挂载。根据快照创建一个部分挂载的可搜索快照索引。

  5. 交换并删除。一旦挂载索引的分片全部完成分配,就在数据流中以原子方式将其替换原始索引,然后删除原始索引。交换过程是原子的,因此查询结果不会在转换过程中看到数据量下降。

如果某个步骤失败,DLM 会在下一次运行时从最后一个成功的步骤继续重试。

每个步骤都是幂等的,集群状态标记可以确保在主节点故障转移后,已经完成的工作不会被重复执行。并发转换数量会受到限制,因此即使生命周期变更覆盖数千个索引,也不会使集群不堪重负。错误会显示在**数据流生命周期状态 API**中,并汇总到生命周期健康指标中。

frozen_after 的范围和限制

  • 仅适用于数据索引frozen_after 适用于数据流的数据索引。故障存储索引目前不支持冻结层,仍然由自身的 data_retention 设置管理。

  • 需要 Enterprise 许可证 。DLM 中的冻结层通过可搜索快照实现,因此需要 Enterprise 许可证。你可以在任何许可证级别上写入 frozen_after,但在许可证有效之前,数据不会移动到冻结层。

  • Serverless 会忽略该字段 。在 Elastic Cloud Serverless 中,frozen_after 会被接受但被忽略 ------ Serverless 会代表你管理分层。内置模板可能包含该字段,因此系统不会拒绝它,但会跳过这一步。

开始使用 frozen_after

  1. 在 Kibana 中打开 StreamsIndex Management,选择一个由数据流生命周期管理的数据流。

  2. 打开 Edit data lifecycle 弹出窗口,设置冻结时间,然后保存。生命周期时间线会显示新的阶段。

  3. 在自管理集群中,将 repositories.default_repository 设置为你控制的仓库。在 ECH 上,如果你希望零配置,found-snapshots 已经配置好。

  4. 对于声明式工作流,将相同的配置写入索引模板,这样新创建的数据流就会自动采用该生命周期。

了解更多

本文中所描述的任何功能或特性的发布时间和推出时间均由 Elastic 自行决定。任何当前尚未提供的功能或特性可能无法按时交付,也可能根本不会交付。

原文:Frozen tier without ILM: data stream lifecycle in Elasticsearch | Elasticsearch Labs

相关推荐
AI大模型-小雄16 小时前
Codex写分页接口为什么越翻越慢?用Cursor Pagination解决重复与漏数据
大数据·数据库·elasticsearch·搜索引擎·chatgpt·后端开发·codex
Elasticsearch17 小时前
深入浅出 Elastic 工作流(Workflows):核心架构与十一大顶级字段详解
elasticsearch
Elasticsearch20 小时前
在 Elasticsearch 中构建上下文:AI Indices 如何使用更少的 tokens 为更智能的 agent 提供支持
elasticsearch
淮北4941 天前
ubuntu22 默认输入法调整频率
运维·服务器·git·ubuntu·elasticsearch
Elasticsearch2 天前
Elasticsearch:使用 AI Agent 来创建 workflows
elasticsearch
gll7732 天前
RAG 检索层实战:Redis 缓存 + ES 混合检索 + BGE-Rerank 重排全链路落地与踩坑
elasticsearch
Elasticsearch2 天前
ES 存日志很贵?我用 ES 9.5 把日志从 4.5G 压到 412M 压缩比11.2倍,日志硬扫每秒128万行!
elasticsearch
Elasticsearch2 天前
Elasticsearch 作为统一平台:引入第二套数据系统究竟要付出什么代价
elasticsearch
Elastic 中国社区官方博客2 天前
Elasticsearch:列式索引模式 - Columnar index mode
大数据·数据库·elasticsearch·搜索引擎·全文检索