2. Databricks架构与故障点分析
要设计一套真正可落地的Databricks灾备方案，第一步不是选工具，而是把Databricks的架构拆开看清楚：哪些组件跑在谁的账号里、哪些数据落在哪个区域、哪些依赖一旦中断就会让整个工作负载停摆。Databricks最核心的架构特征是控制平面（Control Plane）与数据平面（Data Plane）分离，这一设计直接决定了故障域边界和恢复策略的取舍。
控制平面与数据平面：职责与故障域
控制平面由Databricks托管，运行在Databricks自己的云账号中，主要承载：Web UI与REST API、作业调度器（Jobs Scheduler）、集群管理器、笔记本与工作区元数据（Workspace、Notebook、Repo）、Unity Catalog的元数据服务、身份认证与SCIM同步、以及集群启动的编排逻辑。数据平面则运行在客户自己的云账号（经典部署模式）中，承载：计算资源（All-Purpose集群、Job集群、SQL Warehouse的VM/容器）、DBFS根存储（S3/ADLS/GCS桶）、集群日志与Spark事件日志、以及实际读写业务数据的存储路径。
这种分离带来两个关键结论。第一，数据平面故障不会导致数据丢失，因为业务数据始终在客户账号的存储中，控制平面只是“指挥者”。第二，控制平面故障会导致无法启动新集群、无法提交新作业、无法访问UI，但已经在运行的集群和作业通常可以继续执行——这是灾备设计中非常重要的“降级运行”窗口。
区域与可用区拓扑
Databricks工作区（Workspace）是区域级（Regional）资源，创建时必须选定一个云区域（如eastus2、westeurope）。控制平面在该区域内以多可用区方式部署，具备AZ级容错；数据平面中的集群节点分布在客户指定的可用区中，DBFS根存储使用区域级对象存储（如S3、ADLS Gen2），本身具备跨AZ冗余。
需要特别注意的是：Databricks工作区不跨区域。这意味着区域级故障（整个eastus2不可用）无法通过“同工作区切换AZ”来恢复，必须依赖另一个区域的工作区。这是灾备方案中“区域对”设计的根本原因。典型做法是选择同一地理区域内的配对区域（如eastus2 ↔ centralus，或westeurope ↔ northeurope），以降低跨区域复制延迟并满足数据驻留合规要求。
关键组件依赖链与单点故障识别
把架构拆开后，可以沿着“用户请求 → 控制平面 → 数据平面 → 存储”这条链路逐段识别单点故障。以下依赖关系是灾备设计中必须逐一确认的：
- 控制平面区域级单点：工作区绑定单一区域，该区域控制平面不可用时，无法启动集群、提交作业、访问UI。这是最高优先级的SPOF。
- 云存储账户：DBFS根存储和业务数据存储若使用单一存储账户且未开启跨区域复制（CRR/GZRS），区域故障将导致数据不可访问。需确认存储账户的冗余类型（LRS/ZRS/GRS/GZRS）。
- 元数据存储：Unity Catalog的元数据由控制平面托管，若未配置跨区域元数据同步或外部Hive Metastore，灾备区域需要重建Catalog结构。
- 身份与网络：SCIM同步源（如Entra ID）、Private Link/Private Endpoint、防火墙规则、DNS解析，这些在灾备区域都需要预先配置，否则即使工作区恢复也无法连通。
- 作业与集群配置：Job定义、集群策略、库依赖、Init脚本，若未通过Terraform/Asset Bundles等IaC方式管理，灾备切换时需要手工重建，RTO会显著拉长。
故障影响矩阵与恢复优先级
基于上述依赖链，可以建立一张故障影响矩阵，用于指导恢复顺序和演练重点。下表为示例性分析框架，具体RTO/RPO需结合业务SLA确定：
| 故障对象 | 影响范围 | 数据是否丢失 | 恢复手段 | 优先级 |
|---|---|---|---|---|
| 控制平面（区域级） | 无法启停集群、提交作业、访问UI | 否 | 切换至灾备区域工作区 | P0 |
| 单一可用区 | 部分Executor丢失，作业重试 | 否 | 集群自动重调度，无需人工 | P3 |
| DBFS根存储（LRS） | 集群无法读写临时数据、日志 | 可能 | 切换至GRS/GZRS副本或灾备存储 | P1 |
| Unity Catalog元数据 | 表/权限不可解析，作业失败 | 否（需重建） | 从IaC或备份恢复Catalog定义 | P1 |
| SCIM / 身份源 | 新用户无法登录，权限同步中断 | 否 | 启用灾备区域身份集成 | P2 |
灾备设计中的关键确认项
在实际项目中，建议在方案设计阶段完成以下确认，避免灾备切换时才发现缺口：
- 确认当前工作区所在区域及其配对灾备区域，检查两区域是否支持所需的VM SKU和存储类型。
- 确认DBFS根存储和业务数据存储的冗余级别，若为LRS，评估升级为ZRS/GRS的成本与影响。
- 确认Unity Catalog元数据的备份方式：是否使用
databricks unity-catalog导出、是否有外部Hive Metastore、是否通过Terraform管理。 - 确认作业与集群配置是否已IaC化（Databricks Asset Bundles / Terraform Provider），灾备区域能否一键部署。
- 确认网络连通性：Private Link、DNS、防火墙规则在灾备区域是否已预置。
- 确认身份集成：灾备区域工作区是否已配置相同的SCIM源和权限映射。
完成以上分析后，你就得到了一张清晰的“故障地图”：哪些是区域级SPOF、哪些是AZ级可自愈、哪些需要人工介入。这张地图是后续设计RTO/RPO目标、选择复制策略和编排切换流程的直接输入。下一阶段的工作，就是围绕这些故障点逐一设计恢复路径和验证方法。