Perguntas frequentes sobre pacotes de automação declarativa

Este artigo lista perguntas frequentes sobre os Declarative Automation Bundles (anteriormente conhecidos como Databricks Ativo Bundles).

Por que Databricks Ativo Bundles foi renomeado para Declarative Automation Bundles?

O novo nome, Declarative Automation Bundles, reflete com mais precisão o uso e as capacidades dos pacotes. Além disso, o termo ativo causou alguma confusão, pois possui mais de um significado no Databricks. Essa mudança de nome não altera a situação. O comando CLI bundle e toda a sua configuração existente não precisam ser modificados.

Como faço para usar os Declarative Automation Bundles como parte do meu pipeline de CI/CD no Databricks?

Você pode usar os Pacotes de Automação Declarativa para definir e gerenciar programaticamente funcionalidades ativas em sua implementação CI/CD Databricks , que geralmente incluem:

• Notebook : Databricks Notebook costuma ser uma parte key da engenharia de dados e da ciência de fluxo de trabalho de dados. Você pode usar o controle de versão para o Notebook e também validá-lo e testá-lo como parte de um pipeline CI/CD . Você pode executar testes automatizados no Notebook para verificar se eles estão funcionando conforme o esperado.
• biblioteca : gerencia as dependências da biblioteca necessárias para execução do código implantado. Use o controle de versão em bibliotecas e inclua-as em testes e validações automatizados.
• fluxo de trabalho : LakeFlow Jobs são compostos por Job que permitem programar e executar tarefas automatizadas usando Notebook ou Spark Job.
• pipeline de dados : você também pode incluir pipeline de dados na automação de CI/CD , usando LakeFlow Spark Declarative pipeline, a estrutura no Databricks para declarar pipeline de dados.
• Infraestrutura : A configuração da infraestrutura inclui definições e provisionamento de informações para clusters, espaço de trabalho e armazenamento para ambientes de destino. As mudanças na infraestrutura podem ser validadas e testadas como parte de um pipeline de CI/CD, garantindo que sejam consistentes e livres de erros.

Por que preciso ter ambientes-alvo de desenvolvimento e produção separados?

Ambientes separados de desenvolvimento e produção permitem que você:

• Isole com segurança as mudanças de desenvolvimento para que elas não afetem acidentalmente a produção.
• Evite a duplicação de código personalizando o recurso para aplicá-lo a um ambiente de destino específico.
• Agilize e simplifique a CI/CD com configuração específica do ambiente, como caminhos de banco de dados, alertas e controles de acesso.
• Reutilizar o fluxo de trabalho entre equipes e ambientes.

Use alvos para definir ambientes de implantação de pacotes. Veja os alvos.

Como faço para tornar meus pacotes consistentes em toda a minha organização?

Utilize padrões de pacote para uma estrutura consistente, para reduzir erros de configuração e para promover as melhores práticas. Você pode usar o pacote default ou criar seu próprio pacote personalizado. Consulte o projeto Padrão de Pacotes de Automação Declarativa.

Há muita repetição em meus pacotes, como as mesmas definições de clustering. Qual é a melhor maneira de lidar com isso?

Variáveis personalizadas são a melhor maneira de lidar com repetições, bem como configurações específicas do contexto. Consulte Variáveis personalizadas.

Quais são algumas das melhores práticas ao usar pacotes no meu fluxo de implantação?

A Databricks recomenda que você:

• Mudança de implantação manual para automação confiável usando o fluxo de trabalho integrado Git.
• Valide antes de implantar um pacote usando databricks bundle validate em seu CI/CD pipeline.
• Etapas de implantação separadas para garantir que as mudanças sejam revisadas e intencionais.
• Parametrize ambientes (dev, staging, prod) com substituições para isolar as mudanças.
• executar testes de integração pós-implantados para detectar problemas antecipadamente.
• Use GitHub Actions, Azure DevOps, ou GitLab CI para acionar o implantado em commit ou PR merge.
• Rastreie o que foi implantado, onde e quando, para que cada implantado seja mapeado para uma versão do commit e do pacote.

Posso transferir o trabalho, o pipeline, os painéis e outros objetos existentes do Databricks para o meu pacote?

Sim. Use o comando databricks bundle generate para gerar um arquivo de configuração para um Job, pipeline ou painel existente em seu pacote local e, em seguida, use databricks bundle deployment bind para vincular o recurso do pacote ao recurso correspondente no workspace. Isso é ideal para integrar o fluxo de trabalho existente ao desenvolvimento estruturado e com controle de versão. A vinculação também resolve caminhos relativos para referências workspace absolutas, o que evita erros de caminho.

Consulte Migrar recurso existente para um pacote.

Como faço para testar meu pacote iterativamente?

O senhor pode desenvolver mais rapidamente com implantação e execução iterativas:

• Validar antes de ser implantado
• implantado de forma incremental
• execução apenas do que é necessário
• Edite e repita

Isso acelera os testes e a depuração, reduz a troca de contexto, permite uma iteração mais segura e rápida sem reimplantações completas e impõe disciplina à medida que o senhor avança para a produção.