Конфигурация пакета активов Databricks

В этой статье описывается синтаксис файлов конфигурации пакета ресурсов Databricks, определяющих пакеты ресурсов Databricks. См. раздел "Что такое пакеты ресурсов Databricks?".

Сведения о создании и работе с пакетами см. в статье "Разработка пакетов ресурсов Databricks".

databricks.yml

Пакет должен содержать один (и только один) файл конфигурации с именем databricks.yml в корне папки проекта пакета. databricks.yml — это основной файл конфигурации, определяющий пакет, но он может ссылаться на другие файлы конфигурации, такие как файлы конфигурации ресурсов, в сопоставлении include . Конфигурация пакета выражается в YAML. Дополнительные сведения о YAML см. в официальной спецификации YAML.

Самый простой databricks.yml определяет имя пакета, которое находится в требуемом пакете сопоставления верхнего уровня и целевом развертывании.

bundle:
  name: my_bundle

targets:
  dev:
    default: true

Дополнительные сведения обо всех сопоставлениях верхнего уровня см. в разделе "Сопоставления".

Спецификация

Следующая спецификация YAML предоставляет ключи конфигурации верхнего уровня для пакетов ресурсов Databricks. Справочник по конфигурации см. в справочнике по конфигурации.

# 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

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

Примеры

В этом разделе содержатся некоторые основные примеры, которые помогут понять, как работают пакеты и как структурировать конфигурацию.

В следующем примере конфигурация пакета указывает локальный файл с именем hello.py , который находится в том же каталоге, что и файл databricks.ymlконфигурации пакета. Он запускает эту записную книжку в качестве задания с помощью удаленного кластера с указанным идентификатором кластера. URL-адрес удалённой рабочей области и учетные данные аутентификации рабочей области считываются из локального профиля конфигурации пользователя, указанного в .

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, использующим другой URL-адрес удаленной рабочей области и учетные данные проверки подлинности рабочей области, которые считываются из соответствующей записи файла .databrickscfg вызывающего объекта host с указанным URL-адресом рабочей области. Это задание выполняет тот же блокнот, но использует другой удаленный кластер с указанным идентификатором кластера.

Обратите внимание, что не нужно объявлять сопоставление notebook_task внутри сопоставления prod, так как оно возвращается к использованию сопоставления notebook_task внутри сопоставления верхнего уровня resources, если сопоставление notebook_task не переопределяется явным образом в сопоставлении prod.

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

Используйте следующие команды пакета для проверки, развертывания и запуска этого задания в целевом объекте dev . Дополнительные сведения о жизненном цикле пакета см. в разделе "Разработка пакетов активов Databricks".

# 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

Чтобы проверить, развернуть и запустить это задание в целевом объекте, выполните следующее prod :

# 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

Для достижения более модульной структуры и лучшего повторного использования определений и настроек в различных пакетах, разбейте конфигурацию вашего пакета на отдельные файлы:

# 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

Сопоставления

В следующих разделах описаны картирования конфигурации пакета верхнего уровня. Справочник по конфигурации см. в справочнике по конфигурации.

• связка
• run_as
• включать
• Скрипты
• синхронизировать
• Артефакты
• Переменные
• рабочая область
• Разрешения
• ресурсы
• Цели

связка

Файл конфигурации пакета должен содержать только одно сопоставление верхнего уровня bundle , которое связывает содержимое пакета и параметры рабочей области Azure Databricks.

Это bundle сопоставление должно содержать name сопоставление, указывающее программное (или логическое) имя пакета. В следующем примере объявляется пакет с программным (или логическим) именем hello-bundle.

bundle:
  name: hello-bundle

Сопоставление bundle также может быть дочерним элементом одного или нескольких целевых объектов в сопоставлении целевых объектов верхнего уровня. Каждое из этих дочерних bundle сопоставлений указывает любые переопределения, отличные от по умолчанию, на целевом уровне. Однако значение bundle сопоставления верхнего уровня name нельзя переопределить на целевом уровне.

идентификатор_кластера

Сопоставление bundle может иметь дочернее cluster_id сопоставление. Это сопоставление позволяет указать идентификатор кластера, который будет использоваться в качестве переопределения для кластеров, определенных в другом месте файла конфигурации пакета. Сведения о том, как получить идентификатор кластера, см. в разделе URL-адрес и идентификатор кластера.

