Konfiguration av Databricks Asset Bundle

I den här artikeln beskrivs syntaxen för Databricks Asset Bundle-konfigurationsfiler, som definierar Databricks-tillgångspaket. Se Vad är Databricks-tillgångspaket?

En paketkonfigurationsfil måste uttryckas i YAML-format och måste minst innehålla paketmappningen på den översta nivån. Varje paket måste innehålla minst en (och endast en) paketkonfigurationsfil med namnet databricks.yml. Om det finns flera paketkonfigurationsfiler måste de refereras av filen med hjälp av databricks.yml mappningen include .

Mer information om YAML finns i den officiella YAML-specifikationen och självstudien.

Information om hur du skapar och arbetar med paketkonfigurationsfiler finns i Utveckling av Databricks-tillgångspaket.

Översikt

Det här avsnittet innehåller en visuell representation av paketkonfigurationsfilschemat. Mer information finns i Mappningar.

# 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
  git:
    origin_url: string
    branch: string

# These are for any custom variables for use throughout the bundle.
variables:
  <some-unique-variable-name>:
    description: string
    default: string or complex

# These are the default workspace settings if not otherwise overridden in
# the following "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. Non-operational and 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
  root_path: string
  state_path: string

# These are the permissions to apply to experiments, jobs, models, and pipelines 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 default artifact settings if not otherwise overridden in
# the following "targets" top-level mapping.
artifacts:
  <some-unique-artifact-identifier>:
    build: string
    files:
      - source: string
    path: string
    type: string

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

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

# These are the default job and pipeline settings if not otherwise overridden in
# the following "targets" top-level mapping.
resources:
  dashboards:
    <some-unique-programmatic-identifier-for-this-dashboard>:
      # See the REST API create request payload reference for dashboards.
  experiments:
    <some-unique-programmatic-identifier-for-this-experiment>:
      # See the REST API create request payload reference for experiments.
  jobs:
    <some-unique-programmatic-identifier-for-this-job>:
      # See REST API create request payload reference for jobs.
  models:
    <some-unique-programmatic-identifier-for-this-model>:
      # See the REST API create request payload reference for models.
  pipelines:
    <some-unique-programmatic-identifier-for-this-pipeline>:
      # See the REST API create request payload reference for Delta Live Tables (pipelines).
  schemas:
    <some-unique-programmatic-identifier-for-this-schema>:
      # See the Unity Catalog schema request payload reference.

# 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 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.
    cluster_id: string
    default: true | false
    mode: development
    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.

Exempel

Följande exempelpaketkonfiguration anger en lokal fil med namnet hello.py som finns i samma katalog som den lokala paketkonfigurationsfilen med namnet databricks.yml. Den kör den här notebook-filen som ett jobb med hjälp av fjärrklustret med det angivna kluster-ID:t. Autentiseringsuppgifterna för fjärrarbetsytans URL och autentiseringsuppgifter för arbetsytan läss från anroparens lokala konfigurationsprofil med namnet DEFAULT.

Databricks rekommenderar att du använder mappningen host i stället för mappningen default där det är möjligt, eftersom det gör paketkonfigurationsfilerna mer portabla. Om du anger mappningen host instrueras Databricks CLI att hitta en matchande profil i .databrickscfg filen och sedan använda profilens fält för att avgöra vilken Databricks-autentiseringstyp som ska användas. Om det finns flera profiler med ett matchande host fält i .databrickscfg filen måste du använda profile för att instruera Databricks CLI om vilken specifik profil som ska användas. Ett exempel finns i måldeklarationen prod senare i det här avsnittet.

Med den här tekniken kan du återanvända och åsidosätta jobbdefinitionerna och inställningarna i resources blocket:

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

Även om följande paketkonfigurationsfil är funktionellt likvärdig, är den inte modulariserad, vilket inte möjliggör bra återanvändning. Den här deklarationen lägger också till en uppgift i jobbet i stället för att åsidosätta det befintliga jobbet:

bundle:
  name: hello-bundle

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

