Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo descreve a sintaxe dos arquivos de configuração do Databricks Asset Bundle, que definem o Databricks Asset Bundles. Consulte O que são os Databricks Asset Bundles?.
Para criar e trabalhar com pacotes, consulte Desenvolver pacotes de ativos Databricks.
Para referência de configuração de pacotes, veja Referência de configuração.
databricks.yml
Um bundle deve conter um (e apenas um) arquivo de configuração nomeado databricks.yml na raiz da pasta do projeto do bundle.
databricks.yml é o arquivo de configuração principal que define um pacote, mas pode fazer referência a include outros arquivos de configuração, como arquivos de configuração de recursos, no mapeamento. A configuração do pacote é expressa em YAML. Para obter mais informações sobre YAML, consulte a especificação oficial YAML.
O mais databricks.yml simples define o nome do bundle, que é um mapeamento de topo obrigatório, e uma implementação alvo.
bundle:
name: my_bundle
targets:
dev:
default: true
Para detalhes sobre todos os mapeamentos de topo, veja Referência de configuração.
Gorjeta
O suporte Python para Databricks Asset Bundles permite definir recursos em Python. Consulte Configuração do Bundle em Python.
Especificação
A especificação YAML a seguir fornece chaves de configuração de nível superior para Databricks Asset Bundles. Para referência completa de configuração, consulte Referência de Configuração e Recursos Databricks Asset Bundles.
# This is the default bundle configuration if not otherwise overridden in
# the "targets" top-level mapping.
bundle: # Required.
name: string # Required.
databricks_cli_version: string
cluster_id: string
deployment: Map
git:
origin_url: string
branch: string
# This is the identity to use to run the bundle
run_as:
- user_name: <user-name>
- service_principal_name: <service-principal-name>
# These are any additional configuration files to include.
include:
- '<some-file-or-path-glob-to-include>'
- '<another-file-or-path-glob-to-include>'
# These are any scripts that can be run.
scripts:
<some-unique-script-name>:
content: string
# These are any additional files or paths to include or exclude.
sync:
include:
- '<some-file-or-path-glob-to-include>'
- '<another-file-or-path-glob-to-include>'
exclude:
- '<some-file-or-path-glob-to-exclude>'
- '<another-file-or-path-glob-to-exclude>'
paths:
- '<some-file-or-path-to-synchronize>'
# These are the default artifact settings if not otherwise overridden in
# the targets top-level mapping.
artifacts:
<some-unique-artifact-identifier>:
build: string
dynamic_version: boolean
executable: string
files:
- source: string
path: string
type: string
# These are for any custom variables for use throughout the bundle.
variables:
<some-unique-variable-name>:
description: string
default: string or complex
lookup: Map
type: string # The only valid value is "complex" if the variable is a complex variable, otherwise do not define this key.
# These are the workspace settings if not otherwise overridden in
# the targets top-level mapping.
workspace:
artifact_path: string
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:
alerts:
<unique-alert-name>:
# alert settings
apps:
<unique-app-name>:
# app settings
catalogs:
<unique-catalog-name>:
# catalog settings
clusters:
<unique-cluster-name>:
# cluster settings
dashboards:
<unique-dashboard-name>:
# dashboard settings
database_catalogs:
<unique-database-catalog-name>:
# database catalog settings
database_instances:
<unique-database-instance-name>:
# database instance settings
experiments:
<unique-experiment-name>:
# experiment settings
jobs:
<unique-job-name>:
# job settings
model_serving_endpoints:
<unique-model-serving-endpoint-name>:
# model_serving_endpoint settings
pipelines:
<unique-pipeline-name>:
# pipeline settings
postgres_branches:
<unique-postgres-branch-name>:
# postgres branch settings
postgres_endpoints:
<unique-postgres-endpoint-name>:
# postgres endpoint settings
postgres_projects:
<unique-postgres-project-name>:
# postgres project settings
quality_monitors:
<unique-quality-monitor-name>:
# quality monitor settings
registered_models:
<unique-registered-model-name>:
# registered model settings
schemas:
<unique-schema-name>:
# schema settings
secret_scopes:
<unique-secret-scope-name>:
# secret scopes settings
sql_warehouses:
<unique-sql-warehouse-name>:
# sql warehouse settings
synced_database_tables:
<unique-synced-database-table-name>:
# synced database table settings
volumes:
<unique-volume-name>:
# volumes settings
# 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:
# artifact build settings for this target
bundle:
# bundle settings for this target
default: boolean
git: Map
mode: string
permissions:
# permissions for this target
presets:
<preset>: <value>
resources:
# resource settings for this target
sync:
# sync settings for this target
variables:
<defined-variable-name>: <non-default-value> # value for this target
workspace:
# workspace settings for this target
run_as:
# run_as settings for this target
Exemplos
Esta seção contém alguns exemplos básicos para ajudá-lo a entender como os pacotes funcionam e como estruturar a configuração.
Nota
Para obter exemplos de configuração que demonstram recursos de pacote e casos de uso comuns de pacote, consulte Exemplos de configuração de pacote e o repositório de exemplos de pacote no GitHub.
O exemplo de configuração de pacote a seguir especifica um arquivo local chamado hello.py que está no mesmo diretório que o arquivo databricks.ymlde configuração de pacote. Ele executa este notebook como um trabalho usando o cluster remoto com o ID de cluster especificado. A URL do espaço de trabalho remoto e as credenciais de autenticação do espaço de trabalho são lidas a partir do perfil de configuração local do chamador chamado DEFAULT.
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
O exemplo a seguir adiciona um destino com o nome prod que usa uma URL de espaço de trabalho remoto diferente e credenciais de autenticação de espaço de trabalho, que são lidas da entrada correspondente .databrickscfg do arquivo do chamador host com a URL do espaço de trabalho especificado. Esse trabalho executa o mesmo notebook, mas usa um cluster remoto diferente com a ID do cluster especificada.
Nota
A Databricks recomenda que use o mapeamento host em vez do mapeamento default sempre que possível, pois isso torna os ficheiros de configuração do pacote mais portáteis. A definição do host mapeamento instrui a CLI do Databricks a encontrar um perfil correspondente no seu .databrickscfg arquivo e, em seguida, utilizar os campos desse perfil para determinar o tipo de autenticação do Databricks que deve ser usado. Se existirem vários perfis com um campo correspondente host , você deverá usar a --profile opção nos comandos bundle para especificar um perfil a ser usado.
Observe que você não precisa declarar o notebook_task mapeamento dentro do prod mapeamento, pois ele volta a usar o notebook_task mapeamento dentro do mapeamento de nível resources superior, se o notebook_task mapeamento não for explicitamente substituído dentro do prod mapeamento.
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
Use os seguintes comandos de bundle para validar, desplegar e executar este trabalho no dev destino. Para obter detalhes sobre o ciclo de vida de um pacote, consulte Desenvolver pacotes de ativos 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
Para validar, implantar e executar este trabalho no prod alvo:
# 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
Para obter mais modularização e melhor reutilização de definições e configurações entre pacotes, divida a configuração do pacote em arquivos separados:
# 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