数据归档与生命周期：冷热分层、保留策略与合规删除

引言

数据平台有一个反直觉的事实：最贵的不是存储，而是没人管的数据。日志表每月新增几百 GB 无人清理，测试表在三年后还占着热存储，被遗忘的中间表堆满了对象存储。存储账单逐年翻倍，却没人说得清钱花在哪。

数据不是"存下来就好"，而是有生命周期的资产——产生、活跃、降温、归档、销毁，每一阶段都该有明确策略。

本文把数据生命周期管理讲清楚：冷热分层怎么设计、保留策略怎么定、归档与恢复怎么做、合规删除怎么落地，以及如何把这一切自动化。

一、为什么需要生命周期管理

1.1 成本失控的根源

1.2 生命周期管理的目标

生命周期管理要同时满足三个目标：控成本（把冷数据放便宜存储）、保性能（热数据要快）、守合规（该删的必须删）。三者常互相冲突，需要按数据类型分别权衡。

1.3 数据分层的基本认知

# 数据价值的时效性
# 0-7 天:   高频访问, 必须热存储
# 7-90 天:  偶尔访问, 温存储
# 90 天-1年: 极少访问, 冷存储
# > 1 年:   审计/合规需要, 归档
# 到期:     销毁或匿名化

访问频率随数据年龄单调下降，这是分层策略成立的前提。

二、冷热分层架构

2.1 分层定义

2.2 分层实现方式

# 方式一: 物理分层(不同表/路径)
#   hot.orders / warm.orders / cold.orders
# 方式二: 分区分层(同表不同分区)
#   orders/dt=2026-10-01 (热) ... orders/dt=2025-01-01 (冷)
# 方式三: 存储策略(对象存储生命周期规则)
#   S3 Lifecycle 按前缀+天数自动转移

实践中推荐分区分层 + 对象存储生命周期规则：表结构不变，按分区年龄自动降级存储级别，对查询透明。

2.3 跨层查询

分层后最大的挑战是查询要跨层。解决思路是让查询引擎支持"多路径表"：新分区在热层，旧分区在冷层，引擎统一扫描，用户无感知。湖仓表格式天然支持这一点。

三、存储分层与成本模型

3.1 对象存储的存储级别

以主流对象存储为例（抽象）：

关键陷阱：低频/归档级别有最小存储期，未到期删除仍按整期收费。频繁转移反而更贵。

3.2 成本核算

# 总成本 = 存储费 + 请求费 + 取回费 + 转移费
# 存储费: 随级别降低而降低
# 请求费: 冷层每次读取更贵
# 取回费: 归档层取回按 GB 计费
# 转移费: 跨层转移可能收费
# 结论: 只有"确实很少访问"的数据才值得降级

3.3 分层收益评估

降级前先估算：数据量 × 单位价差 vs 预期取回频率 × 取回成本。若数据每月被访问一次以上，降到归档层往往得不偿失。

3.4 生命周期规则与查询引擎的配合

对象存储的生命周期规则只负责"把文件搬到便宜层"，它不理解表结构。因此需要查询引擎与表格式配合，才能让"降级后的数据仍可查"。

-- 查看分区年龄与存储级别, 决定降级范围
SELECT dt, count(*) AS files,
       sum(file_size_in_bytes)/1024/1024 AS mb
  FROM lake.orders.files
 WHERE dt < CURRENT_DATE - INTERVAL '90' DAY
 GROUP BY dt ORDER BY dt;

-- 降级由对象存储生命周期规则按前缀自动执行
-- 引擎侧只需保证冷层分区仍在表元数据中可寻址

四、保留策略设计

4.1 按数据分类定策略

保留策略必须按数据类型分别定义，而非一刀切。

4.2 保留策略的表达

# 保留策略配置(抽象)
retention_policies:
  - dataset: ods.orders
    hot_days: 7
    warm_days: 90
    cold_days: 365
    archive_days: 2555        # 7 年, 合规
    action_after: delete      # 到期删除
  - dataset: ods.user_events
    hot_days: 7
    warm_days: 30
    cold_days: 180
    action_after: anonymize   # 到期匿名化

4.3 TTL 与自动过期

对明确的临时数据，直接用 TTL 自动清理最省心。Iceberg 支持按分区过期，对象存储支持按前缀生命周期规则。

-- Iceberg: 删除 90 天前的分区数据
ALTER TABLE ods.temp_staging DROP PARTITION FIELD dt;
DELETE FROM ods.temp_staging WHERE dt < CURRENT_DATE - INTERVAL '90' DAY;

五、归档与恢复

5.1 归档流程

# 归档流程
# 1. 识别: 按保留策略圈定待归档分区
# 2. 导出: 转成归档格式(如压缩 Parquet)
# 3. 转移: 写入归档存储(冷/归档层)
# 4. 校验: 比对行数/校验和
# 5. 清理: 删除热层原数据
# 关键: 归档后元数据仍要保留, 保证可查可恢复

