Partager via


Exemples de configuration de bundle

Cet article fournit des exemples de configuration pour les fonctionnalités de bundle de ressources Databricks et les cas d’utilisation courants des bundles.

Les exemples complets de bundles, présentés dans le tableau suivant, sont disponibles dans le dépôt GitHub bundle-examples :

Nom de l’offre groupée Descriptif
app_with_database Offre groupée avec une application Databricks sauvegardée par une base de données Postgres OLTP
dashboard_nyc_taxi Offre groupée avec un tableau de bord IA/BI et un travail qui capture un instantané du tableau de bord et l’envoie par e-mail à un abonné
database_with_catalog Ensemble qui définit une instance de base de données OLTP et un catalogue de bases de données
databricks_app Un ensemble qui définit une application Databricks
development_cluster Ensemble qui définit et utilise un cluster de développement (à usage général)
job_read_secret Bundle qui définit une étendue de secret et un travail avec une tâche qui le lit
job_with_multiple_wheels Bundle qui définit et utilise un travail avec plusieurs dépendances de fichiers wheel
job_with_run_job_tasks Bundle avec plusieurs travaux avec des tâches d’exécution
tâche_avec_cahier_SQL Bundle avec un travail utilisant une tâche de notebook SQL
pipeline_with_schema Ensemble qui définit un schéma de catalogue Unity et un pipeline qui l’utilise
private_wheel_packages Bundle qui utilise un package wheel privé issu d’un travail
python_wheel_poetry Bundle qui crée un whl avec Poetry
tâche_sans_serveur Ensemble qui utilise le calcul serverless pour exécuter une tâche
share_files_across_bundles Offre groupée qui inclut des fichiers situés en dehors du répertoire racine de l’offre groupée.
spark_jar_task Ensemble qui définit et utilise une tâche JAR Spark
write_from_job_to_volume Ensemble qui écrit un fichier dans un volume de catalogue Unity

Scénarios groupés

Cette section contient des exemples de configuration qui illustrent l’utilisation de mappages de paquets de niveau supérieur. Consultez la référence de configuration.

Bundle qui charge un fichier JAR dans le catalogue Unity

Vous pouvez spécifier des volumes Unity Catalog en tant que chemin d’accès d’artefact afin que tous les artefacts, tels que les fichiers JAR et les fichiers wheel, soient chargés vers des volumes Unity Catalog. L’exemple suivant génère et charge un fichier JAR dans le catalogue Unity. Pour plus d’informations sur le mappage artifact_path, consultez artifact_path. Pour plus d’informations sur artifacts, consultez 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 travail

Cette section contient des exemples de configuration de travail. Pour plus d’informations sur la configuration du travail, consultez travail.

Tâche qui utilise le calcul sans serveur

Les bundles de ressources Databricks prennent en charge les travaux qui s’exécutent sur du calcul serverless. Consultez Exécuter vos travaux Lakeflow avec un calcul serverless pour les flux de travail. Pour configurer cela, vous pouvez omettre le paramètre clusters pour un travail comprenant une tâche de bloc-notes, ou spécifier un environnement comme indiqué dans les exemples ci-dessous. Pour les tâches de scripts Python, wheel Python et dbt, environment_key est nécessaire pour le calcul serverless. Consultez 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

Travail avec plusieurs fichiers wheel

L’exemple de configuration suivant définit un bundle qui contient un travail avec plusieurs *.whl fichiers.

# 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

Travail avec des paramètres

L’exemple de configuration suivant définit un travail avec des paramètres. Pour plus d’informations sur le paramétrage des travaux, consultez Paramètres des travaux.

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 au moment de l’exécution en passant des paramètres de travail à bundle run, par exemple :

databricks bundle run -- --param1=value2 --param2=value2

Travail qui utilise un fichier requirements.txt

L’exemple de configuration suivant définit un travail 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

Travail selon une planification

Les exemples suivants montrent la configuration des travaux qui s’exécutent selon une planification. Pour plus d’informations sur les planifications et les déclencheurs de travail, consultez Automatisation des travaux avec des planifications et des déclencheurs.

Cette configuration définit un travail qui s’exécute quotidiennement à l’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 travail est exécuté une semaine après sa dernière exécution :

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 plus d’informations sur la configuration du pipeline, consultez pipeline.

Pipeline qui utilise le calcul serverless

Les bundles de ressources Databricks prennent en charge les pipelines qui s’exécutent sur du calcul serverless. Pour configurer ce paramètre, définissez le paramètre serverless du pipeline sur true. L’exemple de configuration suivant définit un pipeline qui s’exécute sur un calcul serverless avec des dépendances installées et un travail qui déclenche une actualisation 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}