2. 源平台评估与迁移就绪度分析

迁移到 Databricks 之前，最容易被低估、也最容易导致项目返工的一步，不是写 Spark 代码，而是把源平台“看清楚”。源平台评估的目标不是做一份资产清单交差，而是回答三个问题：现在有什么、哪些东西是负担、先迁什么后迁什么。这三个问题分别对应资产盘点、技术债识别和迁移复杂度与优先级评估。本节围绕这三件事展开，并给出可直接套用的评估方法。

一、资产盘点：把“看不见的东西”变成可度量对象

Hadoop/Spark/数仓资产通常散落在多个系统中：Hive Metastore 里的表、HDFS 上的目录、Oozie/Airflow 里的调度作业、Shell 脚本、Sqoop 抽取任务、以及报表工具背后的 SQL。盘点时不要只统计表数量，而要按“可迁移单元”归类，因为迁移工作量由作业和依赖决定，而不是由表数量决定。

建议按四类对象盘点，并记录关键属性：

• 存储资产：Hive 表、HDFS 目录、HBase 表。记录表名、格式（ORC/Parquet/Text/Avro）、分区字段、压缩方式、存储量、日均增量、小文件数量。
• 计算资产：MapReduce、Spark、Hive SQL、Pig 作业。记录作业名、调度周期、平均运行时长、输入输出表、是否含 UDF。
• 调度与依赖：Oozie workflow、Airflow DAG、crontab。记录依赖链长度、跨系统依赖、失败重试策略。
• 下游消费：BI 报表、数据接口、导出任务。记录消费方、SLA 时间、是否强依赖特定表结构。

盘点结果建议落成一张可查询的资产表，而不是 Excel 散表。例如在源集群上用 Hive 元数据和 HDFS 命令采集：

-- 采集表级基础信息（示例）
SELECT t.tbl_name,
       t.tbl_type,
       p.param_value AS storage_format,
       s.total_size,
       s.num_files
FROM metastore.tbls t
LEFT JOIN metastore.table_params p
  ON t.tbl_id = p.tbl_id AND p.param_key = 'serialization.format'
LEFT JOIN (
  SELECT d.table_name, SUM(d.total_size) AS total_size, SUM(d.num_files) AS num_files
  FROM hdfs_table_stats d GROUP BY d.table_name
) s ON t.tbl_name = s.table_name;

# 统计小文件问题（示例）
hdfs dfs -count -q /warehouse/ods/order_detail
# 输出中 FILE_COUNT 远大于预期时，说明存在小文件合并需求

这里的关键判断依据是：小文件数量、分区数量、UDF 数量、跨系统依赖数量。它们直接决定迁移后是否需要重写、是否需要引入 Delta 的 OPTIMIZE、以及是否要改造调度。

二、技术债识别：区分“能迁”和“该重写”

技术债不是所有旧代码都算，而是那些迁移后会持续放大成本的部分。评估时重点看五类信号：

• 硬编码路径与集群名：如 hdfs://old-cluster:8020/...，迁移后必须替换为云存储路径或 Unity Catalog 卷路径。
• 非标准 UDF：Java/Python UDF 若依赖本地库或旧版 API，在 Databricks Runtime 上可能无法直接运行，需要重写为原生函数或 Pandas UDF。
• MapReduce 逻辑：MR 作业通常需要改写为 Spark DataFrame/Spark SQL，属于重写而非平移。
• 调度耦合：Oozie 的 workflow 依赖 HDFS 触发文件，迁移到 Databricks Workflows 后需要改为任务依赖或事件触发。
• 表结构漂移：同一张表在不同分区 schema 不一致，迁移到 Delta 前需要先做 schema 对齐。

可以用一个简单的技术债评分辅助判断。对每个作业按“改造类型”赋分：直接平移 1 分、SQL 改写 2 分、UDF 重写 3 分、MR 重写 4 分、调度重构 3 分。再乘以“影响面系数”（下游消费方数量），得到技术债指数。指数越高，越不适合放在第一批迁移。

三、迁移复杂度与优先级：用二维矩阵排批次

复杂度评估建议从四个维度打分（1～5 分）：数据量、依赖深度、改造类型、SLA 严格度。总分越高越复杂。优先级则看两个因素：业务价值（是否核心报表/核心链路）和迁移风险（是否容易回滚）。把复杂度和业务价值放在同一张矩阵里，就能得到清晰的批次策略。

矩阵的用法是：第一批选高价值、低复杂度的资产，例如维表、增量事实表、日汇总表。它们能快速在 Databricks 上跑通，验证存储、权限、调度和性能基线。第二批处理高价值但高复杂度的资产，例如含 UDF 的用户画像作业、实时链路，需要预留重写和联调时间。第三批是低价值低复杂度，可以批量平移。右下角低价值高复杂度的资产，优先确认是否可以直接下线，而不是硬迁。

四、就绪度判断：给出可执行的结论

完成盘点、技术债识别和优先级排序后，需要输出一份就绪度结论。建议至少包含以下字段，作为迁移启动的决策依据：

需要强调的是，就绪度不是“全部准备好才启动”，而是“第一批是否具备可验证的闭环”。只要第一批资产能在 Databricks 上完成端到端跑通，并且有明确的回滚路径，就可以进入迁移实施阶段。剩余资产可以在迁移过程中持续补盘和分批推进。

总结来说，源平台评估与迁移就绪度分析的核心产出是：一份可查询的资产台账、一份技术债清单、一张复杂度—价值矩阵，以及一份就绪度结论表。它们共同回答“先迁什么、怎么迁、什么时候可以开始迁”，为后续的迁移实施提供可执行的输入。