Databricks以声明式模式简化Lakehouse SQL ETL

Databricks 正在将声明式 ETL 引入数据仓库工作流中的Lakehouse，使 SQL 从业者能够更轻松地在他们熟悉的工作环境中简化复杂的转换逻辑。

这是将 ApacheSpark™ 声明式管道背后的声明式执行模型引入 Databricks 更多创作体验的更广泛战略的一部分。 SQL 用户无需在专门的管道导向环境中工作，即可直接在 Databricks Lakehouse 的 SQL 查询中定义常见的 ETL 模式。

简化 Lakehouse 中的重复 ETL 模式

Databricks 上的声明式 SQL ETL 并非新鲜事物。如今，成千上万的 SQL 优先用户已经依赖诸如物化视图和流式表等声明式原语来简化重复转换、保持下游表最新并加速 BI 工作负载。

许多重复的 ETL 模式易于描述但难以操作，需要自定义 SQL 逻辑、手动调度和编排胶水。这些模式包括追加新记录、应用 CDC 更改以及仅刷新已更改的数据。

声明式原语之所以有效，是因为它们让用户描述所需的表或视图，而不必手工编写保持其最新所需的每个步骤。Databricks 负责调度、刷新和适用时的增量处理，因此用户无需手工编写保持表最新所需的逻辑。

我们现在正在将相同的声明式方法扩展到Lakeflow 管道编辑器之外，应用于数据仓库和 SQL 从业者更常见的重复 ETL 模式。现在，Lakehouse 用户可以直接在 SQL 编辑器中定义所需的 ETL 模式，而 Databricks 则处理增量处理、更新逻辑、调度和编排，以可靠地运行它。

Lakehouse 中可用的首批声明式原语

Lakehouse SQL 编辑器中可用的首批声明式操作对应三种常见的重复 ETL 模式：仅追加更新、变更数据捕获和批量覆盖。

其中许多模式已通过 Lakeflow 中的 AUTO CDC 等声明式 API 提供；这里的转变是让 SQL 分析师可以直接在 Lakehouse 中使用它们。

这些流可以按计划刷新、由上游更新触发、按需运行，或通过作业中的 SQL 任务进行编排。

仅追加更新

仅追加更新是当今许多流式表背后的标准模式；用于将源中的新记录增量追加到目标表中。它们常用于摄取工作负载，例如使用 Auto Loader 从云对象存储加载新记录。

无需编写和调度重复的插入逻辑，SQL 用户可以定义一个简单的 APPEND 流，自动跟踪源中新增和已处理的数据。Databricks 处理状态跟踪，并在新记录到达时增量追加，自动管理底层的无服务器管道。

这为 SQL 用户提供了一种简单的方法来操作追加式摄取，而无需手动创建、调度或管理单独的管道。

了解如何在 Lakehouse 中定义 APPEND 流。

变更数据捕获

CDC 管道是 SQL ETL 中最常见且最复杂的模式之一。团队通常使用MERGE INTO来处理插入、更新和删除，但 CDC 数据可能乱序到达，需要额外逻辑以避免错误结果。

AUTO CDC 允许 SQL 用户在 Lakehouse 中用几行声明式代码定义 CDC 逻辑。使用 AUTO CDC，可以轻松指定键、排序、删除处理，以及将结果存储为 SCD 类型 1 还是 SCD 类型 2，而无需手工编写复杂的合并管道。

“在 bsport，SQL AUTO CDC 为我们提供了一种更简单、更模块化的方式来管理 Databricks 中的数据摄取。通过将表加载与单一管道解耦，我们提高了整个平台的可用性和数据新鲜度。它使我们能够独立处理来自第三方的数据，从而更好地管理故障，降低编排复杂性，并简化整体设置的操作和扩展。对我们的团队而言，这创建了一个更简洁、更灵活的基于 SQL 的工作流，并在生产中具有更强的可靠性。”——Adrien Marteau，bsport 数据主管

