Modos de implementación de agrupaciones de recursos de Databricks

En este artículo se describe la sintaxis de los modos de implementación de agrupaciones de recursos de Databricks. Las agrupaciones permiten la administración mediante programación de flujos de trabajo de Azure Databricks. Consulte ¿Qué son las agrupaciones de recursos de Databricks?

En los flujos de trabajo de CI/CD, los desarrolladores suelen codificar, probar, implementar y ejecutar soluciones en varias fases o modos. Por ejemplo, el conjunto más sencillo de modos incluye un modo de desarrollo para la validación de preproducción, seguido de un modo de producción para entregas validadas. Las agrupaciones de recursos de Databricks proporcionan una colección opcional de comportamientos predeterminados que corresponden a cada uno de estos modos. Para usar estos comportamientos para un destino específico, configure mode o presets para un destino en la asignación de configuración targets. Para obtener información sobre targets, consulte asignación de destinos de configuración de agrupación.

Modo de desarrollo

Para implementar la agrupación en modo de desarrollo, primero debe agregar la asignación de mode, establecida en development, al destino previsto. Por ejemplo, este destino denominado dev se trata como destino de desarrollo:

targets:
  dev:
    mode: development

La implementación de un destino en modo de desarrollo mediante la ejecución del comando databricks bundle deploy -t <target-name> implementa los comportamientos siguientes, que se pueden personalizar mediante valores preestablecidos:

• Antepone todos los recursos que no se implementan como archivos o cuadernos con el prefijo [dev ${workspace.current_user.short_name}] y etiqueta cada trabajo implementado y canalización con una etiqueta de dev Azure Databricks.
• Marca las Canalizaciones Declarativas de Lakeflow Spark implementadas relacionadas como development: true.
• Habilita el uso de --cluster-id <cluster-id> en llamadas relacionadas al comando bundle deploy, que invalida todas y cada una de las definiciones de clúster existentes que ya están especificadas en el archivo de configuración de agrupación relacionado. En lugar de usar --cluster-id <cluster-id> en llamadas relacionadas con el comando bundle deploy, puede establecer la asignación de cluster_id aquí, o como asignación secundaria de la asignación de bundle, al identificador del clúster que se va a usar.
• Pausa todas las programaciones y desencadenadores en recursos implementados, como trabajos o monitores de calidad. Reanude las programaciones y los desencadenadores de un trabajo individual estableciendo schedule.pause_status en UNPAUSED.
• Habilite las ejecuciones simultáneas en todos los trabajos implementados para una iteración más rápida. Deshabilite las ejecuciones simultáneas para un trabajo individual estableciendo max_concurrent_runs en 1.
• Deshabilite el bloqueo de implementación para una iteración más rápida. Este bloqueo impide que se produzcan conflictos de implementación que es poco probable que se produzcan en modo de desarrollo. Vuelva a habilitar el bloqueo estableciendo bundle.deployment.lock.enabled en true.

Modo de producción

Para implementar la agrupación en modo de producción, primero debe agregar la mode asignación, establecida en production, al destino previsto. Por ejemplo, este destino denominado prod se trata como destino de producción:

targets:
  prod:
    mode: production

La implementación de un destino en modo de producción mediante la ejecución del comando databricks bundle deploy -t <target-name> implementa los comportamientos siguientes:

• Valida que todas las canalizaciones declarativas de Spark de Lakeflow implementadas relacionadas se marcan como development: false.

• Valida que la rama de Git actual es igual a la rama de Git especificada en el destino. Especificar una rama de Git en el destino es opcional y se puede realizar con una propiedad adicional git como se indica a continuación:

  git:
    branch: main
  

  Esta validación se puede invalidar especificando --force durante la implementación.

• Databricks recomienda usar entidades de servicio para implementaciones de producción. Puede aplicar esto configurando run_as en un principal de servicio. Consulte entidades de servicio y Especificación de una identidad de ejecución para un flujo de trabajo de conjuntos de recursos de Databricks. Si no usa entidades de servicio, tenga en cuenta los siguientes comportamientos adicionales:

  • Valida que las asignaciones artifact_path, file_pathroot_path, o state_path no se invalidan en un usuario específico.
  • Valida que se especifican las asignaciones de run_as y permissions para aclarar qué identidades tienen permisos específicos para las implementaciones.

• A diferencia del comportamiento anterior para establecer la asignación de mode a development, establecer la asignación de mode a production no permite anular ninguna definición de clúster existente especificada en el archivo de configuración de agrupación relacionado, por ejemplo mediante la opción --compute-id <cluster-id> o la asignación de compute_id.

Ajustes personalizados

Las agrupaciones de recursos de Databricks admiten valores preestablecidos configurables para destinos, lo que permite personalizar los comportamientos de los destinos. Los valores preestablecidos disponibles se enumeran en la tabla siguiente:

Nota:

A menos que se especifique una excepción en la tabla siguiente, si se establecen tanto mode como presets, los valores preestablecidos invalidan el comportamiento del modo predeterminado y la configuración de recursos individuales invalida los valores preestablecidos. Por ejemplo, si el valor de max_concurrent_runs para un trabajo es 10, pero el jobs_max_concurrent_runs está configurado en 20, el número máximo de ejecuciones simultáneas del trabajo es 10.

Preajuste	Descripción
artifacts_dynamic_version	Si se va a actualizar dinámicamente la versión de los artefactos whl durante la implementación. Los valores válidos son true y false. Si se especifica el valor de configuración de artifacts.dynamic_version de nivel superior, invalida este valor preestablecido.
jobs_max_concurrent_runs	Número máximo de ejecuciones simultáneas permitido para los trabajos.
name_prefix	Cadena de prefijo que se va a anteponer a los nombres de recursos.
pipelines_development	Si la canalización está o no en modo de desarrollo. Los valores válidos son true y false.
source_linked_deployment	Reservado para uso futuro. Si los recursos creados durante la implementación apuntan a archivos de origen en el área de trabajo en vez de sus copias dentro del área de trabajo.
tags	Conjunto de etiquetas key:value que se aplican a todos los recursos que admiten etiquetas, que incluyen trabajos y experimentos. Los conjuntos de recursos de Databricks no admiten etiquetas para el schema recurso.
trigger_pause_status	Estado de pausa que se aplicará a todos los desencadenadores y programaciones. Los valores válidos son PAUSED y UNPAUSED. Si mode se establece en development, trigger_pause_status siempre es PAUSED.

En el ejemplo siguiente se muestra una configuración de valores preestablecidos personalizada para el destino denominado dev:

targets:
  dev:
    presets:
      name_prefix: 'testing_' # prefix all resource names with testing_
      pipelines_development: true # set development to true for pipelines
      trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
      jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
      tags:
        department: finance