1. 迁移与现代化改造总览

当企业决定把既有的大数据与机器学习负载迁移到 Databricks 时，真正要回答的并不是“换一个平台跑同样的作业”，而是“如何把数据、计算、治理和协作方式一起升级”。Databricks 的核心价值可以概括为三层：以 Delta Lake 为存储底座，把数据湖的开放性与数据仓库的事务能力合并；以 Spark 与 Photon 引擎为计算底座，统一批处理、流处理和交互式分析；以 Unity Catalog 和 Workspace 为治理与协作底座，让数据、模型、Notebook、作业和权限在同一套命名空间下被管理。迁移因此不是一次简单的“搬家”，而是一次围绕数据架构、计算模式和组织协作方式的现代化改造。

一、迁移驱动力：为什么要迁，迁到哪里

常见的迁移驱动力有四类。第一类是成本与弹性：自建 Hadoop 集群在业务波峰时扩容慢、波谷时资源闲置，而 Databricks 的按需集群和自动伸缩可以把计算成本与业务负载对齐。第二类是技术债：旧平台上的 Hive 元数据、手写 MapReduce、分散的调度脚本难以维护，迁移到 Unity Catalog 后可以统一表、视图、函数和权限。第三类是实时与 AI 需求：业务要求从 T+1 报表走向分钟级甚至秒级指标，同时希望在同一份数据上训练和部署模型，Databricks 的 Structured Streaming 与 MLflow 正好覆盖这条链路。第四类是治理与合规：数据分散在多个系统、权限靠人工维护，迁移到统一目录后可以做到列级权限、审计和血缘追踪。

迁移的目标形态通常不是“把旧系统原样复制”，而是“在 Databricks 上重建一条更短的数据链路”。例如，原来从 Kafka 到 HDFS 再到 Hive 再到报表的三段式链路，迁移后可以变成 Kafka 到 Delta 表再到 Databricks SQL 的两段式链路，中间减少一次落盘和一次元数据同步。

二、典型现代化改造场景

场景一：数据仓库现代化。把传统数仓中的维度模型、缓慢变化维和聚合表迁移到 Delta Lake，利用 MERGE INTO 实现增量更新，用物化视图或流式表替代夜间批量重算。场景二：数据湖治理。把散落在 S3、ADLS 上的 Parquet 文件注册为 Unity Catalog 中的外部表或托管表，补上 Schema、分区和权限。场景三：实时化改造。把原本按小时调度的批作业改写成 Structured Streaming，用 Delta 表作为流式 sink，并设置 checkpoint 保证断点续传。场景四：机器学习工程化。把 Notebook 中的实验代码抽成 Feature Store 特征和 MLflow 实验，再用 Model Serving 暴露推理接口。场景五：平台整合。把多个小集群、多个调度器合并到 Databricks Workflows，减少运维面。

三、整体方法论：评估、分层、迁移、验证、优化

迁移方法论可以落成一条可执行的主线。第一步是资产盘点：列出所有数据源、表、作业、依赖和 SLA，标注哪些是核心链路、哪些可以下线。第二步是目标架构设计：确定存储层用托管表还是外部表，计算层用通用集群还是 SQL 仓库，治理层如何划分 Catalog 和 Schema。第三步是分层迁移：先迁元数据和只读表，再迁增量写入作业，最后迁实时链路和机器学习任务。第四步是验证：用行数、主键唯一性、金额汇总和抽样比对来确认数据一致。第五步是优化：根据 Photon 执行计划和 Spark UI 调整分区、Z-Order 和文件大小。

四、一个可参考的迁移示例

假设某零售企业要把旧 Hive 数仓中的订单事实表迁移到 Databricks。旧表按天分区，每天凌晨全量重算，SLA 是早上 7 点前出报表。迁移方案可以这样设计：在 Unity Catalog 中创建 retail.silver.orders 托管 Delta 表，用 Auto Loader 从对象存储增量读取新文件，用 MERGE INTO 按订单号做 upsert，再用 Databricks SQL 创建聚合视图供 BI 查询。验证时对比旧表和新表的行数、订单金额总和以及最近 7 天分区的主键唯一性。如果发现金额偏差，优先检查小数精度和汇率换算逻辑，而不是先怀疑引擎。

-- 示例：订单表增量合并（参数为教学示例）
MERGE INTO retail.silver.orders AS t
USING retail.staging.orders_delta AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

-- 验证：行数与金额汇总比对
SELECT COUNT(*) AS cnt, SUM(amount) AS total FROM retail.silver.orders;
SELECT COUNT(*) AS cnt, SUM(amount) AS total FROM legacy_hive.orders;

五、判断迁移是否成功的几个信号

第一，数据一致性通过：核心表的行数、主键唯一性和金额汇总与旧系统一致，偏差在可解释范围内。第二，SLA 达标：关键报表的产出时间不晚于旧系统，甚至更早。第三，成本可观测：通过集群标签和账单分析，能说清每个作业花了多少钱。第四，治理可落地：新表默认进入 Unity Catalog，权限不再靠人工脚本维护。第五，团队愿意用：分析师和工程师开始主动在 Databricks 上建新表、写新作业，而不是继续绕回旧平台。这五个信号同时出现，才说明迁移真正完成了从“能跑”到“好用”的跨越。