A Decision Framework for ETL Migration to Databricks

用于将 ETL 迁移到 Databricks 的决策框架 | Databricks 博客

跳至主要内容

数据仓库

2026 年 6 月 26 日

用于将 ETL 迁移到 Databricks 的决策框架

如何在 Lakehouse、Spark 声明式管道（SDP）或 PySpark 之间进行选择，以及何时将它们结合使用

作者：Rafael Aielo

摘要

• 三条路径，而非一条：Lakehouse、Spark 声明式管道（SDP）以及 PySpark 或 Spark SQL 笔记本适用于不同的迁移场景。大多数组织最终会采用组合方式。

• 以结果为导向的阶段：采用四阶段方法（评估、快速胜利、现代化、优化），可以逐步淘汰遗留系统，而不是一次性全部切换。

• 让工具完成繁重工作：Lakebridge、合作伙伴转换器和 AI 辅助代码转换可以自动化大部分机械转换，使您的团队能够专注于验证和优化。

您的团队有数百个存储过程、几个调度器、权限分散在角色和模式中，并且云数据仓库的续订期限即将到来。没有人就首先迁移什么达成一致。一些人希望将所有内容重写为 PySpark。另一些人则希望原样迁移 SQL 并认为任务完成。在对话中被忽略的是：随着代码迁移的元数据、血缘和权限，以及在迁移过程中整合它们的机会。

极端做法都不奏效。成功完成数据仓库迁移的团队会针对每个工作负载单独分析，并选择适合任务的工具。本文提出一个决策框架，用于选择：何时使用 Lakehouse（Databricks SQL）、Spark 声明式管道或 PySpark，以及如何分阶段进行工作，以便交付成果，而不是陷入计划中。

三条路径，一次迁移

在 Databricks 上，您可以使用三种主要方式迁移 ETL 管道，通常会结合使用。

#### Lakehouse（Databricks SQL）

这是 SQL 为主的团队最直接的路径。它涵盖从简单到复杂的范围。它运行在 SQL 数据仓库上，默认情况下由 Photon 加速，并且完全兼容 ANSI 和 Spark SQL（%sql）。对于变量或不可预测的工作负载，选择无服务器（Serverless）（快速启动，可扩展至零，按秒计费）。对于稳定的工作负载或需要特定网络或成本控制时，选择经典（Classic）模式。

一个简单的 SQL 任务：

$

/$

当逻辑需要控制流（条件语句）、循环、变量、错误处理或参数驱动执行时，存储过程可以提供这一过程层。它们通过 Unity Catalog 进行管理，并且可以通过 Workflows 使用参数调用。

经验法则：如果您的遗留代码是一个单一的 SQL 语句，请将其迁移为一个 SQL 任务。如果它包含过程逻辑（变量、循环、参数、错误处理），请将其封装在存储过程中，并通过 Unity Catalog 进行管理，可以从 Workflows 调用。不要仅仅因为原始系统要求就将简单的 SQL 封装在过程中。

#### Spark 声明式管道（SDP）

这是 Lakeflow 的一部分，采取了不同的方法。您声明管道应该生成什么，引擎会处理执行顺序、重试和扩展。您将获得内置的数据质量约束、自动依赖关系解析，以及在相同定义中统一的批处理加流处理。

在底层，Enzyme 决定何时进行增量更新，何时完全重新计算派生表。自动扩展根据数据量的变化调整容量，而无需手动调整。像 Block 这样的公司依赖这种声明式模型，随着使用量的增长，简化管道编排。

#### PySpark 和 Spark SQL 笔记本

它们为你提供完全的控制权。它们在作业集群上运行，处理不适合 SQL 数据仓库或声明式流水线的工作负载。

当工作负载需要复杂的业务逻辑、机器学习特征工程、API 集成或自定义验证时，请使用 PySpark。下面的示例使用在 Unity Catalog 中注册的模型对交易进行评分：

当语言仍然是 SQL，但工作负载可能超出 SQL 数据仓库的处理能力时，请在笔记本中使用 Spark SQL：非常大的表、繁重的洗牌操作、长时间运行的批处理 ETL，你希望对分区、广播连接或缓存有显式控制。

