迁移到 Databricks 无服务器计算:提升效率与成本优化的完整指南

本文详细介绍了如何将传统工作负载从 Databricks 经典计算迁移到无服务器计算,涵盖迁移步骤、优势对比、环境兼容性验证、数据安全配置以及性能优化策略,帮助实现高效的集群管理和成本控制。

迁移传统工作负载从经典计算到 Databricks 无服务器计算

本文引导我们完成将使用经典计算的传统工作负载迁移到无服务器计算的过程,以实现高效的集群管理、成本效益、更好的可扩展性和优化性能。

概述

随着数据工程的发展,企业工作负载的基础设施需求也在不断演变。随着对敏捷性、可扩展性和成本效益的日益增长的需求,Databricks 无服务器计算提供了一个引人注目的经典集群替代方案。在本文中,我们探讨了一个实用的路线图,将您的管道和分析工作负载从经典计算(手动集群或作业集群)迁移到 Databricks 无服务器计算,特别关注数据安全、调度、成本和操作弹性。

为什么迁移到无服务器计算?

在深入迁移步骤之前,让我们比较一下为什么无服务器计算比经典计算更适合工作负载:

特性 经典计算 无服务器计算
集群管理 手动或自动化 由 Databricks 完全管理
成本控制 容易产生闲置成本 闲置计算不收费
可扩展性 手动配置 根据工作负载需求自动扩展
安全隔离 共享虚拟机,除非隔离 安全的运行时隔离计算
性能优化 用户优化 Databricks 优化的运行时和 IO

对于涉及计划 ETL 作业、月度对账或分类账计算的数据管道任务,无服务器计算提供了弹性和减少的维护负担——非常适合具有可预测模式的中小型批处理工作负载。

先决条件:评估当前工作负载的资产

让我们从审计您现有的经典集群工作负载开始:

  • 识别作业类型:ETL 管道、报告脚本、对账逻辑。
  • 数据源:Delta 表、JDBC、云存储(例如 S3、ADLS)。
  • 计划和频率:作业运行频率如何?每晚、每月、临时?
  • 依赖项:是否有共享库、密钥或初始化脚本?
  • 执行环境:Python、SQL、Scala 或笔记本?

创建一个清单,并为每个工作负载标记计算和运行时需求(例如,内存、核心、运行时间)。

迁移过程流程演练

步骤 1:在 Databricks 中设置无服务器计算

a. 在您的工作区启用无服务器

  • 转到管理员控制台 → 计算。
  • 确保无服务器计算已启用。
  • 如果需要,请联系您的 Databricks 支持团队在工作区中启用它(可能取决于云提供商和计划)。

b. 创建一个无服务器 SQL 仓库(可选)

如果您的工​​作负载主要是 SQL(例如,分类账查询、报告仪表板):

  • 导航到 SQL → SQL 仓库。
  • 单击创建 → 选择无服务器 → 配置自动扩展、超时和权限。

对于 Python/Scala 作业,继续下一步。

步骤 2:将作业迁移到无服务器计算

a. 作业迁移步骤(Databricks 工作流)

如果您使用作业集群:

  • 从工作流中打开现有作业。
  • 单击编辑作业设置。
  • 在集群配置下 → 更改集群类型为:
    • “共享”无服务器作业集群,或
    • 使用现有的无服务器池(如果已设置)。

如果您使用笔记本或工作流:

  • 将附加计算设置为无服务器作业集群。
  • 确保使用初始化脚本或工作区库安装所有库(避免集群级安装)。

b. 验证环境兼容性

  • 确保所有库(例如 Pandas、PySpark)在无服务器支持的 Databricks 运行时下工作。
  • 如果使用旧版 Hive 或 JDBC 连接器,确认其工作或迁移到 Unity Catalog / 本机 Delta 连接。
  • 审查任何假定 VM 或磁盘上下文的初始化脚本或文件路径——它们在无服务器中可能不会完全相同地行为。

步骤 3:调度作业和监控性能

Databricks 允许通过工作流进行作业调度和重试逻辑:

  • 转到工作流 → 创建作业。
  • 设置笔记本/脚本路径、参数和计划(例如,“每月第一天凌晨 3 点”)。
  • 配置成功/失败的电子邮件/Slack 警报。
  • 启用重试策略(例如,失败时最多重试 3 次)。

使用作业指标 UI 比较性能:

  • 每个任务的 CPU 和内存使用情况。
  • 无服务器迁移前后每个作业的运行时间。
  • 成本估算仪表板(如果启用)。

步骤 4:安全访问数据

大多数数据是敏感的。确保:

  • 启用 Unity Catalog 进行细粒度访问控制。
  • 使用凭据传递或服务主体访问云存储。
  • 使用 Databricks 密钥存储密钥并在作业中安全访问它们。

示例:

1
2
3
4
import os
import pyspark.sql.functions as F

db_pass = dbutils.secrets.get(scope="-secrets", key="db-password")

步骤 5:优化和扩展

迁移后,应用这些优化步骤:

  • 对所有表使用 Delta Lake 以受益于缓存和 ACID 合规性。
  • 对频繁列应用 Z-Ordering(例如,account_id、period)。
  • 在无服务器 SQL 中使用 photon 运行时进行更快计算。
  • 监控未充分利用的计算——相应地调整自动扩展阈值。

步骤 6:示例用例:月度会计对账

假设您的经典集群运行一个像这样的笔记本:

1
2
3
4
5
6
7
8
# Load entries
df = spark.read.table("Ledger_2024")

# Summarize per account
summary = df.groupBy("account_id").agg(F.sum("debit"), F.sum("credit"))

# Write to delta
summary.write.format("delta").mode("overwrite").save("/mnt/ledger/summary")

要迁移:

  • 将此笔记本移动到具有无服务器作业集群的计划工作流中。
  • 如果可能,将路径如 /mnt/… 替换为 Unity Catalog 引用。
  • 确保通过目录权限访问 Ledger_2024。

关键考虑和限制

考虑因素 说明
冷启动时间 第一个请求可能有轻微延迟(约 10 秒)
外部库 优先通过 PyPI 或工作区库安装的库
作业隔离 无法直接访问 DBFS 根或集群本地文件
网络约束 如果您依赖 VPC 对等或私有端点,检查与无服务器网络架构的兼容性

迁移后注意事项

  • 成本监控:无服务器收费是基于使用量的。定期通过 Databricks 计费仪表板监控成本。
  • 审计日志记录:确保配置审计日志以跟踪访问和执行。
  • 安全加固:为生产环境应用适当的工作区控制、令牌生命周期和访问级别。

结论

在 Databricks 中从经典计算迁移到无服务器计算显著提高了成本效率、可管理性和可扩展性,特别是对于像会计这样的结构化工作负载。通过遵循从清单、计算设置、作业转换到优化的结构化迁移路径,您可以确保平稳过渡而不牺牲性能或安全性。

这种迁移是现代化您的数据和 AI 基础设施的战略步骤。随着过渡引入架构和操作变化,在敏捷性、成本节省和可扩展性方面的好处是显著的。通过遵循先决条件并采用有条理的迁移策略,您的团队可以充分利用 Databricks 无服务器计算的力量。

我们应该逐步和战略性地处理迁移,首先从非关键工作负载开始,然后将无服务器使用扩展到核心和关键数据管道和作业。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计