cluster_id Переопределение предназначено исключительно для сценариев разработки и поддерживается только для целевого объекта, для которого задано mode значение сопоставления с development. Для получения дополнительной информации о сопоставлении target, см. цели.

compute_id

Сопоставление bundle может иметь дочернее compute_id сопоставление. Это сопоставление позволяет указать идентификатор кластера, который будет использоваться в качестве переопределения для кластеров, определенных в другом месте файла конфигурации пакета.

Git

Вы можете получить и переопределить сведения об управлении версиями Git, связанные с пакетом, что полезно для распространения метаданных развертывания, которые можно использовать позже для идентификации ресурсов. Например, можно отслеживать происхождение репозитория задачи, развернутой с помощью CI/CD.

При каждом выполнении команды bundle, такой как validate, deploy или run, команда bundle заполняет дерево конфигурации команды следующими параметрами по умолчанию:

• bundle.git.origin_url, представляющий URL-адрес источника репозитория. Это то же значение, что и при выполнении команды git config --get remote.origin.url из клонированного репозитория. Вы можете использовать подстановки , чтобы ссылаться на это значение с файлами конфигурации пакета, как ${bundle.git.origin_url}.
• bundle.git.branch, представляющий текущую ветвь в репозитории. Это то же значение, что и при выполнении команды git branch --show-current из клонированного репозитория. Вы можете использовать подстановки , чтобы ссылаться на это значение с файлами конфигурации пакета, как ${bundle.git.branch}.

Чтобы получить или переопределить параметры Git, пакет должен находиться в каталоге, связанном с репозиторием Git, например локальный каталог, инициализированный с помощью git clone команды. Если каталог не связан с репозиторием Git, эти параметры Git пусты.

При необходимости, вы можете переопределить настройки origin_url и branch в сопоставлении верхнего уровня git следующим образом:

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

databricks_cli_version

Сопоставление bundle может содержать databricks_cli_version сопоставление, которое ограничивает версию интерфейса командной строки Databricks, необходимую для пакета. Это может предотвратить проблемы, вызванные использованием сопоставлений, которые не поддерживаются в определенной версии интерфейса командной строки Databricks.

Версия интерфейса командной строки Databricks соответствует семантическому версионированию, а databricks_cli_version сопоставление поддерживает указание ограничений версии. Если текущее databricks --version значение не находится в пределах, указанных в сопоставлении пакета databricks_cli_version, возникает ошибка при databricks bundle validate выполнении над пакетом. В следующих примерах демонстрируется некоторый распространенный синтаксис ограничения версии:

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

run_as

Параметр run_as указывает, какой user_name или service_principal_name следует использовать для запуска пакета. Он предоставляет возможность отделять учетные данные, используемые для развертывания задания пакета или конвейерного задания, от учетных данных, используемых для выполнения задания или конвейерного задания.

См. Задайте идентификатор выполнения для рабочего процесса пакетов ресурсов Databricks.

включать

Массив include задает список глобов пути, содержащих файлы конфигурации для включения в пакет. Эти глобы пути относятся к расположению файла конфигурации пакета, в котором указаны глобы пути.

Интерфейс командной строки Databricks не включает файлы конфигурации по умолчанию в пакете. Массив include необходимо использовать для указания всех файлов конфигурации, которые должны быть включены в пакет, кроме самого файла databricks.yml.

Этот include массив может отображаться только как сопоставление верхнего уровня.

В следующем примере конфигурации содержится три файла конфигурации. Эти файлы находятся в той же папке, что и файл конфигурации пакета:

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

В следующем примере конфигурации содержатся все файлы с именами файлов, начинающимися bundle и заканчивающимися .yml. Эти файлы находятся в той же папке, что и файл конфигурации пакета:

include:
  - 'bundle*.yml'

Сценарии

Этот scripts параметр задает сценарии, которые можно запускать с помощью bundle run. Каждый именованный скрипт в сопоставлении scripts содержит содержимое с командами. Рассмотрим пример.

scripts:
  my_script:
    content: uv run pytest -m ${bundle.target}

Дополнительные сведения см. в разделе "Выполнение скриптов".

синхронизация

Сопоставление sync позволяет конфигурировать файлы, входящие в состав развертываний пакета.

включить и исключить

Сопоставления include и exclude в сопоставлении sync указывают список файлов или папок для включения или исключения из развертываний пакетов в зависимости от следующих правил:

