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

O CI/CD (Continuous Integration and Continuous Delivery) tornou-se uma pedra angular 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 moldados por suas preferências organizacionais, fluxos de trabalho existentes e ambiente de tecnologia específico, e fornece uma estrutura flexível que suporta várias opções de CI/CD.

Esta página descreve as práticas recomendadas para ajudá-lo a projetar e criar pipelines de CI/CD robustos e personalizados que se alinham com suas necessidades e restrições exclusivas. Ao aproveitar 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 da IC/CD

Pipelines de CI/CD eficazes compartilham princípios fundamentais, independentemente das especificidades da implementação. As seguintes práticas recomendadas universais aplicam-se às preferências organizacionais, aos fluxos de trabalho dos desenvolvedores e aos ambientes de nuvem, garantindo a consistência em diversas implementações. Isso aplica-se independentemente de sua equipe priorizar o desenvolvimento prioritário de notebooks ou fluxos de trabalho de infraestrutura-como-código. Adote estes princípios como diretrizes, ao mesmo tempo em que adapta as especificidades à pilha tecnológica e aos processos da sua organização.

• Controle a versão de tudo
  • Armazene blocos de anotações, scripts, definições de infraestrutura (IaC) e configurações de trabalho no Git.
  • Use estratégias de ramificação, como o Gitflow, que estejam alinhadas com 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 bibliotecas, como pytest para Python e ScalaTest para Scala.
  • Valide a funcionalidade de notebook e fluxo de trabalho com ferramentas, como Databricks CLI bundle validate.
  • Use testes de integração para fluxos de trabalho e pipelines de dados, como chispa para Spark DataFrames.
• Empregar infraestrutura como código (IaC)
  • Defina clusters, trabalhos e configurações de espaço de trabalho com Databricks Asset Bundles YAML ou Terraform.
  • Parametrizar em vez de codificar configurações referentes ao ambiente, como o tamanho do cluster e informações confidenciais.
• Isolar ambientes
  • Mantenha espaços de trabalho separados para desenvolvimento, preparação e produção.
  • Use o MLflow Model Registry para controle de versão de modelos entre ambientes.
• Escolha ferramentas que correspondam ao seu ecossistema de nuvem:
  • Azure: Azure DevOps e Databricks Asset Bundles ou Terraform.
  • AWS: GitHub Actions e Databricks Asset Bundles ou Terraform.
  • GCP: Cloud Build e Databricks Asset Bundles ou Terraform.
• Monitore e automatize reversões
  • Acompanhe as taxas de sucesso da implantação, o desempenho do trabalho e a cobertura do teste.
  • Implemente mecanismos de reversão automatizados para implantações com falha.
• Unificar a gestão de ativos
  • Use o Databricks Asset Bundles para implantar código, trabalhos e infraestrutura como uma única unidade. Evite o gerenciamento em silos de blocos de anotações, bibliotecas e fluxos de trabalho.

Pacotes de Recursos Databricks para CI/CD

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

Por exemplo, os desenvolvedores Java são usados para construir 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 a agregação de código e infraestrutura para uma implantação perfeita.

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

Para começar rapidamente a usar o Databricks Asset Bundles, experimente um tutorial: Desenvolva um trabalho com Databricks Asset Bundles ou Desenvolva Lakeflow Spark Declarative Pipelines com Databricks Asset Bundles.

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

A primeira escolha que os desenvolvedores precisam fazer ao implementar CI/CD é como armazenar e versionar arquivos de origem. Os pacotes permitem que você contenha facilmente tudo - código-fonte, artefatos de compilaçã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:

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

Se escolher integrar ou separar os seus ficheiros relacionados com o código dos ficheiros de configuração do pacote, utilize sempre versões dos artefatos, como hashes de confirmação do Git, ao carregar para o Databricks ou armazenamento externo para garantir rastreabilidade e capacidade de reversão.

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

Nessa abordagem, o código-fonte e os arquivos de configuração do pacote são armazenados no mesmo repositório. Isso simplifica os fluxos de trabalho e garante mudanças 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 ou projetos maiores, onde grupos separados lidam com o desenvolvimento de aplicativos e o gerenciamento de fluxo de trabalho do Databricks.

Exemplo: projeto Java e bundle

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 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 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 para um volume do Catálogo Databricks Unity. Consulte carregar JAR.

Repositório 2: Agrupar arquivos

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

• Os databricks.yml de configuração do pacote e as definições de tarefas são mantidos de forma independente.

• 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 colocalizando 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

   • Acionado em uma solicitação pull ou uma confirmação para a ramificação principal.
   • Compile código e execute testes de unidade.
   • Exporte um ficheiro versionado, por exemplo, my-app-1.0.jar.

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

   • Armazene o arquivo compilado em um volume do Databricks Unity Catalog ou em um repositório de artefatos, como o AWS S3 ou o Armazenamento de Blobs do Azure.
   • Use um esquema de versionamento vinculado a hashes de confirmação do Git ou versionamento 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 as configurações incorretas, por exemplo, bibliotecas ausentes, sejam detetadas antecipadamente.

