1. 迁移与现代化改造的总体蓝图
把既有的大数据与机器学习负载迁移到 Databricks AI 平台，本质上不是一次“换机器”的搬家，而是一次围绕数据、计算、治理与 AI 能力的整体重构。要避免把迁移做成简单的环境平移，第一步必须建立一张总体蓝图：清楚 Databricks AI 平台由哪些核心组件构成、为什么要迁移、现代化改造要达成什么目标、哪些场景最适合先落地，以及用什么指标判断成功。这张蓝图决定了后续每一章的取舍标准。
一、Databricks AI 平台的核心组件
从架构视角看，Databricks AI 平台可以拆成五个相互咬合的层次，它们共同支撑从原始数据到 AI 应用的完整链路。
- 存储与数据层：以云对象存储为底座，通过 Delta Lake 提供 ACID 事务、时间旅行与 Schema 演进；Unity Catalog 统一管理表、卷、模型、函数等资产的元数据与权限。
- 计算层：All-Purpose Cluster 面向交互式开发，Job Cluster 面向调度作业，SQL Warehouse 面向 BI 查询，Serverless 计算按需弹性伸缩，避免长期空转。
- 工程与治理层：Lakeflow（含 Declarative Pipelines 与 Workflows）负责数据管道编排，Databricks SQL 与 Dashboard 负责分析消费，Unity Catalog 的 lineage 与 audit 贯穿全链路。
- AI/ML 层：MLflow 管理实验与模型注册，Feature Store 统一特征，Model Serving 提供在线推理，Mosaic AI 支持模型微调、向量检索与 Agent 编排。
- 接入与协作层：Notebook、Repos、REST/SDK、Partner Connect 以及 BI 工具连接器，把平台能力开放给数据工程师、分析师、数据科学家与业务用户。
理解这五层的关键在于：迁移时它们不是独立迁移的，而是存在依赖顺序——存储与治理先行，计算与工程跟进，AI 能力最后叠加。若顺序颠倒，往往会出现“模型能跑但数据不可信”或“权限失控”的返工。
二、迁移驱动因素
企业启动迁移通常不是单一原因，而是几股力量叠加。常见驱动包括：现有 Hadoop/自建 Spark 集群运维成本高、扩缩容慢；数据孤岛导致跨团队协作困难；机器学习模型从实验到上线周期过长；合规审计要求统一权限与血缘；以及希望借助托管平台降低对稀缺运维人力的依赖。识别真正的驱动因素很重要，因为它直接决定优先级——如果核心痛点是成本，那么计算层的 Serverless 与自动伸缩就是首要目标；如果痛点是模型上线慢，则 MLflow 与 Model Serving 的打通应提前。
三、现代化改造目标
现代化改造不等同于“迁移完成”。可以把它拆成四个可衡量的目标层次：
- 可用：数据与作业在新平台稳定运行，关键报表与模型不中断。
- 可信：Unity Catalog 统一权限，Delta Lake 保证数据质量与可回溯，血缘可查。
- 高效：计算资源按需伸缩，作业失败可自动重试，开发到上线周期缩短。
- 智能：特征、模型、向量与 Agent 能力被统一治理，AI 应用可以规模化复用。
这四个层次是递进关系，跳过“可信”直接追求“智能”，往往会在生产环境暴露权限与数据质量问题时被迫回退。
四、典型场景与优先级
不同场景的迁移难度与收益差异很大。以下是一份可用于排期的场景对照示例（参数为教学假设，非实测结果）：
| 场景 | 典型现状 | 迁移要点 | 建议优先级 |
|---|---|---|---|
| 批处理 ETL | Hive/Spark 脚本 + 调度器 | 转 Delta 表，接入 Workflows | 高 |
| BI 报表 | 独立数仓 + 直连查询 | SQL Warehouse + 语义层 | 高 |
| 机器学习训练 | 单机 Notebook + 手工部署 | MLflow 跟踪 + Feature Store | 中 |
| 实时流处理 | Kafka + 自建流作业 | Structured Streaming + Delta Live Tables | 中 |
| RAG / Agent 应用 | 外部向量库 + 拼接脚本 | Mosaic AI + 向量检索 + Serving | 低（依赖前序） |
五、成功度量
度量指标要能反映“迁移是否真的带来改变”，而不是只看作业数量。建议从四个维度设定基线并持续跟踪：
- 成本：单位数据处理成本、集群空闲率、Serverless 占比。
- 效率：作业平均运行时长、失败率、从提交到上线的中位天数。
- 质量：数据质量校验通过率、血缘覆盖率、权限违规事件数。
- 业务：关键报表可用率、模型上线数量、AI 应用调用量。