Práticas recomendadas e fluxos de trabalho de CI/CD recomendados no Databricks

A CI/CD (Integração Contínua e Entrega Contínua) tornou-se uma base da engenharia e análise de dados modernas, pois garante que as alterações de código sejam integradas, testadas e implantadas de forma rápida e confiável. O Databricks reconhece que você pode ter diversos requisitos de CI/CD moldado por suas preferências organizacionais, fluxos de trabalho existentes e ambiente de tecnologia específico e fornece uma estrutura flexível que dá suporte a várias opções de CI/CD.

Esta página descreve as práticas recomendadas para ajudá-lo a criar pipelines de CI/CD robustos e personalizados que se alinham às suas necessidades e restrições exclusivas. Aproveitando esses insights, você pode acelerar suas iniciativas de engenharia e análise de dados, melhorar a qualidade do código e reduzir o risco de falhas de implantação.

Princípios fundamentais de CI/CD

Pipelines de CI/CD eficazes compartilham princípios fundamentais, independentemente das especificidades da implementação. As práticas recomendadas universais a seguir se aplicam entre preferências organizacionais, fluxos de trabalho de desenvolvedores e ambientes de nuvem e garantem consistência em diversas implementações, independentemente de sua equipe priorizar fluxos de trabalho de desenvolvimento de notebook ou infraestrutura como código. Adote esses princípios como diretrizes enquanto adapta as especificidades para o conjunto de ferramentas tecnológicas e os processos da sua organização.

• Controle de versão de tudo
  • Armazene notebooks, scripts, iac (definições de infraestrutura) e configurações de trabalho no Git.
  • Use estratégias de ramificação, como o Gitflow, alinhadas com ambientes padrão de desenvolvimento, preparo e implantação de produção.
• Automatizar o teste
  • Implemente testes de unidade para lógica de negócios usando bibliotecas, como pytest para Python e ScalaTest para Scala.
  • Valide a funcionalidade do notebook e do fluxo de trabalho com ferramentas, como o comando bundle validate da CLI do Databricks.
  • Use testes de integração para fluxos de trabalho e pipelines de dados, como chispa para DataFrames do Spark.
• Empregar a Infraestrutura como Código (IaC)
  • Defina clusters, tarefas e configurações de workspace com Bundles de Ativos Databricks YAML ou Terraform.
  • Parametrizar em vez de codificar configurações específicas do ambiente, como tamanho do cluster e informações confidenciais.
• Isolar ambientes
  • Mantenha espaços de trabalho separados para desenvolvimento, preparo e produção.
  • Use o Registro de Modelo do MLflow para controle de versão de modelo entre ambientes.
• Escolha ferramentas que correspondam ao ecossistema de nuvem:
  • Azure: Azure DevOps e Pacotes de Ativos do Databricks ou Terraform.
  • AWS: GitHub Actions e Pacotes de Ativos do Databricks ou Terraform.
  • GCP: Compilação na Nuvem e Pacotes de Ativos do Databricks ou Terraform.
• Monitorar e automatizar reversões
  • Acompanhe as taxas de êxito da implantação, o desempenho do trabalho e a cobertura de teste.
  • Implemente mecanismos de reversão automatizados para implantações com falha.
• Unificar o gerenciamento de ativos
  • Use os Pacotes de Ativos do Databricks para implantar código, trabalhos e infraestrutura como uma única unidade. Evite o gerenciamento isolado de notebooks, bibliotecas e fluxos de trabalho.

Pacotes de Ativos do Databricks para CI/CD

Os Pacotes de Ativos do Databricks oferecem uma abordagem avançada e unificada para gerenciar código, fluxos de trabalho e infraestrutura dentro do ecossistema do Databricks e são recomendados para seus pipelines de CI/CD. Agrupando esses elementos em uma única unidade definida por YAML, os pacotes simplificam a implantação e garantem a consistência entre ambientes. No entanto, para usuários acostumados com fluxos de trabalho de CI/CD tradicionais, a adoção de pacotes pode exigir uma mudança de mentalidade.

Por exemplo, os desenvolvedores Java são usados para criar JARs com Maven ou Gradle, executar testes de unidade com JUnit e integrar essas etapas em pipelines de CI/CD. Da mesma forma, os desenvolvedores Python geralmente empacotam o código em rodas e testam com pytest, enquanto os desenvolvedores SQL se concentram na validação de consultas e no gerenciamento de notebooks. Com os pacotes, esses fluxos de trabalho convergem para um formato mais estruturado e prescritivo, enfatizando o agrupamento de código e a infraestrutura para implantação perfeita.

As seções a seguir exploram como os desenvolvedores podem adaptar seus fluxos de trabalho para aproveitar os pacotes com eficiência.

Para começar rapidamente com os Pacotes de Ativos do Databricks, experimente um tutorial: Desenvolver um Trabalho com Pacotes de Ativos do Databricks ou Desenvolver Pipelines Declarativos do Spark do Lakeflow com Pacotes de Ativos do Databricks.

Recomendações de controle do código-fonte para CI/CD

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