I följande exempel läggs ett mål med namnet prod som använder en annan url för fjärrarbetsyta och autentiseringsuppgifter för arbetsytan, som läss från anroparens filmatchningspost host med den angivna arbetsytans .databrickscfg URL. Det här jobbet kör samma notebook-fil men använder ett annat fjärrkluster med det angivna kluster-ID:t. Observera att du inte behöver deklarera mappningen i mappningen prod eftersom den återgår till att använda mappningen notebook_task i den översta mappningenresources, om mappningen notebook_task inte uttryckligen åsidosätts i mappningenprod.notebook_task

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

Verifiera, distribuera och kör det här jobbet inom dev målet:

# 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

Verifiera, distribuera och kör det här jobbet inom prod målet i stället:

# 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öljande är det föregående exemplet men delas upp i komponentfiler för ännu mer modularisering och bättre återanvändning över flera paketkonfigurationsfiler. Med den här tekniken kan du inte bara återanvända olika definitioner och inställningar, utan du kan också växla ut någon av dessa filer med andra filer som ger helt olika deklarationer:

databricks.yml:

bundle:
  name: hello-bundle

include:
  - "bundle*.yml"

bundle.resources.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

bundle.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

Mappningar

I följande avsnitt beskrivs syntaxen för paketkonfigurationsfilen efter mappning på den översta nivån.

• knyte
• Variabler
• arbetsyta
• permissions
• Artefakter
• inbegripa
• Resurser
• synkronisering
• Mål

knyte

En paketkonfigurationsfil får bara innehålla en mappning på den översta nivån bundle som associerar paketets innehåll och inställningarna för Azure Databricks-arbetsytan.

Den här bundle mappningen måste innehålla en name mappning som anger ett programmatiskt (eller logiskt) namn för paketet. I följande exempel deklareras ett paket med det programmatiska (eller logiska) namnet hello-bundle.

bundle:
  name: hello-bundle

En bundle mappning kan också vara underordnad ett eller flera av målen i den översta målmappningen . Var och en av dessa underordnade bundle mappningar anger eventuella icke-standard åsidosättningar på målnivå. Det går dock inte att åsidosätta värdet för toppnivåmappningen bundle name på målnivån.

cluster_id

Mappningen kan ha en underordnad bundle cluster_id mappning. Med den här mappningen kan du ange ID för ett kluster som ska användas som åsidosättning för kluster som definierats någon annanstans i paketkonfigurationsfilen. Information om hur du hämtar ID:t för ett kluster finns i Kluster-URL och ID.

Åsidosättningen cluster_id är avsedd för scenarier med endast utveckling och stöds endast för det mål som har mappningen mode inställd på development. Mer information om mappningen finns i target mål.

compute_id

Mappningen kan ha en underordnad bundle compute_id mappning. Med den här mappningen kan du ange ID för ett kluster som ska användas som åsidosättning för kluster som definierats någon annanstans i paketkonfigurationsfilen.

Git

Du kan hämta och åsidosätta information om Git-versionskontroll som är associerade med ditt paket. Detta är användbart för att kommentera dina distribuerade resurser. Du kanske till exempel vill ta med ursprungs-URL:en för lagringsplatsen i beskrivningen av en maskininlärningsmodell som du distribuerar.

När du kör ett bundle kommando som validate, deploy eller run, bundle fyller kommandots konfigurationsträd med följande standardinställningar:

• bundle.git.origin_url, som representerar lagringsplatsens ursprungs-URL. Det här är samma värde som du skulle få om du körde kommandot git config --get remote.origin.url från din klonade lagringsplats. Du kan använda ersättningar för att referera till det här värdet med dina paketkonfigurationsfiler , som ${bundle.git.origin_url}.
• bundle.git.branch, som representerar den aktuella grenen i lagringsplatsen. Det här är samma värde som du skulle få om du körde kommandot git branch --show-current från din klonade lagringsplats. Du kan använda ersättningar för att referera till det här värdet med dina paketkonfigurationsfiler , som ${bundle.git.branch}.
• bundle.git.commit, som representerar incheckningen HEAD i lagringsplatsen. Det här är samma värde som du skulle få om du körde kommandot git rev-parse HEAD från din klonade lagringsplats. Du kan använda ersättningar för att referera till det här värdet med dina paketkonfigurationsfiler , som ${bundle.git.commit}.

