Partilhar via

Modos de implantação do Databricks Asset Bundle

  • Artigo

Este artigo descreve a sintaxe para os modos de implantação do Databricks Asset Bundle . Os pacotes permitem o gerenciamento programático de fluxos de trabalho do Azure Databricks. Consulte O que são Databricks Asset Bundles?

Em fluxos de trabalho de CI/CD, os desenvolvedores normalmente codificam, testam, implantam e executam soluções em várias fases ou modos. Por exemplo, o conjunto mais simples de modos inclui um modo de desenvolvimento para validação de pré-produção, seguido por um modo de produção para resultados validados. O Databricks Asset Bundles fornece uma coleção opcional de comportamentos padrão que correspondem a cada um desses modos. Para usar esses comportamentos para um destino específico, defina um mode ou configure presets para um destino no mapeamento de configuração targets. Para obter informações sobre targets, consulte o mapeamento de alvos de configuração de pacotes.

Modo de desenvolvimento

Para implantar seu pacote no modo de desenvolvimento, você deve primeiro adicionar o mapeamento de mode, definido como development, ao destino pretendido. Por exemplo, esse destino nomeado dev é tratado como um destino de desenvolvimento:

targets:
  dev:
    mode: development

A implantação de um destino no modo de desenvolvimento executando o databricks bundle deploy -t <target-name> comando implementa os seguintes comportamentos, que podem ser personalizados usando predefinições:

  • Antecipe todos os recursos que não são implantados como ficheiros ou notebooks com o prefixo [dev ${workspace.current_user.short_name}] e marque cada tarefa e pipeline implantados com uma etiqueta dev do Azure Databricks.
  • Marca todos os pipelines DLT implantados relacionados como development: true.
  • Permite o uso de --compute-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, que substitui quaisquer definições de cluster existentes já especificadas no ficheiro de configuração do pacote relacionado. Em vez de usar --compute-id <cluster-id> em chamadas relacionadas ao comando bundle deploy, você pode definir o mapeamento de compute_id aqui, ou como um mapeamento filho do mapeamento de bundle, para a ID do cluster a ser usado.
  • Pausa todos os agendamentos e disparadores em recursos implementados, como trabalhos ou monitores de qualidade. Retome as agendas e gatilhos para uma tarefa individual definindo schedule.pause_status como UNPAUSED.
  • Permite execuções simultâneas em todos os trabalhos implantados para uma iteração mais rápida. Desative as execuções simultâneas para um trabalho individual definindo max_concurrent_runs como 1.
  • Desativa o bloqueio de implantação para iteração mais rápida. Esse bloqueio evita conflitos de implantação que provavelmente não ocorrerão no modo de desenvolvimento. Reative o bloqueio definindo bundle.deployment.lock.enabled como true.

Modo de produção

Para implantar o seu pacote no modo de produção, deve primeiro adicionar o mapeamento mode, definido como production, ao destino pretendido. Por exemplo, esse destino nomeado prod é tratado como um destino de produção:

targets:
  prod:
    mode: production

A implantação de um destino no modo de produção executando o databricks bundle deploy -t <target-name> comando implementa os seguintes comportamentos:

  • Valida que todos os pipelines DLT implantados relacionados estejam marcados como development: false.

  • Valida se a ramificação atual do Git é igual à ramificação do Git especificada no destino. A especificação de uma ramificação Git no destino é opcional e pode ser feita com uma propriedade adicional git da seguinte maneira:

    git:
  branch: main

    Essa validação pode ser substituída especificando --force durante a implantação.

  • O Databricks recomenda que você use entidades de serviço para implantações de produção. Você pode impor isso configurando run_as como um principal de serviço. Consulte Gerenciar entidades de serviço e Especificar uma identidade de execução para um fluxo de trabalho do Databricks Asset Bundles. Se não forem utilizados principais de serviço, observe os seguintes comportamentos adicionais:

    • Valida que artifact_path, file_path, root_pathou state_path mapeamentos não são substituídos para um usuário específico.
    • Valida que os mapeamentos run_as e permissions são especificados para esclarecer quais identidades têm permissões específicas para implantações.

  • Ao contrário do comportamento anterior para definir o mode mapeamento como development, definir o mode mapeamento como production não permite substituir quaisquer definições de cluster existentes especificadas no arquivo de configuração de pacote relacionado, por exemplo, usando a --compute-id <cluster-id> opção ou o compute_id mapeamento.

Predefinições personalizadas

O Databricks Asset Bundles suporta predefinições configuráveis para destinos, o que permite personalizar os comportamentos para destinos. As predefinições disponíveis estão listadas na tabela a seguir:

Predefinição Descrição
name_prefix A cadeia de caracteres de prefixo a ser anexada aos nomes de recursos.
pipelines_development Se o pipeline está ou não no modo de desenvolvimento. Os valores válidos são true ou false.
trigger_pause_status Um status de pausa para aplicar a todos os gatilhos e agendas. Os valores válidos são PAUSED ou UNPAUSED.
jobs_max_concurrent_runs O número de execuções simultâneas máximo permitido para tarefas.
tags Um conjunto de etiquetas chave:valor que se aplica a todos os recursos que aceitam etiquetas, incluindo trabalhos e experiências. Os pacotes de ativos Databricks não suportam tags para o schema recurso.
source_linked_deployment Reservado para uso futuro. Se os recursos criados durante a implantação apontam ou não para os arquivos de origem no espaço de trabalho em vez de suas cópias do espaço de trabalho.

Nota

Se mode e presets estiverem definidas, as predefinições substituirão o comportamento do modo padrão e as configurações de recursos individuais substituirão as predefinições. Por exemplo, se uma agenda estiver definida como UNPAUSED, mas a predefinição de trigger_pause_status estiver definida como PAUSED, a agenda não será pausada.

O exemplo a seguir mostra uma configuração de predefinições personalizada para o destino chamado 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