3. 灾备恢复核心概念与策略

在 Databricks AI 场景中，灾备恢复策略的选择直接决定了模型训练、特征工程、推理服务在故障发生时能否继续对外提供价值。与传统的数据库灾备不同，Databricks 的灾备对象既包括元数据（Unity Catalog、作业定义、集群策略），也包括数据资产（Delta 表、特征表、向量索引）以及计算与推理端点。因此，热备、温备、冷备、多活、双活这五种模式在 Databricks 中并不是简单的“切换速度”差异，而是对元数据、数据、计算、推理四层恢复能力的组合取舍。

五种模式的核心定义与 Databricks 映射

冷备（Cold Standby）指灾备侧只保留数据副本和基础设施定义，计算资源、集群、推理端点均不常驻。故障时先恢复元数据与数据，再按需拉起集群和模型服务。在 Databricks 中，典型做法是把 Delta 表通过 deep clone 或云存储跨区域复制到灾备区域，Unity Catalog 的 metastore 通过 CREATE CATALOG ... MANAGED LOCATION 指向灾备存储，作业与集群策略以 JSON/Terraform 形式保存在代码仓库中。恢复时执行 Terraform apply 重建工作区对象，再启动集群。冷备成本最低，但 RTO 通常在小时级，RPO 取决于复制频率，可能达到小时级。

温备（Warm Standby）在灾备侧保留数据副本、元数据定义以及部分常驻计算资源（如一个最小规模的 SQL Warehouse 或通用集群），但推理端点、GPU 集群不常驻。故障时只需扩容计算并启动推理服务。Databricks 中可通过 Databricks Asset Bundles 把作业、管道、模型注册定义同步到灾备工作区，模型权重存放在灾备区域的 Unity Catalog Volume 中。温备的 RTO 通常在 15～60 分钟，RPO 可做到分钟级，成本适中，是多数企业 AI 平台的默认选择。

热备（Hot Standby）在灾备侧保持与生产侧几乎对等的计算与推理资源，数据持续同步，模型端点处于可接收流量的状态，但通常不承载生产流量或只承载极小比例流量。Databricks 中可通过 Model Serving 在灾备区域部署同名端点，特征表通过 Delta Live Tables 持续刷新，向量索引通过定期重建保持接近生产。热备 RTO 可到分钟级，RPO 秒级到分钟级，但成本接近双活。

双活（Active-Active）指两个区域同时承载生产流量，互为备份。在 Databricks AI 场景中，双活要求模型端点、特征表、向量索引在两个区域都可读写，且需要解决数据冲突与一致性。常见做法是按用户或请求维度做流量分区，例如按地理区域路由，避免同一特征行在两区域并发写入。双活的 RTO 接近零，RPO 接近零，但架构复杂度和成本最高。

多活（Multi-Active）是双活的扩展，指三个及以上区域同时承载流量。Databricks 中多活通常用于全球业务，需要 Unity Catalog 跨区域元数据同步、Delta Sharing 或 Lakehouse Federation 来统一数据视图。多活的选型门槛最高，一般只在监管要求或全球低延迟场景下采用。

Databricks AI 场景下的适用性分析

选择哪种模式，关键看 AI 负载对“中断”的容忍度。以下从四个维度展开。

训练与批推理负载通常可以容忍小时级中断，因为训练任务本身可以重跑，批推理可以延迟。这类负载适合冷备或温备。冷备下，Delta 表通过 CREATE TABLE ... DEEP CLONE 定期同步，作业定义用 Databricks Asset Bundles 管理，故障时重建工作区并重跑。温备下，可以保留一个最小 SQL Warehouse 用于元数据查询和轻量验证，GPU 集群按需拉起。

在线推理与实时特征服务对中断敏感，通常要求分钟级甚至秒级恢复。这类负载适合热备或双活。热备下，Model Serving 端点在灾备区域常驻，但可以通过路由权重设为 0，故障时把权重切到 100。特征表通过 Delta Live Tables 的 continuous 模式持续刷新，向量索引通过定时任务重建。双活下，两个区域的端点都接收流量，需要按请求维度做一致性处理，例如同一用户的特征读写固定路由到同一区域。

向量检索与 RAG 服务的灾备有其特殊性：向量索引重建耗时较长，且索引与源数据之间可能存在版本差异。冷备下，灾备侧只保留源 Delta 表，故障时重建索引，RTO 可能达到数小时。温备下，可以定期在灾备侧重建索引并保留，RTO 可压缩到 30 分钟以内。热备下，索引持续同步，RTO 分钟级。因此，RAG 服务通常至少需要温备，核心业务建议热备。

模型注册与治理是容易被忽视的一层。Unity Catalog 中的模型版本、权限、血缘信息如果不同步，即使数据恢复了，模型也无法正确加载。因此，无论选择哪种模式，元数据同步都是必选项。冷备下可以用 databricks unity-catalog metastore 的导出导入；温备和热备下建议用 Terraform 或 Databricks REST API 持续同步。

选型方法：从 RTO/RPO 到成本约束

选型不是拍脑袋，可以按以下步骤推进。

1. 明确业务分级。把 AI 负载分为关键（在线推理、实时特征）、重要（批推理、训练）、一般（实验、报表）。关键负载 RTO ≤ 5 分钟、RPO ≤ 1 分钟；重要负载 RTO ≤ 1 小时、RPO ≤ 15 分钟；一般负载 RTO ≤ 8 小时、RPO ≤ 1 小时。
2. 映射到模式。关键负载对应热备或双活；重要负载对应温备；一般负载对应冷备。同一平台可以混合使用，例如在线推理用热备，训练用冷备。
3. 核算成本。热备和双活的成本约为生产环境的 60%～100%，温备约 20%～40%，冷备约 5%～15%。成本核算要包括计算、存储、跨区域数据传输和推理端点常驻费用。
4. 验证恢复流程。每季度做一次切换演练，记录实际 RTO 和 RPO。演练时重点观察：Unity Catalog 元数据是否完整、模型端点是否能加载最新版本、特征表是否有数据缺口、向量索引是否与源数据一致。

一个可参考的混合灾备配置示例

假设某企业有一个推荐系统，包含实时特征服务、在线推理端点和每日训练任务。可以这样配置：

这个示例中，热备部分承担了在线服务的恢复能力，冷备部分承担了训练任务的低成本备份，元数据同步贯穿始终。实际参数需要根据业务流量、数据量和预算调整，但结构可以作为起点。

总结来看，Databricks AI 灾备没有“一刀切”的最优模式。冷备、温备、热备、双活、多活分别对应不同的恢复速度和成本区间，选型的本质是把业务分级、RTO/RPO 目标和预算三者对齐。对于大多数企业，温备加关键负载热备的混合策略，往往能在成本和恢复能力之间取得较好的平衡。