• На основе любого списка глобов файлов и путей в файле в .gitignore корневом каталоге пакета сопоставление может содержать список глобов файлов, глобов пути или обоих, относительно корневого include каталога пакета, чтобы явно включить.
• На основе любого списка шаблонов файлов и путей в файле, находящемся в .gitignore корневом каталоге пакета, вместе со списком шаблонов файлов и путей в include сопоставлении, в exclude сопоставлении может содержаться список шаблонов файлов, путей или того и другого относительно корневого каталога пакета, для явного исключения.

Все пути к указанным файлам и папкам относятся к расположению файла конфигурации пакета, в котором они указаны.

Синтаксис шаблонов include, файлов и путей exclude следует стандартному синтаксису .gitignore. См. формат шаблона gitignore.

Например, если следующий .gitignore файл содержит следующие записи:

.databricks
my_package/dist

И файл конфигурации пакета содержит следующее include сопоставление:

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

Затем включаются все файлы в папке my_package/dist с расширением *.whl. Другие файлы в папке my_package/dist не включены.

Однако если файл конфигурации пакета также содержит следующее exclude сопоставление:

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

Затем все файлы в папке my_package/dist с расширением *.whl, кроме файла с именем delete-me.whl, будут включены. Другие файлы в папке my_package/dist также не включены.

Сопоставление sync также можно объявить в targets сопоставлении для определенного целевого объекта. Любое сопоставление sync, объявленное в целевом объекте, объединяется с любыми сопоставлениями верхнего уровня sync. Например, продолжая работу с предыдущим примером, следующее include сопоставление на targets уровне объединяется с include сопоставлением в сопоставлении верхнего уровня sync :

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

пути

Сопоставление sync может содержать другое сопоставление paths, указывающее пути для локальной синхронизации с рабочей областью. Сопоставление paths позволяет использовать общие файлы между пакетами, а также может применяться для синхронизации файлов, расположенных вне корневого каталога пакета. (Корневой каталог пакета — это расположение файла databricks.yml.) Это особенно полезно, если у вас есть один репозиторий, в котором размещено несколько пакетов и требуется совместно использовать библиотеки, файлы кода или конфигурацию.

Указанные пути должны быть относительными к файлам и каталогам, привязанным к папке, в которой paths задано сопоставление. Если одно или несколько значений пути поднимается по каталогу до предка корня пакета, то корневой путь динамически определяется, чтобы структура папок оставалась нетронутой. Например, если корневая папка пакета называется my_bundle , эта конфигурация databricks.yml синхронизирует common папку, расположенную над корнем пакета, и сам корневой каталог пакета:

sync:
  paths:
    - ../common
    - .

Развертывание этого пакета приводит к следующей структуре папок в рабочей области:

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

Артефакты

Сопоставление верхнего уровня artifacts указывает один или несколько артефактов, которые автоматически создаются во время развертывания пакета и могут использоваться позже при выполнении пакета. Каждый дочерний артефакт поддерживает следующие сопоставления:

• type требуется для сборок колес Python. Чтобы создать файл колесика Python перед развертыванием, задайте для этого значение whl. Чтобы создать другие артефакты, этот параметр не требуется указывать.
• path — это необязательный путь. Пути относятся к расположению конфигурационного файла пакета. Для сборки колес Python это путь к файлу setup.py колеса Python. Если path не задан, то Databricks CLI пытается найти файл Python wheel setup.py в корневом каталоге пакета.
• files является необязательным сопоставлением, которое включает в себя дочернее сопоставление source, которое можно использовать для указания созданных артефактов. Пути относятся к расположению конфигурационного файла пакета.
• build — это необязательный набор команд сборки, отличных от по умолчанию, которые необходимо выполнить локально перед развертыванием. Для сборок колес Python интерфейс командной строки Databricks предполагает, что он может найти локальную установку пакета Python wheel для выполнения сборок, и она выполняет команду python setup.py bdist_wheel по умолчанию во время каждого развертывания пакета. Чтобы указать несколько команд сборки, разделите каждую команду символами двойного амперсанда (&&).
• dynamic_version позволяет пакетам обновлять версию wheel-файла в зависимости от временной метки wheel-файла. Затем новый код можно развернуть без необходимости обновлять версию в setup.py или pyproject.toml. Этот параметр действителен только в том случае, если type задано значение whl.

