2. 现有AI平台资产盘点与依赖分析

迁移到 Databricks AI 平台之前，最危险的做法是“先动手搬，再发现漏了什么”。一个看似独立的模型服务，背后往往牵着特征表、训练脚本、调度任务、服务主体和权限策略。本节的目标不是罗列资产清单，而是把资产之间的依赖关系显性化，并据此输出一张可排序、可决策的迁移影响矩阵。

一、盘点对象：六类资产与它们的“接口面”

盘点要落到具体对象，而不是笼统的“AI 平台”。建议按六类资产分别采集，每类都记录其对外接口面，因为接口面决定了迁移时的耦合强度。

• 数据管道：批处理作业、流式作业、ETL/ELT 脚本、外部数据源连接（JDBC、对象存储、消息队列）。关键字段：输入源、输出表、更新频率、SLA、是否含状态。
• 特征工程：特征计算逻辑、特征表（离线/在线）、特征回填任务、特征版本。关键字段：特征名、实体主键、时间窗口、离线与在线一致性要求。
• 模型训练：训练脚本、超参配置、实验跟踪记录、训练数据快照、GPU/CPU 资源画像。关键字段：框架与版本、依赖库、训练时长、可复现性要求。
• 模型服务：在线推理 API、批推理作业、模型注册与版本、灰度/回滚策略。关键字段：QPS、延迟预算、模型格式、调用方。
• 调度：作业编排（DAG）、触发方式（定时/事件/依赖）、重试与告警、跨作业依赖。关键字段：调度器类型、依赖边、失败处理。
• 权限：服务主体、密钥/凭证、数据访问授权、模型与端点访问控制。关键字段：身份来源、授权范围、密钥轮换方式。

采集时建议用“资产—接口—依赖”三列记录，例如：资产=用户流失预测训练脚本；接口=读取 feature_user_30d 表、写入 MLflow 实验；依赖=特征回填 DAG、GPU 集群策略、服务主体 sp-etl-prod。这样后续才能算出影响面。

二、依赖分析：把隐式耦合变成有向图

依赖分析的核心是识别三类边：数据依赖（谁读谁的表）、调度依赖（谁等谁完成）、权限依赖（谁用谁的身份）。很多迁移事故并非代码问题，而是权限主体在目标平台不存在，或调度依赖被切断导致上游未就绪。

实操上可以先用元数据查询拉出依赖边。例如在源平台查询表级血缘：

-- 示例：查询某特征表的下游消费者（示意 SQL，字段名按实际元数据调整）
SELECT downstream_object, object_type, owner
FROM lineage_edges
WHERE upstream_object = 'feature_user_30d'
  AND object_type IN ('NOTEBOOK','JOB','MODEL_ENDPOINT');

对调度依赖，则导出 DAG 的边列表，标记跨团队、跨环境的边。对权限依赖，导出所有服务主体及其授权对象，重点标注“仅存在于源平台”的身份。完成这一步后，你会得到一张有向图，节点是资产，边是依赖，边上带类型标签。

三、迁移影响矩阵：从依赖图到决策表

影响矩阵不是简单打分，而是把“迁移难度”和“业务影响”两个维度交叉，再叠加依赖数量，形成可排序的批次建议。建议字段如下：资产名称、资产类型、依赖数量（上游/下游）、迁移难度（1–5）、业务影响（1–5）、是否强依赖、建议批次、备注。

下面这张图展示了从六类资产采集、依赖边识别，到影响矩阵与批次决策的完整链路，可作为盘点工作的结构参照。

四、实操示例：一次特征表迁移的影响判定

假设源平台有一张特征表 feature_user_30d，被 3 个训练脚本、2 个在线推理端点、1 个批推理作业和 2 个报表任务消费，共 8 条下游边。其中在线推理端点要求延迟低于 80ms，且特征必须在线可用。迁移难度评为 4（涉及在线特征存储改造），业务影响评为 5（直接影响线上推荐）。因此该资产进入 P0 批次，且必须与在线特征存储的迁移同步进行。

权限侧要特别检查：该表由服务主体 sp-etl-prod 写入，若目标平台使用 Unity Catalog，需要提前创建对应服务主体并授予 USE CATALOG、USE SCHEMA、SELECT、MODIFY 权限。调度侧要确认原 DAG 中 daily_feature 的上游数据管道是否也在迁移范围内，否则会出现“特征任务已迁、上游未迁”的断链。

五、盘点成果的交付形态

建议最终交付三份材料：一份资产清单（含接口面字段）、一份依赖边列表（含类型与强弱标记）、一份迁移影响矩阵（含批次建议）。矩阵中的每一行都应能追溯到具体的依赖边，避免“拍脑袋定批次”。当依赖图与矩阵同时更新时，迁移计划才具备可执行性和可审计性。

完成本节盘点后，你会得到一张清晰的迁移地图：哪些资产必须先行、哪些可以并行、哪些需要兼容层过渡。这张地图将直接决定后续迁移批次划分与资源投入顺序。