Konfiguracje pakietu zasobów usługi Databricks

Artykuł
06/27/2024

W tym artykule opisano składnię plików konfiguracji pakietu zasobów usługi Databricks, które definiują pakiety zasobów usługi Databricks. Zobacz Co to są pakiety zasobów usługi Databricks?

Plik konfiguracji pakietu musi być wyrażony w formacie YAML i musi zawierać co najmniej mapowanie pakietów najwyższego poziomu. Każdy pakiet musi zawierać co najmniej jeden (i tylko jeden) plik konfiguracji pakietu o nazwie databricks.yml. Jeśli istnieje wiele plików konfiguracji pakietu, muszą być przywołyne przez databricks.yml plik.

Aby uzyskać więcej informacji na temat języka YAML, zobacz oficjalną specyfikację YAML i samouczek.

Aby utworzyć pliki konfiguracji pakietu i pracować z plikami konfiguracji, zobacz Programowanie pakietów zasobów usługi Databricks.

Omówienie
Przykłady
Mapowania
Zmienne niestandardowe
Zastąpienia

Omówienie

Ta sekcja zawiera wizualną reprezentację schematu pliku konfiguracji pakietu. Aby uzyskać szczegółowe informacje, zobacz Mapowania.

# These is the default bundle configuration if not otherwise overridden in
# the "targets" top-level mapping.
bundle: # Required.
  name: string # Required.
  databricks_cli_version: string
  compute_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:
  experiments:
    <some-unique-programmatic-identifier-for-this-experiment>:
      # See the Experiments API's create experiment request payload reference.
  jobs:
    <some-unique-programmatic-identifier-for-this-job>:
      # See the Jobs API's create job request payload reference.
  models:
    <some-unique-programmatic-identifier-for-this-model>:
      # See the Models API's create model request payload reference.
  pipelines:
    <some-unique-programmatic-identifier-for-this-pipeline>:
      # See the Delta Live Tables API's create pipeline 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>"

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

Przykłady

Poniżej znajduje się przykładowy plik konfiguracji pakietu. Ten pakiet określa zdalne wdrożenie pliku lokalnego o nazwie hello.py , który znajduje się w tym samym katalogu co ten lokalny plik konfiguracji pakietu o nazwie databricks.yml. Ten notes jest uruchamiany jako zadanie przy użyciu klastra zdalnego z określonym identyfikatorem klastra. Poświadczenia uwierzytelniania zdalnego obszaru roboczego i adresu URL obszaru roboczego są odczytywane z lokalnego profilu konfiguracji obiektu wywołującego o nazwie DEFAULT.

Uwaga

Usługa Databricks zaleca użycie host mapowania zamiast default mapowania wszędzie tam, gdzie jest to możliwe, ponieważ sprawia to, że pliki konfiguracji pakietu są bardziej przenośne. host Ustawienie mapowania powoduje, że interfejs wiersza polecenia usługi Databricks znajdzie pasujący profil w .databrickscfg pliku, a następnie użyj pól tego profilu, aby określić typ uwierzytelniania usługi Databricks do użycia. Jeśli w pliku istnieje .databrickscfg wiele profilów z pasującym host polem, musisz użyć profile polecenia , aby poinstruować interfejs wiersza polecenia usługi Databricks o określonym profilu do użycia. Aby zapoznać się z przykładem, zobacz deklarację docelową prod w dalszej części tej sekcji.

Ta technika umożliwia ponowne użycie oraz zastąpienie definicji i ustawień zadania w resources bloku:

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

Chociaż następujący plik konfiguracji pakietu jest funkcjonalnie równoważny, nie jest modularyzowany, co nie umożliwia dobrego ponownego użycia. Ponadto ta deklaracja dołącza zadanie do zadania, a nie zastępuje istniejącego zadania:

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

Poniżej przedstawiono poprzedni przykład modułowy, ale z dodatkiem elementu docelowego z nazwą prod programową (lub logiczną), która używa innego adresu URL zdalnego obszaru roboczego i poświadczeń uwierzytelniania obszaru roboczego, które są odczytywane z pasującego host wpisu pliku obiektu .databrickscfg wywołującego z określonym adresem URL obszaru roboczego. To zadanie uruchamia ten sam notes, ale używa innego klastra zdalnego z określonym identyfikatorem klastra. Zwróć uwagę, że nie trzeba deklarować notebook_task mapowania w ramach prod mapowania, ponieważ wraca do używania notebook_task mapowania w ramach mapowania najwyższego poziomu resources , jeśli notebook_task mapowanie nie jest jawnie zastępowane w ramach prod mapowania.

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

Aby zweryfikować, wdrożyć i uruchomić to zadanie w ramach dev obiektu docelowego, uruchom następujące polecenia:

# 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

Aby zamiast tego zweryfikować, wdrożyć i uruchomić to zadanie w obiekcie prod docelowym, uruchom następujące polecenia:

# 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

Poniżej przedstawiono poprzedni przykład, ale podzielony na pliki składników w celu jeszcze większej modularyzacji i lepszego ponownego użycia w wielu plikach konfiguracji pakietu. Ta technika umożliwia nie tylko ponowne używanie różnych definicji i ustawień, ale także zamianę dowolnego z tych plików z innymi plikami, które zapewniają zupełnie inne deklaracje:

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

Aby uzyskać więcej przykładów, zobacz repozytorium przykładów pakietów w usłudze GitHub.

Mapowania

W poniższych sekcjach opisano składnię pliku konfiguracji pakietu według mapowania najwyższego poziomu.