4. Implantar o pacote

   • Use databricks bundle deploy para implantar o pacote em um ambiente de preparação ou produção.
   • Faça referência à biblioteca compilada carregada em databricks.yml. Para obter informações sobre como referenciar bibliotecas, consulte Dependências da biblioteca Databricks Asset Bundles.

CI/CD para aprendizagem automática

Os projetos de aprendizado de máquina 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 ferramentas e fluxos de trabalho diferentes. O Databricks unifica esses processos com MLflow para rastreamento de experimentos, Delta Sharing para governança de dados e Databricks Asset Bundles para infraestrutura como código.
• Controle de versão de dados e modelos: os pipelines de ML exigem o acompanhamento não apenas de código, mas também de esquemas de dados de treinamento, distribuições de recursos e artefatos de modelo. O Databricks Delta Lake fornece transações ACID e viagens no tempo para versionamento 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ódigos e infraestrutura. Os pacotes de ativos Databricks garantem a implantação atômica desses componentes em ambientes de desenvolvimento, preparação e produção com definições YAML.
• Retreinamento e monitoramento contínuos: Os modelos se degradam devido à deriva de dados. Os Lakeflow Jobs permitem pipelines de re-treino automatizados, enquanto o MLflow se integra com o Prometheus e o Databricks Data Quality Monitoring para rastreamento de desempenho.

Pilhas MLOps para ML CI/CD

O Databricks aborda a complexidade do ML CI/CD por meio do MLOps Stacks, uma estrutura de nível de produção que combina Databricks Asset Bundles, fluxos de trabalho de CI/CD pré-configurados e modelos modulares de projeto de ML. Estas stacks reforçam as práticas recomendadas, ao mesmo tempo que permitem flexibilidade para a colaboração entre várias equipas nas funções de engenharia de dados, ciência de dados e MLOps.

A colaboração ML CI/CD pode ter a seguinte aparência:

• Os engenheiros de dados confirmam alterações no pipeline de ETL num pacote, acionando a validação automatizada do schema e uma implantação de teste.
• Os cientistas de dados enviam código de Aprendizagem Automática, que executa testes unitários e implantam em um espaço de trabalho de teste para testes de integração.
• Os engenheiros do MLOps revisam as métricas de validação e promovem modelos aprovados para a produção usando o MLflow Registry.

Para obter detalhes sobre a implementação, consulte:

• MLOps Stacks bundle: orientação passo a passo para a inicialização e a implementação do conjunto.
• Repositório GitHub MLOps Stacks: modelos pré-configurados 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 enquanto mantêm a auditabilidade em todo o ciclo de vida do ML.

CI/CD para desenvolvedores SQL

Os desenvolvedores SQL que usam o Databricks SQL 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 Git para consultas, os desenvolvedores SQL podem se concentrar em escrever consultas enquanto aproveitam o Git para controlar a versão de seus .sql arquivos, o que permite colaboração e automação sem precisar de profundo conhecimento em infraestrutura. Além disso, o editor SQL permite a colaboração em tempo real e integra-se perfeitamente com fluxos de trabalho 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 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 .sql arquivos em pipelines de CI/CD para automatizar a implantação:

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

• Parametrizar para isolamento ambiental

  • Use variáveis em .sql arquivos para fazer referência dinâmica a recursos específicos do ambiente, como caminhos de dados ou nomes de tabelas:

    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 para 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. Desenvolva: escreva e teste .sql scripts localmente ou no editor SQL do Databricks e, em seguida, faça commit deles numa branch do Git.
2. Validar: Durante uma solicitação pull, valide a sintaxe e a compatibilidade de esquema usando verificações de CI automatizadas.
3. Implantar: Após a mesclagem, implante os scripts de .sql no ambiente de destino usando pipelines de CI/CD, por exemplo, Ações do GitHub ou Pipelines do Azure.
4. Monitor: Use painéis e alertas do Databricks para acompanhar o desempenho de consultas e a atualização dos dados.

CI/CD para desenvolvedores de painéis

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

• Painéis de controle de versão, que garantem auditabilidade e simplificam a colaboração entre as equipes.
• Automatize implantações de painéis juntamente com trabalhos e pipelines 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.
• Mantenha fluxos de trabalho de análise de alta qualidade enquanto adere às práticas recomendadas de CI/CD.

Para painéis em CI/CD:

• Use o databricks bundle generate comando para exportar painéis existentes como arquivos JSON e gerar a configuração YAML que o 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 rastrear alterações e colaborar de forma eficaz.

• Desloque automaticamente painéis em pipelines de CI/CD com databricks bundle deploy. Por exemplo, a etapa Ações do GitHub 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 uma implantação perfeita em ambientes de desenvolvimento, preparação e produção.

• Use a bundle generate --watch opção para sincronizar continuamente 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 painéis em pacotes, consulte recurso de painel. Para obter detalhes sobre os comandos de pacote, consulte o grupo de comandos.