Om du vill hämta eller åsidosätta Git-inställningar måste ditt paket finnas i en katalog som är associerad med en Git-lagringsplats, till exempel en lokal katalog som initieras genom att köra git clone kommandot. Om katalogen inte är associerad med en Git-lagringsplats är de här Git-inställningarna tomma.

Du kan åsidosätta origin_url inställningarna och branch i mappningen git av din toppnivåmappning bundle om det behövs, enligt följande:

bundle:
  git:
    origin_url: <some-non-default-origin-url>
    branch: <some-non-current-branch-name>

databricks_cli_version

Mappningen bundle kan innehålla en databricks_cli_version mappning som begränsar den Databricks CLI-version som krävs av paketet. Detta kan förhindra problem som orsakas av mappningar som inte stöds i en viss version av Databricks CLI.

Databricks CLI-versionen överensstämmer med semantisk versionshantering och mappningen databricks_cli_version har stöd för att ange versionsbegränsningar. Om det aktuella databricks --version värdet inte ligger inom de gränser som anges i paketets databricks_cli_version mappning uppstår ett fel när databricks bundle validate det körs i paketet. I följande exempel visas några vanliga syntaxer för versionsbegränsningar:

bundle:
  name: hello-bundle
  databricks_cli_version: "0.218.0" # require Databricks CLI 0.218.0

bundle:
  name: hello-bundle
  databricks_cli_version: "0.218.*" # allow all patch versions of Databricks CLI 0.218

bundle:
  name: my-bundle
  databricks_cli_version: ">= 0.218.0" # allow any version of Databricks CLI 0.218.0 or higher

bundle:
  name: my-bundle
  databricks_cli_version: ">= 0.218.0, <= 1.0.0" # allow any Databricks CLI version between 0.218.0 and 1.0.0, inclusive

Variabler

Filen med paketinställningar kan innehålla en mappning på den översta nivån variables där anpassade variabler definieras. För varje variabel anger du en valfri beskrivning, standardvärde, om den anpassade variabeln är en komplex typ eller uppslag för att hämta ett ID-värde med följande format:

variables:
  <variable-name>:
    description: <variable-description>
    default: <optional-default-value>
    type: <optional-type-value> # "complex" is the only valid value
    lookup:
      <optional-object-type>: <optional-object-name>

Om du vill referera till en anpassad variabel i paketkonfigurationen använder du ersättningen ${var.<variable_name>}.

Mer information om anpassade variabler och ersättningar finns i Substitutioner och variabler i Databricks-tillgångspaket.

arbetsyta

Paketkonfigurationsfilen kan bara innehålla en mappning på den översta nivån workspace för att ange eventuella icke-standardinställningar för Azure Databricks-arbetsytor som ska användas.

root_path

Den här workspace mappningen kan innehålla en root_path mappning för att ange en icke-standardrotsökväg som ska användas på arbetsytan för både distributioner och arbetsflödeskörningar, till exempel:

workspace:
  root_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}

Som standard root_path använder Databricks CLI standardsökvägen /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}för , som använder substitutioner.

artifact_path

Den här workspace mappningen kan också innehålla en artifact_path mappning för att ange en icke-standardartefaktsökväg som ska användas på arbetsytan för både distributioner och arbetsflödeskörningar, till exempel:

workspace:
  artifact_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}/artifacts

Som standard artifact_path använder Databricks CLI standardsökvägen ${workspace.root}/artifactsför , som använder substitutioner.

file_path

Den här workspace mappningen kan också innehålla en file_path mappning för att ange en icke-standardfilsökväg som ska användas på arbetsytan för både distributioner och arbetsflödeskörningar, till exempel:

workspace:
  file_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}/files

Som standard file_path använder Databricks CLI standardsökvägen ${workspace.root}/filesför , som använder substitutioner.

state_path

Mappningen state_path är standardsökvägen ${workspace.root}/state för och representerar sökvägen i din arbetsyta för att lagra Terraform-tillståndsinformation om distributioner.

