Freigeben über


Konfiguration für Databricks-Ressourcenpaket

In diesem Artikel wird die Syntax für Databricks Asset Bundle-Konfigurationsdateien beschrieben, die Databricks Asset Bundles definieren. Siehe Was sind Databricks Asset Bundles?.

Informationen zum Erstellen und Arbeiten mit Bündeln finden Sie unter Develop Databricks Asset Bundles.

Referenz zur Bündelkonfiguration finden Sie unter Konfigurationsreferenz.

databricks.yml

Ein Bündel muss eine (und nur eine) Konfigurationsdatei enthalten, die im Stammverzeichnis des Bundleprojektordners benannt databricks.yml ist. databricks.yml ist die Hauptkonfigurationsdatei, die ein Bündel definiert, aber sie kann auf andere Konfigurationsdateien wie Ressourcenkonfigurationsdateien in der include Zuordnung verweisen. Die Bundlekonfiguration wird in YAML ausgedrückt. Weitere Informationen zu YAML finden Sie in der offiziellen YAML-Spezifikation.

Der einfachste databricks.yml definiert den Bundlenamen, bei dem es sich um eine erforderliche Zuordnung auf oberster Ebene und eine Zielbereitstellung handelt.

bundle:
  name: my_bundle

targets:
  dev:
    default: true

Ausführliche Informationen zu allen Zuordnungen auf oberster Ebene finden Sie in der Konfigurationsreferenz.

Tipp

Python-Unterstützung für Databricks Asset Bundles ermöglicht es Ihnen, Ressourcen in Python zu definieren. Siehe Bundle-Konfiguration in Python.

Spezifikation

Die folgende YAML-Spezifikation stellt Konfigurationsschlüssel der obersten Ebene für Databricks Asset Bundles bereit. Eine Konfigurationsreferenz finden Sie unter Konfigurationsreferenz.

# This is the default bundle configuration if not otherwise overridden in
# the "targets" top-level mapping.
bundle: # Required.
  name: string # Required.
  databricks_cli_version: string
  cluster_id: string
  deployment: Map
  git:
    origin_url: string
    branch: string

# This is the identity to use to run the bundle
run_as:
  - user_name: <user-name>
  - service_principal_name: <service-principal-name>

# These are any additional configuration files to include.
include:
  - '<some-file-or-path-glob-to-include>'
  - '<another-file-or-path-glob-to-include>'

# These are any scripts that can be run.
scripts:
  <some-unique-script-name>:
    content: string

# These are any additional files or paths to include or exclude.
sync:
  include:
    - '<some-file-or-path-glob-to-include>'
    - '<another-file-or-path-glob-to-include>'
  exclude:
    - '<some-file-or-path-glob-to-exclude>'
    - '<another-file-or-path-glob-to-exclude>'
  paths:
    - '<some-file-or-path-to-synchronize>'

# These are the default artifact settings if not otherwise overridden in
# the targets top-level mapping.
artifacts:
  <some-unique-artifact-identifier>:
    build: string
    dynamic_version: boolean
    executable: string
    files:
      - source: string
    path: string
    type: string

# These are for any custom variables for use throughout the bundle.
variables:
  <some-unique-variable-name>:
    description: string
    default: string or complex
    lookup: Map
    type: string # The only valid value is "complex" if the variable is a complex variable, otherwise do not define this key.

# These are the default workspace settings if not otherwise overridden in
# the targets top-level mapping.
workspace:
  artifact_path: string
  auth_type: string
  azure_client_id: string # For Azure Databricks only.
  azure_environment: string # For Azure Databricks only.
  azure_login_app_id: string # For Azure Databricks only. Reserved for future use.
  azure_tenant_id: string # For Azure Databricks only.
  azure_use_msi: true | false # For Azure Databricks only.
  azure_workspace_resource_id: string # For Azure Databricks only.
  client_id: string # For Databricks on AWS only.
  file_path: string
  google_service_account: string # For Databricks on Google Cloud only.
  host: string
  profile: string
  resource_path: string
  root_path: string
  state_path: string

# These are the permissions to apply to resources defined
# in the resources mapping.
permissions:
  - level: <permission-level>
    group_name: <unique-group-name>
  - level: <permission-level>
    user_name: <unique-user-name>
  - level: <permission-level>
    service_principal_name: <unique-principal-name>

# These are the resource settings if not otherwise overridden in
# the targets top-level mapping.
resources:
  apps:
    <unique-app-name>:
      # See the REST API create request payload reference for apps.
  clusters:
    <unique-cluster-name>:
      # See the REST API create request payload reference for clusters.
  dashboards:
    <unique-dashboard-name>:
      # See the REST API create request payload reference for dashboards.
  experiments:
    <unique-experiment-name>:
      # See the REST API create request payload reference for experiments.
  jobs:
    <unique-job-name>:
      # See REST API create request payload reference for jobs.
  model_serving_endpoint:
    <unique-model-serving-endpoint-name>:
    # See the model serving endpoint request payload reference.
  models:
    <unique-model-name>:
      # See the REST API create request payload reference for models (legacy).
  pipelines:
    <unique-pipeline-name>:
      # See the REST API create request payload reference for :re[LDP] (pipelines).
  quality_monitors:
    <unique-quality-monitor-name>:
    # See the quality monitor request payload reference.
  registered_models:
    <unique-registered-model-name>:
    # See the registered model request payload reference.
  schemas:
    <unique-schema-name>:
      # See the Unity Catalog schema request payload reference.
  secret_scopes:
    <unique-secret-scope-name>:
      # See the secret scope request payload reference.
  volumes:
    <unique-volume-name>:
    # See the Unity Catalog volume request payload reference.