在作业集群上启用 Photon 以加速计算密集型的 SQL 或 DataFrame 工作负载：大型连接、聚合、窗口函数、对大型列式表的扫描。Photon 是一个原生的、向量化引擎，可以加速这些模式，而无需更改代码，包括基于 Arrow 的 Pandas UDF。当行级 Python UDF 占主导、数据集较小或作业纯粹是 I/O 时，可以跳过 Photon。

笔记本也适合混合流水线：在 SDP 中进行数据摄入，在笔记本任务中进行数据丰富。

决策矩阵

下面的表格是团队讨论的起点，而不是硬性规则。

| 准则 | Lakehouse（任务和存储过程） | Spark 声明式流水线 | PySpark + Spark SQL 笔记本 | |------|-----------------------------|---------------------|---------------------------| | 团队背景 | 以 SQL 为主，DBA，DW 工程师 | 数据工程师和 SQL 团队构建管理流水线 | Python/Spark 开发者，机器学习工程师 | | 逻辑类型 | SQL ETL：单条语句的简单任务，存储过程用于过程逻辑 | 声明式流水线，CDC，SCD | 复杂逻辑，自定义 UDF，机器学习准备 | | SQL 迁移速度 | 对类似 ANSI 的 SQL 工作负载很高 | 中等：需要重新设计流水线，但可以重用 SQL | 可变：可能需要大量重构 | | 流水线编排 | 包含 SQL 任务或 CALL 过程的流水线 | 嵌入在流水线中 | 包含笔记本任务的流水线 | | 批处理 vs 流处理 | 主要是批处理 | 统一的批处理和流处理 | 通过结构化流处理进行批处理和流处理 | | 数据质量 | 手动 SQL 检查 | 声明式约束 | 代码中的自定义验证 |

快速决策网格

在列中找到你的团队，在行中找到你的工作负载复杂度。单元格可能会建议你从哪里开始。

| 工作负载复杂度 | SQL 优先团队 | 混合团队 | 代码优先团队 | |----------------|----------------|----------|----------------| | 低（批处理加载、聚合、MERGE） | Workflows 中的 SQL 任务 | SQL 任务或 SDP | PySpark 或 SDP | | 中（多步骤流水线、CDC、数据质量） | 存储过程或 SDP | SDP | SDP 或 PySpark | | 高（机器学习准备、自定义 UDF、API、密集的业务逻辑） | SDP + PySpark 辅助 | PySpark + SDP 用于摄入 | PySpark |

四个阶段而不是一次性全部决定

与其决定“所有内容采用哪种方法”，不如在每个阶段决定“下一步该做什么”。

阶段 1 — 评估。从遗留数据仓库中收集指标：CPU 时间、运行时间、执行频率、源表和目标表。根据复杂性对工作负载进行分类。尽可能使用迁移工具，构建按价值与难度评分的库存清单。获取这些数据的位置取决于数据源。在 Teradata 上，查询 DBC.QryLog；在 SQL Server 上，使用 sys.dm_exec_query_stats；在 Oracle 上，使用 AWR 报告；在 Snowflake 上，使用 QUERY_HISTORY。具体细节可能有所不同。如果你已经部署了集成工具，可以利用其元数据来识别表之间的关系，或者依赖 LLM 来帮助构建这种血缘关系。输出结果是一张地图，而不是重写计划。目标保持不变：根据资源消耗和依赖级别对工作负载进行排序，以便知道从哪里开始。如果执行得当，这种评估使用迁移工具只需几天时间，而不是手动脚本需要几周时间。

阶段 2 — 快速胜利。选择那些迁移风险较低且业务可见性较高的工作负载。这可能意味着从那些易于转换的重 SQL 任务开始，或者从那些能尽早将新平台展示给利益相关者的报告流水线开始。简单的语句将变成 Workflows 中的 SQL 任务。过程逻辑将变成存储过程。使用转译器和 AI 辅助转换进行初始转换。并行运行两个系统，比较行数、校验和、样本记录。关键在于建立信心，无论是技术方面还是组织方面。