pakiet
Zmiennych
obszar roboczy
permissions
Artefakty
include
zasoby
synchronizować
Cele

pakiet

Plik konfiguracji pakietu musi zawierać tylko jedno mapowanie najwyższego poziomu bundle , które kojarzy zawartość pakietu i ustawienia obszaru roboczego usługi Azure Databricks.

To bundle mapowanie musi zawierać name mapowanie określające nazwę programową (lub logiczną) pakietu. Poniższy przykład deklaruje pakiet z nazwą hello-bundleprogramową (lub logiczną).

bundle:
  name: hello-bundle

bundle Mapowanie może być również elementem podrzędnym jednego lub większej liczby obiektów docelowych w mapowaniu obiektów docelowych najwyższego poziomu. Każde z tych mapowań podrzędnych bundle określa wszelkie przesłonięcia inne niż domyślne na poziomie docelowym. Jednak wartości mapowania name najwyższego poziomu bundle nie można zastąpić na poziomie docelowym.

compute_id

Mapowanie bundle może mieć mapowanie podrzędne compute_id . To mapowanie umożliwia określenie identyfikatora klastra do użycia jako przesłonięcia dla wszystkich klastrów zdefiniowanych gdzie indziej w pliku konfiguracji pakietu. To zastąpienie jest przeznaczone dla scenariuszy przeznaczonych tylko do programowania przed produkcją. Mapowanie compute_id działa tylko dla obiektu docelowego, który ma jego mode mapowanie ustawione na developmentwartość . Aby uzyskać więcej informacji na temat compute_id mapowania, zobacz mapowanie obiektów docelowych .

Git

Możesz pobrać i zastąpić szczegóły kontroli wersji usługi Git skojarzone z pakietem. Jest to przydatne w przypadku dodawania adnotacji do wdrożonych zasobów. Możesz na przykład uwzględnić adres URL pochodzenia repozytorium w opisie wdrażanego modelu uczenia maszynowego.

Za każdym razem, gdy uruchamiasz bundle polecenie, takie jak validate, deploy lub run, bundle polecenie wypełnia drzewo konfiguracji polecenia następującymi ustawieniami domyślnymi:

bundle.git.origin_url, który reprezentuje adres URL pochodzenia repozytorium. Jest to ta sama wartość, którą można uzyskać po uruchomieniu polecenia git config --get remote.origin.url z sklonowanego repozytorium. Za pomocą podstawiania można odwoływać się do tej wartości z plikami konfiguracji pakietu jako ${bundle.git.origin_url}.
bundle.git.branch, który reprezentuje bieżącą gałąź w repozytorium. Jest to ta sama wartość, którą można uzyskać po uruchomieniu polecenia git branch --show-current z sklonowanego repozytorium. Za pomocą podstawiania można odwoływać się do tej wartości z plikami konfiguracji pakietu jako ${bundle.git.branch}.
bundle.git.commit, który reprezentuje HEAD zatwierdzenie w repozytorium. Jest to ta sama wartość, którą można uzyskać po uruchomieniu polecenia git rev-parse HEAD z sklonowanego repozytorium. Za pomocą podstawiania można odwoływać się do tej wartości z plikami konfiguracji pakietu jako ${bundle.git.commit}.

Aby pobrać lub zastąpić ustawienia usługi Git, pakiet musi znajdować się w katalogu skojarzonym z repozytorium Git, na przykład katalogiem lokalnym zainicjowanym przez uruchomienie git clone polecenia . Jeśli katalog nie jest skojarzony z repozytorium Git, te ustawienia usługi Git są puste.

W razie potrzeby można zastąpić origin_url ustawienia i branch w git mapowaniu mapowania najwyższego poziomu bundle w następujący sposób:

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

databricks_cli_version

Mapowanie bundle może zawierać databricks_cli_version mapowanie, które ogranicza wersję interfejsu wiersza polecenia usługi Databricks wymaganą przez pakiet. Może to zapobiec problemom spowodowanym użyciem mapowań, które nie są obsługiwane w określonej wersji interfejsu wiersza polecenia usługi Databricks.

Wersja interfejsu wiersza polecenia usługi Databricks jest zgodna z semantyczną wersją , a databricks_cli_version mapowanie obsługuje określanie ograniczeń wersji. Jeśli bieżąca databricks --version wartość nie znajduje się w granicach określonych w mapowaniu pakietu databricks_cli_version , wystąpi błąd podczas databricks bundle validate wykonywania w pakiecie. W poniższych przykładach pokazano niektóre typowe składnie ograniczeń wersji:

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

Zmiennych

Plik ustawień pakietów może zawierać jedno mapowanie najwyższego poziomu variables w celu określenia ustawień zmiennych do użycia. Zobacz Zmienne niestandardowe.

obszar roboczy

Plik konfiguracji pakietu może zawierać tylko jedno mapowanie najwyższego poziomu workspace , aby określić domyślne ustawienia obszaru roboczego usługi Azure Databricks do użycia.

To workspace mapowanie może zawierać mapowanie, root_path aby określić inną niż domyślną ścieżkę główną do użycia w obszarze roboczym dla wdrożeń i przebiegów przepływu pracy, na przykład:

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

Domyślnie w interfejsie root_path wiersza polecenia usługi Databricks jest używana domyślna ścieżka /Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}, która używa podstawień.

To workspace mapowanie może również zawierać mapowanie, aby określić inną niż domyślną artifact_path ścieżkę artefaktu do użycia w obszarze roboczym dla wdrożeń i przebiegów przepływu pracy, na przykład:

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

