📚 课程目录第3章迁移前的架构评估

3、迁移前的架构评估：现有系统盘点、数据血缘梳理、依赖关系分析

说实话，很多团队在Lakehouse迁移上栽跟头，不是因为技术选型不对，而是因为——根本没搞清楚自己手里有什么。

我见过最夸张的一个项目，迁移团队花了三个月搭好新平台，结果发现源系统里有200多张没人维护的“僵尸表”，还有一堆连DBA都说不清来源的ETL脚本。最后不得不回滚，重新做盘点。嗯，那场面挺尴尬的。

所以这一章，咱们就聊聊迁移前必须做的三件事：系统盘点、血缘梳理、依赖分析。这三件事做扎实了，后面的迁移才能心里有底。

系统盘点听起来简单，不就是列个清单吗？但实际做起来，坑比想象的多。

我个人习惯把盘点分成四个维度：

维度	核心内容	常见遗漏点
数据源	OLTP库、日志、消息队列、文件、API	临时表、测试库、手工导入的Excel
计算引擎	Hive、Spark、Presto、Flink、Impala	Ad-hoc查询脚本、定时任务
存储层	HDFS、S3、NAS、本地盘	归档数据、冷备副本
调度与元数据	Airflow、Oozie、Atlas、Hive Metastore	手动触发的Shell脚本、Crontab

我曾经在一个金融客户那里做盘点，发现他们的核心风控表居然依赖一个藏在某台虚拟机里的Python脚本，而这个脚本连版本控制都没有。你想想看，这种依赖要是迁移时断了，后果是什么？

我的建议：盘点时不要只问“你们用了什么”，要问“如果明天这个系统停了，谁会第一个跳起来”。顺着人去找系统，往往能发现那些被遗忘的角落。

数据血缘，说白了就是一张数据流转地图。从源表到中间表，再到应用层，每一步的加工逻辑都要理清楚。

为什么这件事重要？我举个例子：

有一次我们做迁移，发现一张报表的某个字段值总是对不上。查了两天才发现，这个字段经过了7层ETL转换，中间有一层用了过时的业务规则。如果没有血缘图谱，你根本不知道问题出在哪一环。

梳理血缘时，我一般关注三个层次：

工具方面，如果你们已经用了Atlas或DataHub，那可以直接导出血缘图。如果没有，也别慌——从调度系统的日志和SQL脚本里手工梳理，虽然累，但效果一样。

    避坑指南：我曾经遇到一个团队，他们用Atlas自动采集血缘，结果发现采集到的血缘关系有30%是错的——因为很多ETL脚本用了动态SQL，工具根本解析不了。所以，自动采集+人工校验才是靠谱的做法。

依赖关系分析，是架构评估里最容易被低估的一环。很多人觉得“不就是上下游关系吗”，但实际上一张核心表的依赖链可能长达十几层。

我习惯把依赖关系分成三类：

为什么要分这么细？因为迁移策略不一样。强依赖的表必须一起迁移，弱依赖的表可以分批迁移，无依赖的表甚至可以最后再动。

这里我分享一个真实案例：

有个电商客户，迁移时把订单表和支付表分到了两个批次。结果支付表先迁完，订单表还在旧平台，导致对账系统连续三天报错。原因就是——他们没发现订单表和支付表之间存在一个隐式依赖：对账任务会同时读取两张表做关联。

注意：隐式依赖是最危险的。它不在调度系统里，也不在ETL脚本里，而是藏在业务逻辑或应用代码里。排查隐式依赖的唯一方法，就是逐条核对SQL和API调用，没有捷径。

好了，前面说了那么多，咱们用一张图把整个评估过程串起来。这张图是我做每个迁移项目时必画的，你可以直接拿去用。

评估做完，最终要产出两个东西：

我一般用下面这个矩阵来排优先级：

依赖强度	业务影响高	业务影响中	业务影响低
强依赖	P0（第一批，必须一起迁）	P1（第二批，尽量一起迁）	P2（第三批，可单独迁）
弱依赖	P1（第二批，可分批迁）	P2（第三批，可分批迁）	P3（最后迁）
无依赖	P2（第三批，可独立迁）	P3（最后迁）	P3（最后迁）

一个小技巧：排优先级时，别忘了考虑回滚成本。有些表虽然依赖简单，但一旦迁错，恢复起来可能要几天。这种表我建议放在最后一批，或者先做一次完整的演练。

好了，架构评估这部分就聊到这儿。记住一句话：迁移前的评估做得越细，迁移中的意外就越少。别嫌麻烦，这一步省下来的时间，后面会加倍还给你。