2. Databricks架构与AI工作负载剖析

要谈 Databricks 的灾备恢复，必须先看清它的架构骨架。Databricks 采用控制面（Control Plane）与数据面（Data Plane）分离的设计，这一分离不仅是产品形态，更直接决定了故障发生时“哪些东西会一起挂、哪些能独立存活”。理解这一点，是后续设计 RTO/RPO 目标、选择恢复策略的前提。

控制面与数据面：职责边界

控制面由 Databricks 托管，运行在 Databricks 自己的云账户中，核心职责包括：Web 控制台与 REST API、作业调度器（Jobs Scheduler）、集群管理器（Cluster Manager）、笔记本与工作区元数据、Unity Catalog 的元数据服务、以及身份认证与权限校验。它不存储用户数据，也不执行用户的计算任务，本质上是“大脑与调度中枢”。

数据面运行在客户自己的云账户（经典部署模式）中，包含计算资源（Driver 与 Worker 组成的 Spark 集群、用于模型服务的推理集群）和存储资源（云对象存储中的 Delta 表、DBFS 挂载点、模型工件）。数据面是真正“干活”的地方：读取数据、执行训练、返回推理结果。

两者通过一条受控的安全通道通信：控制面下发集群创建指令、作业定义、凭据；数据面回传集群状态、日志、指标。这条通道一旦中断，已有集群可能继续运行，但无法新建集群、无法提交新作业、无法通过 UI 查看状态——这是灾备场景中非常典型的一种“半可用”状态。

AI 工作负载的依赖链与故障影响面

Databricks 上的 AI 工作负载并非孤立运行，它们共享一条从数据到服务的依赖链。理解这条链，才能判断“哪个环节断了，会影响谁”。

特征工程位于链条最上游。它依赖 Delta 表或外部数据源，通过 Spark 作业计算特征并写入特征存储（Feature Store）。特征工程通常是批处理或流式作业，对计算资源和存储读取带宽敏感。如果存储层不可用，特征工程立即失败；如果控制面不可用，已运行的作业可能继续，但新作业无法调度。

模型训练依赖特征表、训练框架（如 MLflow、PyTorch、XGBoost）和 GPU 计算资源。训练作业通常运行时间长、检查点频繁。训练过程中如果数据面存储中断，检查点写入失败，训练可能崩溃或回滚到上一个检查点。如果控制面中断，训练本身可能继续，但 MLflow 实验跟踪、模型注册会失败，导致训练结果无法被记录和版本化。

模型推理分为批推理和在线服务两种。批推理依赖模型工件和输入数据表，通常以作业形式运行；在线服务则依赖模型服务集群（Model Serving），对延迟和可用性要求最高。在线推理的故障影响面最直接：服务集群不可用，业务侧立即感知。值得注意的是，在线服务集群通常运行在数据面，但模型版本、路由配置等元数据由控制面管理，因此控制面故障可能导致“服务还在跑，但无法更新模型版本或调整流量”。

三者之间的依赖关系可以概括为：特征工程 → 训练 → 推理，但实际生产中往往存在反馈回路——推理结果回流为新的训练数据，形成持续迭代。灾备设计必须考虑这条链上每个环节的恢复优先级。

故障影响面的分级判断

并非所有故障都需要同等对待。可以按影响面将故障分为三级：

• 一级（全局中断）：控制面与数据面同时不可用，或客户云账户区域级故障。此时所有工作负载停止，需要启动跨区域灾备切换。RTO 通常以小时计，RPO 取决于数据复制策略。
• 二级（控制面中断）：数据面仍在运行，已有集群和作业继续执行，但无法提交新作业、无法查看状态、无法更新配置。影响面是“运维与调度”，而非“计算与数据”。恢复重点是控制面通道恢复后的状态同步。
• 三级（数据面局部故障）：例如某个可用区计算资源不足、某张 Delta 表损坏、某个模型服务实例崩溃。影响面局限于特定工作负载，可通过重试、切换实例或从备份恢复解决。

灾备设计的关键启示

基于上述架构分析，Databricks 灾备设计应遵循几条原则。第一，数据面优先：存储和计算是业务连续性的根基，控制面恢复可以稍后，但数据不能丢。第二，元数据必须备份：Unity Catalog 的元数据、作业定义、笔记本、MLflow 实验记录，这些控制面资产一旦丢失，即使数据面完好，也无法快速重建工作负载。第三，依赖链要逐段验证：灾备演练不能只验证“集群能起来”，还要验证特征表可读、模型可加载、推理端点可响应。第四，区分恢复优先级：在线推理通常优先于批训练，特征工程优先于探索性分析。