Domyślnie w interfejsie artifact_path wiersza polecenia usługi Databricks jest używana domyślna ścieżka ${workspace.root}/artifacts, która używa podstawień.

.. uwaga:: Mapowanie artifact_path nie obsługuje ścieżek systemu plików usługi Databricks (DBFS).

To workspace mapowanie może również zawierać mapowanie, aby określić inną niż domyślną file_path ścieżkę pliku do użycia w obszarze roboczym dla wdrożeń i przebiegów przepływu pracy, na przykład:

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

Domyślnie w interfejsie file_path wiersza polecenia usługi Databricks jest używana domyślna ścieżka ${workspace.root}/files, która używa podstawień.

Mapowanie state_path jest domyślnie ustawione na domyślną ścieżkę ${workspace.root}/state i reprezentuje ścieżkę w obszarze roboczym, aby przechowywać informacje o stanie programu Terraform dotyczące wdrożeń.

Mapowanie workspace może również zawierać następujące opcjonalne mapowania, aby określić mechanizm uwierzytelniania usługi Azure Databricks do użycia. Jeśli nie są one określone w tym workspace mapowaniu, muszą być określone w workspace mapowaniu jako element podrzędny co najmniej jednego miejsca docelowego w mapowaniu obiektów docelowych najwyższego poziomu.

Ważne

Musisz trwale kodować wartości dla następujących workspace mapowań uwierzytelniania usługi Azure Databricks. Na przykład nie można określić zmiennych niestandardowych dla wartości tych mapowań przy użyciu ${var.*} składni.

Mapowanie profile (lub opcje lub --profile -p podczas uruchamiania pakietu walidować, wdrażać, uruchamiać i niszczyć polecenia za pomocą interfejsu wiersza polecenia usługi Databricks) określa nazwę profilu konfiguracji do użycia z tym obszarem roboczym na potrzeby uwierzytelniania usługi Azure Databricks. Ten profil konfiguracji jest mapowy na ten, który został utworzony podczas konfigurowania interfejsu wiersza polecenia usługi Databricks.

Uwaga

Usługa Databricks zaleca użycie host mapowania (lub --profile -p opcji podczas uruchamiania pakietu walidowania, wdrażania, uruchamiania i niszczenia poleceń za pomocą interfejsu wiersza polecenia usługi Databricks) zamiast profile mapowania, ponieważ sprawia to, że pliki konfiguracji pakietu są bardziej przenośne. host Ustawienie mapowania powoduje, że interfejs wiersza polecenia usługi Databricks znajdzie pasujący profil w .databrickscfg pliku, a następnie użyj pól tego profilu, aby określić typ uwierzytelniania usługi Databricks do użycia. Jeśli w pliku istnieje .databrickscfg wiele profilów z pasującym host polem, musisz użyć profile mapowania (lub --profile -p opcji wiersza polecenia), aby poinstruować interfejs wiersza polecenia usługi Databricks o tym, którego profilu użyć. Przykład można znaleźć w prod deklaracji docelowej w przykładach.
Mapowanie host określa adres URL obszaru roboczego usługi Azure Databricks. Zobacz Adres URL obszaru roboczego.
W przypadku uwierzytelniania maszyny-maszyny (M2M) protokołu OAuth jest używane mapowanie client_id . Alternatywnie można ustawić tę wartość w lokalnej zmiennej środowiskowej DATABRICKS_CLIENT_ID. Możesz też utworzyć profil konfiguracji z client_id wartością, a następnie określić nazwę profilu z profile mapowaniem (lub za pomocą opcji lub -p podczas uruchamiania pakietu weryfikujące, wdrażać, uruchamiać i niszczyć polecenia za pomocą --profile interfejsu wiersza polecenia usługi Databricks). Zobacz Używanie jednostki usługi do uwierzytelniania w usłudze Azure Databricks.

Uwaga

Nie można określić wartości wpisu tajnego OAuth usługi Azure Databricks w pliku konfiguracji pakietu. Zamiast tego ustaw lokalną zmienną środowiskową DATABRICKS_CLIENT_SECRET. Możesz też dodać client_secret wartość do profilu konfiguracji, a następnie określić nazwę profilu z profile mapowaniem (lub za pomocą opcji lub -p podczas uruchamiania pakietu weryfikowania, wdrażania, uruchamiania i niszczenia poleceń za pomocą --profile interfejsu wiersza polecenia usługi Databricks).
W przypadku uwierzytelniania interfejsu wiersza polecenia platformy Azure jest używane mapowanie azure_workspace_resource_id . Alternatywnie można ustawić tę wartość w lokalnej zmiennej środowiskowej DATABRICKS_AZURE_RESOURCE_ID. Możesz też utworzyć profil konfiguracji z azure_workspace_resource_id wartością, a następnie określić nazwę profilu z profile mapowaniem (lub za pomocą opcji lub -p podczas uruchamiania pakietu weryfikujące, wdrażać, uruchamiać i niszczyć polecenia za pomocą --profile interfejsu wiersza polecenia usługi Databricks). Zobacz Uwierzytelnianie interfejsu wiersza polecenia platformy Azure.
W przypadku uwierzytelniania wpisów tajnych klienta platformy Azure z jednostkami usługi są używane mapowania azure_workspace_resource_id, azure_tenant_idi azure_client_id . Alternatywnie można ustawić te wartości w lokalnych zmiennych DATABRICKS_AZURE_RESOURCE_IDśrodowiskowych , ARM_TENANT_IDi ARM_CLIENT_ID, odpowiednio. Możesz też utworzyć profil konfiguracji z wartościami azure_workspace_resource_id, azure_tenant_idi , a azure_client_id następnie określić nazwę profilu za profile pomocą mapowania (lub za pomocą opcji lub -p podczas uruchamiania pakietu weryfikujące, wdrażać, uruchamiać i niszczyć polecenia za pomocą --profile interfejsu wiersza polecenia usługi Databricks). Zobacz Uwierzytelnianie jednostki usługi Microsoft Entra ID.

