Melhores práticas e recomendações CI/CD fluxo de trabalho on Databricks

CI/CD (integração contínua (CI) e entrega contínua (CD)) tornou-se a pedra angular da moderna engenharia e análise de dados, pois garante que as alterações de código sejam integradas, testadas e implantadas de forma rápida e confiável. Databricks reconhece que o senhor pode ter diversos requisitos CI/CD moldados por suas preferências organizacionais, fluxo de trabalho existente e ambiente tecnológico específico, e oferece uma estrutura flexível que suporta várias opções CI/CD.

Esta página descreve as práticas recomendadas para ajudá-lo a projetar e criar um pipeline CI/CD robusto e personalizado que se alinhe às suas necessidades e restrições exclusivas. Ao aproveitar essas percepções, o senhor pode acelerar suas iniciativas de engenharia e análise de dados, melhorar a qualidade do código e reduzir o risco de falhas na implantação.

Princípios fundamentais do CI/CD

O pipeline eficaz CI/CD compartilha princípios fundamentais, independentemente das especificidades da implementação. As práticas recomendadas universais a seguir se aplicam a todas as preferências organizacionais, ao fluxo de trabalho do desenvolvedor e aos ambientes de nuvem, e garantem a consistência em diversas implementações, independentemente de sua equipe priorizar o desenvolvimento com base no notebook ou no Infrastructure-as-Code fluxo de trabalho. Adote esses princípios como diretrizes e, ao mesmo tempo, adapte as especificidades à pilha tecnológica e aos processos de sua organização.

Controle tudo de versão
- Armazene o Notebook, os scripts, as definições de infraestrutura (IaC) e as configurações de trabalho em Git.
- Use estratégias de ramificação, como o Gitflow, que estejam alinhadas aos ambientes padrão de desenvolvimento, preparação e implantação de produção.
Automatize os testes
- Implemente testes de unidade para lógica de negócios usando biblioteca, como pytest para Python e ScalaTest para Scala.
- Valide a funcionalidade do Notebook e do fluxo de trabalho com ferramentas, como Databricks CLI bundle validate.
- Use testes de integração para fluxo de trabalho e pipeline de dados, como o chispa para Spark DataFrames.
Empregar a infraestrutura como código (IaC)
- Defina as configurações de clustering, Job e workspace com Databricks ativo Bundles YAML ou Terraform.
- Parametrize em vez de codificar configurações específicas do ambiente, como tamanho do agrupamento e segredos.
Isole ambientes
- Manter espaços de trabalho separados para desenvolvimento, preparação e produção.
- Use o MLflow Model Registry para o controle de versão do modelo entre ambientes.
Escolha ferramentas que correspondam ao seu ecossistema de nuvem:
- Azure: Azure DevOps e Databricks ativo Bundles ou Terraform.
- AWS: GitHub Actions e Databricks ativo Bundles ou Terraform.
- GCP: Cloud Build e Databricks ativo Bundles ou Terraform.
Monitore e automatize reversões
- Acompanhe as taxas de sucesso da implantação, o desempenho dos trabalhos e a cobertura dos testes.
- Implemente mecanismos de reversão automatizados para implantações com falha.
Unificar o gerenciamento ativo
- Use Databricks ativo Bundles para implantar código, trabalho e infraestrutura como uma única unidade. Evite o gerenciamento em silos do Notebook, da biblioteca e do fluxo de trabalho.

nota

A Databricks recomenda a federação de identidade de carga de trabalho para autenticação de CI/CD. A federação de identidade de carga de trabalho elimina a necessidade de segredos da Databricks, o que a torna a maneira mais segura de autenticar seus fluxos automatizados para a Databricks. Consulte Habilitar federação de identidade de carga de trabalho em CI/CD.

Databricks Pacotes ativos para CI/CD

Databricks Os pacotes ativos oferecem uma abordagem avançada e unificada para gerenciar código, fluxo de trabalho e infraestrutura no ecossistema Databricks e são recomendados para seu pipeline CI/CD. Ao agrupar esses elementos em uma única unidade definida pelo YAML, os pacotes simplificam a implantação e garantem a consistência em todos os ambientes. No entanto, para os usuários acostumados com o tradicional CI/CD fluxo de trabalho, a adoção de pacotes pode exigir uma mudança de mentalidade.

Por exemplo, os desenvolvedores do Java estão acostumados a criar JARs com o Maven ou o Gradle, a executar testes de unidade com o JUnit e a integrar essas etapas no pipeline do CI/CD. Da mesma forma, os desenvolvedores do Python costumam empacotar o código em rodas e testar com o pytest, enquanto os desenvolvedores do SQL se concentram na validação da consulta e no gerenciamento do Notebook. Com os pacotes, esses fluxos de trabalho convergem para um formato mais estruturado e prescritivo, enfatizando o agrupamento de código e infraestrutura para uma implementação perfeita.

