保留与降采样解决什么
时序数据的存储成本随时间线性增长，通行做法是分层保存：原始高精度数据只保留很短一段时间用来排查故障，再把它们降采样成低精度数据长期保留。保留策略负责自动清理过期数据，降采样负责把分钟级聚合成小时或天级，两者配合把长期成本压到可接受的水平。
基本信息
| 原始层 | 秒级或分钟级精度，保留 7 到 30 天，支撑故障排查与回溯 |
|---|---|
| 聚合层 | 按 5 分钟、1 小时、1 天窗口聚合（avg / max / min / count），保留数月至数年 |
| 实现方式 | InfluxDB 2.x 用 bucket 保留期加 task 降采样；1.x 用 retention policy 加 continuous query |
| 降采样指标 | 必须一并保留最大值与计数，避免均值掩盖尖峰 |
| 任务幂等 | 按窗口边界重算并覆盖写入，重跑不产生重复点 |
典型使用场景
- 容量控制：原始数据保留一周，聚合数据保留两年
- 长期趋势分析：只查询小时或天级聚合结果
- 故障排查：在原始数据保留期内精确定位问题时间点
- 成本优化：把老数据换成更低精度与更小体积
- 报表与容量规划：用长期聚合数据做趋势评估
分层结构与常用命令
分层结构与常用命令
分层示意：
原始 bucket：autogen 精度 10s 保留 7 天
→ task 每小时聚合 avg / max / count
聚合 bucket：downsampled 精度 1h 保留 730 天
# InfluxDB 2.x 查看已有 bucket 与保留期
influx bucket list
# 创建带保留期的 bucket（保留 7 天）
influx bucket create --name raw --retention 168h --org myorg
# 查看降采样任务与最近运行状态
influx task list
influx task logs --task-id <task_id>分层策略对照
| 层级 | 精度 | 保留期 | 用途 |
|---|---|---|---|
| 原始层 | 秒级到分钟级 | 7 到 30 天 | 故障排查与精确回溯 |
| 小时聚合 | 1 小时 | 数月至一年 | 日常趋势看板 |
| 天级聚合 | 1 天 | 一年以上 | 容量规划与长期报表 |
降采样不能只保留平均值：容量与尖峰排查需要最大值，统计口径需要计数与总和；只存均值会在出现异常峰时严重失真。
降采样任务应设计成幂等：按窗口边界重算并覆盖写入，任务延迟或重跑时才不会产生重复点，也不会漏掉中间窗口。