# These are the targets to use for deployments and workflow runs. One and only one of these
# targets can be set to "default: true".
targets:
  <some-unique-programmatic-identifier-for-this-target>:
    artifacts:
      # See the preceding "artifacts" syntax.
    bundle:
      # See the preceding "bundle" syntax.
    default: boolean
    git: Map
    mode: string
    permissions:
      # See the preceding "permissions" syntax.
    presets:
      <preset>: <value>
    resources:
      # See the preceding "resources" syntax.
    sync:
      # See the preceding "sync" syntax.
    variables:
      <preceding-unique-variable-name>: <non-default-value>
    workspace:
      # See the preceding "workspace" syntax.
    run_as:
      # See the preceding "run_as" syntax.

Beispiele

Dieser Abschnitt enthält einige grundlegende Beispiele, die Ihnen helfen, zu verstehen, wie Bündel funktionieren und wie die Konfiguration strukturiert wird.

Hinweis

Beispiele für die Konfiguration, die die Bundle-Funktionen und gängige Bundle-Anwendungsfälle demonstrieren, finden Sie unter Beispiele für die Bundle-Konfiguration und im Repository für Bundle-Beispiele auf GitHub.

Die folgende Beispielbundlekonfiguration gibt eine lokale Datei mit dem Namen hello.py an, die sich im selben Verzeichnis wie die Bundlekonfigurationsdatei databricks.ymlbefindet. Sie führt dieses Notebook als Job aus und verwendet dabei den remote Cluster mit der angegebenen Cluster-ID. Die URL des Remotearbeitsbereichs und die Anmeldeinformationen für die Arbeitsbereichauthentifizierung werden aus dem lokalen Konfigurationsprofil des Anrufers mit dem Namen DEFAULTgelesen.

bundle:
  name: hello-bundle

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

targets:
  dev:
    default: true

Das folgende Beispiel fügt ein Ziel mit dem Namen prod hinzu, das eine andere remote Arbeitsbereich-URL und Anmeldeinformationen für den Arbeitsbereich verwendet, die aus dem passenden .databrickscfg-Eintrag der Datei host des Aufrufers mit der angegebenen Arbeitsbereich-URL gelesen werden. Dieser Auftrag führt dasselbe Notebook aus, verwendet jedoch einen anderen Remotecluster mit der angegebenen Cluster-ID.

Hinweis

Databricks empfiehlt, nach Möglichkeit die host-Zuordnung anstelle der default-Zuordnung zu verwenden, da Ihre Paketkonfigurationsdateien dadurch portierbarer werden. Wenn Sie die host-Zuordnung festlegen, weist dies die Databricks CLI an, ein übereinstimmendes Profil in Ihrer .databrickscfg-Datei zu finden und dann die Felder dieses Profils zu verwenden, um zu bestimmen, welcher Databricks-Authentifizierungstyp genutzt werden soll. Wenn mehrere Profile mit einem übereinstimmenden host Feld vorhanden sind, müssen Sie die --profile Option für Bundlebefehle verwenden, um ein zu verwendenes Profil anzugeben.

Beachten Sie, dass Sie die notebook_task-Zuordnung innerhalb der prod-Zuordnung nicht deklarieren müssen, da sie auf die Verwendung der notebook_task-Zuordnung innerhalb der Zuordnung der obersten Ebene resources zurückfällt, wenn die notebook_task-Zuordnung nicht explizit in der prod-Zuordnung überschrieben wird.

bundle:
  name: hello-bundle

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>
    resources:
      jobs:
        hello-job:
          name: hello-job
          tasks:
            - task_key: hello-task
              existing_cluster_id: 2345-678901-fabcd456

Verwenden Sie die folgenden Bundlebefehle , um diesen Auftrag innerhalb des dev Ziels zu überprüfen, bereitzustellen und auszuführen. Ausführliche Informationen zum Lebenszyklus eines Bundles finden Sie unter Develop Databricks Asset Bundles.

# Because the "dev" target is set to "default: true",
# you do not need to specify "-t dev":
databricks bundle validate
databricks bundle deploy
databricks bundle run hello_job

# But you can still explicitly specify it, if you want or need to:
databricks bundle validate
databricks bundle deploy -t dev
databricks bundle run -t dev hello_job

So können Sie diesen Auftrag stattdessen im prod-Ziel überprüfen, bereitstellen und ausführen:

# You must specify "-t prod", because the "dev" target
# is already set to "default: true":
databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod hello_job

Für eine bessere Modularisierung und eine bessere Wiederverwendung von Definitionen und Einstellungen in Bündeln, teilen Sie Ihre Bundlekonfiguration in separate Dateien auf:

# databricks.yml

bundle:
  name: hello-bundle

include:
  - '*.yml'
# hello-job.yml

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py
# targets.yml

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>
    resources:
      jobs:
        hello-job:
          name: hello-job
          tasks:
            - task_key: hello-task
              existing_cluster_id: 2345-678901-fabcd456