• Para projetos pequenos ou acoplamento apertado entre código e configuração, use um único repositório para configuração de código e pacote para simplificar fluxos de trabalho.
• Para equipes maiores ou ciclos de versão independentes, use repositórios separados para configuração de código e pacote, mas estabeleça pipelines claros de CI/CD que garantam a compatibilidade entre as versões.

Independentemente de você escolher por localizar ou separar seus arquivos relacionados ao código dos arquivos de configuração do pacote, sempre use artefatos versionados, como hashes de commit do Git, ao fazer upload para o Databricks ou armazenamento externo para garantir a rastreabilidade e as funcionalidades de reversão.

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

Nessa abordagem, os arquivos de configuração do código-fonte e do pacote são armazenados no mesmo repositório. Isso simplifica os fluxos de trabalho e garante alterações atômicas.

Exemplo: código python em um pacote

Este exemplo tem arquivos Python e arquivos de pacote em um 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 maiores ou projetos em que grupos separados lidam com o desenvolvimento de aplicativos e o gerenciamento de fluxo de trabalho do Databricks.

Exemplo: projeto e pacote java

Neste exemplo, um projeto Java e seus arquivos estão em um repositório e os arquivos de 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 gravam código do aplicativo em src/main/java ou src/main/scala.
• Os testes de unidade são armazenados em src/test/java ou src/test/scala.
• Em um pull request ou confirmação, os pipelines de CI/CD:
  • Compile o código em um JAR, por exemplo, target/my-app-1.0.jar.
  • Carregue o JAR em um volume do Databricks Unity Catalog. Veja upload JAR.

Repositório 2: Arquivos de pacote

Um segundo repositório contém apenas 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 independentemente.

• O databricks.yml faz referência ao artefato JAR carregado, por exemplo:

  - jar: /Volumes/artifacts/my-app-${{ GIT_SHA }}.)jar
  

Fluxo de trabalho de CI/CD recomendado

Independentemente de você estar localizando ou separando seus arquivos de código dos arquivos de configuração do pacote, um fluxo de trabalho recomendado seria o seguinte:

1. Compilar e testar o código

   • Disparado por um pull request ou uma confirmação na ramificação principal.
   • Compile o código e execute testes de unidade.
   • Gerar um arquivo versionado, por exemplo, my-app-1.0.jar.

2. Carregue e armazene o arquivo compilado, como um JAR, em um volume do Catálogo do Databricks Unity.

   • Armazene o arquivo compilado em um volume do Catálogo do Databricks Unity ou em um repositório de artefatos como o AWS S3 ou o Armazenamento de Blobs do Azure.
   • Use um esquema de controle de versão vinculado a hashes de confirmação do Git ou controle de versão semântico, por exemplo, dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.

3. Validar o pacote

   • Execute databricks bundle validate para garantir que a databricks.yml configuração esteja correta.
   • Esta etapa garante que configurações incorretas, por exemplo, bibliotecas ausentes, sejam capturadas antecipadamente.

4. Implantar o pacote

   • Use databricks bundle deploy para implantar o pacote em um ambiente de preparo ou produção.
   • Referencie a biblioteca compilada carregada em databricks.yml. Para obter informações sobre como referenciar bibliotecas, consulte dependências de bibliotecas para Pacotes de Ativos do Databricks.

CI/CD para aprendizado de máquina

Os projetos de machine learning introduzem desafios exclusivos de CI/CD em comparação com o desenvolvimento de software tradicional. Ao implementar CI/CD para projetos de ML, você provavelmente precisará considerar o seguinte:

• Coordenação de várias equipes: cientistas de dados, engenheiros e equipes de MLOps geralmente usam diferentes ferramentas e fluxos de trabalho. O Databricks unifica esses processos com o MLflow para acompanhamento de experimentos, Compartilhamento Delta para governança de dados e Pacotes de Ativos do Databricks para infraestrutura como código.
• Controle de versão de dados e modelos: pipelines de ML exigem o acompanhamento não apenas do código, mas também dos esquemas de dados de treinamento, distribuições de recursos e artefatos de modelo. O Databricks Delta Lake oferece transações ACID e viagem no tempo para controle de versão de dados, enquanto o Registro de Modelos do MLflow gerencia a linhagem de modelos.
• Reprodutibilidade entre ambientes: os modelos de ML dependem de combinações específicas de dados, código e infraestrutura. Os Pacotes de Ativos do Databricks garantem a implantação atômica desses componentes em ambientes de desenvolvimento, preparo e produção com definições YAML.
• Retreinamento e monitoramento contínuos: os modelos se degradam devido ao descompasso de dados. Os Trabalhos do Lakeflow permitem pipelines de retreinamento automatizados, enquanto o MLflow se integra ao Monitoramento de Qualidade de Dados do Prometheus e do Databricks para acompanhamento de desempenho.

Pilhas MLOps para CI/CD de ML

