Exemples de configuration de bundle
Cet article fournit un exemple de configuration pour les fonctionnalités des bundles d’automatisation déclaratifs (anciennement connus sous le nom de Databricks Asset Bundles) et les cas d’utilisation courants des bundles.
Des exemples complets de bundles, détaillés dans le tableau suivant, sont disponibles dans le repository GitHub bundle-examples:
Nom du bundle | Description |
|---|---|
Un bundle avec une application Databricks adossée à une base de données OLTP Postgres. | |
Un ensemble qui définit une application Databricks utilisant un agent Genie. | |
Un bundle avec un AI/BI dashboard et un Job qui capture un instantané du dashboard et l'envoie par e-mail à un abonné | |
Un bundle qui définit une instance de base de données OLTP et un catalogue de base de données | |
Un bundle qui définit une application Databricks | |
Un ensemble qui définit et utilise un cluster de développement (polyvalent) | |
Un bundle qui définit un agent Genie qui répond aux questions concernant la table | |
Un bundle qui définit un job exécutant une tâche SQL avec un paramètre de date pour le remplissage des données. | |
Un bundle qui définit un Job qui utilise l'exécution conditionnelle des tâches basée sur des vérifications de qualité des données. | |
Un bundle qui définit un Job qui utilise des Trigger d'arrivée de fichiers pour traiter automatiquement les nouveaux fichiers lorsqu'ils arrivent dans un volume Unity Catalog. | |
Un bundle qui définit un Secret Scope et un Job avec une tâche qui le lit. | |
Un bundle qui démontre un workflow lorsque les producteurs écrivent dans des tables Unity Catalog, les consommateurs peuvent Trigger des mises à jour de table au lieu de planifications temporelles. | |
Un bundle qui définit et utilise un Job avec plusieurs dépendances de roue | |
Un bundle avec plusieurs Jobs avec des tâches d'exécution de Job | |
Un bundle avec un Job qui utilise une tâche de Notebook SQL | |
Un bundle qui crée une vue de métriques de Unity Catalog. Une fois enregistrée, la vue de métrique est disponible pour les analystes et les outils de BI dans l'ensemble de votre workspace, interrogeable avec la fonction SQL | |
Un bundle qui définit un schéma Unity Catalog et un pipeline qui l'utilise | |
Un bundle qui utilise un package wheel privé d'un Job | |
Un bundle qui construit un | |
Un bundle qui utilise le compute serverless pour exécuter un job | |
Un bundle qui inclut des fichiers situés en dehors du répertoire racine du bundle. | |
Un bundle qui définit et utilise une tâche JAR Spark | |
Un bundle qui démontre le concept d'utilisation de target_includes (ou de mécanismes d'inclusion similaires) pour organiser les configurations de Job dans différents environnements sans duplication. | |
Un pack qui démontre la recherche sémantique de produits à l'aide de Databricks Vector Search. | |
Un bundle qui écrit un fichier dans un volume Unity Catalog. |
Scénarios de bundle
Cette section contient des exemples de configuration qui montrent comment utiliser les mappages de bundles de niveau supérieur. Reportez-vous à la référence de configuration.
Bundle qui upload un fichier JAR vers Unity Catalog
Vous pouvez spécifier les volumes Unity Catalog comme chemin d'artefact afin que tous les artefacts, tels que les fichiers JAR et les fichiers wheel, soient upload vers les volumes Unity Catalog. Le bundle d'exemples suivant construit et upload un fichier JAR vers Unity Catalog. Pour plus d'informations sur le mappage artifact_path, consultez workspace.artifact_path. Pour plus d'informations sur artifacts, consultez les artefacts.
bundle:
name: jar-bundle
workspace:
host: https://myworkspace.cloud.databricks.com
artifact_path: /Volumes/main/default/my_volume
artifacts:
my_java_code:
path: ./sample-java
build: 'javac PrintArgs.java && jar cvfm PrintArgs.jar META-INF/MANIFEST.MF PrintArgs.class'
files:
- source: ./sample-java/PrintArgs.jar
resources:
jobs:
jar_job:
name: 'Spark Jar Job'
tasks:
- task_key: SparkJarTask
new_cluster:
num_workers: 1
spark_version: '14.3.x-scala2.12'
node_type_id: 'i3.xlarge'
spark_jar_task:
main_class_name: PrintArgs
libraries:
- jar: ./sample-java/PrintArgs.jar
Configuration du tableau de bord
Cette section contient des exemples de configuration de tableau de bord. Pour plus de détails sur la configuration du tableau de bord, consultez le tableau de bord.
Paramétrisation du catalogue et du schéma du tableau de bord
Vous pouvez définir un catalogue et un schéma uniques pour les datasets d’un tableau de bord lorsque vous le déployez avec des bundles d’automatisation déclarative à l’aide des champs dataset_catalog et dataset_schema de la ressource de tableau de bord.
Pour paramétrer des références de table spécifiques dans SQL, vous pouvez utiliser la fonction current_catalog().
La configuration de bundle exemple suivante définit des variables pour définir les valeurs de catalogue et de schéma pour les cibles dev et prod. Il suppose qu'il existe un fichier nyc_taxi_trip_analysis.lvdash.json dans le dossier src du bundle.
bundle:
name: dashboard-bundle
variables:
warehouse_id:
description: Warehouse
default: baf79a9e4ze90f02
catalog_name:
description: 'Catalog name'
default: test_catalog
schema_name:
description: 'Schema name'
default: ${workspace.current_user.short_name}
resources:
dashboards:
nyc_taxi_trip_analysis:
display_name: 'NYC Taxi Trip Analysis'
file_path: src/nyc_taxi_trip_analysis.lvdash.json
warehouse_id: ${var.warehouse_id}
dataset_catalog: ${var.catalog}
dataset_schema: ${var.schema}
targets:
dev:
mode: development
default: true
workspace:
host: https://myworkspace.cloud.databricks.com
variables:
catalog: dev_catalog
schema: ${workspace.current_user.short_name}
prod:
mode: production
workspace:
host: https://myworkspace.cloud.databricks.com
root_path: /Workspace/Users/someone@example.com/.bundle/${bundle.name}/${bundle.target}
variables:
catalog_name: prod_catalog
schema_name: prod_schema
permissions:
- user_name: someone@example.com
level: CAN_MANAGE
Configuration du Job
Cette section contient des exemples de configuration du job. Pour plus de détails sur la configuration des jobs, consultez job.
Job qui utilise le compute Serverless
Les Declarative Automation Bundles prennent en charge les jobs qui s'exécutent sur le compute serverless. Voir Exécutez vos Lakeflow Jobs avec le compute serverless pour les workflows. Pour configurer cela, vous pouvez soit omettre le paramètre clusters pour un job avec une tâche de notebook, soit spécifier un environnement comme indiqué dans les exemples ci-dessous. Pour les scripts Python, les Python wheel et les tâches dbt, environment_key est requis pour le compute serverless. Voir environment_key.
# A serverless job (no cluster definition)
resources:
jobs:
serverless_job_no_cluster:
name: serverless_job_no_cluster
email_notifications:
on_failure:
- someone@example.com
tasks:
- task_key: notebook_task
notebook_task:
notebook_path: ../src/notebook.ipynb
# A serverless job (environment spec)
resources:
jobs:
serverless_job_environment:
name: serverless_job_environment
tasks:
- task_key: task
spark_python_task:
python_file: ../src/main.py
# The key that references an environment spec in a job.
# https://docs.databricks.com/api/workspace/jobs/create#tasks-environment_key
environment_key: default
# A list of task execution environment specifications that can be referenced by tasks of this job.
environments:
- environment_key: default
# Full documentation of this spec can be found at:
# https://docs.databricks.com/api/workspace/jobs/create#environments-spec
spec:
environment_version: '2'
dependencies:
- my-library
Job avec plusieurs fichiers wheel
Les configurations d'exemple suivantes définissent un bundle qui contient un job avec plusieurs fichiers *.whl.
# job.yml
resources:
jobs:
example_job:
name: 'Example with multiple wheels'
tasks:
- task_key: task
spark_python_task:
python_file: ../src/call_wheel.py
libraries:
- whl: ../my_custom_wheel1/dist/*.whl
- whl: ../my_custom_wheel2/dist/*.whl
new_cluster:
node_type_id: i3.xlarge
num_workers: 0
spark_version: 14.3.x-scala2.12
spark_conf:
'spark.databricks.cluster.profile': 'singleNode'
'spark.master': 'local[*, 4]'
custom_tags:
'ResourceClass': 'SingleNode'
# databricks.yml
bundle:
name: job_with_multiple_wheels
include:
- ./resources/job.yml
workspace:
host: https://myworkspace.cloud.databricks.com
artifacts:
my_custom_wheel1:
type: whl
build: poetry build
path: ./my_custom_wheel1
my_custom_wheel2:
type: whl
build: poetry build
path: ./my_custom_wheel2
targets:
dev:
default: true
mode: development
Job avec paramètres
La configuration d'exemple suivante définit un job avec des paramètres. Pour plus d'information sur la paramétrisation des Jobs, consultez Paramétrer les Jobs.
resources:
jobs:
job_with_parameters:
name: job_with_parameters
tasks:
- task_key: task_a
spark_python_task:
python_file: ../src/file.py
parameters:
- '--param1={{ job.parameters.param1 }}'
- '--param2={{ job.parameters.param2 }}'
new_cluster:
node_type_id: i3.xlarge
num_workers: 1
spark_version: 14.3.x-scala2.12
parameters:
- name: param1
default: value1
- name: param2
default: value1
Ces paramètres peuvent être définis à l'exécution en passant des paramètres de Job à bundle run, par exemple :
databricks bundle run -- --param1=value2 --param2=value2
Job qui utilise un fichier requirements.txt
L’exemple de configuration suivant définit un job qui utilise un fichier requirements.txt.
resources:
jobs:
job_with_requirements_txt:
name: 'Example job that uses a requirements.txt file'
tasks:
- task_key: task
job_cluster_key: default
spark_python_task:
python_file: ../src/main.py
libraries:
- requirements: /Workspace/${workspace.file_path}/requirements.txt
Job planifié
Les exemples suivants présentent la configuration pour les jobs qui s'exécutent selon un planning. Pour des informations sur les planifications de Jobs et les Triggers, consultez la page Automatisez les Jobs avec des planifications et des Triggers.
Cette configuration définit un job qui s'exécute quotidiennement à une heure spécifiée :
resources:
jobs:
my-notebook-job:
name: my-notebook-job
tasks:
- task_key: my-notebook-task
notebook_task:
notebook_path: ./my-notebook.ipynb
schedule:
quartz_cron_expression: '0 0 8 * * ?' # daily at 8am
timezone_id: UTC
pause_status: UNPAUSED
Dans cette configuration, le job s'exécute une semaine après la dernière exécution du job :
resources:
jobs:
my-notebook-job:
name: my-notebook-job
tasks:
- task_key: my-notebook-task
notebook_task:
notebook_path: ./my-notebook.ipynb
trigger:
pause_status: UNPAUSED
periodic:
interval: 1
unit: WEEKS
Configuration du pipeline
Cette section contient des exemples de configuration de pipeline. Pour les informations de configuration de pipeline, consultez pipeline.
Pipeline qui utilise le compute serverless
Les bundles d’automatisation déclarative prennent en charge les pipelines qui s’exécutent sur un compute Serverless. Pour configurer cela, définissez le paramètre de pipeline serverless sur true. La configuration d’exemple suivante définit un pipeline qui s’exécute sur un compute Serverless avec des dépendances installées, et un Job qui Trigger un refresh du pipeline toutes les heures.
# A pipeline that runs on serverless compute
resources:
pipelines:
my_pipeline:
name: my_pipeline
target: ${bundle.environment}
serverless: true
environment:
dependencies:
- 'dist/*.whl'
catalog: users
libraries:
- notebook:
path: ../src/my_pipeline.ipynb
configuration:
bundle.sourcePath: /Workspace/${workspace.file_path}/src
# This defines a job to refresh a pipeline that is triggered every hour
resources:
jobs:
my_job:
name: my_job
# Run this job once an hour.
trigger:
periodic:
interval: 1
unit: HOURS
email_notifications:
on_failure:
- someone@example.com
tasks:
- task_key: refresh_pipeline
pipeline_task:
pipeline_id: ${resources.pipelines.my_pipeline.id}