В следующем примере конфигурация создает колесо с помощью поэзии. Полный пример пакета, который использует artifacts для сборки колеса, см. раздел Создание файла колеса Python с помощью наборов ресурсов Databricks.

artifacts:
  default:
    type: whl
    build: poetry build
    path: .

На примере конфигурации, которая создает JAR-файл и отправляет его в Unity Catalog, см. пакет, который загружает JAR-файл в Unity Catalog.

Переменные

Файл параметров пакетов может содержать одно сопоставление верхнего уровня variables , в котором определены пользовательские переменные. Для каждой переменной задайте необязательное описание, значение по умолчанию, укажите, является ли переменная сложным типом, или настройку поиска для получения значения идентификатора, используя следующий формат:

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>

Чтобы ссылаться на пользовательскую переменную в конфигурации пакета, используйте замену ${var.<variable_name>}.

Дополнительные сведения о пользовательских переменных и подстановках см. в разделе Подстановки и переменные в пакетах ресурсов Databricks.

рабочая область

Файл конфигурации пакета может содержать только одно сопоставление верхнего уровня workspace, чтобы указать любые параметры рабочей области Azure Databricks, отличные от параметров по умолчанию.

корневой путь

Это сопоставление workspace может содержать сопоставление root_path для указания корневого пути, отличного от стандартного, который используется в рабочей области как для развертывания, так и для запуска рабочих процессов, например:

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

По умолчанию интерфейс командной строки Databricks использует стандартный путь root_path, который включает /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}.

путь_к_артефакту

Это workspace сопоставление также может содержать artifact_path сопоставление, чтобы указать нестандартный путь артефакта для использования в рабочем пространстве как для развертываний, так и для запусков рабочих процессов, например:

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

По умолчанию интерфейс командной строки Databricks использует стандартный путь artifact_path, который включает ${workspace.root}/artifacts.

путь_к_файлу

Это workspace сопоставление также может содержать file_path сопоставление, чтобы указать путь к файлу, не являющийся значением по умолчанию, который используется в рабочей области для развертываний и выполнения рабочих процессов, например:

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

По умолчанию интерфейс командной строки Databricks использует стандартный путь file_path, который включает ${workspace.root}/files.

путь_состояния

Сопоставление state_path по умолчанию указывает путь ${workspace.root}/state в вашей рабочей области для хранения сведений о состоянии Terraform, связанных с развертываниями.

Другие сопоставления рабочих областей

Сопоставление workspace также может содержать следующие необязательные сопоставления, чтобы указать механизм проверки подлинности Azure Databricks для использования. Если они не указаны в этом workspace сопоставлении, они должны быть указаны в workspace сопоставлении как дочерний объект одного или нескольких целевых объектов в сопоставлении целевых объектов верхнего уровня.

• Сопоставление profile (или опции --profile и -p при выполнении команд validate, deploy, run и destroy с помощью CLI Databricks) указывает имя профиля конфигурации для использования с этой рабочей областью для аутентификации в Azure Databricks. Этот профиль конфигурации сопоставляется с созданным при настройке интерфейса командной строки Databricks.

  Примечание.

  Databricks рекомендует использовать сопоставление host (или параметры --profile или -p при выполнении команд проверки, развертывания, запуска и уничтожения пакета с помощью интерфейса командной строки Databricks) вместо сопоставления profile, так как это делает файлы конфигурации пакета более универсальными. host Установка сопоставления указывает интерфейсу командной строки Databricks найти соответствующий профиль в файле .databrickscfg, а затем использовать поля этого профиля для определения используемого типа проверки подлинности Databricks. Если в файле host существует несколько профилей с соответствующим полем .databrickscfg, необходимо использовать сопоставление profile (или параметры командной строки --profile или -p), чтобы указать Databricks CLI, какой профиль использовать. Пример см. в объявлении целевого prod объекта в примерах.

• Сопоставление host указывает URL-адрес рабочей области Azure Databricks. См. URL-адрес рабочей области.