Uwaga

Nie można określić wartości wpisu tajnego klienta platformy Azure w pliku konfiguracji pakietu. Zamiast tego ustaw lokalną zmienną środowiskową ARM_CLIENT_SECRET. Możesz też dodać azure_client_secret wartość do profilu konfiguracji, a następnie określić nazwę profilu z profile mapowaniem (lub za pomocą opcji lub -p podczas uruchamiania pakietu weryfikowania, wdrażania, uruchamiania i niszczenia poleceń za pomocą --profile interfejsu wiersza polecenia usługi Databricks).
W przypadku uwierzytelniania tożsamości zarządzanych platformy azure_use_msiAzure używane są mapowania , azure_client_idi azure_workspace_resource_id . Alternatywnie można ustawić te wartości w lokalnych zmiennych ARM_USE_MSIśrodowiskowych , ARM_CLIENT_IDi DATABRICKS_AZURE_RESOURCE_ID, odpowiednio. Możesz też utworzyć profil konfiguracji z wartościami azure_use_msi, azure_client_idi , a azure_workspace_resource_id następnie określić nazwę profilu za profile pomocą mapowania (lub za pomocą opcji lub -p podczas uruchamiania pakietu weryfikujące, wdrażać, uruchamiać i niszczyć polecenia za pomocą --profile interfejsu wiersza polecenia usługi Databricks). Zobacz Uwierzytelnianie tożsamości zarządzanych platformy Azure.
Mapowanie azure_environment określa typ środowiska platformy Azure (na przykład Publiczny, UsGov, Chiny i Niemcy) dla określonego zestawu punktów końcowych interfejsu API. Domyślna wartość to PUBLIC. Alternatywnie można ustawić tę wartość w lokalnej zmiennej środowiskowej ARM_ENVIRONMENT. Możesz też dodać azure_environment wartość do profilu konfiguracji, a następnie określić nazwę profilu z profile mapowaniem (lub za pomocą opcji lub -p podczas uruchamiania pakietu weryfikowania, wdrażania, uruchamiania i niszczenia poleceń za pomocą --profile interfejsu wiersza polecenia usługi Databricks).
Mapowanie azure_login_app_id nie działa i jest zarezerwowane do użytku wewnętrznego.
Mapowanie auth_type określa typ uwierzytelniania usługi Azure Databricks do użycia, zwłaszcza w przypadkach, gdy interfejs wiersza polecenia usługi Databricks wnioskowa nieoczekiwany typ uwierzytelniania. Zobacz pole Typ uwierzytelniania.

Uprawnienia

Mapowanie najwyższego poziomu permissions określa co najmniej jeden poziom uprawnień, który ma być stosowany do wszystkich zasobów zdefiniowanych w pakiecie. Jeśli chcesz zastosować uprawnienia do określonego zasobu, zobacz Definiowanie uprawnień dla określonego zasobu.

Dozwolone poziomy uprawnień najwyższego poziomu to CAN_VIEW, CAN_MANAGEi CAN_RUN.

Poniższy przykład w pliku konfiguracji pakietu definiuje poziomy uprawnień dla użytkownika, grupy i jednostki usługi, które są stosowane do wszystkich zadań, potoków, eksperymentów i modeli zdefiniowanych w resources pakiecie:

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

Artefakty

Mapowanie najwyższego poziomu artifacts określa co najmniej jeden artefakt, który jest automatycznie kompilowany podczas wdrożeń pakietu i może być używany w kolejnych uruchomieniach pakietu. Każdy artefakt podrzędny obsługuje następujące mapowania:

Ciąg type jest wymagany. Aby skompilować plik wheel języka Python przed wdrożeniem, to mapowanie musi być ustawione na whl.
path jest opcjonalną ścieżką względną z lokalizacji pliku konfiguracji pakietu do lokalizacji pliku wheel języka setup.py Python. Jeśli path nie zostanie uwzględniona, interfejs wiersza polecenia usługi Databricks podejmie próbę znalezienia pliku setup.py wheel języka Python w katalogu głównym pakietu.
files to opcjonalne mapowanie, które zawiera mapowanie podrzędne source , którego można użyć do określenia lokalizacji innych niż domyślne, które mają być uwzględniane w przypadku złożonych instrukcji kompilacji. Lokalizacje są określane jako ścieżki względne z lokalizacji pliku konfiguracji pakietu.
build jest opcjonalnym zestawem poleceń kompilacji innych niż domyślne, które mają być uruchamiane lokalnie przed wdrożeniem. W przypadku kompilacji wheel języka Python interfejs wiersza polecenia usługi Databricks zakłada, że może znaleźć lokalną instalację pakietu języka Python wheel do uruchamiania kompilacji i uruchamia python setup.py bdist_wheel polecenie domyślnie podczas każdego wdrożenia pakietu. Aby określić wiele poleceń kompilacji, należy oddzielić każde polecenie podwójnymi znakami i (&&).