Andra mappningar för arbetsytor

Mappningen workspace kan också innehålla följande valfria mappningar för att ange den Azure Databricks-autentiseringsmekanism som ska användas. Om de inte anges i den här workspace mappningen måste de anges i en workspace mappning som underordnad ett eller flera av målen i den översta målmappningen .

• Mappningen profile (eller --profile alternativen -p när du kör paketet verifierar, distribuerar, kör och förstör kommandon med Databricks CLI) anger namnet på en konfigurationsprofil som ska användas med den här arbetsytan för Azure Databricks-autentisering. Den här konfigurationsprofilen mappar till den som du skapade när du konfigurerade Databricks CLI.

  Kommentar

  Databricks rekommenderar att du använder mappningen host (eller alternativen eller --profile -p när du kör paketet validerar, distribuerar, kör och förstör kommandon med Databricks CLI) i stället för mappningen profile , eftersom det gör paketkonfigurationsfilerna mer portabla. Om du anger mappningen host instrueras Databricks CLI att hitta en matchande profil i .databrickscfg filen och sedan använda profilens fält för att avgöra vilken Databricks-autentiseringstyp som ska användas. Om det finns flera profiler med ett matchande host fält i .databrickscfg filen måste du använda mappningen profile (eller kommandoradsalternativen --profile -p ) för att instruera Databricks CLI om vilken profil som ska användas. Ett exempel finns i måldeklarationen prod i exemplen.

• Mappningen host anger URL:en för din Azure Databricks-arbetsyta. Se URL per arbetsyta.

• För OAuth-autentisering från dator till dator (M2M) används mappningen client_id . Du kan också ange det här värdet i den lokala miljövariabeln DATABRICKS_CLIENT_ID. Eller så kan du skapa en konfigurationsprofil med client_id värdet och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI). Se Autentisera åtkomst till Azure Databricks med ett huvudnamn för tjänsten med OAuth (OAuth M2M).

  Kommentar

  Du kan inte ange ett hemligt Azure Databricks OAuth-värde i paketkonfigurationsfilen. Ange i stället den lokala miljövariabeln DATABRICKS_CLIENT_SECRET. Eller så kan du lägga till värdet i client_secret en konfigurationsprofil och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI).

• För Azure CLI-autentisering används mappningen azure_workspace_resource_id . Du kan också ange det här värdet i den lokala miljövariabeln DATABRICKS_AZURE_RESOURCE_ID. Eller så kan du skapa en konfigurationsprofil med azure_workspace_resource_id värdet och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI). Se Azure CLI-autentisering.

• För Azure-klienthemlig autentisering med tjänstens huvudnamn används mappningarna azure_workspace_resource_id, azure_tenant_idoch azure_client_id . Du kan också ange dessa värden i de lokala miljövariablerna DATABRICKS_AZURE_RESOURCE_ID, ARM_TENANT_IDrespektive , och ARM_CLIENT_ID. Eller så kan du skapa en konfigurationsprofil med azure_workspace_resource_idvärdena , azure_tenant_idoch azure_client_id och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI). Se MS Entra-tjänstens huvudnamnsautentisering.

  Kommentar

  Du kan inte ange ett Azure-klienthemlighetsvärde i paketkonfigurationsfilen. Ange i stället den lokala miljövariabeln ARM_CLIENT_SECRET. Eller så kan du lägga till värdet i azure_client_secret en konfigurationsprofil och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI).

• För Azure-autentisering av hanterade identiteter används mappningarna azure_use_msi, azure_client_idoch azure_workspace_resource_id . Du kan också ange dessa värden i de lokala miljövariablerna ARM_USE_MSI, ARM_CLIENT_IDrespektive , och DATABRICKS_AZURE_RESOURCE_ID. Eller så kan du skapa en konfigurationsprofil med azure_use_msivärdena , azure_client_idoch azure_workspace_resource_id och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI). Se autentisering av hanterade Azure-identiteter.