• Для проверки подлинности OAuth между компьютерами (M2M) используется сопоставление client_id . Кроме того, можно задать это значение в локальной переменной DATABRICKS_CLIENT_IDсреды. Или вы можете создать профиль конфигурации со значением client_id, а затем указать имя профиля с помощью сопоставления profile (или, используя параметры --profile или -p, при выполнении команд проверки, развертывания, запуска и уничтожения с интерфейсом командной строки Databricks). См. статью "Разрешение на автоматический доступ к ресурсам Azure Databricks с помощью субъекта-службы и OAuth".

  Примечание.

  Нельзя указать значение секрета OAuth Azure Databricks в файле конфигурации пакета. Вместо этого задайте переменную DATABRICKS_CLIENT_SECRETлокальной среды. Кроме того, можно добавить значение client_secret в профиль конфигурации, а затем указать имя профиля с помощью сопоставления profile (или использовать параметры --profile и -p при выполнении команд проверки, развертывания, запуска и удаления с помощью интерфейса командной строки Databricks CLI).

• Для авторизации в Azure CLI используется сопоставление azure_workspace_resource_id. Кроме того, можно задать это значение в локальной переменной DATABRICKS_AZURE_RESOURCE_IDсреды. Или вы можете создать профиль конфигурации со значением azure_workspace_resource_id, а затем указать имя профиля с помощью сопоставления profile (или, используя параметры --profile или -p, при выполнении команд проверки, развертывания, запуска и уничтожения с интерфейсом командной строки Databricks). См. проверку подлинности Azure CLI.

• Для аутентификации клиента Azure с помощью субъектов-служб используются сопоставления azure_workspace_resource_id, azure_tenant_id и azure_client_id. Кроме того, эти значения можно задать в переменных DATABRICKS_AZURE_RESOURCE_IDARM_TENANT_IDлокальной среды и ARM_CLIENT_IDсоответственно. Или можно создать профиль конфигурации с помощью значений azure_workspace_resource_id, azure_tenant_id и azure_client_id, а затем указать имя профиля с помощью сопоставления profile (или используя параметры --profile или -p при выполнении команд проверки, развертывания, запуска и уничтожения через интерфейс командной строки Databricks). См . сведения о проверке подлинности субъекта-службы MS Entra.

  Примечание.

  Нельзя указать значение секрета клиента Azure в файле конфигурации пакета. Вместо этого задайте переменную ARM_CLIENT_SECRETлокальной среды. Кроме того, можно добавить значение azure_client_secret в профиль конфигурации, а затем указать имя профиля с помощью сопоставления profile (или использовать параметры --profile и -p при выполнении команд проверки, развертывания, запуска и удаления с помощью интерфейса командной строки Databricks CLI).

• Для проверки подлинности управляемых удостоверений Azure используются сопоставления azure_use_msi, azure_client_id и azure_workspace_resource_id. Кроме того, эти значения можно задать в переменных ARM_USE_MSIARM_CLIENT_IDлокальной среды и DATABRICKS_AZURE_RESOURCE_IDсоответственно. Или можно создать профиль конфигурации с помощью значений azure_use_msi, azure_client_id и azure_workspace_resource_id, а затем указать имя профиля с помощью сопоставления profile (или используя параметры --profile или -p при выполнении команд проверки, развертывания, запуска и уничтожения через интерфейс командной строки Databricks). См. проверку подлинности управляемых удостоверений Azure.

• Сопоставление azure_environment указывает тип среды Azure (например, Public, UsGov, Китай и Германия) для определенного набора конечных точек API. Значение по умолчанию — PUBLIC. Кроме того, можно задать это значение в локальной переменной ARM_ENVIRONMENTсреды. Кроме того, можно добавить значение azure_environment в профиль конфигурации, а затем указать имя профиля с помощью сопоставления profile (или использовать параметры --profile и -p при выполнении команд проверки, развертывания, запуска и удаления с помощью интерфейса командной строки Databricks CLI).

• Сопоставление azure_login_app_id не работает и зарезервировано для внутреннего использования.

• Сопоставление auth_type указывает используемый тип проверки подлинности Azure Databricks, особенно в тех случаях, когда интерфейс командной строки Databricks вызывает непредвиденный тип проверки подлинности. Ознакомьтесь с разрешением доступа к ресурсам Azure Databricks.

Разрешения

Сопоставление верхнего уровня permissions указывает один или несколько уровней разрешений для применения ко всем ресурсам, определенным в пакете. Если вы хотите применить разрешения к конкретному ресурсу, см. статью "Определение разрешений для определенного ресурса".

Допустимые уровни разрешений верхнего уровня: CAN_VIEWи CAN_MANAGECAN_RUN.

