5.4 数据归档与冷热分离

5.4 数据归档与冷热分离

本节摘要：数据越积越多拖慢查询。本节讲清楚冷热数据识别、归档策略、冷存储、TTL 管理，让热表保持小而快。

为什么归档

数据随时间增长——订单、日志、历史记录越积越多。全留热表：

• 查询慢——大表扫描慢。
• 维护难——OPTIMIZE/VACUUM 大表慢。
• 备份慢——备份大表耗时长。
• 成本高——SSD 存所有数据贵。

冷热分离：

• 热数据（近期、频繁访问）留热表（SSD）。
• 冷数据（历史、少访问）归档冷表/冷存储（HDD/对象存储）。

好处：热表小查询快、维护易、备份快、成本降。

冷热数据识别

热数据：

• 近期数据（如近 3 个月订单）。
• 频繁访问（用户查自己订单、报表查近期）。
• 高价值（当前业务依赖）。

冷数据：

• 历史数据（如 3 个月前订单）。
• 少访问（偶尔查询历史、合规留存）。
• 低价值（不直接影响当前业务）。

识别方法：

• 访问频率——监控查询的时间范围分布。
• 业务规则——如订单超 3 个月为冷。
• 存储成本——冷数据用便宜存储。

归档策略

1. 归档表

• 创建历史表（如 orders_archive），结构与热表同。
• 定期迁移：INSERT INTO orders_archive SELECT * FROM orders WHERE create_time < 3 月前。
• 删热表老数据：DELETE FROM orders WHERE create_time < 3 月前（或 DROP PARTITION 分区表）。
• 查询跨热冷：UNION 或视图。

2. 分区归档

• 热表按时间分区（见 3.3）。
• 老分区 EXCHANGE 到归档表，再 DROP PARTITION。
• 快——DROP PARTITION 比 DELETE 快。

3. 冷存储

• 冷数据移到冷存储——HDD、对象存储（S3/OSS）、归档存储。
• 数据库不直接查冷存储——需要时导入或用外部表。
• 适合合规留存（很少查）。

4. 数据仓库

• 历史数据入数据仓库（OLAP）。
• 热库只留近期，分析查询走数仓。
• 适合报表分析场景。

TTL（Time-To-Live）管理

TTL：数据自动过期删除。

• MongoDB：TTL 索引自动删过期文档。
• Redis：TTL 自动删 key。
• Cassandra：TTL 自动删行。
• 关系库：定时任务 DELETE 老数据，或分区 DROP。

TTL 设计：

• 按业务定 TTL——如日志 30 天、会话 1 天、订单永久（归档不删）。
• 分级 TTL——热 30 天、冷 1 年、归档永久。
• 自动化——定时任务或数据库 TTL。

归档实践

1. 归档流程自动化

• 定时任务（如每天）迁移老数据。
• 监控归档成功/失败。
• 归档日志记录。

2. 查询透明

• 应用查询不感知归档——用视图 UNION 热冷。
• 或应用明确查热/冷——按时间路由。

3. 归档验证

• 归档后验证数据完整——行数、校验和。
• 热表删数据前确认归档成功。

4. 回查支持

• 冷数据偶尔要查——提供回查接口。
• 冷存储数据可临时导入或用外部表。

5. 合规留存

• 法规要求留存 N 年（如金融 7 年）。
• 归档冷存储满足合规，不占热库。

归档对性能的影响

热表变小：

• 查询快——扫描少。
• 索引小——缓存命中高。
• 维护快——OPTIMIZE/VACUUM 小表快。

归档操作影响：

• 迁移读老数据——IO 增加，低峰期做。
• DELETE 老数据——产生 undo/redo，PG 死元组需 VACUUM。
• DROP PARTITION——快不产生 undo。

冷查询：

• 跨热冷查询——慢（UNION 大数据）。
• 尽量只查热——应用按时间路由。

⚠️ 常见误读：以为"数据全留热表方便查询"。全留热表越大越慢，维护/备份/成本都增。冷热分离让热表小快，冷数据便宜存。