例如，Walgreens 在分阶段迁移中退役了本地 Teradata，现在每秒在湖房（lakehouse）上处理约 40,000 个数据事件，为近 9,000 家门店的供应链优化提供支持。

阶段 3 — 现代化。现在重新设计值得现代化的流水线。候选对象包括：数据质量约束和血缘关系减少人工检查的流程、受益于流表和 CDC 的批处理任务、通过物化视图减少复杂性的流水线，以及之前分散在不同工具中的元数据、权限和审计信息，现在统一在 Unity Catalog 下。一个常见的模式是保留遗留过程作为回退方案，同时新流水线并行运行，直到通过验证。现代化的流水线通常将批处理窗口从小时缩短到分钟，并消除了对单独 DQ 工具的需求。

阶段 4 — 优化。合并那些仅为了绕过旧数据仓库限制而存在的冗余 ETL 流水线。将复杂的热点任务转移到 PySpark，当它简化逻辑时。现在你有了统一的引擎，可以重新审视批处理与流处理的边界。这就是迁移带来的回报：旧平台已关闭，冗余流水线已消失，架构现在运行在一个系统上，而不是两个系统上。

迁移工具和 AI 的适用场景

迁移工具自动化处理机械性工作，但不会替代架构决策。三个典型角色：

• 分析和评估。发现存储过程、SQL 脚本和 ETL 任务。绘制依赖关系。Lakebridge 提供了一个 Analyzer 组件，用于扫描遗留数据仓库平台，并构建对象、使用模式和复杂性的清单。

• 代码转换。将 Teradata、Oracle、SQL Server、DataStage、Informatica 和 SSIS 中的 SQL 和 ETL 转换为 Lakehouse 或声明式流水线。Lakebridge 的 Converter 处理存储过程和 ETL 流程，公开的指导资料指出，其自动化率高达 80%，项目时间表也加快了约两倍。

• 验证。通过自动检查模式、行数和聚合值，跨系统比较结果。Lakebridge 包含一个验证器。Databricks 的迁移方法将对账视为一个首要阶段，而不是后续步骤。

务实的方法：让工具处理初始转换的 60%-80%，并保留工程师的时间用于你真正希望现代化的模式。这样可以避免将技术债务一对一地移植过来。

会被移除的内容

成功的迁移会主动退役系统，而不仅仅是转换代码：独立的调度服务器、自定义的数据质量框架、独立的血缘和元数据工具、特定供应商的存储过程编译器以及手动构建的验证框架。只有当这些系统被关闭，账单停止时，迁移才算完成。

会阻碍迁移的三种反模式

• 不考虑团队技能、风险状况和工作负载类型，为所有内容选择单一路径。仅使用 SQL 的团队会错失现代化的机会。仅使用 PySpark 的团队会毫无理由地重新编写简单的 SQL。

• 仅衡量“迁移百分比”，而忽略并行运行时间、验证时间和遗留系统的实际退役情况。如果旧的数据仓库平台仍在以全额成本运行，那么 50% 的迁移率毫无意义。

• 在湖房（lakehouse）中重新创建旧的调度器和中间层，而不是使用工作流和声明式管道。迁移是简化管道编排的好机会。抓住这个机会。

如果 SQL ETL 在引擎、层级和工具之间仍然碎片化，即使数据以开放格式存储，平台也会保持碎片化。

没有一种唯一正确的数据管道迁移方式。Lakehouse 能够快速带你到达目的地：简单的任务用于简单的逻辑，需要过程控制时使用存储过程。SDP 为你提供内置质量和血缘的现代 ETL 管道。Notebook 处理其余部分，无论你选择使用 PySpark 还是 Spark SQL。分阶段进行工作，从快速胜利开始，尽可能使用所有加速器。

通过 Databricks 迁移指南探索技术操作步骤，或使用 Databricks 免费版亲自尝试。

在你的邮箱中获取最新文章

订阅我们的博客，获取最新文章发送到你的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"