databricks-serverless

在无服务器计算上部署 Databricks 作业和管道

首先：使用父级 databricks-core 技能了解 CLI 基础知识、身份验证和配置文件选择。

此技能用于决定计算资源。如果其他技能或示例（例如 databricks-jobs）展示了集群配置，请改用此技能。

无服务器计算是你创建的每个作业、管道和 bundle 的默认计算资源。如果用户明确要求使用集群，就按要求操作，并用一行说明无服务器选项。编辑现有作业时，除非用户要求更改，否则保留其计算资源；你添加的任务则遵循此技能。

1. 无服务器计算还是经典计算

仅在以下情况下使用经典计算：

• R 代码，或笔记本单元格中的 Scala（%scala）：无服务器笔记本仅运行 Python 和 SQL；
• 自定义 Docker 镜像；
• OS 软件包（apt-get）或没有 pip 等效项的原生库；
• 自定义 Spark 数据源 JAR；
• 明确要求特定实例类型或 Databricks Runtime 版本；
• 用户明确要求；
• 现有代码超出第 5 节的预算；
• 工作区不支持无服务器计算：如果创建或运行作业因该工作区不支持无服务器计算而失败，请将整个作业改为经典计算，并说明原因。

此时仅为受阻任务分配集群（添加一个较小的 job_clusters 条目，使用最新的 LTS Runtime，并设置 autoscale: {min_workers: 1, max_workers: 4}），其他任务仍使用无服务器计算，并用一行说明受阻原因。对于受阻的管道，为管道添加 clusters 块，而不是设置 serverless: true。

以下情况不构成使用经典计算的理由：JAR 任务中的 Scala 或 Java（JAR 任务可在无服务器计算上运行）、GPU（无服务器 GPU）、大型数据、长时间运行、Kafka、成本（在大多数情况下，无服务器 STANDARD 的费用与按需经典计算持平或更低），或习惯。

2. 让每个任务都使用无服务器计算

• **新建作业：**省略 new_cluster、job_clusters、job_cluster_key、existing_cluster_id、instance_pool_id、node_type_id、num_workers、autoscale 和 spark_version。未指定集群的任务将在无服务器计算上运行。在现有作业中，保留已有的集群设置。
• 笔记本任务无需其他设置。Python 脚本、wheel 和 JAR 任务从作业级环境获取其库。使用工作区提供的最新环境版本，并将其设为带引号的字符串：

  environments:
    - environment_key: default
      spec:
        environment_version: "4"                # example; use the latest
        dependencies: ["requests==2.32.3"]   # pin versions; JARs go in java_dependencies
  tasks:
    - task_key: main
      spark_python_task: {python_file: /Workspace/.../main.py}
      environment_key: default
  

• **SQL 任务：**使用无服务器 SQL 仓库。**管道：**设置 serverless: true，不添加 clusters 块。
• **流式处理：**使用 .trigger(availableNow=True)，这是无服务器计算支持的触发器（不要使用 processingTime 或 continuous 触发器）。对于持续运行的处理，将该流放入连续作业中运行（continuous: {pause_status: UNPAUSED}），这样一次运行结束后就会立即启动下一次运行；也可以使用连续管道。
• 为创建的每个作业添加标签以跟踪资源，与其他 Databricks 技能一致：在作业级设置 tags: {"aidevkit_project": "ai-dev-kit"}。保留用户已有的标签。

3. 选择性能模式

设置作业级 performance_target：

• STANDARD：当任务没有时效要求，且成本比速度更重要时使用；适用于定时批处理和 ETL、每晚或每周运行的任务，或用户未提出延迟要求的任何作业。运行启动时间为数分钟而非数秒，费用更低。这是默认选项。
• PERFORMANCE_OPTIMIZED：仅当用户提出 SLA 或相对于运行时长而言较紧迫的截止时间、有人等待结果，或作业每 30 分钟或更频繁地运行时使用。

performance_target 适用于整个作业，包括笔记本任务（只有交互式笔记本始终以性能优化模式运行）。用一行说明所选模式及原因，例如：“STANDARD：每晚批处理，无截止时间要求。” 无服务器 GPU 任务不受 performance_target 影响。

管道没有自己的 performance_target。要调度管道，请通过带有 pipeline_task 的作业触发管道，并在该作业上设置模式；作业的模式会应用于管道更新。只有在连续作业运行连续管道时，该连续管道才会以 STANDARD 模式运行。

4. 从一开始，你编写的代码就运行在无服务器环境中

无服务器环境可以读取 Unity Catalog 表、/Volumes/... 路径、Unity Catalog 外部位置背后的云路径，以及 dbfs:/databricks-datasets/ 下的示例数据。它无法读取 DBFS 挂载（dbfs:/mnt/...）或其他 DBFS 根路径；只有这些才算 DBFS 阻碍。

仅使用 DataFrame 和 SQL API（不使用 RDD、sc.*、spark.sparkContext）；使用 Unity Catalog 三段式表名；使用 /Volumes/... 路径，而不是 DBFS 挂载（dbfs:/mnt/...）；使用 availableNow 流式触发器；不使用 .cache() 或 .persist()；不使用 spark.conf.set 设置执行器、驱动程序或内存参数；在环境中固定依赖项，绝不使用初始化脚本。