💡 关键直觉：归档冷热分离——数据增长拖慢查询/维护难/备份慢/成本高。识别热（近期频繁访问高价值）/冷（历史少访问低价值），按访问频率/业务规则/存储成本。策略——归档表（历史表同结构，INSERT 迁移+DELETE/DROP PARTITION 删热，UNION/视图跨查）、分区归档（EXCHANGE 到归档表+DROP PARTITION 快）、冷存储（HDD/对象存储 S3/OSS，数据库不直接查需导入或外部表，合规留存）、数据仓库（历史入数仓 OLAP，热库留近期）。TTL（MongoDB/Redis/Cassandra 原生，关系库定时 DELETE 或分区 DROP，按业务定分级）。实践——自动化定时迁移+监控+日志、查询透明（视图 UNION 或应用路由）、归档验证（行数/校验和，删前确认）、回查支持（接口/临时导入/外部表）、合规留存（法规 N 年冷存储）。影响——热表小查询快索引小维护快、归档低峰期（IO 增加/DELETE 产生 undo 需 VACUUM/DROP PARTITION 快）、冷查询慢（跨热冷 UNION 大数据，尽量只查热按时间路由）。

本节要点回顾

• 归档必要性：数据增长全留热表——查询慢（大表扫描）、维护难（OPTIMIZE/VACUUM 大表慢）、备份慢、成本高（SSD 存所有贵）。冷热分离——热表小快维护易备份快成本降。
• 冷热识别：热（近期 3 个月/频繁访问/高价值当前业务依赖）、冷（历史 3 个月前/少访问/低价值）。方法：访问频率监控（查询时间范围分布）、业务规则（订单超 3 月冷）、存储成本（冷用便宜存储）。
• 归档策略：归档表（orders_archive 同结构，INSERT 迁移+DELETE 热老数据或 DROP PARTITION，UNION/视图跨热冷查）、分区归档（热表按时间分区，EXCHANGE 老分区到归档表+DROP PARTITION 比 DELETE 快不产生 undo）、冷存储（HDD/对象存储 S3/OSS/归档存储，数据库不直接查需导入或外部表，合规留存少查）、数据仓库（历史入数仓 OLAP，热库留近期，报表分析走数仓）。
• TTL 管理：数据自动过期删除。MongoDB TTL 索引/Redis TTL/Cassandra TTL 原生，关系库定时 DELETE 或分区 DROP。按业务定（日志 30 天/会话 1 天/订单永久归档），分级（热 30 天/冷 1 年/归档永久），自动化定时任务或数据库 TTL。
• 实践：自动化（定时每天迁移+监控成功失败+日志）、查询透明（视图 UNION 热冷不感知或应用按时间路由）、归档验证（行数/校验和，删热前确认归档成功）、回查支持（冷数据偶尔查接口/临时导入/外部表）、合规留存（金融 7 年冷存储不占热库）。
• 性能影响：热表变小（查询快扫描少/索引小缓存高/维护快）、归档操作（迁移读老数据 IO 增加低峰期/DELETE 产生 undo redo PG 死元组需 VACUUM/DROP PARTITION 快不产生 undo）、冷查询慢（跨热冷 UNION 大数据，尽量只查热应用按时间路由）。

归档的三个工程要点

归档看着是"搬数据"，工程上有三个决定成败的要点。要点一，删除策略要用低成本方式——归档后的源表清理，逐行删除会产生海量日志与锁竞争，分区表的分区摘除（第 3 章）或分批限速删除是正解；清理窗口与批量大小要写入方案，避免"归档半小时、清理三天"。要点二，冷数据的可查性设计——归档库的表结构与索引按查询模式重新裁剪（冷数据查询通常按时间与少数维度），不必照搬在线库的全套索引；同时给业务方明确的查询路径（在线查近一年、归档查历史），模糊的双查体验会催生"偷偷把冷数据拉回在线"的影子行为。要点三，归档的完整性对账——每次归档跑行数与校验和比对（源减归档等于剩余），差异为零才允许清理源表；这个对账自动化进归档脚本，人工"看起来都对"不算数。三个要点合成一句话：归档是一次数据的新陈代谢，工程目标是无感（在线业务不受扰）、可查（历史随时能取）、无失（数据零丢失）——三者靠的不是勤奋，是方案里的预先设计。

