4. 数据资产发现与分类
迁移项目最容易踩的坑，不是“搬不动”，而是“不知道要搬什么、搬了之后谁受影响”。在动手迁移之前，必须先把数据资产盘清楚：有哪些表、哪些字段、谁在用、从哪来、到哪去、哪些含敏感信息、哪些必须一起搬。这一节围绕四件事展开——元数据采集、数据血缘分析、敏感数据识别、迁移批次划分。
一、元数据采集：先建立“资产台账”
元数据采集的目标是把散落在各处的技术元数据、业务元数据、操作元数据统一收拢到一张可查询的资产清单里。在 Databricks 环境中，采集对象通常包括：
- 技术元数据：catalog、schema、表名、列名、数据类型、分区键、文件格式（Delta/Parquet）、表属性、存储路径、表大小与行数。
- 业务元数据：表/字段的中文名、业务口径、负责人、所属主题域、SLA 等级。
- 操作元数据：最近访问时间、访问频次、作业依赖、刷新周期。
Databricks 的 Unity Catalog 自带 information_schema，可以直接用 SQL 拉取技术元数据。例如统计某 schema 下所有表的规模与最近访问情况：
SELECT t.table_catalog, t.table_schema, t.table_name,
t.table_type, t.data_source_format,
SUM(c.row_count) AS row_cnt
FROM system.information_schema.tables t
LEFT JOIN system.information_schema.table_lineage l
ON t.table_name = l.target_table_full_name
WHERE t.table_schema = 'sales_dw'
GROUP BY 1,2,3,4,5
ORDER BY row_cnt DESC;采集结果建议落到一张 asset_inventory 表中，字段至少包含：full_table_name、layer（ODS/DWD/DWS/ADS）、owner、row_count、last_access_time、has_pii、migration_batch。这张表就是后续所有决策的“单一事实来源”。
二、数据血缘分析：判断“牵一发动全身”的范围
血缘分析回答两个问题：这张表的数据从哪来（上游）、被谁消费（下游）。在 Databricks 中，Unity Catalog 的 system.access.table_lineage 与 column_lineage 会自动记录 Notebook、Job、SQL Warehouse 产生的读写关系。对于未接入 UC 的旧集群，则需要通过解析 SQL 日志、Spark 执行计划或调度系统依赖来补全。
血缘的价值在于确定迁移的“最小闭包”。假设要迁移 sales_dw.dwd_order，如果它的下游有 12 张表、3 个报表、2 个特征工程任务，那么单独迁移这一张表会导致下游全部断链。正确做法是：以目标表为起点，向上追溯到 ODS 源表，向下追踪到所有消费方，形成一个完整的迁移单元。
血缘分析还要识别跨层依赖和循环依赖。跨层依赖（如 ADS 表直接读 ODS 表）会打乱分层迁移顺序，需要在迁移前先做“依赖拉直”；循环依赖则必须人工介入拆分，否则批次划分无法收敛。
三、敏感数据识别：合规是迁移的前置条件
敏感数据识别不能只靠字段名猜测。实践中采用“规则 + 采样 + 分类分级”三层策略：
- 规则匹配：按字段名和注释匹配关键词，如
id_card、phone、email、bank_card、address。 - 数据采样验证：对候选字段抽样 1000 行，用正则校验真实内容。例如手机号用
^1[3-9]\d{9}$，身份证用 18 位校验规则。 - 分类分级打标：按合规要求分为 L1（公开）、L2（内部）、L3（敏感）、L4（高敏），并在 Unity Catalog 中用 tag 标注，如
pii.level = L3。
识别结果直接影响迁移方案：L3/L4 字段在迁移过程中必须启用列级加密或脱敏视图，跨区域迁移还需评估数据出境合规。若目标环境尚未配置好访问控制，这些表应推迟到后续批次，而不是抢进度先搬。
四、迁移批次划分策略
批次划分的本质是在“风险可控”和“进度可见”之间找平衡。推荐按以下优先级排序：
- 第一批：低风险、无下游、非敏感。用于验证迁移工具链、网络、权限、调度是否跑通，通常选 5～10 张临时表或历史归档表。
- 第二批：核心链路但血缘清晰。按主题域整条链路迁移，如“订单域”从 ODS 到 ADS 一次性搬完，保证链路完整。
- 第三批：含敏感数据或跨系统依赖。需要额外做脱敏、加密、合规审批，放在工具链稳定之后。
- 第四批：长尾与低频表。访问频次低、负责人不清、可能已废弃，先冻结再评估是否迁移。
批次划分时可参考一个简单的量化打分：优先级 = 业务重要性 × 0.4 + 血缘复杂度 × 0.3 + 敏感等级 × 0.2 + 访问频次 × 0.1。分数越高越靠后，先易后难，快速建立信心。
五、从资产清单到迁移计划
四步走完之后，asset_inventory 表应该已经具备完整的决策字段。此时可以生成迁移计划视图：
SELECT migration_batch,
COUNT(*) AS table_cnt,
SUM(row_count) AS total_rows,
SUM(CASE WHEN has_pii THEN 1 ELSE 0 END) AS pii_tables
FROM asset_inventory
GROUP BY migration_batch
ORDER BY migration_batch;判断迁移是否“盘清楚”的标准很简单：任意挑一张表，都能回答出它的上游来源、下游消费方、敏感等级、所属批次、负责人。如果有一项答不上来，说明资产发现还没做到位，不应进入实际搬迁阶段。