5.2 归档格式选择

优先选列式可查格式（Parquet/ORC），归档后仍能被查询引擎直接读取，避免"归档即失联"。

5.3 恢复流程与 SLA

-- 从归档恢复: 把归档分区重新挂回表
-- 1. 从归档层取回数据(可能需数分钟解冻)
-- 2. 重新注册分区元数据
ALTER TABLE ods.orders ADD PARTITION (dt='2024-01-01')
  LOCATION 's3://archive/orders/dt=2024-01-01';

恢复耗时取决于归档层的解冻时间，深度归档可能数小时，需在 SLA 中明确。

5.4 归档校验清单

归档最怕"归档后才发现文件损坏"。转移完成后必须做一次校验，确认数据完整可读。

# [ ] 行数比对: 归档文件行数 == 源分区行数
# [ ] 校验和: 逐文件比对 checksum 或文件大小
# [ ] 抽样查询: 从归档层随机抽分区, 用引擎读一遍
# [ ] 元数据完整: 分区元数据仍能被 catalog 解析
# [ ] 记录归档清单: 哪些分区去了哪里, 便于日后恢复

六、合规删除与数据主体请求

6.1 为什么删除这么难

合规要求"用户要求删除时必须彻底删除"，但数据湖的不可变文件 + 快照特性让删除变得复杂：直接删文件会破坏快照一致性，删除的记录可能还残留在历史快照、备份、下游副本里。

6.2 删除策略

6.3 数据主体请求（DSR）落地

# DSR 处理流程
# 1. 定位: 在 catalog/血缘中找出所有含该用户数据的表
# 2. 删除: 各表执行删除/匿名化
# 3. 传播: 同步删除下游派生表、缓存、备份
# 4. 快照: 过期相关快照, 防止历史版本残留
# 5. 证明: 记录删除操作作为合规证据

6.4 删除与快照的冲突

删除记录后，历史快照仍引用旧文件。要让删除"生效"，必须过期相关快照并清理孤儿文件，否则被删数据仍可被时间旅行读到——这在合规审计中是严重问题。

七、自动化生命周期流水线

7.1 流水线组成

# 生命周期流水线(抽象)
lifecycle:
  daily:
    - scan_datasets          # 扫描数据集与年龄
    - evaluate_policies      # 评估保留策略
    - tier_transition        # 执行冷热转移
  weekly:
    - archive_candidates     # 归档到期分区
    - expire_snapshots       # 清理过期快照
  monthly:
    - purge_expired          # 销毁到期数据
    - dsr_batch              # 处理批量删除请求
    - cost_report            # 生成成本报告

7.2 与编排和血缘集成

生命周期任务应接入统一调度（Airflow/Dagster），并依赖数据血缘确定影响范围——删除一张表前，要知道哪些下游依赖它。

7.3 审批与护栏

删除是不可逆操作，必须加护栏：批量删除需人工审批、先 dry-run 出清单、保留操作日志、设置删除速率上限。

八、踩坑清单与最佳实践

8.1 分层类坑

• 频繁跨层转移：未考虑最小存储期，转移费比省下的存储费还多。
• 冷层放热数据：查询频繁取回，延迟与费用双输。
• 分层后查询报错：引擎未配置多路径，冷层数据"看不见"。

8.2 保留类坑

• 一刀切保留期：合规数据被过早删除，临时数据永久堆积。
• TTL 误伤：TTL 设太短，删掉了仍在使用的数据。
• 策略无版本：策略变更无记录，无法追溯为何删除。

8.3 删除类坑

• 删了文件不删快照：被删数据仍可通过时间旅行读到。
• 只删主表不删派生：下游聚合表、缓存、备份仍含个人数据。
• 删除无证据：合规审计时拿不出删除记录。
• 误删生产数据：无审批、无 dry-run、无回退方案。

总结

数据生命周期管理的本质，是承认数据有价也有成本。把每类数据的保留策略定义清楚、把冷热分层做成自动化、把删除做成有护栏、有证据的流程，才能在成本、性能与合规之间取得平衡。最贵的从来不是存储本身，而是那些没人负责、只增不减、又不合规的"僵尸数据"。

参考与延伸阅读

• AWS S3 官方文档：存储级别与生命周期规则
• Apache Iceberg 官方文档：分区过期与快照维护
• GDPR 官方指引：数据主体删除请求（DSR）处理
• 数据 FinOps 成本优化 — 存储成本治理全景
• 数据安全与隐私合规 — 合规与隐私工程
• 数据治理与质量 — 元数据与策略管理
• 数据湖技术 — 湖表格式与存储分层基础