O Databricks aborda a complexidade de CI/CD de ML por meio do MLOps Stacks, uma estrutura de nível de produção que combina pacotes de ativos do Databricks, fluxos de trabalho de CI/CD pré-configurados e modelos de projeto ML modulares. Essas pilhas impõem as práticas recomendadas, mas permitem flexibilidade para a colaboração de várias equipes nas funções de engenharia de dados, ciência de dados e MLOps.

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

• Os engenheiros de dados confirmam as alterações no pipeline ETL em um pacote, acionando a validação de esquema automatizada e uma implantação de preparo.
• Os cientistas de dados enviam o código de ML, que executa testes de unidade e implanta em um espaço de trabalho de preparo para teste de integração.
• Os engenheiros do MLOps revisam as métricas de validação e promovem modelos controlados para produção usando o Registro MLflow.

Para obter detalhes de implementação, consulte:

• Pacote do MLOps Stacks: diretrizes passo a passo para inicialização e implantação do pacote.
• Repositório GitHub do MLOps Stacks: modelos pré-configurados para treinamento, inferência e CI/CD.

Ao alinhar equipes com pacotes padronizados e MLOps Stacks, as organizações podem simplificar a colaboração, mantendo a auditabilidade em todo o ciclo de vida de ML.

CI/CD para desenvolvedores do SQL

Os desenvolvedores de SQL que usam o SQL do Databricks para gerenciar tabelas de streaming e exibições materializadas podem aproveitar a integração do Git e os pipelines de CI/CD para simplificar seus fluxos de trabalho e manter pipelines de alta qualidade. Com a introdução do suporte do Git para consultas, os desenvolvedores de SQL podem se concentrar na gravação de consultas, aproveitando o Git para controlar seus .sql arquivos de versão, o que permite a colaboração e a automação sem precisar de conhecimentos profundos em infraestrutura. Além disso, o editor do SQL habilita a colaboração em tempo real e se integra perfeitamente aos fluxos de trabalho do Git.

Para fluxos de trabalho centrados em SQL:

• Arquivos SQL de controle de versão

  • Armazene arquivos .sql em repositórios Git usando pastas Git do Databricks ou provedores Git externos, por exemplo, GitHub, Azure DevOps.
  • Use ramificações (por exemplo, desenvolvimento, preparo, produção) para gerenciar alterações específicas do ambiente.

• Integrar arquivos .sql a pipelines de CI/CD para automatizar a implantação:

  • Valide a sintaxe e as alterações de esquema durante solicitações de pull.
  • Implantar arquivos .sql em fluxos de trabalho ou trabalhos do Databricks SQL.

• Parametrizar para isolamento de ambiente

  • Use variáveis em .sql arquivos para referenciar dinamicamente recursos específicos do ambiente, como caminhos de dados ou nomes de tabela:

    CREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
    

• Agendar e monitorar atualizações

  • Use tarefas SQL em um Trabalho do Databricks para agendar atualizações de tabelas e exibições materializadas (REFRESH MATERIALIZED VIEW view_name).
  • Monitore o histórico de atualizações usando tabelas do sistema.

Um fluxo de trabalho pode ser:

1. Desenvolver: escreva e teste scripts .sql localmente ou no editor de SQL do Databricks e confirme-os em um GIT branch.
2. Validar: durante uma solicitação de pull, valide a sintaxe e a compatibilidade de esquema usando verificações de CI automatizadas.
3. Implantar: após a mesclagem, implante os scripts .sql no ambiente de destino usando pipelines de CI/CD, por exemplo, GitHub Actions ou Azure Pipelines.
4. Monitorar: use painéis e alertas do Databricks para acompanhar o desempenho da consulta e a atualização dos dados.

CI/CD para desenvolvedores de dashboard

O Databricks dá suporte à integração de dashboards em fluxos de trabalho de CI/CD usando pacotes de ativos do Databricks. Essa funcionalidade permite que os desenvolvedores de dashboard:

• Painéis de controle de versão, que garantem a auditabilidade e simplificam a colaboração entre as equipes.
• Automatizar implantações de painéis junto com trabalhos e pipelines em ambientes, para alinhamento de ponta a ponta.
• Reduza erros manuais e verifique se as atualizações são aplicadas de forma consistente entre ambientes.
• Mantenha fluxos de trabalho de análise de alta qualidade ao aderir às práticas recomendadas de CI/CD.

Para painéis em CI/CD:

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

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

• Armazene esses .lvdash.json arquivos em repositórios Git para controlar as alterações e colaborar efetivamente.

• Implantar painéis automaticamente em pipelines de CI/CD com databricks bundle deploy. Por exemplo, a etapa do GitHub Actions para implantação:

  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 warehouses ou fontes de dados, garantindo a implantação perfeita em ambientes de desenvolvimento, preparo e produção.

• Use a opção bundle generate --watch para sincronizar continuamente arquivos JSON do painel local com alterações feitas na interface do usuário do Databricks. Se ocorrerem discrepâncias, use o sinalizador --force durante a implantação para substituir os painéis remotos pelas versões locais.

Para obter informações sobre recursos de dashboards em pacotes, consulte o recurso de dashboards. Para obter detalhes sobre comandos de pacote, consulte bundle o grupo de comandos.