• Mappningen azure_environment anger Azure-miljötypen (till exempel Public, UsGov, Kina och Tyskland) för en specifik uppsättning API-slutpunkter. Standardvärdet är PUBLIC. Du kan också ange det här värdet i den lokala miljövariabeln ARM_ENVIRONMENT. Eller så kan du lägga till värdet i azure_environment en konfigurationsprofil och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI).

• Mappningen azure_login_app_id är inte i drift och är reserverad för intern användning.

• Mappningen auth_type anger vilken Azure Databricks-autentiseringstyp som ska användas, särskilt i fall där Databricks CLI härleder en oväntad autentiseringstyp. Se Autentisera åtkomst till Azure Databricks-resurser.

Behörigheter

Mappningen på den översta nivån permissions anger en eller flera behörighetsnivåer som ska tillämpas på alla resurser som definierats i paketet. Om du vill använda behörigheter för en specifik resurs kan du läsa Definiera behörigheter för en specifik resurs.

Tillåtna behörighetsnivåer på den översta nivån är CAN_VIEW, CAN_MANAGEoch CAN_RUN.

I följande exempel i en paketkonfigurationsfil definieras behörighetsnivåer för en användare, grupp och tjänstens huvudnamn, som tillämpas på alla jobb, pipelines, experiment och modeller som definierats i resources paketet:

permissions:
  - level: CAN_VIEW
    group_name: test-group
  - level: CAN_MANAGE
    user_name: someone@example.com
  - level: CAN_RUN
    service_principal_name: 123456-abcdef

Artefakter

Mappningen på den översta nivån artifacts anger en eller flera artefakter som skapas automatiskt under paketdistributioner och kan användas senare i paketkörningar. Varje underordnad artefakt stöder följande mappningar:

• type måste anges. Om du vill skapa en Python-hjulfil innan du distribuerar måste den här mappningen vara inställd på whl.
• path är en valfri relativ sökväg från platsen för paketkonfigurationsfilen till platsen för Python-hjulfilens setup.py fil. Om path det inte ingår försöker Databricks CLI hitta Python-hjulfilens setup.py fil i paketets rot.
• files är en valfri mappning som innehåller en underordnad source mappning, som du kan använda för att ange icke-standardplatser som ska inkluderas för komplexa bygginstruktioner. Platser anges som relativa sökvägar från platsen för paketkonfigurationsfilen.
• build är en valfri uppsättning icke-standardversionskommandon som du vill köra lokalt före distributionen. För Python-hjulversioner förutsätter Databricks CLI att det kan hitta en lokal installation av Python-paketet wheel för att köra versioner och kör kommandot python setup.py bdist_wheel som standard under varje paketdistribution. Om du vill ange flera kompileringskommandon separerar du varje kommando med tecken med dubbel-ampersand (&&).

Mer information, inklusive ett exempelpaket som använder artifacts, finns i Utveckla en Python-hjulfil med databricks-tillgångspaket.

inbegripa

Matrisen include anger en lista över sökvägsglober som innehåller konfigurationsfiler som ska ingå i paketet. Dessa sökvägsglober är relativa till platsen för paketkonfigurationsfilen där sökvägens globs anges.

Databricks CLI inkluderar inte några konfigurationsfiler som standard i paketet. Du måste använda matrisen include för att ange alla konfigurationsfiler som ska ingå i paketet, förutom databricks.yml själva filen.

Den här include matrisen kan bara visas som en mappning på den översta nivån.

Följande exempelkonfiguration innehåller tre konfigurationsfiler. Dessa filer finns i samma mapp som paketkonfigurationsfilen:

include:
  - "bundle.artifacts.yml"
  - "bundle.resources.yml"
  - "bundle.targets.yml"

Följande exempelkonfiguration innehåller alla filer med filnamn som börjar med bundle och slutar med .yml. Dessa filer finns i samma mapp som paketkonfigurationsfilen:

include:
  - "bundle*.yml"

Resurser

Mappningen resources anger information om de Azure Databricks-resurser som används av paketet.

