1. Lakehouse 备份概述

大家好，我是这次课程的主讲。在数据架构这个行当摸爬滚打十几年，我见过太多因为备份没做好而翻车的案例。今天咱们聊聊 Lakehouse 架构下的备份，先把这个基础概念理清楚。

什么是 Lakehouse？

说白了，Lakehouse 就是数据湖和数据仓库的「合体」。数据湖能存海量原始数据，但查询慢、管理乱；数据仓库查询快、治理好，但存不了非结构化数据。Lakehouse 把两者的优点捏在一起——底层用对象存储（比如 S3、OSS），上层用 Delta Lake、Iceberg 这类表格式做事务和治理。

我习惯这么理解：Lakehouse 像是一个带「超市货架」的「大仓库」。货架（数据仓库层）摆好分类商品方便拿取，仓库深处（数据湖层）堆着还没拆箱的原材料。备份策略得同时照顾这两层。

为什么需要备份？

这个问题我问过不少团队，答案五花八门。有人说是为了合规，有人说是怕误删。其实核心就一条：数据是公司的命根子，丢了就没了。

我在项目中遇到过一件事：某次生产环境升级，脚本写错了一个路径参数，直接把一周的增量数据覆盖了。幸好我们有按小时级别的备份，只丢了 20 分钟的数据。你想想看，如果没有备份，那一周的业务报表全得重跑，客户投诉能把你电话打爆。

具体来说，备份解决这几类问题：

• 硬件故障：磁盘坏了、节点宕了，数据可能永久丢失
• 人为误操作：DROP TABLE、DELETE 忘加 WHERE 条件，我见过不止一次
• 软件 Bug：表格式版本升级出问题，数据文件损坏
• 安全攻击：勒索病毒加密数据，没有备份就只能交赎金
• 合规审计：金融、医疗行业要求数据保留一定年限

备份的核心目标：RPO 和 RTO

做备份策略，绕不开两个指标：RPO 和 RTO。我刚开始做架构时，总觉得这两个概念太理论，后来吃过亏才明白——它们是衡量备份方案好坏的硬标准。

指标	全称	含义	打个比方
RPO	Recovery Point Objective	能恢复到哪个时间点？丢失多少数据？	你开车时看后视镜，RPO 就是后视镜能看到的最近距离
RTO	Recovery Time Objective	恢复需要多长时间？业务中断多久？	车坏了，修好需要多久才能重新上路

举个例子：RPO=1 小时，意味着最多丢失 1 小时的数据；RTO=4 小时，意味着从故障发生到业务恢复，最长需要 4 小时。

我个人的经验是：RPO 和 RTO 是「对赌协议」。你投入多少成本，就获得多好的指标。RPO 越小（比如秒级），备份频率越高，存储成本越大；RTO 越小（比如分钟级），恢复基础设施越复杂，运维成本越高。做架构时一定要和业务方谈清楚：你们能接受丢多少数据？能等多久？

备份策略的演进历史

备份这件事，不是 Lakehouse 才有的。我把它分成四个阶段，你看看自己团队现在处在哪个阶段：

1. 传统数仓时代（2000s）：全量备份为主，每周一次全量，每天一次增量。恢复时先恢复全量，再按顺序应用增量。缺点很明显——全量备份时间长、存储空间大，恢复速度也慢。
2. Hadoop 时代（2010s）：数据量暴增，全量备份变得不现实。出现了快照（Snapshot）和 DistCp 工具。但 HDFS 的快照功能有限，跨集群复制效率低。
3. 云原生时代（2015s）：对象存储成为主流，备份开始依赖存储层的版本控制和跨区域复制。但问题是——版本控制只能防误删，不能防逻辑错误；跨区域复制有延迟，RPO 很难做到分钟级。
4. Lakehouse 时代（2020s 至今）：表格式（Delta Lake、Iceberg、Hudi）自带时间旅行（Time Travel）功能，可以查询历史版本。备份策略从「文件级」升级到「表级」和「事务级」。我们可以做增量克隆、零拷贝克隆、跨表格式的备份恢复。

下面这张图能帮你直观理解这个演进过程：

嗯，这里要注意一点：Lakehouse 的时间旅行虽然强大，但它不是万能的。时间旅行依赖事务日志（Transaction Log），如果日志被清理了，历史版本就找不回来了。所以备份策略不能只靠时间旅行，还得有独立的备份副本。

我个人习惯把 Lakehouse 的备份策略分成三层：

• 存储层备份：对象存储的跨区域复制、版本控制、生命周期管理
• 表格式层备份：Delta Lake 的 VACUUM 策略、历史版本保留、表克隆
• 应用层备份：元数据备份、Catalog 备份、权限策略备份

这三层缺一不可。我在项目中遇到过只做了存储层备份的团队，结果表格式的元数据丢了，数据文件还在但拼不回去——那叫一个尴尬。