Como engenheiro de dados, você certamente já se deparou com diversos modelos de computação e diferentes cenários para aplicá-los. Mesmo para os profissionais mais experientes, o lançamento constante de novas features exige adaptação para escolher a infraestrutura ideal. O objetivo deste artigo é explicar os diferentes tipos de compute e discutir como podemos utilizá-los da melhor forma na prática:
Serverless Computing
Computação para Notebooks: Suporte de Python e SQL em notebooks, sem o gerenciamento de infraestrutura na sua conta cloud e com dimensionamento automático conforme a sua necessidade. Apresenta alta disponibilidade sem necessidade de uma grande espera para ligar o cluster.
Lakeflow Jobs: Execute Jobs sem configuração e deploy de infraestrutura
Lakeflow Pipelines: Aqui temos um ponto interessante, caso deseje trabalhar com atualizações incrementais automática de tabelas e visões materializadas o uso da computação serverless é obrigatória para o funcionamento correto do Enzyme, o motor de otimização interno
Classic All-Purpose Clusters
Ideal para notebooks, análise exploratória, experimentação em ciência de dados e colaboração em equipe, em que múltiplos usuários podem se conectar, compartilhar bibliotecas e iterar rapidamente.
𝗝𝗼𝗯 𝗖𝗹𝘂𝘀𝘁𝗲𝗿𝘀
Construído para fluxos automatizados e agendados: pipelines ETL, treinamento de modelos, jobs em batch. Sobem quando necessário, executam o job e terminam.
SQL Storage
Computação otimizada para consultas SQL , análise e cargas de trabalho de business intelligence com opções serverless ou clássicas .
Casos de Uso e Discussões da Comunidade
Deixo dois links de referência muito bons em que é discutido o que usar em cada caso e experiência boas e ruins de usuários Databricks:
Questões e Desafios:
Job Compute
Economia vs. Espera: É a opção mais barata do Databricks (chegando a ser 2 a 3 vezes mais econômica). O principal problema é o tempo de inicialização (spin-up time): demora de 5 a 10 minutos para que a nuvem provisione as máquinas virtuais.
Não atende SLAs imediatos: Por causa desse atraso na inicialização, não é a melhor escolha se você tem uma tarefa de emergência que precisa começar a processar dados no exato segundo em que eles chegam.
Isolamento: Job Clusters são clusters temporários criados para executar um Job. Eles podem ser compartilhados entre as tarefas desse Job, mas não entre Jobs diferentes.
All-purpose Compute
A Databricks cobra um valor por hora significativamente mais alto pelo uso desses clusters em comparação aos de Job.
Armadilha de custos: Usar clusters interativos para rodar jobs de produção agendados é considerado uma má prática financeira, pois você pagará tarifas mais caras e arcará com os custos de tempo ocioso da máquina (quando o cluster não está processando nada, mas continua ligado).
Serverless Compute
Falta de "Guardrails" é a maior reclamação dos usuários, visto que como a computação escala automaticamente e de forma agressiva, jobs comuns podem provisionar recursos em excesso de forma invisível. Isso resultou em relatos de contas explodindo em até 5 vezes o valor original.
Casos de uso muito específicos: É altamente recomendado para SQL Warehouses e ambientes interativos (onde o não pagamento por ociosidade compensa a tarifa alta), e para pequenos jobs de menos de 5 minutos que possuem SLAs críticos. Para rotinas normais de produção que levam horas, é financeiramente inviável.
Minha conclusão geral e de algumas pessoas que conversei, claro que cada cenário precisa ser avaliado de acordo com a sua natureza, mas eu usaria Job clusters para tarefas de produção agendadas visando economizar dinheiro, deixaria os All-purpose clusters para quando estiver escrevendo e testando código ativamente para ganhar agilidade, e reservar o Serverless para tarefas pequenas e urgentes