📚 课程目录第2章数据湖与数据仓库的备份差异

数据湖与数据仓库的备份差异

聊备份策略之前，咱们得先搞清楚一个根本问题——你到底在备份什么？

我见过不少团队，把数据湖的备份方案直接套到数据仓库上，结果恢复的时候发现根本对不上。说白了，这两者的底层架构差异太大了，备份逻辑完全是两码事。

数据湖（对象存储）备份特点

数据湖的核心存储是对象存储，比如 AWS S3、Azure Blob 或者 MinIO。这类存储的特点是啥？扁平结构、无限扩展、按量付费。

我个人习惯把对象存储的备份分成三个层次：

桶级别备份：跨区域复制（CRR）或同区域复制（SRR）。这是最粗粒度的方案，整个桶的数据自动同步到另一个区域。
对象级别备份：版本控制 + 生命周期策略。开启版本控制后，每次覆盖写都会保留旧版本，配合过期删除规则，相当于自带时间旅行能力。
增量快照：针对特定前缀或标签的对象集做快照。适合那些不需要全量备份的场景。

我的经验：千万别只依赖跨区域复制。我记得有一次，源桶误删了关键分区，跨区域复制是异步的，删除操作也同步过去了。最后靠版本控制才救回来。所以我的建议是——版本控制 + 跨区域复制一起开，别省那点存储费。

数据湖备份有个天然优势：对象存储的不可变性。你可以设置对象锁定策略，让文件在指定时间内无法被删除或覆盖。这对合规场景特别重要。

备份维度	实现方式	恢复粒度	成本
桶级别	跨区域复制	整个桶	存储费 × 2 + 传输费
对象级别	版本控制	单个文件	存储费 × 版本数
增量快照	定时任务 + 清单	前缀/标签	按扫描量计费

数据仓库（托管表）备份特点

数据仓库这边就完全不一样了。无论是 Snowflake、Redshift 还是 BigQuery，它们的表都是托管表——存储和计算分离，但元数据由平台统一管理。

托管表的备份，核心是备份元数据和事务日志，而不是底层文件。你想想看，底层文件可能被压缩、编码、分片，直接拷贝文件根本恢复不了表结构。

快照备份：大多数云数仓支持创建表或数据库的快照。比如 Snowflake 的 CLONE 命令，零拷贝克隆，瞬间完成。
时间旅行：利用事务日志回滚到指定时间点。一般保留 1-90 天不等，取决于配置。
导出备份：将表数据导出为 Parquet/CSV 到外部存储。这是最传统的方式，适合长期归档。

注意：我曾经遇到一个坑——某数仓的时间旅行功能默认只保留 24 小时。团队以为数据随时能恢复，结果周末出了故障，周一才发现已经过了保留期。所以，一定要检查默认配置，根据业务需求调整保留周期。

托管表备份的恢复速度通常比数据湖快，因为元数据操作是轻量级的。但代价是——你只能恢复到平台支持的保留窗口内。超过窗口的数据，必须依赖导出备份。

Delta Lake 与 Iceberg 的事务日志备份

到了 Lakehouse 时代，事情变得更有意思了。Delta Lake 和 Iceberg 这类表格式，本质上是在对象存储上模拟了数据库的事务能力。它们的核心是事务日志——记录了每一笔变更。

备份事务日志，就是备份表的全部历史。我个人觉得，这是 Lakehouse 备份策略里最容易被忽视的一环。

Delta Lake 的事务日志

Delta Lake 的日志存在 _delta_log/ 目录下，每个 JSON 文件对应一次事务提交。日志文件按版本号递增命名：00000000000000000001.json。

-- 查看 Delta 表的历史
DESCRIBE HISTORY my_table;

-- 恢复到指定版本
RESTORE TABLE my_table TO VERSION AS OF 5;

-- 恢复到指定时间
RESTORE TABLE my_table TO TIMESTAMP AS OF '2024-03-15 10:00:00';

备份 Delta 日志，我建议这样做：

定期将 _delta_log/ 目录复制到另一个桶或区域
配合 VACUUM 策略，确保日志文件在清理前已被备份
日志文件很小，但数量可能很多，建议用 rsync 或 S3 批量操作来同步

Iceberg 的事务日志

Iceberg 的元数据管理更分散。它的日志结构是：

metadata/ 目录下存放元数据文件
每个快照对应一个 snapshot-*.avro 或 snapshot-*.json 文件
version-hint.text 指向当前最新的元数据文件

-- 查看 Iceberg 表的快照历史
SELECT * FROM my_table.snapshots;

-- 时间旅行查询
SELECT * FROM my_table FOR SYSTEM_TIME AS OF '2024-03-15 10:00:00';

-- 回滚到指定快照
CALL my_catalog.system.rollback_to_snapshot('my_db.my_table', 1234567890);

  关键区别：Delta Lake 的日志是线性的、递增的版本号；Iceberg 的日志是图结构的，快照之间可以分支。备份 Iceberg 时，要确保整个 metadata 目录的一致性，不能只备份单个文件。

备份事务日志时，有个细节要注意——日志文件本身是不可变的，一旦写入就不会再修改。这意味着你可以放心地做增量备份，只复制新增的日志文件即可。

我曾经帮一个客户排查恢复失败的问题，发现他们只备份了数据文件，没备份 _delta_log。结果数据文件都在，但表结构全丢了，恢复出来一堆孤立的 Parquet 文件。嗯，那感觉就像你有一堆拼图碎片，但没有图纸。

总结一下我的看法：数据湖备份靠的是存储层的能力，数据仓库备份靠的是平台层的能力，而 Lakehouse 备份靠的是表格式的事务日志。三者没有谁替代谁，而是互补关系。你在设计备份策略时，得先搞清楚你的数据到底在哪一层。