---
title: "数据生命周期与保留策略"
date: 0001-01-01
description: "从业务合规与成本出发，设计 Easysearch 中的冷热分层、保留窗口、归档与删除策略。"
summary: "数据生命周期与保留策略 #  这篇从“业务数据要活多久”的角度出发，帮你把几块能力串在一起：
 时间序列索引设计（按时间切分索引） 热/温/冷 分层与硬件资源规划 自动化的保留与归档流程（ILM/SLM 思路） data-retention 里讲到的删除/关闭/快照等具体动作  如果你只想记住一句话：先画清楚数据时间轴，再用索引 + 模板 + 生命周期策略把它搬进 Easysearch。
1. 先画一条“数据时间轴” #  通常可以按“价值 + 访问频率”粗分为几段：
 实时区（Hot）：最近几小时～几天，写入密集、查询频繁，对延迟和可用性要求最高。 近线/历史区（Warm/Cold）：最近几周～几个月，主要用于排查与报表，对延迟容忍度更高。 归档区（Archive）：为了合规或审计留存多年，几乎不查，只要“能找回来”。  每一段都需要明确三件事：
 保留多久（例如：实时 7 天、近线 90 天、归档 3 年） 大致容量（每天多少文档/多少 GB） 访问模式（实时 OLTP vs 批量统计/偶尔查询）  有了这条时间轴，后面的索引结构、硬件资源和自动化策略才有落点。
2. 把时间轴映射到索引与模板 #  2.1 按时间切索引：一天/一周/一月？ #  结合业务特征和容量估算，选择合适的时间粒度：
 高流量日志：通常是按天建索引：logs-2026.02.04 中等流量：可以按周：metrics-2026.w05 低流量：甚至可以按月：audit-2026.02  核心目标：
 单个分片不要过大（影响恢复和迁移） 单个索引不要包含“过长时间跨度”的数据（否则删除/归档粒度太粗）  2.2 用索引模板固化生命周期相关设置 #  为一类时间序列业务准备一个模板，例如 logs-*："
---


# 数据生命周期与保留策略

这篇从“业务数据要活多久”的角度出发，帮你把几块能力串在一起：

- 时间序列索引设计（按时间切分索引）
- 热/温/冷 分层与硬件资源规划
- 自动化的保留与归档流程（ILM/SLM 思路）
- `data-retention` 里讲到的删除/关闭/快照等具体动作

如果你只想记住一句话：**先画清楚数据时间轴，再用索引 + 模板 + 生命周期策略把它搬进 Easysearch**。

## 1. 先画一条“数据时间轴”

通常可以按“价值 + 访问频率”粗分为几段：

- **实时区（Hot）**：最近几小时～几天，写入密集、查询频繁，对延迟和可用性要求最高。
- **近线/历史区（Warm/Cold）**：最近几周～几个月，主要用于排查与报表，对延迟容忍度更高。
- **归档区（Archive）**：为了合规或审计留存多年，几乎不查，只要“能找回来”。

每一段都需要明确三件事：

1. **保留多久**（例如：实时 7 天、近线 90 天、归档 3 年）
2. **大致容量**（每天多少文档/多少 GB）
3. **访问模式**（实时 OLTP vs 批量统计/偶尔查询）

有了这条时间轴，后面的索引结构、硬件资源和自动化策略才有落点。

## 2. 把时间轴映射到索引与模板

### 2.1 按时间切索引：一天/一周/一月？

结合业务特征和容量估算，选择合适的时间粒度：

- 高流量日志：通常是**按天**建索引：`logs-2026.02.04`
- 中等流量：可以**按周**：`metrics-2026.w05`
- 低流量：甚至可以**按月**：`audit-2026.02`

核心目标：

- 单个分片不要过大（影响恢复和迁移）
- 单个索引不要包含“过长时间跨度”的数据（否则删除/归档粒度太粗）

### 2.2 用索引模板固化生命周期相关设置

为一类时间序列业务准备一个模板，例如 `logs-*`：

- 默认 `number_of_shards` / `number_of_replicas`
- 分词与 mapping 策略
- 默认别名，比如写入别名 `logs-write`、查询别名 `logs-recent`
- （可选）与生命周期策略关联的元数据标签