冷热分层的三种架构形态

归档章收官谈冷热分层的架构选择，三种形态各有其位。形态一，同库分区（第 3 章的分区即冷热分离的最简形态）：热分区在高质量存储、冷分区降级存储，查询与维护统一——适合规模中等、查询模式统一的业务。形态二，独立归档库：历史数据搬入专门的归档实例（可以是廉价硬件甚至列式引擎），在线库轻装上阵——适合在线与历史查询模式差异大的业务（在线按键查、历史按分析扫），代价是查询路径分裂。形态三，分层存储引擎（在线库加分析库加对象存储的湖仓形态）：数据按年龄流经多层引擎，每层用最适合的形态服务——适合数据量大、分析需求重的企业级场景，运维复杂度也最高。选型的三问：历史数据的查询频率与模式是什么（决定要不要独立引擎）、团队运维半径多大（决定能养几套系统）、合规保留期多长（决定最冷层的形态）。三种形态没有高下，只有与业务现实的匹配——而"先从最简形态起步、按痛点演进"永远是性价比最高的路径。

数据保命的三个合规锚点

归档章补三个合规锚点——它们常常反过来决定技术方案。锚点一，保留期限：行业法规对各类数据的最低保留年限（交易类常见五到十年）决定了归档库的容量规划与介质选择（超长期数据用最廉价耐久的层）。锚点二，可提供性：监管检查时"时限内提供指定数据"的要求决定了冷层查询的响应能力——纯磁带库满足不了七十二小时出数的要求，对象存储加索引才是合格形态。锚点三，可删除性：用户行使删除权（个人信息保护）时要能跨层定位并删除该用户数据——冷层数据的主键索引（哪个用户在哪些归档批次）是必备设施，事后补建等于重新扫描全部历史。三个锚点的共同启示：合规需求要前置进归档设计——等监管来函再改造，每次都是项目级工程；把它们写进归档方案的需求清单，是数据治理成熟度最直接的试金石。

归档的用户体验设计

归档章补一个常被忽略的维度：归档的"用户体验"——查询路径的变化要让业务方无感或有知。无感设计：统一查询入口内部自动路由（在线查近段、穿透归档查历史）——体验最好但实现成本高（跨源查询的一致性与性能都要兜住），适合历史查询频率可观的场景。有知设计：明确的双入口（在线系统查近一年、归档系统查历史）加界面的清晰引导——实现简单，成本是把"切换"的心智负担给了用户，适合历史查询低频的场景。两种设计的选择标准是历史查询的真实频率——统计三个月再定，别拍脑袋。而无论哪种，都要防"影子回流"：业务方嫌归档慢，偷偷把历史数据拉回在线库自己建表查——及时发现（在线库的异常增长监控）与疏导（优化归档查询体验）双管齐下，堵是堵不住的，体验问题最终只能靠体验解决。

收尾一句：归档体系建成后每年做一次"归档价值回顾"——统计冷层的历史查询量与节省的在线资源成本，把归档从"技术后厨"变成"有经营数据的资产"；这个动作让数据治理的投入可量化，也让下一次申请归档预算时，你有数字而不是情怀。

补最后一个实操细节：归档任务的执行时间要避开统计收集与备份的窗口（第 7 小节维护编排的原则），且归档自身的限速参数（每批行数、批间隔）要在首次执行时实测校准——不限速的归档曾在无数个夜晚悄悄拖垮在线库，而限速过严又让归档窗口装不下任务；"批行数千级、间隔百毫秒级"是常见的起点，按你的库与窗口微调。归档是慢工，慢工的纪律是匀速。