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

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

• 时间序列索引设计（按时间切分索引）
• 热/温/冷 分层与硬件资源规划
• 自动化的保留与归档流程（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 说明，可以参考：

• 数据退役与保留：让老索引优雅下线
• 索引模板
• 索引与分片设计（实践指南）

参考手册（API 与参数） #

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

• 数据生命周期
• 索引模板
• ILM API
• 备份与恢复