В следующем примере в файле конфигурации пакета определяются уровни разрешений для пользователя, группы и субъекта-службы, которые применяются ко всем заданиям, конвейерам, экспериментам и моделям, определенным в resources пакете:

permissions:
  - level: CAN_VIEW
    group_name: test-group
  - level: CAN_MANAGE
    user_name: [email protected]
  - level: CAN_RUN
    service_principal_name: 123456-abcdef

ресурсы

Сопоставление resources указывает сведения о ресурсах Azure Databricks, используемых пакетом.

Это отображение может выступать как отображение верхнего уровня или быть дочерним элементом одного или нескольких целевых объектов в сопоставлении целевых объектов верхнего уровня , и включает ноль или один из поддерживаемых типов ресурсов. Каждое сопоставление типов ресурсов включает в себя одно или несколько отдельных объявлений ресурсов, которые должны иметь уникальное имя. Эти декларации отдельных ресурсов используют данные запроса операции создания соответствующего объекта, выраженные в YAML, чтобы определить ресурс. Поддерживаемые свойства ресурса — это поддерживаемые поля соответствующего объекта.

Полезные данные запроса на создание операций описаны в справочнике по REST API Databricks, а команда databricks bundle schema выводит все поддерживаемые схемы объектов. Кроме того, команда databricks bundle validate возвращает предупреждения, если в файлах конфигурации пакета обнаружены неизвестные свойства ресурсов.

В следующем примере конфигурации определяется ресурс задания:

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

Для получения дополнительной информации о ресурсах, поддерживаемых в пакетах, а также о распространённых конфигурациях и примерах, см. ресурсы комплектов Databricks и примеры конфигурации пакетов.

Цели

Сопоставление targets указывает один или несколько контекстов, в которых выполняется рабочий процесс Azure Databricks. Каждый целевой объект — это уникальная коллекция артефактов, параметров рабочей области Azure Databricks и сведений о задании или конвейере Azure Databricks.

Сопоставление targets состоит из одного или нескольких целевых сопоставлений, которые должны иметь уникальное программное (или логическое) имя.

Это targets сопоставление является необязательным, но настоятельно рекомендуется. Если он указан, он может отображаться только как сопоставление верхнего уровня.

Параметры в рабочей области верхнего уровня, артефактах и сопоставлениях ресурсов используются, если они не указаны в targets сопоставлении, но все конфликтующие параметры переопределяются параметрами в целевом объекте.

Целевой объект также может переопределить значения любых переменных верхнего уровня.

по умолчанию

Чтобы задать целевое значение по умолчанию для команд пакета, сопоставьте default с true. Например, этот целевой объект называется целевым объектом dev по умолчанию:

targets:
  dev:
    default: true

Если целевой объект по умолчанию не настроен или вы хотите проверить, развернуть и запустить задания или конвейеры в определенном целевом объекте, используйте -t параметр команд пакета.

Следующие команды проверяют, развертывают и выполняют my_job внутри целей dev и 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

В следующем примере объявляется два целевых объекта. Первый целевой объект имеет имя dev и является целевым объектом по умолчанию, используемым при отсутствии целевого объекта для команд пакета. Второй целевой объект имеет имя prod и используется только в том случае, если этот целевой объект указан для команд пакета.

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

режим и предустановки

Чтобы упростить разработку и рекомендации по CI/CD, наборы активов Databricks предоставляют режимы развертывания для целевых объектов, которые устанавливают поведение по умолчанию для предварительных и рабочих рабочих процессов. Некоторые поведения также можно настроить. Дополнительные сведения см. в режимах развертывания пакета ресурсов Databricks.

Чтобы указать, что целевой объект рассматривается как объект разработки, добавьте mode набор сопоставлений development. Чтобы указать, что цель обрабатывается как производственная, добавьте набор сопоставленийmodeproduction. Например, целевой объект под названием prod рассматривается как производственный целевой объект.

targets:
  prod:
    mode: production

Некоторые из поведения можно настроить с помощью presets сопоставления. Список доступных предустановок см. в разделе "Пользовательские предустановки". В следующем примере показана настраиваемая производственная цель, которая добавляет префиксы и теги ко всем производственным ресурсам.

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

Если установлены и mode, и presets, настройки переопределяют поведение режима по умолчанию. Параметры отдельных ресурсов переопределяют предустановки. Например, если для расписания задано UNPAUSED, но предустановка trigger_pause_status установлена на PAUSED, приостановка расписания будет снята.