详细的模板能力和写法见：`ingest-and-storage/index-templates.md`。

## 3. 生命周期策略：从“写入”一路走到“删除”

无论底层实现是基于 ILM/SLM 还是自建定时任务，整条链路大致会包含这些步骤：

1. **创建与写入阶段（Hot）**
   - 通过写入别名把新数据写入当前“活跃索引”
   - 控制索引大小（按天切/按体积切，避免单索引过大）
2. **降温阶段（Warm/Cold）**
   - 当索引不再写入：迁移到更便宜的节点（冷热分层）
   - 可选：对旧索引执行 `_forcemerge`，减少段数量
3. **冻结/关闭阶段**
   - 对极少访问但仍需在线保留的数据，可以关闭索引减少运行时资源
4. **归档阶段（Archive）**
   - 定期为即将删除的索引做快照，存到更便宜的长期存储
5. **删除阶段（Delete）**
   - 删除已快照的旧索引，释放线上集群的磁盘与资源

在 Easysearch 中，可以通过：

- 索引设置 + 节点属性，实现热/温/冷节点的迁移
- 快照与恢复 API，完成归档与按需回溯
- 定时任务或运维平台，把这些动作自动化

更细致的“每一步怎么做”可以参见 `operations/data-retention.md`。

## 4. ILM/SLM 思路融入你的流程

下面是 ILM/SLM 的典型管理模式，可以直接用在 Easysearch 中：

- **索引生命周期（ILM 思路）**
  - Hot：创建索引、写入、滚动生成新索引
  - Warm：降低副本数、迁移到温节点、forcemerge
  - Cold：迁往更便宜的节点，降低资源占用
  - Delete：到达保留期后删除索引
- **快照生命周期（SLM 思路）**
  - 定期对某些索引模式做快照（比如每天一次）
  - 为快照本身设置保留策略（如保留最近 N 份）

在 Easysearch 的实践里，你可以：

- 在索引模板中给不同阶段的索引打好标签（如 `lifecycle: hot/warm/cold`）
- 让外部调度系统或平台根据标签和时间窗触发相应动作
- 把“写入别名 + 滚动新索引 + 生命周期动作”统一当成一个 pipeline 来设计

## 5. 与业务/合规/运维一起确认的 checklist

在真正落地前，建议至少一起确认这些问题：

- **合规要求**
  - 不同类型数据（用户行为日志、审计日志、交易记录）的最短/最长保留期？
  - 是否需要“不可篡改”“只能追加”等额外约束？
- **查询需求**
  - 实时排查需要多大的时间窗口？（例如近 7 天）
  - 报表和稽核通常会查多久之前的数据？（例如近 6 个月）
  - 归档数据是否允许通过线下导出/恢复再分析？
- **成本与资源**
  - 热节点预算 vs 温/冷节点预算？
  - 归档存储（对象存储等）的价格与可用性？
- **操作窗口**
  - 夜间是否有允许执行 forcemerge/快照/迁移的维护窗口？
  - 是否有统一的任务编排平台可以承载这些周期任务？

这些答案会直接影响你最终选用的“粒度 + 保留期 + 分层策略”。

## 6. 小结与延伸阅读

- **先画清业务侧的数据时间轴**，再决定索引粒度与保留期
- 把“按时间切索引 + 热/温/冷分层 + 快照归档”当成一个整体生命周期来设计
- 把生命周期策略固化进索引模板与标准化流程，而不是靠人工记忆

进一步的实现细节和 API 说明，可以参考：

- [数据退役与保留：让老索引优雅下线](../operations/data-retention.md)
- [索引模板]({{< relref "/docs/operations/data-management/index-templates" >}})
- [索引与分片设计（实践指南）](./index-design.md)

## 参考手册（API 与参数）

如果你在落地冷热分层与保留策略时需要具体参数，可以参考：

- [数据生命周期]({{< relref "/docs/features/data-retention/lifecycle" >}})
- [索引模板]({{< relref "/docs/operations/data-management/index-templates" >}})
- [ILM API]({{< relref "/docs/features/data-retention/ilm.md" >}})
- [备份与恢复]({{< relref "/docs/features/data-retention/backup-restore" >}})