As seções a seguir exploram como os desenvolvedores podem adaptar seu fluxo de trabalho para aproveitar os pacotes de forma eficaz.

Para começar a trabalhar rapidamente com Databricks ativo Bundles, experimente tutorial: Desenvolver um trabalho com Databricks ativo Bundles ou Desenvolver LakeFlow pipeline declarativo com Databricks ativo Bundles.

Recomendações de controle de origem CI/CD

A primeira escolha que os desenvolvedores precisam fazer ao implementar a CI/CD é como armazenar e versionar os arquivos de origem. Os pacotes permitem que você contenha facilmente tudo — código-fonte, artefatos de construção e arquivos de configuração — e os localize no mesmo repositório de código-fonte, mas outra opção é separar os arquivos de configuração do pacote dos arquivos relacionados ao código. A escolha depende do fluxo de trabalho da sua equipe, da complexidade do projeto e dos requisitos de CI/CD, mas a Databricks recomenda o seguinte:

Em projetos pequenos ou com forte acoplamento entre o código e a configuração, use um único repositório para o código e a configuração do pacote para simplificar o fluxo de trabalho.
Para equipes maiores ou ciclos de lançamento independentes, use repositórios separados para código e configuração de pacotes, mas estabeleça um pipeline CI/CD claro que garanta a compatibilidade entre as versões.

Independentemente de optar por co-localizar ou separar os arquivos relacionados ao código dos arquivos de configuração do pacote, sempre use artefatos com versão, como hashes Git commit , ao fazer upload para Databricks ou armazenamento externo para garantir a rastreabilidade e os recursos de reversão.

Repositório único para código e configuração

Nessa abordagem, tanto o código-fonte quanto os arquivos de configuração do pacote são armazenados no mesmo repositório. Isso simplifica o fluxo de trabalho e garante mudanças atômicas.

Prós	Contras
Todos os artefatos, códigos e configurações YAML relacionados são versionados juntos, o que reduz a sobrecarga de coordenação. Uma única solicitação pull pode atualizar o arquivo de compilação compilado e a configuração do pacote correspondente. O CI/CD pipeline pode criar, testar, validar e implantar a partir de um único repositório.	Com o tempo, o repositório pode ficar cheio de códigos e arquivos de configuração. Mudanças no código e no pacote exigem uma versão coordenada.

Exemplo: Código Python em um pacote

Este exemplo tem arquivos Python e arquivos de pacote em um único repositório:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── workflows/
│   │   ├── my_pipeline.yml      # YAML pipeline def
│   │   └── my_pipeline_job.yml  # YAML job def that runs pipeline
│   ├── clusters/
│   │   ├── dev_cluster.yml      # development cluster def
│   │   └── prod_cluster.yml     # production def
├── src/
│   ├── my_pipeline.ipynb       # pipeline notebook
│   └── mypython.py              # Additional Python
└── README.md

Repositórios separados para código e configuração

Nessa abordagem, o código-fonte reside em um repositório, enquanto os arquivos de configuração do pacote são mantidos em outro. Essa opção é ideal para equipes ou projetos maiores em que grupos separados lidam com o desenvolvimento de aplicativos e o gerenciamento do fluxo de trabalho do Databricks.

Prós	Contras
As equipes que trabalham no desenvolvimento de código podem se concentrar em seu repositório, enquanto a equipe de engenharia de dados gerencia as configurações do pacote. Permite atualizações de versões independentes e controle de versão para o código compilado, como JAR, e configurações de pacotes sem acoplá-los. Cada repositório é menor e mais fácil de gerenciar.	Requer coordenação adicional entre os repositórios durante a implantação. O senhor deve garantir que a versão correta das dependências, como a versão JAR, seja referenciada no repositório de pacotes.

Exemplo: Projeto e pacote Java

Neste exemplo, um projeto Java e seus arquivos estão em um repositório e os arquivos do pacote estão em outro repositório.

Repositório 1: arquivos Java

O primeiro repositório contém todos os arquivos relacionados ao Java:

java-app-repo/
├── pom.xml                  # Maven build configuration
├── src/
│   ├── main/
│   │   ├── java/            # Java source code
│   │   │   └── com/
│   │   │       └── mycompany/
│   │   │           └── app/
│   │   │               └── App.java
│   │   └── resources/       # Application resources
│   └── test/
│       ├── java/            # Unit tests for Java code
│       │   └── com/
│       │       └── mycompany/
│       │           └── app/
│       │               └── AppTest.java
│       └── resources/       # Test-specific resources
├── target/                  # Compiled JARs and classes
└── README.md

