3. 数据资产盘点与灾备分级
灾备恢复的第一条铁律是：你无法保护你尚未盘点的资产。在 Databricks 平台上，一个工作区里往往同时存在数千张 Delta 表、上万个 Notebook、数百个作业、若干外部存储卷以及 Unity Catalog 中的元数据对象。如果不做资产盘点与分级，灾备方案要么"全量保护"导致成本失控，要么"重点保护"却漏掉了关键对象。本节的目标是建立一套可落地的资产分类框架，并给出优先级排序的判断依据。
一、为什么必须先盘点再谈恢复
灾备的核心指标是 RTO（恢复时间目标）与 RPO（恢复点目标）。这两个指标不是对所有资产一刀切的——一张用于每日报表的汇总表，和一张支撑实时风控的特征表，其 RTO 可能相差两个数量级。资产盘点的作用，就是把"整个平台"这个模糊对象拆解为可独立评估、可独立设定 RTO/RPO 的资产单元，从而让灾备资源按价值分配。
在 Databricks 语境下，盘点需要覆盖四类对象：Unity Catalog 元数据（catalog、schema、table、view、function、volume、外部位置、权限授权）、Delta 表数据（含托管表与外部表）、非结构化数据（Volume 中的文件、模型工件、日志、图片等）、Notebook 与作业（含 Job 定义、调度、依赖、参数）。这四类对象的恢复方式、恢复顺序和依赖关系各不相同，必须分开盘点。
二、四类资产的盘点维度与关键字段
盘点不是简单列清单，而是为每个资产采集"恢复决策所需的最小字段集"。以下字段是实践中真正会用到的：
- 唯一标识：Unity Catalog 全限定名（如
prod.finance.risk_features）、Volume 路径、Notebook 路径或 Job ID。 - 资产类型：MANAGED_TABLE / EXTERNAL_TABLE / VIEW / VOLUME / NOTEBOOK / JOB。
- 存储位置：托管表落在 UC 管理的存储根，外部表指向外部位置（如
s3://corp-data/prod/...或abfss://...）。这一字段直接决定恢复时是"重建元数据"还是"重新挂载路径"。 - 数据规模与更新频率：行数、大小、每日增量、是否流式写入。用于估算恢复耗时与增量恢复可行性。
- 上游依赖：该表由哪些 Job 产出、依赖哪些源表。用于确定恢复顺序。
- 下游消费者：哪些报表、模型、API 读取它。用于评估业务影响面。
- 合规属性：是否含 PII、是否受审计要求约束、保留期限。
这些字段可以通过 Unity Catalog 的 information_schema 与 Jobs API 自动采集。例如，列出所有托管表及其大小：
SELECT table_catalog, table_schema, table_name,
table_type, data_source_format
FROM prod.information_schema.tables
WHERE table_type IN ('MANAGED','EXTERNAL')
ORDER BY table_catalog, table_schema, table_name;
-- 结合 DESCRIBE DETAIL 获取存储路径与大小
DESCRIBE DETAIL prod.finance.risk_features;
-- 返回字段包含 location、numFiles、sizeInBytes、format 等对于 Job，可通过 Jobs API 2.1 的 /api/2.1/jobs/list 拉取全部作业定义，再逐个 /api/2.1/jobs/get?job_id= 获取任务依赖、集群配置与调度。Notebook 则可通过 Workspace API 递归遍历目录树导出。
三、灾备分级：从资产属性到恢复优先级
分级不是按"重要性"主观打分，而是按业务影响 × 恢复难度两个维度定位。业务影响由下游消费者数量、是否支撑实时决策、是否涉及合规决定；恢复难度由数据规模、依赖深度、是否可重建决定。据此可划分为四级：
| 级别 | 典型资产 | RTO 目标 | RPO 目标 | 恢复策略 |
|---|---|---|---|---|
| P0 关键 | 实时风控特征表、核心交易明细、UC 元数据与授权 | ≤ 1 小时 | ≤ 5 分钟 | 跨区域副本 + 持续同步 + 元数据快照 |
| P1 重要 | 每日报表汇总表、关键 Job、模型工件 | ≤ 4 小时 | ≤ 1 小时 | 定时快照 + 增量恢复 |
| P2 一般 | 探索性 Notebook、中间层表、日志 Volume | ≤ 24 小时 | ≤ 24 小时 | 按需重建或从上游重算 |
| P3 低 | 临时表、草稿 Notebook、过期归档 | 不承诺 | 不承诺 | 不备份，接受丢失 |
需要特别强调的是 Unity Catalog 元数据本身应至少定为 P0。原因在于：即使底层 Delta 数据文件完好，如果 UC 中的 catalog、schema、表定义、权限授权丢失，所有查询都会失败，恢复数据文件也无法直接访问。元数据的恢复往往比数据恢复更紧急，因为它是一切访问的前提。
四、依赖关系决定恢复顺序
资产之间存在明确的生产依赖：Job 产出表，表被下游表引用，Notebook 调用函数，Volume 中的文件被表读取。恢复时若顺序错误，会出现"表恢复了但上游 Job 未恢复导致无法继续写入"或"Job 恢复了但依赖的表不存在导致启动失败"。因此盘点必须同时产出一张依赖图，恢复顺序应遵循：元数据 → 基础源表 → 中间层表 → 应用层表 → Job 与调度 → Notebook 与函数。
五、盘点成果的落地形式
盘点最终应产出一份可维护的资产台账，建议以 Delta 表形式存放在独立的 governance catalog 中，便于持续更新与查询。台账至少包含以下字段：asset_id、asset_type、full_name、storage_location、size_bytes、update_frequency、upstream_deps、downstream_consumers、compliance_flag、dr_tier、rto_minutes、rpo_minutes、last_reviewed。台账本身也应纳入 P0 保护范围。
台账建立后，应定期（建议每月）复核一次，重点检查：新增资产是否已分级、P0/P1 资产的下游消费者是否发生变化、外部表的存储路径是否仍然有效、Job 依赖是否因重构而改变。只有持续维护的台账，才能在真正发生故障时作为恢复依据。
information_schema 与 Jobs API 自动生成台账初稿，再组织业务方对 P0/P1 资产逐条确认。人工确认环节不可省略，因为"哪些表真正支撑业务"往往只有业务方清楚，自动化采集无法替代。完成本节盘点后，你将得到一份带分级、带依赖、带 RTO/RPO 目标的资产清单。这份清单是后续所有灾备动作——备份策略选择、跨区域复制配置、恢复演练设计——的输入。没有它，灾备方案就是空中楼阁。