Aby uzyskać więcej informacji, w tym przykładowy pakiet korzystający z artifactsprogramu , zobacz Develop a Python wheel file using Databricks Asset Bundles (Tworzenie pliku wheel języka Python przy użyciu pakietów zasobów usługi Databricks).

Napiwek

Ustawienia artefaktów w pakietach można definiować, łączyć i zastępować przy użyciu technik opisanych w artykule Definiowanie ustawień artefaktów dynamicznie w pakietach zasobów usługi Databricks.

zawierać

Tablica include określa listę ścieżek globs, które zawierają pliki konfiguracji do uwzględnienia w pakiecie. Te globy ścieżki są względem lokalizacji pliku konfiguracji pakietu, w którym określono globy ścieżki.

Interfejs wiersza polecenia usługi Databricks domyślnie nie zawiera żadnych plików konfiguracji w pakiecie. Należy użyć tablicy include , aby określić dowolne i wszystkie pliki konfiguracji do uwzględnienia w pakiecie, innym niż databricks.yml sam plik.

Ta include tablica może być wyświetlana tylko jako mapowanie najwyższego poziomu.

Poniższy przykład w pliku konfiguracji pakietu zawiera trzy określone pliki konfiguracji. Te pliki znajdują się w tym samym katalogu co plik konfiguracji pakietu:

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

Poniższy przykład w pliku konfiguracji pakietu zawiera wszystkie pliki z nazwami plików, które zaczynają się od i kończą się bundle .ymlna . Te pliki znajdują się w tym samym katalogu co plik konfiguracji pakietu:

include:
  - "bundle*.yml"

zasoby

Mapowanie resources określa informacje o zasobach usługi Azure Databricks używanych przez pakiet.

To resources mapowanie może być wyświetlane jako mapowanie najwyższego poziomu lub może być elementem podrzędnym jednego lub większej liczby obiektów docelowych w mapowaniu obiektów docelowych najwyższego poziomu i zawiera zero lub jeden z obsługiwanych typów zasobów. Każde mapowanie typu zasobu zawiera co najmniej jedną pojedynczą deklarację zasobów, która musi mieć unikatową nazwę. Te indywidualne deklaracje zasobów używają ładunku żądania operacji tworzenia odpowiadającego obiektu wyrażonego w yaML, aby zdefiniować zasób. Obsługiwane właściwości zasobu to obsługiwane pola odpowiedniego obiektu.

Ładunki żądań operacji tworzenia są udokumentowane w dokumentacji interfejsu API REST usługi Databricks, a databricks bundle schema polecenie zwraca wszystkie obsługiwane schematy obiektów. Ponadto polecenie zwraca ostrzeżenia, databricks bundle validate jeśli w plikach konfiguracji pakietu znajdują się nieznane właściwości zasobu.

W poniższej tabeli wymieniono obsługiwane typy zasobów dla pakietów i linki do dokumentacji dotyczącej odpowiednich ładunków.

Typ zasobu	Mapowania zasobów
`jobs`	Mapowania zadań: POST /api/2.1/jobs/create Aby uzyskać dodatkowe informacje, zobacz typy zadań zadań i zastąpić nowe ustawienia klastra zadań.
`pipelines`	Mapowania potoków: POST /api/2.0/pipelines
`experiments`	Mapowania eksperymentów: POST /api/2.0/mlflow/experiments/create
`models`	Mapowania modeli: POST /api/2.0/mlflow/registered-models/create
`model_serving_endpoints`	Mapowania punktów końcowych obsługujące model: POST /api/2.0/serving-endpoints
`registered_models` (Wykaz aparatu Unity)	Mapowania modeli wykazu aparatu Unity: POST /api/2.1/unity-catalog/models

Wszystkie ścieżki do folderów i plików, do których odwołują się deklaracje zasobów, są powiązane z lokalizacją pliku konfiguracji pakietu, w którym określono te ścieżki.

Poniższy przykład deklaruje zadanie z kluczem hello-job zasobu i potokiem z kluczem zasobu :hello-pipeline

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py
  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

synchronizować

Tablica sync określa listę globów plików lub ścieżek do uwzględnienia w ramach wdrożeń pakietów lub wykluczania z wdrożeń pakietów, w zależności od następujących reguł:

Na podstawie dowolnej listy plików i ścieżek globs w .gitignore pliku głównym pakietu include mapowanie może zawierać listę globów plików, globów ścieżek lub obu elementów w stosunku do katalogu głównego pakietu, aby jawnie dołączyć.
Na podstawie dowolnej listy plików i ścieżek globs w .gitignore pliku w katalogu głównym pakietu oraz listy globów plików i ścieżek w include mapowaniu exclude mapowanie mapowanie może zawierać listę globów plików, globów ścieżki lub obu elementów w stosunku do katalogu głównego pakietu, aby jawnie wykluczyć.

Wszystkie ścieżki do określonych folderów i plików są powiązane z lokalizacją pliku konfiguracji pakietu, w którym określono te ścieżki.

Składnia wzorców plików include i exclude ścieżek są zgodne ze standardową .gitignore składnią wzorca. Zobacz format wzorca gitignore.

Jeśli na przykład następujący .gitignore plik zawiera następujące wpisy:

.databricks
my_package/dist

Plik konfiguracji pakietu zawiera następujące include mapowanie:

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

Następnie uwzględniane są wszystkie pliki w my_package/dist folderze z rozszerzeniem *.whl pliku. Żadne inne pliki w folderze my_package/dist nie są uwzględniane.

Jeśli jednak plik konfiguracji pakietu zawiera również następujące exclude mapowanie:

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