Os desenvolvedores escrevem o código do aplicativo em src/main/java ou src/main/scala.
Os testes unitários são armazenados em src/test/java ou src/test/scala.
Em uma solicitação pull ou commit, CI/CD pipeline:
- Compile o código em um JAR, por exemplo, target/my-app-1.0.jar.
- Faça upload do JAR para um volume Databricks Unity Catalog . Veja upload JAR.

Repositório 2: Agrupar arquivos

Um segundo repositório contém somente os arquivos de configuração do pacote:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── jobs/
│   │   ├── my_java_job.yml  # YAML job dev
│   │   └── my_other_job.yml # Additional job definitions
│   ├── clusters/
│   │   ├── dev_cluster.yml  # development cluster def
│   │   └── prod_cluster.yml # production def
└── README.md

A configuração do pacote databricks.yml e as definições de trabalho são mantidas de forma independente.
O databricks.yml faz referência ao artefato de upload JAR, por exemplo:
YAML
```
- jar: /Volumes/artifacts/my-app-${{ GIT_SHA }}.)jar
```

CI/CD para aprendizado de máquina

Os projetos de aprendizado de máquina apresentam desafios únicos de CI/CD em comparação com o desenvolvimento tradicional de software. Ao implementar CI/CD para projetos de ML, o senhor provavelmente precisará considerar o seguinte:

Coordenação de várias equipes: data scientists As equipes de engenheiros e MLOps geralmente usam ferramentas e fluxos de trabalho diferentes. Databricks Unifica esses processos com MLflow para acompanhamento de experimentos, Delta Sharing para governança de dados e Databricks ativo Bundles para Infrastructure-as-Code.
Versões de dados e modelos: o pipeline ML exige o acompanhamento não apenas do código, mas também de esquemas de dados de treinamento, distribuições de recursos e artefatos de modelos. Databricks Delta O Lake fornece transações ACID e viagem do tempo para controle de versão de dados, enquanto o MLflow Model Registry lida com a linhagem do modelo.
Reprodutibilidade entre ambientes: Os modelos de ML dependem de combinações específicas de dados, código e infraestrutura. Databricks Os ativo Bundles garantem a implantação atômica desses componentes em ambientes de desenvolvimento, preparação e produção com definições YAML.
Treinamento contínuo e monitoramento: os modelos se deterioram devido à variação dos dados. LakeFlow As tarefas permitem um pipeline de reciclagem automatizado, enquanto o MLflow se integra ao Prometheus e ao monitoramento do lakehouse para acompanhamento do desempenho.

Pilhas de MLOps para CI/CD de ML

Databricks aborda a complexidade do ML CI/CD por meio do MLOps Stacks, uma estrutura de nível de produção que combina Databricks pacotes ativos, fluxo de trabalho pré-configurado CI/CD e padrão de projeto modular ML. Essas pilhas aplicam as práticas recomendadas e, ao mesmo tempo, permitem flexibilidade para a colaboração de várias equipes nas funções de engenharia de dados, ciência de dados e MLOps.

Equipe	Responsabilidades	Exemplos de componentes do pacote	Exemplos de artefatos
engenheiro de dados	Crie o pipeline ETL, reforce a qualidade dos dados	LakeFlow Pipeline declarativo YAML, política de cluster	`etl_pipeline.yml`, `feature_store_job.yml`
data scientists	Desenvolver a lógica de treinamento do modelo, validar as métricas	MLflow Projetos, fluxo de trabalho baseado em notebook	`train_model.yml`, `batch_inference_job.yml`
Engenheiros de MLOps	Orquestrar implementações, monitorar o pipeline	variável de ambiente, monitoramento de dashboards	`databricks.yml`, `lakehouse_monitoring.yml`

A colaboração ML CI/CD pode ser semelhante:

engenheiro de dados commit ETL pipeline alterações em um pacote, acionando a validação automatizada do esquema e uma implantação de teste.
data scientists enviar o código ML, que executa testes de unidade e é implantado em um workspace de preparação para testes de integração.
Os engenheiros de MLOps analisam as métricas de validação e promovem modelos aprovados para produção usando o MLflow Registry.

Para obter detalhes da implementação, consulte:

Pacote MLOps Stacks: Orientação passo a passo para inicialização e implementação do pacote.
MLOps Repositório Stacks GitHub: Padrão pré-configurado para treinamento, inferência e CI/CD.

Ao alinhar as equipes com pacotes padronizados e pilhas de MLOps, as organizações podem simplificar a colaboração e, ao mesmo tempo, manter a capacidade de auditoria em todo o ciclo de vida do ML.

CI/CD para desenvolvedores de SQL