5. 现有代码：快速检查，而非迁移

用户正在等待部署。快速检查一遍，然后部署。

1. 只扫描作业会运行的文件（使用 grep 或 rg 之类的文本搜索；不要通读整个仓库），搜索以下内容：sc., sparkContext、.rdd、parallelize、mapPartitions、reduceByKey、groupByKey、dbfs:/、/dbfs/、dbutils.fs.mount、.cache(、.persist(、spark.conf.set、processingTime、continuous=、writeStream、hive_metastore.、GLOBAL TEMP、hivevar、init_scripts、apt-get、docker，以及其他语言：作为完整 magic 的 %scala 或 %r（# MAGIC %r，而非 %run）、.r 文件和 R 笔记本、SparkR 和 sparklyr。R 和 Scala 单元格转到 classic（第 1 节）。

2. 轻微阻碍：修复后部署到 serverless，前提是所有修复都是机械且局部的，保留原有逻辑，无需新增基础设施，且总共约 5 处或更少的小改动：

   • 删除 .cache()、.persist()、.unpersist()、setLogLevel 以及 executor/driver/AQE 的 spark.conf.set 行
   • 将 pip install 或 requirements.txt 移至环境中，并固定版本
   • 如果流没有设置触发器，且作业本来就按计划运行，则添加 .trigger(availableNow=True)（设置了 processingTime 或 continuous 触发器的流属于第 4 步的阻碍）
   • 只有当卷的存储位置就是挂载点的源位置时，才将 dbfs:/mnt/... 路径替换为 /Volumes/... 路径，以确保作业读取相同数据；卷名称相似并不足够。否则，挂载点属于第 4 步的阻碍。
   • 如果同一文件中创建并读取视图，则将 CREATE GLOBAL TEMP VIEW 改为 CREATE TEMP VIEW，并将对 global_temp.<view> 的读取改为 <view>（serverless 不支持全局临时视图）；其他任务或笔记本读取的全局临时视图属于第 4 步的阻碍
   • 只有在明确知道 Unity Catalog 中哪个目录保存该表时，才为两段式表名添加目录名（例如作业的默认目录）；位于 hive_metastore 中的表属于第 4 步的阻碍

   在回复中列出你所做的每项改动。

3. RDD 或 SparkContext 代码：仅当满足以下所有条件时，才将其转换为 DataFrames 并部署到 serverless：

   • 代码在一个文件中，且约 200 行或更少；
   • 这是纯 API 转换：使用 DataFrame 或 SQL 表达相同逻辑；
   • 每个输入路径、表、输出表和参数都保持原样。绝不能换成其他数据集，即使是示例数据集也不行；
   • 每个输入在 serverless 上都已可读（第 4 节：Unity Catalog 表、现有的 /Volumes/... 路径、由外部位置支持的云路径，或 dbfs:/databricks-datasets/），因此无需进行任何新设置。

   将原文件保存为同目录下的 <name>.classic.py，并让作业指向转换后的文件。告知用户转换尚未运行，并建议执行一次测试运行，将输出与 classic 版本进行比较。

4. 其他情况：不要重写。 现在将该任务放到 classic 上（第 1 节），其他任务继续使用 serverless，并以以下内容结尾："Kept on classic because . To move it to serverless, use the databricks-serverless-migration skill." 更大的改动包括：未满足第 3 步任一条件的 RDD 代码（例如读取 DBFS 挂载点）、没有同一存储位置上的卷的挂载点、从 Hive Metastore 迁移到 Unity Catalog、重新编译 JAR、网络变更、改变流的行为（持续运行的 processingTime 或 continuous 流），或除第 3 步转换外超过约 5 处改动。

不要停下来询问是否迁移。完成部署后，再报告所做的工作。

常见问题

问题	解决方案
Libraries field is not supported for serverless task	将库移到 environments[].spec.dependencies 中（JAR：java_dependencies），并在任务上设置 environment_key
无服务器作业启动过慢	仅当用户需要快速启动时，使用 performance_target: PERFORMANCE_OPTIMIZED（第 3 节）
Only remote Spark sessions ... are supported 或其他 RDD 错误	RDD/SparkContext 代码：第 5 节的步骤 3 或 4
[PATH_NOT_FOUND] 或无法访问 dbfs:/mnt/...	DBFS 挂载无法在无服务器环境中使用：请使用同一存储上的卷（第 5 节，步骤 2），否则使用步骤 4
工作区未启用或无法使用无服务器	将作业放到经典计算上并告知用户（第 1 节）
相关技能中的示例对新作业使用 job_clusters	不要添加集群代码块；由此技能决定计算资源。现有作业保留其计算资源

相关技能

• databricks-core - CLI 基础、身份验证、配置文件
• databricks-jobs - 作业结构、任务类型、触发器、通知
• databricks-pipelines - Lakeflow Spark 声明式管道
• databricks-serverless-migration - 将现有经典工作负载迁移到无服务器

文档

• 作业的无服务器计算
• 无服务器计算限制
• 无服务器依赖项（环境）
• 无服务器管道