ARTICLE / 2 MIN READ

海量数据的冷热分层、压缩与生命周期管理

从存储成本、查询热度、保留期限和恢复目标出发,设计可持续的大数据存储策略。

数据会不断增长,但所有数据都放在高性能存储上既浪费成本,也会拖慢索引和备份。冷热分层要把访问频率、合规保留和恢复目标放到同一张表里。

用访问热度分层

层级 访问特征 存储策略
热数据 最近 7 至 30 天高频查询 SSD、在线索引
温数据 偶尔报表和回溯 压缩列式文件
冷数据 月度审计或低频取证 低频对象存储
归档 几乎不读但需保留 归档存储,多副本

热度不是按创建时间硬编码。重要活动或审计数据可能在很久以后再次被访问,应支持按查询日志调整层级。

压缩和文件格式

列式格式、字典编码和合适的压缩算法可以显著降低存储和扫描成本。高压缩比通常意味着更高 CPU,查询服务要按 P95 延迟预算选择。

小文件合并要限制并发,避免 compaction 与在线查询抢资源。合并前后记录文件数、总大小和扫描字节变化。

生命周期规则

生命周期至少定义创建、转温、转冷、删除和法律保留五个阶段。删除规则必须带业务确认和恢复窗口,避免误删造成不可逆损失。

事件日志 0-30 天:在线检索
30-180 天:压缩列式 + 低频查询
180 天以后:对象存储归档
合规保留:锁定删除策略

备份与恢复

备份不是复制一份文件。需要明确 RPO、RTO、备份频率、跨区域副本、加密密钥和恢复演练。恢复演练要验证表格式快照、元数据、权限和下游读取是否完整。

成本看板

按业务域统计存储字节、请求次数、跨区域流量、扫描字节、压缩比、compaction 资源和未命中数据。对于长期没有查询的表,先迁移再观察,而不是一次性删除。

大数据成本优化的原则是让每一份数据都有“为什么保留、放在哪里、谁会读、如何恢复”的答案。

GITHUB DISCUSSION

评论与回复

评论保存在 GitHub Discussions,登录 GitHub 后即可参与,发布和回复都在本页完成。

评论区进入视口后自动加载。