SQL Os desenvolvedores que utilizam o site Databricks SQL para gerenciar tabelas de transmissão e visualizações materializadas podem aproveitar a integração Git e o pipeline CI/CD para agilizar seu fluxo de trabalho e manter um pipeline de alta qualidade. Com a introdução do suporte do Git para consultas, os desenvolvedores de SQL podem se concentrar em escrever consultas e, ao mesmo tempo, aproveitar o Git para controlar a versão de seus arquivos .sql, o que permite a colaboração e a automação sem a necessidade de um profundo conhecimento de infraestrutura. Além disso, o editor SQL permite a colaboração em tempo real e se integra perfeitamente ao Git fluxo de trabalho.

Para fluxo de trabalho centrado em SQL:

Controle de versão de arquivos SQL
- Armazenar .sql arquivos em repositórios Git usando pastas Git da Databricks ou provedores Git externos, por exemplo, GitHub, Azure DevOps.
- Use ramificações (por exemplo, desenvolvimento, preparação, produção) para gerenciar alterações específicas do ambiente.
Integre os arquivos .sql ao pipeline CI/CD para automatizar a implementação:
- Valide as alterações de sintaxe e esquema durante solicitações pull.
- implantado .sql arquivos para Databricks SQL fluxo de trabalho ou Job.
Parametrize para isolamento do ambiente
- Use variáveis nos arquivos .sql para fazer referência dinâmica a recursos específicos do ambiente, como caminhos de dados ou nomes de tabelas:
  SQL
```
CREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
```
atualização de programa e monitor
- Use a tarefa SQL em um Databricks Job para programar atualizações em tabelas e visualizações materializadas (REFRESH MATERIALIZED VIEW view_name).
- Monitorar refresh história usando tabelas do sistema.

Um fluxo de trabalho pode ser:

Desenvolva: Escreva e teste .sql scripts localmente ou no editor Databricks SQL e, em seguida, commit -os em uma ramificação Git.
Validar: durante uma pull request, valide a compatibilidade de sintaxe e esquema usando verificações automatizadas de CI.
implantado: Em merge, implantado o .sql scripts para o ambiente de destino usando o pipeline CI/CD, por exemplo, o pipeline GitHub Actions ou Azure.
Monitore: Use os painéis e alertas do site Databricks para monitorar o desempenho das consultas e a atualização dos dados.

CI/CD para desenvolvedores de painéis

Databricks suporta a integração de dashboards em CI/CD fluxo de trabalho usando Databricks ativo Bundles. Esse recurso permite que os desenvolvedores de painéis:

Painéis de controle de versão, que garantem auditabilidade e simplificam a colaboração entre equipes.
Automatize as implementações de dashboards juntamente com o Job e o pipeline em todos os ambientes, para alinhamento de ponta a ponta.
Reduza os erros manuais e garanta que as atualizações sejam aplicadas de forma consistente em todos os ambientes.
Manter um fluxo de trabalho analítico de alta qualidade e aderir às práticas recomendadas do site CI/CD.

Para painéis de controle em CI/CD:

Use o comando databricks bundle generate para exportar painéis existentes como arquivos JSON e gerar a configuração YAML que os inclui no pacote:

YAML
resources:
  dashboards:
    sales_dashboard:
      display_name: 'Sales Dashboard'
      file_path: ./dashboards/sales_dashboard.lvdash.json
      warehouse_id: ${var.warehouse_id}

Armazene esses arquivos .lvdash.json em repositórios Git para acompanhar as alterações e colaborar de forma eficaz.
Painéis implantados automaticamente no pipeline CI/CD com databricks bundle deploy. Por exemplo, a etapa GitHub Actions para implantação:
YAML
```
name: Deploy Dashboard
  run: databricks bundle deploy --target=prod
env:
  DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
```
Use variáveis, por exemplo, ${var.warehouse_id}, para parametrizar configurações como SQL warehouse ou fonte de dados, garantindo uma implementação perfeita em ambientes de desenvolvimento, preparação e produção.
Use a opção bundle generate --watch para sincronizar continuamente os arquivos JSON do painel local com as alterações feitas na interface do usuário do Databricks. Se ocorrerem discrepâncias, use o sinalizador --force durante a implantação para substituir painéis remotos por versões locais.

Para obter informações sobre dashboards em pacotes, consulte recurso de dashboard. Para obter detalhes sobre o comando do pacote, consulte bundle comando group.

Princípios fundamentais do CI/CD​

Databricks Pacotes ativos para CI/CD​

Recomendações de controle de origem CI/CD​

Repositório único para código e configuração​

Exemplo: Código Python em um pacote​

Repositórios separados para código e configuração​

Exemplo: Projeto e pacote Java​

Recomendado CI/CD fluxo de trabalho​

CI/CD para aprendizado de máquina​

Pilhas de MLOps para CI/CD de ML​

CI/CD para desenvolvedores de SQL​

CI/CD para desenvolvedores de painéis​