Następnie wszystkie pliki w folderze my_package/dist z rozszerzeniem *.whlpliku , z wyjątkiem pliku o nazwie delete-me.whl, są uwzględniane. Wszystkie inne pliki w folderze my_package/dist również nie są uwzględniane.

Tablicę sync można również zadeklarować w targets mapowaniu dla określonego obiektu docelowego. Każda sync tablica zadeklarowana w obiekcie docelowym jest scalona z dowolnymi deklaracjami tablic najwyższego poziomu sync . Na przykład kontynuując poprzedni przykład, następujące include mapowanie na targets poziomie scala się z include mapowaniem w tablicy najwyższego poziomu sync :

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

Po uruchomieniu databricks bundle validate --output jsonpolecenia odpowiednia część wynikowego grafu jest następująca:

"sync": {
  "include": [
    "my_package/dist/*.whl",
    "my_package/dist/delete-me.whl"
  ],
  "exclude": [
    "my_package/dist/delete-me.whl"
  ]
}

Cele

Mapowanie targets określa co najmniej jeden kontekst, w którym mają być uruchamiane przepływy pracy usługi Azure Databricks. Każdy element docelowy to unikatowa kolekcja artefaktów, ustawień obszaru roboczego usługi Azure Databricks oraz szczegółów zadania lub potoku usługi Azure Databricks.

To targets mapowanie jest opcjonalne, ale zdecydowanie zalecane. Jeśli zostanie określony, może być wyświetlany tylko jako mapowanie najwyższego poziomu. targets Jeśli mapowanie nie zostanie określone, ustawienia w obszarze roboczym najwyższego poziomu, artefakty i mapowania zasobów są zawsze używane.

Mapowanie targets składa się z co najmniej jednego mapowania docelowego, które musi mieć unikatową nazwę programową (lub logiczną).

Jeśli mapowanie obiektu docelowego nie określa workspacemapowań podrzędnych , artifactslub resources , obiekt docelowy używa ustawień w mapowaniach najwyższego poziomu workspacei artifactsresources .

Jeśli mapowanie obiektu docelowego określa workspaceartifacts, lub resources mapowanie, a najwyższego poziomu workspace, artifactslub resources mapowanie istnieje również, wszystkie ustawienia powodujące konflikt są zastępowane przez ustawienia w obiekcie docelowym.

Obiekt docelowy może również zastąpić wartości dowolnych zmiennych najwyższego poziomu.

Aby określić, że element docelowy jest domyślny, chyba że określono inaczej, dodaj default mapowanie, ustaw wartość true. Na przykład ten obiekt docelowy o nazwie dev jest domyślnym obiektem docelowym:

targets:
  dev:
    default: true

Aby określić, że element docelowy jest traktowany jako element docelowy programowania, dodaj mode mapowanie, ustaw wartość development. Aby określić, że element docelowy jest traktowany jako docelowy w środowisku produkcyjnym, dodaj mode mapowanie, ustaw wartość .production Na przykład ten obiekt docelowy o nazwie prod jest traktowany jako docelowy produkt produkcyjny:

targets:
  prod:
    mode: production

mode Określanie zapewnia kolekcję odpowiednich domyślnych zachowań dla przepływów pracy przedprodukcyjnej i produkcyjnej. Aby uzyskać szczegółowe informacje, zobacz Tryby wdrażania pakietu zasobów usługi Databricks. Ponadto można określić run_as dla każdego elementu docelowego zgodnie z opisem w temacie Określanie tożsamości przebiegu dla przepływu pracy pakietów zasobów usługi Databricks.

W poniższym przykładzie zadeklarowane są dwa cele. Pierwszy element docelowy ma nazwę dev programową (lub logiczną) i jest domyślnym elementem docelowym. Drugi element docelowy ma nazwę prod programową (lub logiczną) i nie jest domyślnym obiektem docelowym. Ten drugi element docelowy używa profilu połączenia usługi Azure Databricks o nazwie PROD na potrzeby uwierzytelniania:

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

Aby zweryfikować, wdrożyć i uruchomić zadania lub potoki w obiekcie dev docelowym, uruchom następujące polecenia:

# 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 <job-or-pipeline-programmatic-name>

# 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 <job-or-pipeline-programmatic-name>

Aby zamiast tego zweryfikować, wdrożyć i uruchomić to zadanie w obiekcie prod docelowym, uruchom następujące polecenia:

# 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 <job-or-pipeline-programmatic-name>

Zmienne niestandardowe

Możesz użyć zmiennych niestandardowych, aby pliki konfiguracji pakietu bardziej modułowe i wielokrotnego użytku. Można na przykład zadeklarować zmienną reprezentującą identyfikator istniejącego klastra, a następnie zmienić wartość tej zmiennej na różne identyfikatory klastra dla różnych przebiegów przepływu pracy w wielu miejscach docelowych bez zmiany oryginalnego kodu plików konfiguracji pakietu.

Zmienne niestandardowe są deklarowane w plikach konfiguracji pakietu w variables ramach mapowania. Dla każdej zmiennej ustaw opcjonalny opis, wartość domyślną, typ lub wyszukiwanie, aby pobrać wartość identyfikatora, używając następującego formatu:

variables:
  <variable-name>:
    description: <optional-description>
    default: <optional-default-value>
    type: <optional-type-value>
    lookup:
      <optional-object-type>: <optional-object-name>

Uwaga

Przyjmuje się, że zmienne mają być typu string, chyba że type ustawiono wartość complex. Zobacz Definiowanie zmiennej złożonej.

