Fluxos de trabalho de CI/CD no Databricks
CI/CD (integração contínua (CI) e entrega contínua (CD)) tornou-se um pilar fundamental da engenharia de dados e analítica modernas, pois garante que as alterações de código sejam integradas, testadas e implantadas de forma rápida e confiável. A Databricks reconhece que os requisitos de CI/CD podem ser diversos, moldados pelas preferências organizacionais, pelos fluxos de trabalho existentes e pelo ambiente de tecnologia específico, e oferece uma estrutura flexível que suporta diversas opções de CI/CD.
Esta página descreve fluxos de trabalho CI/CD recomendados para ajudar a projetar e construir pipelines CI/CD robustos e personalizados que se alinhem com suas necessidades e restrições exclusivas. Ao aproveitar essas percepções, você pode acelerar suas iniciativas de engenharia de dados e analítica, melhorar a qualidade do código e reduzir o risco de falhas de implantação.
Princípios essenciais de CI/CD
Pipelines de CI/CD eficazes compartilham princípios fundamentais independentemente das especificidades da implementação. As seguintes melhores práticas universais se aplicam a preferências organizacionais, fluxos de trabalho de desenvolvedores e ambientes de cloud, e garantem consistência entre diversas implementações, quer sua equipe priorize o desenvolvimento focado em Notebook ou fluxos de trabalho de Infrastructure-as-Code. Adote estes princípios como guardrails, adaptando as especificidades à stack de tecnologia e aos processos de sua organização.
-
Aplique o controle de versões a tudo.
- Armazene Notebooks, scripts, definições de infraestrutura (IaC) e configurações de job no Git.
- Use estratégias de ramificação, como o Gitflow, que estejam alinhadas com os ambientes padrão de desenvolvimento, teste e implantação de produção.
-
Automatize 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 a CLI do Databricks validar pacote.
- 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 as configurações de clusters, Jobs e workspace com Declarative Automation Bundles YAML ou Terraform.
- Parametrizar em vez de codificar diretamente configurações específicas do ambiente, como tamanho do cluster e segredos.
-
Isolar ambientes
- Mantenha workspaces separados para desenvolvimento, preparação e produção.
- Use MLflow Model Registry para versionamento de modelos entre ambientes.
-
Escolha as ferramentas que correspondam ao seu ecossistema de cloud:
- Azure: Azure DevOps e Declarative Automation Bundles ou Terraform.
- AWS: GitHub Actions e Pacotes de Automação Declarativa ou Terraform.
- GCP: Cloud Build e Pacotes de Automação Declarativa ou Terraform.
-
Monitorar e automatizar reversões
- Acompanhar taxas de sucesso de implantação, desempenho de Job e cobertura de teste.
- Implementar mecanismos de rollback automatizados para implantações com falha.
-
Gerenciamento unificado de ativos
- Use Pacotes de Automação Declarativa para implantar código, Jobs e infraestrutura como uma única unidade. Evite o gerenciamento isolado de notebooks, bibliotecas e fluxos de trabalho.
Databricks recomenda a federação de identidade de carga de trabalho para autenticação CI/CD. A federação de identidade de carga de trabalho elimina a necessidade de segredos do Databricks, o que a torna a maneira mais segura de autenticar seus fluxos automatizados no Databricks. Consulte Habilitar federação de identidade de carga de trabalho em CI/CD.
Pacotes de Automação Declarativa para CI/CD
Os Bundles de Automação Declarativa (anteriormente conhecidos como Pacotes de Ativos do Databricks) 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 por YAML, os pacotes simplificam a implantação e garantem a consistência entre ambientes. No entanto, para usuários acostumados a fluxos de trabalho tradicionais de CI/CD, a adoção de bundles pode exigir uma mudança de mentalidade.
Por exemplo, desenvolvedores Java estão acostumados a construir JARs com Maven ou Gradle, executar testes de unidade com JUnit e integrar esses os passos em pipelines de CI/CD. Da mesma forma, desenvolvedores Python frequentemente empacotam código em wheels e testam com pytest, enquanto desenvolvedores SQL se concentram na validação de consultas e gerenciamento de notebooks. Com pacotes, esses fluxos de trabalho convergem para um formato mais estruturado e prescritivo, enfatizando o agrupamento de código e infraestrutura para implantação contínua.
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 os Pacotes de Automação Declarativa, experimente um tutorial: Desenvolva um Job com Pacotes de Automação Declarativa ou Desenvolva pipelines com Pacotes de Automação Declarativa.
Controle do código-fonte
Pacotes permitem conter facilmente tudo (código-fonte, artefatos de build e arquivos de configuração) e localizá-los no mesmo repositório de código-fonte, mas você também pode 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 para simplificar os fluxos de trabalho e o compartilhamento de melhores práticas, a Databricks recomenda que se utilize um único repositório para código e configuração de pacote.
Além disso, a Databricks recomenda uma estratégia de ramificação baseada em tronco para minimizar conflitos de merge e garantir que a ramificação principal esteja sempre em um estado implantável, e sempre use artefatos versionados, como hashes de commit do Git, ao fazer upload para a Databricks ou armazenamento externo para garantir rastreabilidade e recursos de reversão.
Para mais informações sobre essas melhores práticas, consulte Controle de código-fonte.
Fluxo de Trabalho de CI/CD com Pacotes
Um fluxo de trabalho simples recomendado usando Pacotes de Automação Declarativa é o seguinte:
-
Compilar e testar o código
- Acionado em uma solicitação pull ou em um commit para a ramificação principal.
- Compilar código e executar testes unitários.
- Gerar um arquivo versionado, por exemplo,
my-app-1.0.jar.
-
Faça o upload do arquivo compilado, como um JAR, e armazene-o em um volume do Unity Catalog do Databricks.
- Armazene o arquivo compilado em um volume do Databricks Unity Catalog ou em um repositório de artefatos como AWS S3 ou Azure Blob Storage.
- Use um esquema de versionamento vinculado a hashes de commit do Git ou controle de versão semântico, por exemplo,
dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.
-
Validar o bundle
- Execute
databricks bundle validatepara garantir que a configuraçãodatabricks.ymlesteja correta. - Esta etapa garante que as configurações incorretas, por exemplo, bibliotecas ausentes, sejam detectadas antecipadamente.
- Execute
-
Implementar o pacote
- Use
databricks bundle deploypara implantar o pacote em um ambiente de teste ou de 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 de Pacotes de Automação Declarativa.
- Use
CI/CD para machine learning
Projetos de machine learning introduzem desafios únicos de CI/CD em comparação com o desenvolvimento de software tradicional. Ao implementar CI/CD para projetos de ML, é provável que seja necessário considerar o seguinte:
- Coordenação de várias equipes: cientistas de dados, engenheiros e equipes de MLOps frequentemente usam ferramentas e fluxos de trabalho diferentes. O Databricks unifica esses processos com o MLflow para acompanhamento de experimentos, o OpenSharing para governança de dados e os Declarative Automation Bundles para Infrastructure-as-Code.
- Versionamento de dados e modelos: ML pipelines exigem o acompanhamento não apenas do código, mas também dos esquemas de dados de treinamento, das distribuições de recursos e dos artefatos de modelo. O Delta Lake fornece transações ACID e viagem do tempo para versionamento de dados, enquanto o MLflow Model Registry gerencia a linhagem do modelo.
- Reprodutibilidade entre ambientes: modelos de ML dependem de combinações específicas de dados, código e infraestrutura. Pacotes de Automação Declarativa garantem a implantação atômica desses componentes em ambientes de desenvolvimento, preparação e produção com definições YAML.
- Retreinamento contínuo e monitoramento: Modelos se degradam devido a drift de dados. Jobs do LakeFlow possibilitam pipelines de retreinamento automatizados, enquanto o MLflow se integra com o Prometheus e o Monitoramento de Qualidade de Dados do Databricks para acompanhamento de desempenho.
Pilhas de MLOps para ML de CI/CD
Databricks aborda a complexidade de CI/CD de ML por meio de MLOps Stacks, uma estrutura de nível de produção que combina Pacotes de Automação Declarativos, fluxos de trabalho de CI/CD pré-configurados e padrões de projeto de ML modulares. Essas pilhas impõem as melhores práticas ao mesmo tempo em que permitem flexibilidade para a colaboração entre várias equipes nas funções de engenharia de dados, ciência de dados e MLOps.
Equipe | Responsabilidades | Exemplos de componentes de pacote | Exemplos de artefatos |
|---|---|---|---|
engenheiro de dados | Criar pipelines de ETL, garantir a qualidade dos dados | Lakeflow Spark Declarative Pipelines YAML, políticas de cluster |
|
data scientists | Desenvolver a lógica de treinamento do modelo, validar as métricas | MLflow Projects, fluxos de trabalho baseados em Notebooks |
|
engenheiros de MLOps | Orquestrar implantações, monitorar pipelines | Variáveis de ambiente, painéis de monitoramento |
|
A colaboração de ML CI/CD pode ser assim:
- Engenheiros de dados realizam o commit de alterações de pipeline ETL em um bundle, acionando a validação automática de esquema e uma implantação de staging.
- Cientistas de dados enviam código ML, que executa testes de unidade e implanta em um workspace de preparo para teste de integração.
- Engenheiros de MLOps revisam métricas de validação e promovem modelos verificados para produção usando o Registro do MLflow.
Para detalhes de implementação, veja:
- Pacote de MLOps Stacks: orientação passo a passo para a inicialização e implantação de pacotes.
- Repositório GitHub do MLOps Stacks: Padrões pré-configurados para treinamento, inferência e CI/CD.
Ao alinhar as equipes com pacotes padronizados e stacks de MLOps, as organizações podem otimizar a colaboração, mantendo a auditabilidade em todo o ciclo de vida do ML.
CI/CD para desenvolvedores SQL
Desenvolvedores SQL que usam o Databricks SQL para gerenciar tabelas de transmissão e views materializadas podem aproveitar a integração Git e os pipelines de CI/CD para otimizar seus fluxos de trabalho e manter pipelines de alta qualidade. Com a introdução do suporte a Git para consultas, os desenvolvedores SQL podem se concentrar em escrever consultas enquanto aproveitam o Git para controle de versão de seus arquivos .sql, o que possibilita colaboração e automação sem a necessidade de profunda experiência em infraestrutura. Além disso, o editor SQL permite a colaboração em tempo real e se integra perfeitamente a fluxos de trabalho do Git.
Para fluxos de trabalho centrados em SQL:
-
Controle de versão de arquivos SQL
- Armazenamento de SQL arquivos em repositórios Git usando pastas Git do Databricks ou provedores Git externos, por exemplo, GitHub, Azure DevOps.
- Utilize ramificações (por exemplo, desenvolvimento, staging, produção) para gerenciar alterações específicas do ambiente.
-
Integre
.sqlarquivos em pipelines de CI/CD para automatizar a implantação:- Validar sintaxe e alterações de esquema durante pull requests.
- Implantar
.sqlarquivos para fluxos de trabalho ou Jobs do Databricks SQL.
-
Parametrizar para isolamento do ambiente
-
Use variáveis em arquivos
.sqlpara referenciar dinamicamente recursos específicos do ambiente, como caminhos de dados ou nomes de tabela:SQLCREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
-
-
Programar e monitorar refreshes
- Usar tarefas SQL em um Job do Databricks para programar atualizações para tabelas e visualizações materializadas (
REFRESH MATERIALIZED VIEW view_name). - Monitorar o histórico de refresh usando tabelas do sistema.
- Usar tarefas SQL em um Job do Databricks para programar atualizações para tabelas e visualizações materializadas (
Um fluxo de trabalho poderia ser:
- Desenvolver: Escreva e teste scripts
.sqllocalmente ou no editor do Databricks SQL e faça o commit deles em uma branch Git. - Validar: Durante uma solicitação pull, valide a compatibilidade da sintaxe e do esquema usando verificações automatizadas de CI.
- Implantar: Após o merge, implantar o .sql scripts para o ambiente de destino usando pipelines de CI/CD, por exemplo, GitHub Actions ou Azure Pipelines.
- Monitore: Use os dashboards e alertas do Databricks para acompanhar o desempenho das consultas e a atualização dos dados.
CI/CD para desenvolvedores de dashboards
Databricks oferece suporte à integração de painéis em fluxos de trabalho de CI/CD usando Pacotes de Automação Declarativa. Esta funcionalidade permite aos desenvolvedores de painéis:
- Dashboards com controle de versão, o que garante auditabilidade e simplifica a colaboração entre equipes.
- Automatize implantações de dashboards juntamente com jobs e pipelines entre ambientes, para alinhamento de ponta a ponta.
- Reduzir erros manuais e garantir que as atualizações sejam aplicadas consistentemente em todos os ambientes.
- Manter fluxos de trabalho de analítica de alta qualidade ao aderir às práticas recomendadas de CI/CD.
Para dashboards em CI/CD:
-
Use o comando
databricks bundle generatepara exportar dashboards existentes como arquivos JSON e gerar a configuração YAML que o inclui no pacote:YAMLresources:
dashboards:
sales_dashboard:
display_name: 'Sales Dashboard'
file_path: ./dashboards/sales_dashboard.lvdash.json
warehouse_id: ${var.warehouse_id} -
Armazenar estes
.lvdash.jsonarquivos em repositórios Git para acompanhar as alterações e colaborar de forma eficaz. -
Automatize a implantação de painéis em pipelines de CI/CD com
databricks bundle deploy. Por exemplo, o passo do GitHub Actions para implantação:YAMLname: 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 contínua em todos os ambientes de desenvolvimento, preparo e produção. -
Use a opção
bundle generate --watchpara sincronizar continuamente arquivos JSON de dashboard locais com as alterações feitas na interface do usuário do Databricks. Se ocorrerem discrepâncias, use o sinalizador--forcedurante a implantação para substituir painéis remotos por versões locais.
Para obter informações sobre painéis em pacotes, consulte recurso do painel. Para obter detalhes sobre os comandos do pacote, consulte bundle grupo de comandos.