1. 课程导入与灾备认知
在传统数据平台时代，灾备的核心命题相对清晰：数据库能否在故障后恢复、备份能否按时完成、主备切换需要多久。但当数据平台演进为承载机器学习训练、特征工程、向量检索与大模型推理的 Databricks AI 平台后，业务连续性的边界被显著拉宽。一次区域级故障影响的可能不只是某张报表，而是实时推荐、风控评分、智能问答等在线 AI 服务；一次误删操作损失的也不只是数据表，而是模型训练所依赖的特征版本、实验记录与推理端点配置。因此，理解 Databricks AI 灾备，首先要理解它保护的对象已经从"数据"扩展为"数据 + 计算 + 模型 + 服务 + 元数据"的复合资产。
一、Databricks AI 平台为什么更难做灾备
Databricks 的典型架构由控制平面（Control Plane）与数据平面（Data Plane）组成。控制平面承载工作区管理、作业调度、集群编排、Unity Catalog 元数据、笔记本与权限配置；数据平面则运行在客户云账号的 VPC 中，承载实际的计算集群与数据访问。这种分离设计带来了弹性与隔离优势，也让灾备设计必须同时考虑两侧：控制平面故障时，作业无法提交、集群无法创建；数据平面故障时，即使控制台可用，计算与存储访问也会中断。
更复杂的是 AI 工作负载的依赖链。一个在线推理服务通常依赖：Unity Catalog 中的模型注册版本、特征表或向量索引、推理集群配置、服务端点、以及上游数据管道。这条链上任一环节缺失，服务都无法正常提供。传统灾备只关注"数据副本是否可用"，而 AI 灾备必须回答"模型能否重新加载、特征能否对齐、端点能否重新拉起、权限与血缘是否一致"。
① 数据资产：Delta 表、Parquet 文件、向量索引、特征表；
② 计算资产：集群策略、作业定义、SQL 仓库配置；
③ 模型资产：MLflow 实验、模型注册版本、推理代码；
④ 服务资产：Model Serving 端点、在线特征服务；
⑤ 元数据与治理：Unity Catalog、权限、血缘、审计日志。
二、RTO 与 RPO：把业务语言翻译成技术指标
灾备目标通常用两个指标衡量。RPO（Recovery Point Objective，恢复点目标）描述"允许丢失多少数据"，本质是时间维度上的数据新鲜度要求；RTO（Recovery Time Objective，恢复时间目标）描述"允许中断多久"，本质是从故障发生到业务恢复可用的时间上限。二者共同决定了灾备方案的成本与复杂度。
举例说明：某电商的实时推荐服务要求 RTO ≤ 30 分钟、RPO ≤ 5 分钟。这意味着故障后半小时内必须恢复推理能力，且最多只能丢失最近 5 分钟的行为数据。若采用跨区域热备，RPO 可压到分钟级，但成本高；若采用每日快照，RPO 可能达到 24 小时，无法满足要求。因此 RPO/RTO 不是拍脑袋定的，而是由业务影响分析（BIA）反推出来的。
| 业务场景 | 典型 RTO | 典型 RPO | 灾备策略倾向 |
|---|---|---|---|
| 在线 AI 推理服务 | ≤ 15 分钟 | ≤ 5 分钟 | 跨区域热备 / 多活 |
| 实时特征管道 | ≤ 30 分钟 | ≤ 5 分钟 | 流式复制 + 检查点 |
| 模型训练与实验 | ≤ 4 小时 | ≤ 1 小时 | 温备 + 定期快照 |
| 历史分析与报表 | ≤ 24 小时 | ≤ 24 小时 | 冷备 + 对象存储复制 |
需要强调的是，RTO 与 RPO 是"目标"而非"承诺"。实际达成能力取决于备份频率、复制链路带宽、恢复演练结果。课程后续会反复强调：没有演练过的灾备方案，等于没有灾备方案。
三、灾备恢复的四个关键阶段
从故障发生到业务恢复，Databricks AI 灾备通常经历四个阶段，每个阶段都有明确的输入、动作与判断依据。下图展示了这一恢复链路的核心结构与依赖关系。
四、课程整体学习路径与实战项目
本课程围绕"认知—设计—实施—验证—优化"的主线展开，共 30 章。前段建立灾备认知与目标体系，中段深入 Databricks 各层级的备份、复制与恢复技术，后段聚焦 AI 特有资产（模型、特征、向量索引、推理端点）的灾备实践，并以一个贯穿式实战项目收束。
实战项目设定为：为一家使用 Databricks 提供实时推荐与智能客服的零售企业，设计并演练一套跨区域灾备方案。项目要求明确 RTO ≤ 30 分钟、RPO ≤ 5 分钟，覆盖 Delta 表、MLflow 模型、Feature Store 特征表与 Model Serving 端点。学员需要完成现状评估、方案设计、脚本编写、故障注入演练与恢复验证报告。项目中的参数（如区域、表规模、复制频率）均为教学示例，学员可根据实际环境调整。