了解如何为 SCD 类型 1 和类型 2 创建 AUTO CDC 流。

批量覆盖

某些批量 ETL 工作负载只需刷新特定数据子集，例如日期范围、分区或业务段。传统上，团队通常通过昂贵的全量重算或自定义覆盖逻辑来处理。

REPLACE WHERE 流为 Lakehouse 带来了定向增量批量重算的声明式模式。用户在目标表上定义谓词，Databricks 自动刷新该区域。借助 Databricks 的自动增量引擎 Enzyme，Databricks 可以在可能的情况下仅识别和处理指定谓词内已更改的数据，而不是重算整个目标表或重写整个匹配切片。

在 Lakehouse 基准测试中，由 Enzyme 驱动的 REPLACE WHERE 比传统 REPLACE WHERE 快 3.4 倍，成本降低 2.5 倍。这对于选择性重新处理、模式演化、回填以及在处理较大历史范围之前对小数据窗口进行迭代非常有用。

了解如何使用 REPLACE WHERE 流刷新表的定向子集（并阅读社区博客这里）。

简而言之：为什么这对 SQL 从业者很重要

现代化你的 ETL 并不需要完全重写，也不需要对复杂的管道框架做出全有或全无的承诺。将声明式语义引入现有的 Lakehouse SQL 操作中，你可以在最合理的地方将现有代码与现代化的声明式 SQL 混合匹配。

你可以保留现有的、针对自定义任务调优过的过程式SQL查询，同时无缝接入声明式操作，如仅追加摄取、AUTO CDC或针对重复性高、维护成本高的模式进行定向批量覆盖。这让你两全其美：既能完全控制你的传统SQL逻辑，又能在需要的地方获得自动化状态管理、依赖处理和schema演化，所有这些都直接在Lakehouse内完成。

从声明式原语到完全声明式管道

将声明式原语混合到你的日常SQL工作流中，为管理单个表和增量逻辑提供了一个实用、低摩擦的起点。随着项目规模和复杂性的增长，你的开发工作流可以自然地随之演进。

对于管理多个相关转换、共享依赖和生产工作流的团队，Lakeflow管道编辑器为声明式ETL提供了更丰富的、面向项目的开发体验，支持多文件开发、依赖管理、管道可视化、集成验证和生产部署。

这对于管理跨领域、数据产品或业务部门中许多相关转换的团队尤其有用。团队可以在Databricks上组织受治理的、团队拥有的管道，而不是维护断开的脚本或将所有逻辑集中在一个大项目中。借助Unity Catalog，每个团队可以构建在共享数据资产之上，一致地管理权限，并了解跨管道和下游消费者的血缘关系。

SQL从业者可以从熟悉的SQL编辑器中的声明式流程开始，然后在需要更结构化环境处理更大项目、更深层管道管理和基于团队的开发时，进入管道编辑器。

了解有关使用Lakeflow管道编辑器构建声明式ETL工作流的更多信息。

使用Genie Code更快入门

Genie Code使SQL从业者更容易在他们已经使用的工作流中发现和应用这些声明式ETL模式。用户无需从空白页开始或手动将现有SQL翻译成生产就绪模式，而是可以请求Genie Code帮助生成、解释和完善声明式流程。

例如，使用CDC数据的用户可以请求Genie Code帮助创建AUTO CDC流程，包括适当的键、序列列、删除处理和SCD类型1或类型2行为。处理重复批处理逻辑的用户可以请求Genie Code帮助将现有的覆盖逻辑转换为增量REPLACE WHERE流程。

随着声明式ETL在更多创作体验中可用，Genie Code可以帮助指导用户为手头任务选择正确的声明式模式。

要开始，请浏览上面各部分中链接的文档-并在SQL编辑器中使用Genie Code来识别APPEND流程、AUTO CDC流程或REPLACE WHERE流程可以简化你现有ETL逻辑的地方。