Den här resources mappningen kan visas som en mappning på den översta nivån, eller så kan den vara underordnad ett eller flera av målen i den översta målmappningen och innehåller noll eller en av de resurstyper som stöds. Varje resurstypmappning innehåller en eller flera enskilda resursdeklarationer, som var och en måste ha ett unikt namn. Dessa enskilda resursdeklarationer använder motsvarande objekts create-åtgärds nyttolast för begäran, uttryckt i YAML, för att definiera resursen. Egenskaper som stöds för en resurs är motsvarande objekts fält som stöds.

Nyttolaster för att skapa åtgärdsbegäran dokumenteras i referensen databricks bundle schema för Databricks REST API och kommandot matar ut alla objektscheman som stöds. Dessutom databricks bundle validate returnerar kommandot varningar om okända resursegenskaper finns i paketkonfigurationsfiler.

I följande tabell visas resurstyper som stöds för paket och länkar till dokumentation om motsvarande nyttolaster.

Resurstyp	Resursmappningar
kluster	Klustermappningar: POST /api/2.1/clusters/create
instrumentbräda	Instrumentpanelsmappningar: POST /api/2.0/preview/sql/dashboards
experiment	Experimentmappningar: POST /api/2.0/mlflow/experiments/create
jobb	Jobbmappningar: POST /api/2.1/jobs/create Mer information finns i jobbaktivitetstyper och åsidosätt nya jobbklusterinställningar.
rörledning	Pipelinemappningar: POST /api/2.0/pipelines
modell	Modellmappningar: POST /api/2.0/mlflow/registered-models/create
model_serving_endpoint	Modell som betjänar slutpunktsmappningar: POST /api/2.0/serving-endpoints
registered_model (Unity Catalog)	Enhetskatalogmodellmappningar: POST /api/2.1/unity-catalog/models
schema (Unity Catalog)	Schemamappningar för Unity-katalog: POST /api/2.1/unity-catalog/schemas

Alla sökvägar till mappar och filer som refereras till av resursdeklarationer är relativa till platsen för paketkonfigurationsfilen där dessa sökvägar anges.

cluster

Med klusterresursen kan du skapa kluster för alla syften. I följande exempel skapas ett kluster med namnet my_cluster och anger det som det kluster som ska användas för att köra notebook-filen i my_job:

bundle:
  name: clusters

resources:
  clusters:
    my_cluster:
      num_workers: 2
      node_type_id: "i3.xlarge"
      autoscale:
        min_workers: 2
        max_workers: 7
      spark_version: "13.3.x-scala2.12"
      spark_conf:
        "spark.executor.memory": "2g"

  jobs:
    my_job:
      tasks:
        - task_key: test_task
          existing_cluster_id: ${resources.clusters.my_cluster.id}
          notebook_task:
            notebook_path: "./src/my_notebook.py"

instrumentpanel

Med instrumentpanelsresursen kan du hantera AI/BI-instrumentpaneler i ett paket. Information om AI/BI-instrumentpaneler finns i Instrumentpaneler.

I följande exempel ingår och distribueras exempelinstrumentpanelen NYC Taxi Trip Analysis till Databricks-arbetsytan.

resources:
  dashboards:
    nyc_taxi_trip_analysis:
      display_name: "NYC Taxi Trip Analysis"
      file_path: ../src/nyc_taxi_trip_analysis.lvdash.json
      warehouse_id: ${var.warehouse_id}

Om du använder användargränssnittet för att ändra instrumentpanelen tillämpas inte ändringar som görs via användargränssnittet på instrumentpanelens JSON-fil i det lokala paketet om du inte uttryckligen uppdaterar den med hjälp av bundle generate. Du kan använda alternativet --watch för att kontinuerligt avsöka och hämta ändringar på instrumentpanelen. Se Skapa en paketkonfigurationsfil.

Om du försöker distribuera ett paket som innehåller en JSON-instrumentpanelsfil som skiljer sig från den på fjärrarbetsytan uppstår dessutom ett fel. Använd alternativet för att tvinga distributionen och skriva över instrumentpanelen på den fjärranslutna arbetsytan med den lokala --force . Se Distribuera ett paket.

jobb

I följande exempel deklareras ett jobb med resursnyckeln hello-job:

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

rörledning

I följande exempel deklareras en pipeline med resursnyckeln hello-pipeline:

resources:
  pipelines:
    hello-pipeline:
      name: hello-pipeline
      clusters:
        - label: default
          num_workers: 1
      development: true
      continuous: false
      channel: CURRENT
      edition: CORE
      photon: false
      libraries:
        - notebook:
            path: ./pipeline.py

schema

Med schemaresurstypen kan du definiera Unity Catalog-scheman för tabeller och andra tillgångar i dina arbetsflöden och pipelines som skapats som en del av ett paket. Ett schema, som skiljer sig från andra resurstyper, har följande begränsningar:

• Ägaren till en schemaresurs är alltid distributionsanvändaren och kan inte ändras. Om run_as anges i paketet ignoreras det av åtgärder i schemat.
• Endast fält som stöds av motsvarande API för att skapa schemaobjekt är tillgängliga för resursen schema . Till exempel enable_predictive_optimization stöds inte eftersom det bara är tillgängligt i uppdaterings-API:et.

I följande exempel deklareras en pipeline med resursnyckeln my_pipeline som skapar ett Unity Catalog-schema med nyckeln my_schema som mål:

resources:
  pipelines:
    my_pipeline:
      name: test-pipeline-{{.unique_id}}
      libraries:
        - notebook:
            path: ./nb.sql
      development: true
      catalog: main
      target: ${resources.schemas.my_schema.id}

  schemas:
    my_schema:
      name: test-schema-{{.unique_id}}
      catalog_name: main
      comment: This schema was created by DABs.

Mappning av bidrag på den översta nivån stöds inte av Databricks-tillgångspaket, så om du vill ange bidrag för ett schema definierar du bidragen för schemat i mappningen schemas :

schemas:
    my_schema:
      name: test-schema
      grants:
        - principal: users
          privileges:
            - CAN_MANAGE
        - principal: my_team
          privileges:
            - CAN_READ
      catalog_name: main
      comment: "my schema with grants"

synkronisering

Med sync mappningen kan du konfigurera vilka filer som ingår i dina paketdistributioner.

inkludera och exkludera

Mappningarna include och exclude i mappningen sync anger en lista över filer eller mappar som ska inkluderas i eller undantas från paketdistributioner, beroende på följande regler:

• Baserat på en lista över fil- och sökvägsglober i en .gitignore fil i paketets rot kan mappningen include innehålla en lista över filglober, sökvägsglober eller båda, i förhållande till paketets rot, som uttryckligen ska inkluderas.
• Baserat på en lista över fil- och sökvägsglober i en .gitignore fil i paketets rot, plus listan över fil- och sökvägsglober i mappningen include , exclude kan mappningen innehålla en lista över filglober, sökvägsglober eller båda, i förhållande till paketets rot, som uttryckligen ska undantas.

Alla sökvägar till angivna filer och mappar är relativa till platsen för paketkonfigurationsfilen där de anges.

Syntaxen för include och exclude fil- och sökvägsmönster följer standardmönstersyntaxen .gitignore . Se gitignore-mönsterformat.

Om till exempel följande .gitignore fil innehåller följande poster:

.databricks
my_package/dist

Och paketkonfigurationsfilen innehåller följande include mappning:

sync:
  include:
    - my_package/dist/*.whl

Sedan ingår alla filer i my_package/dist mappen med filnamnstillägget *.whl . Andra filer i my_package/dist mappen ingår inte.

Men om paketkonfigurationsfilen också innehåller följande exclude mappning:

sync:
  include:
    - my_package/dist/*.whl
  exclude:
    - my_package/dist/delete-me.whl

Sedan ingår alla filer i my_package/dist mappen med filnamnstillägget *.whl, förutom filen med namnet delete-me.whl. Andra filer i my_package/dist mappen ingår inte heller.

Mappningen sync kan också deklareras i mappningen targets för ett specifikt mål. Alla sync mappningar som deklareras i ett mål sammanfogas med eventuella mappningsdeklarationer på den översta nivån sync . Om du till exempel fortsätter med föregående exempel sammanfogas följande include mappning på targets nivån med mappningen include i mappningen på den översta nivån sync :

targets:
  dev:
    sync:
      include:
        - my_package/dist/delete-me.whl

Sökvägar

Mappningen sync kan innehålla en paths mappning som anger lokala sökvägar som ska synkroniseras till arbetsytan. Med paths mappningen kan du dela vanliga filer mellan paket och kan användas för att synkronisera filer som finns utanför paketroten. (Paketroten är platsen för filen databricks.yml.) Detta är särskilt användbart när du har en enda lagringsplats som är värd för flera paket och vill dela bibliotek, kodfiler eller konfiguration.

Angivna sökvägar måste vara relativa till filer och kataloger som är förankrade i mappen där mappningen paths anges. Om en eller flera sökvägsvärden passerar upp i katalogen till en överordnad till paketroten bestäms rotsökvägen dynamiskt för att säkerställa att mappstrukturen förblir intakt. Om paketrotmappen till exempel heter my_bundle synkroniserar den här konfigurationen databricks.yml common mappen som finns en nivå ovanför paketroten och själva paketroten:

sync:
  paths:
    - ../common
    - .

En distribution av det här paketet resulterar i följande mappstruktur på arbetsytan:

common/
  common_file.txt
my_bundle/
  databricks.yml
  src/
    ...

Mål

Mappningen targets anger en eller flera kontexter där Azure Databricks-arbetsflöden ska köras. Varje mål är en unik samling artefakter, Azure Databricks-arbetsyteinställningar och Azure Databricks-jobb- eller pipelineinformation.

Mappningen targets består av en eller flera målmappningar, som var och en måste ha ett unikt programmatiskt (eller logiskt) namn.

Den här targets mappningen är valfri men rekommenderas starkt. Om den anges kan den bara visas som en mappning på den översta nivån.

Inställningarna på den översta arbetsytan, artefakter och resursmappningar används om de inte anges i en targets mappning, men eventuella motstridiga inställningar åsidosättas av inställningarna i ett mål.

Ett mål kan också åsidosätta värdena för alla variabler på den översta nivån.

standard

Om du vill ange ett standardmål för paketkommandon anger du mappningen default till true. Det här målet med namnet dev är till exempel standardmålet:

targets:
  dev:
    default: true

Om ett standardmål inte har konfigurerats, eller om du vill verifiera, distribuera och köra jobb eller pipelines inom ett specifikt mål, använder -t du alternativet för paketkommandona.

Följande kommandon validerar, distribuerar och kör my_job inom dev målen och prod :

databricks bundle validate
databricks bundle deploy -t dev
databricks bundle run -t dev my_job

databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod my_job

I följande exempel deklareras två mål. Det första målet har namnet dev och är standardmålet som används när inget mål har angetts för paketkommandon. Det andra målet har namnet prod och används endast när det här målet anges för paketkommandon.

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>

läge och förinställningar

För att underlätta enkel utveckling och metodtips för CI/CD tillhandahåller Databricks Asset Bundles distributionslägen för mål som anger standardbeteenden för arbetsflöden för förproduktion och produktion. Vissa beteenden kan också konfigureras. Mer information finns i Distributionslägen för Databricks Asset Bundle.

Om du vill ange att ett mål ska behandlas som ett utvecklingsmål lägger du till mappningsuppsättningen mode i development. Om du vill ange att ett mål ska behandlas som ett produktionsmål lägger du till mappningsuppsättningen mode i production. Det här målet med namnet prod behandlas till exempel som ett produktionsmål:

targets:
  prod:
    mode: production

Du kan anpassa några av beteendena med hjälp av mappningen presets . En lista över tillgängliga förinställningar finns i Anpassade förinställningar. I följande exempel visas ett anpassat produktionsmål som prefix och taggar alla produktionsresurser:

targets:
  prod:
    mode: production
    presets:
      name_prefix: "production_"  # prefix all resource names with production_
      tags:
        prod: true

Om både mode och presets anges åsidosätter förinställningar standardlägets beteende. Inställningar för enskilda resurser åsidosätter förinställningarna. Om ett schema till exempel är inställt på UNPAUSED, men förinställningen trigger_pause_status är inställd på PAUSED, kommer schemat att pausas.