Na przykład, aby zadeklarować zmienną o nazwie my_cluster_id z wartością 1234-567890-abcde123domyślną , i zmienną o nazwie my_notebook_path z wartością ./hello.pydomyślną :

variables:
  my_cluster_id:
    description: The ID of an existing cluster.
    default: 1234-567890-abcde123
  my_notebook_path:
    description: The path to an existing notebook.
    default: ./hello.py

Jeśli nie podasz default wartości zmiennej w ramach tej deklaracji, musisz ustawić ją podczas wykonywania poleceń pakietu, za pomocą zmiennej środowiskowej lub w innych miejscach w plikach konfiguracji pakietu zgodnie z opisem w temacie Ustawianie wartości zmiennej.

Uwaga

Niezależnie od wybranego podejścia do podawania wartości zmiennych należy użyć tego samego podejścia zarówno podczas wdrażania, jak i etapów uruchamiania. W przeciwnym razie mogą wystąpić nieoczekiwane wyniki między czasem wdrożenia a uruchomieniem zadania lub potoku opartego na tym istniejącym wdrożeniu.

Aby odwołać się do zmiennych niestandardowych w plikach konfiguracji pakietu, użyj podstawiania. W przypadku zmiennych użyj formatu ${var.<variable_name>}. Na przykład aby odwołać się do zmiennych o nazwach my_cluster_id i my_notebook_path:

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: ${var.my_cluster_id}
          notebook_task:
            notebook_path: ${var.my_notebook_path}

Ustawianie wartości zmiennej

Jeśli nie podano default wartości zmiennej lub jeśli chcesz tymczasowo zastąpić default wartość zmiennej, podaj nową wartość tymczasową zmiennej przy użyciu jednej z następujących metod:

Podaj wartość zmiennej w ramach bundle polecenia, takiego jak validate, deploylub run. W tym celu użyj opcji --var="<key>=<value>", gdzie <key> jest nazwą zmiennej i <value> jest wartością zmiennej. Na przykład w ramach bundle validate polecenia, aby podać wartość 1234-567890-abcde123 zmiennej o nazwie , i podać wartość ./hello.py zmiennej o nazwie my_cluster_idmy_notebook_path, uruchom:
```
databricks bundle validate --var="my_cluster_id=1234-567890-abcde123,my_notebook_path=./hello.py"

# Or:
databricks bundle validate --var="my_cluster_id=1234-567890-abcde123" --var="my_notebook_path=./hello.py"
```
Podaj wartość zmiennej, ustawiając zmienną środowiskową. Nazwa zmiennej środowiskowej musi zaczynać się od BUNDLE_VAR_. Aby ustawić zmienne środowiskowe, zapoznaj się z dokumentacją systemu operacyjnego. Aby na przykład podać wartość 1234-567890-abcde123 zmiennej o nazwie , i podać wartość ./hello.py zmiennej o nazwie my_notebook_pathmy_cluster_id, uruchom następujące polecenie przed wywołaniem bundle polecenia takiego jak validate, deploylub run:

W przypadku systemów Linux i macOS:
```
export BUNDLE_VAR_my_cluster_id=1234-567890-abcde123 && export BUNDLE_VAR_my_notebook_path=./hello.py
```
Dla systemu Windows:
```
"set BUNDLE_VAR_my_cluster_id=1234-567890-abcde123" && "set BUNDLE_VAR_my_notebook_path=./hello.py"
```
Możesz też podać wartość zmiennej w ramach bundle polecenia, takiego jak validate, deploylub run, na przykład dla systemów Linux i macOS:
```
BUNDLE_VAR_my_cluster_id=1234-567890-abcde123 BUNDLE_VAR_my_notebook_path=./hello.py databricks bundle validate
```
Lub dla systemu Windows:
```
"set BUNDLE_VAR_my_cluster_id=1234-567890-abcde123" && "set BUNDLE_VAR_my_notebook_path=./hello.py" && "databricks bundle validate"
```
Podaj wartość zmiennej w plikach konfiguracji pakietu. W tym celu użyj variables mapowania w ramach mapowania, korzystając z następującego targets formatu:
```
variables:
  <variable-name>: <value>
```
Aby na przykład podać wartości zmiennych o nazwie my_cluster_id i my_notebook_path dla dwóch oddzielnych obiektów docelowych:
```
targets:
  dev:
    variables:
      my_cluster_id: 1234-567890-abcde123
      my_notebook_path: ./hello.py
  prod:
    variables:
      my_cluster_id: 2345-678901-bcdef234
      my_notebook_path: ./hello.py
```

W poprzednich przykładach interfejs wiersza polecenia usługi Databricks szuka wartości dla zmiennych my_cluster_id i my_notebook_path w następującej kolejności, zatrzymując się po znalezieniu wartości dla każdej pasującej zmiennej, pomijając wszystkie inne lokalizacje dla tej zmiennej:

W ramach dowolnych --var opcji określonych jako część bundle polecenia.
W dowolnym zestawie zmiennych środowiskowych rozpoczynających się od BUNDLE_VAR_.
W ramach wszelkich variables mapowań między targets mapowaniami w plikach konfiguracji pakietu.
Dowolna default wartość definicji tej zmiennej wśród mapowań najwyższego poziomu variables w plikach konfiguracji pakietu.

Definiowanie zmiennej złożonej

Aby zdefiniować zmienną niestandardową ze złożonym typem pakietu, ustaw wartość type na complex w konfiguracji pakietu.

Uwaga

