1. 灾备与业务连续性导论

在讨论 Databricks 灾备之前，需要先建立一个基本认识：灾备不是“把数据复制一份”这么简单，它要回答的是——当故障发生时，业务能容忍中断多久、能容忍丢多少数据、哪些业务必须优先恢复。这三个问题分别对应 RTO、RPO 和业务影响分析（BIA）。本节先把这些概念在 Databricks 语境下讲清楚，再给出故障域模型和灾备等级划分，为后续章节的具体方案设计打基础。

一、RTO 与 RPO：两个必须量化的时间指标

RTO（Recovery Time Objective，恢复时间目标）指从故障发生到业务恢复可接受服务水平所允许的最长停机时间。它衡量的是“多久能恢复”。RPO（Recovery Point Objective，恢复点目标）指故障发生时允许丢失的数据时间窗口，即最近一次可用恢复点与故障时刻之间的最大可接受差距。它衡量的是“能丢多少数据”。

在 Databricks 平台上，这两个指标不是抽象概念，而是直接映射到具体组件的能力上。例如：

• RPO 通常由数据层的复制方式决定。Delta Lake 表如果使用云存储跨区域复制（如 S3 CRR、ADLS GRS），RPO 取决于复制延迟，常见在分钟级；如果使用 Delta Sharing 或定期快照导出，RPO 可能达到小时级。
• RTO 则取决于计算层和元数据层的恢复速度。集群启动、作业重新调度、Unity Catalog 元数据恢复、外部表位置重建，都会叠加进 RTO。

一个常见的误区是把 RPO 和 RTO 混为一谈。举例来说，某团队每天凌晨 2 点把 Delta 表快照导出到灾备区域，那么 RPO 约为 24 小时；但如果灾备区域已有集群模板和作业定义，故障后 30 分钟内就能拉起计算并挂载数据，RTO 可以做到 30 分钟。两者独立，必须分别设定和验证。

二、Databricks 故障域模型

要设计灾备，先要识别故障域。故障域是指一个故障事件所能影响的最大范围。Databricks 的架构天然分层，故障域也按层划分：

• 计算层故障域：单个集群、单个作业、单个 SQL Warehouse 失效。影响范围限于该计算资源，数据通常不受影响，重启或重建即可恢复。
• 控制平面故障域：Databricks 控制平面（Web 控制台、作业调度、Unity Catalog 元数据服务）在某个区域不可用。此时已有集群可能继续运行，但无法提交新作业、无法访问元数据。
• 数据平面故障域：云存储桶、VNet/子网、Private Link 端点故障。影响数据读写和网络连通性。
• 区域级故障域：整个云区域不可用。这是最严重的故障域，需要跨区域灾备。
• 逻辑故障域：误删表、错误覆盖写入、恶意操作。这类故障不依赖物理区域，但同样需要恢复能力，通常靠 Delta 时间旅行或版本恢复应对。

理解故障域的意义在于：不同故障域需要不同的恢复策略。计算层故障靠重试和重建；区域级故障才需要跨区域灾备。如果对所有故障都按区域级灾备设计，成本会严重浪费。

三、灾备等级划分与选择依据

灾备等级不是越高越好，而是要与业务影响分析结果匹配。上图中给出了从等级 0 到等级 4 的五档划分，每档对应不同的 RTO/RPO 能力和成本量级。

等级 0 适用于内部实验、临时分析等可容忍长时间中断的场景。等级 1 是最常见的起点：每天或每小时把关键 Delta 表导出到灾备区域的对象存储，同时用 Databricks Asset Bundles 或 Terraform 保存作业和集群定义。恢复时需要手动或脚本化重建。等级 2 在等级 1 基础上增加持续数据复制，灾备区保留最小计算资源，故障时快速扩容。等级 3 在灾备区常驻小规模集群，数据近实时同步，可承接部分读流量。等级 4 则是双区同时写入，需要解决冲突合并、全局一致性等问题，通常只在极少数核心交易类场景使用。

选择等级时，建议用下面的判断逻辑：先看业务中断一小时的损失金额，再看数据丢失一小时的影响。如果损失可忽略，等级 0 或 1 即可；如果损失显著但可容忍短暂中断，等级 2；如果中断几乎不可接受，才考虑等级 3 或 4。

四、业务影响分析（BIA）在 Databricks 上的落地

业务影响分析的目标是给每个业务系统或数据产品标注 RTO、RPO 和恢复优先级。在 Databricks 上，BIA 的落地对象不是抽象的“系统”，而是具体的作业、表、Dashboard 和 SQL Warehouse。建议按以下步骤执行：

1. 盘点关键数据产品：列出所有对外提供价值的作业、表、报表和 API。例如“每日销售汇总表”“实时风控特征表”“财务对账作业”。
2. 标注业务影响：对每个对象，记录中断 1 小时、4 小时、24 小时的业务损失等级（高/中/低），以及数据丢失 5 分钟、1 小时、24 小时的影响。
3. 推导 RTO/RPO：根据影响等级反推可接受指标。例如“高影响 + 可容忍 15 分钟中断”对应 RTO≤15min，“高影响 + 可容忍 5 分钟数据丢失”对应 RPO≤5min。
4. 映射到灾备等级：把 RTO/RPO 与上图的等级能力对照，选出最低满足要求的等级，避免过度设计。
5. 记录依赖关系：标注该对象依赖的上游表、Unity Catalog 元数据、外部系统。恢复顺序必须按依赖拓扑排列，否则会出现“表恢复了但上游没恢复”的情况。

五、一个简化的 BIA 示例表

下面给出一个示例表格，展示如何把业务对象、影响等级和灾备等级对应起来。表中数据为教学示例，实际项目需根据业务方确认填写。

这张表的价值在于把“业务语言”翻译成“平台指标”。后续章节中设计跨区域复制、作业容灾、Unity Catalog 元数据备份时，都会回到这张表来判断某个方案是否满足目标。没有 BIA 的灾备设计，很容易变成“为了做而做”，既浪费成本又无法在真正故障时支撑业务决策。

最后强调一点：RTO 和 RPO 是目标，不是承诺。实际恢复时间（RTA）和实际恢复点（RPA）需要通过演练来测量。只有经过定期演练验证的灾备方案，才具备真正的业务连续性价值。