Jedyną prawidłową wartością ustawienia type jest complex. Ponadto sprawdzanie poprawności pakietu kończy się niepowodzeniem, jeśli type jest ustawiona complex wartość , a default zdefiniowana dla zmiennej jest pojedynczą wartością.

W poniższym przykładzie ustawienia klastra są definiowane w niestandardowej zmiennej złożonej o nazwie my_cluster:

variables:
  my_cluster:
    description: "My cluster definition"
    type: complex
    default:
      spark_version: "13.2.x-scala2.11"
      node_type_id: "Standard_DS3_v2"
      num_workers: 2
      spark_conf:
        spark.speculation: true
        spark.databricks.delta.retentionDurationCheck.enabled: false

resources:
  jobs:
    my_job:
      job_clusters:
        - job_cluster_key: my_cluster_key
          new_cluster: ${var.my_cluster}
      tasks:
      - task_key: hello_task
        job_cluster_key: my_cluster_key

Pobieranie wartości identyfikatora obiektu

alertDla typów obiektów , , cluster_policy, instance_poolmetastorejobdashboardclusterqueryservice_principalpipelinei warehouse można zdefiniować lookup dla zmiennej niestandardowej , aby pobrać identyfikator nazwanego obiektu przy użyciu tego formatu:

variables:
  <variable-name>:
    lookup:
      <object-type>: "<object-name>"

Jeśli wyszukiwanie jest zdefiniowane dla zmiennej, identyfikator obiektu o określonej nazwie jest używany jako wartość zmiennej. Gwarantuje to, że prawidłowy rozpoznany identyfikator obiektu jest zawsze używany dla zmiennej.

Uwaga

Błąd występuje, jeśli obiekt o określonej nazwie nie istnieje lub jeśli istnieje więcej niż jeden obiekt o określonej nazwie.

Na przykład w poniższej konfiguracji ${var.my_cluster_id} zostanie zastąpiony identyfikatorem udostępnionego klastra 12.2.

variables:
  my_cluster_id:
    description: An existing cluster
    lookup:
      cluster: "12.2 shared"

resources:
  jobs:
    my_job:
      name: "My Job"
      tasks:
        - task_key: TestTask
          existing_cluster_id: ${var.my_cluster_id}

Zastępstwa

Można użyć podstawień, aby pliki konfiguracji pakietu bardziej modułowe i wielokrotnego użytku.

Napiwek

Można również użyć odwołań wartości dynamicznych dla wartości parametrów zadania, aby przekazać kontekst o uruchomieniu zadania do zadań podrzędnych zadania. Zobacz Pass context about job runs into job tasks (Przekazywanie kontekstu zadania w zadaniach podrzędnych).

Na przykład po uruchomieniu bundle validate --output json polecenia może zostać wyświetlony wykres podobny do tego (wielokropek wskazuje pominiętą zawartość, aby uzyskać zwięzłość):

{
  "bundle": {
    "name": "hello-bundle",
    "target": "dev",
    "...": "..."
  },
  "workspace": {
    "...": "...",
    "current_user": {
      "...": "...",
      "userName": "someone@example.com",
      "...": "...",
    },
    "...": "..."
  },
  "...": {
    "...": "..."
  }
}

W poprzednim przykładzie można odwołać się do wartości someone@example.com w pliku konfiguracji pakietu z podstawieniem ${workspace.current_user.userName}.

Podobnie następujące podstawianie:

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

W pliku konfiguracji pakietu, takim jak następujące (wielokropek wskazuje pominiętą zawartość dla zwięzłości):

bundle:
  name: hello-bundle

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

# ...

targets:
  dev:
    default: true

Aby rozwiązać problem z następującym grafem bundle validate --output json podczas uruchamiania polecenia (wielokropek wskazuje pominiętą zawartość w celu zwięzłości):

{
  "bundle": {
    "name": "hello-bundle",
    "target": "dev",
    "...": "..."
  },
  "workspace": {
    "profile": "DEFAULT",
    "current_user": {
      "...": "...",
      "userName": "someone@example.com",
      "...": "...",
    },
    "root": "/Users/someone@example.com/.bundle/hello-bundle/my-envs/dev",
    "...": "..."
  },
  "...": {
    "...": "..."
  }
}

Można również tworzyć podstawienia dla nazwanych zasobów. Na przykład dla potoku skonfigurowanego przy użyciu nazwy my_pipeline, ${resources.pipelines.my_pipeline.target} jest podstawianie wartości docelowej my_pipeline.

Aby określić prawidłowe podstawienia, możesz użyć hierarchii schematu udokumentowanej w dokumentacji interfejsu API REST lub danych wyjściowych bundle schema polecenia.

Poniżej przedstawiono niektóre często używane podstawianie:

${bundle.name}
${bundle.target} # Use this substitution instead of ${bundle.environment}
${workspace.host}
${workspace.current_user.short_name}
${workspace.current_user.userName}
${workspace.file_path}
${workspace.root_path}
${resources.jobs.<job-name>.id}
${resources.models.<model-name>.name}
${resources.pipelines.<pipeline-name>.name}

Udostępnij za pośrednictwem

Konfiguracje pakietu zasobów usługi Databricks

Omówienie

Przykłady

Mapowania

pakiet

compute_id

Git

databricks_cli_version

Zmiennych

obszar roboczy

Uprawnienia

Artefakty

zawierać

zasoby

synchronizować

Cele

Zmienne niestandardowe

Ustawianie wartości zmiennej

Definiowanie zmiennej złożonej

Pobieranie wartości identyfikatora obiektu

Zastępstwa

Opinia

Opinia

Dodatkowe zasoby