Tecnologia

Consultoria e implementação Databricks

A empresa comprou Databricks para resolver um problema de dado que, no fundo, era de processo. Meses depois o cluster está caro, os notebooks pertencem a uma pessoa só, e ninguém consegue apontar qual tabela é a oficial. A conta cresce, a confiança no número não.

Como a gente encara.

Começamos pelo inventário de custo e de dono, não pelo recurso novo. Cada job ganha um responsável nomeado e um teto de gasto antes de qualquer refatoração. Governança entra no começo, com o catálogo definido antes da primeira carga, porque migrar governança depois de a plataforma estar cheia custa mais do que o projeto inicial. Notebook vira código versionado com teste; o que precisa de interatividade continua interativo, o resto vira job.

Onde costuma quebrar

Os erros que aparecem sempre, e que ninguém conta na demonstração.

  1. 01

    All-purpose cluster ligado o dia inteiro para carga que é batch: você paga preço de interativo por uso de job.

  2. 02

    Notebook tratado como artefato de produção. Sem versionamento nem teste, o pipeline vira a memória de quem o escreveu.

  3. 03

    Medallion aplicado como dogma. Bronze, silver e gold em dado que tem uma fonte e um consumidor triplicam armazenamento e latência sem entregar governança nenhuma.

  4. 04

    Unity Catalog deixado para a fase dois. A fase dois chega com a plataforma cheia, e aí a migração de governança compete com a operação.

  5. 05

    Delta sem compactação nem expurgo. O acúmulo de arquivos pequenos degrada a consulta até alguém pedir um cluster maior em vez de compactar a tabela.

O que custa mais do que parece

  • Você paga duas contas: a de DBU para a Databricks e a de computação para a nuvem. Orçamento feito só com uma das duas estoura.
  • Tempo de subida de cluster aparece na fatura de job curto e frequente. Um pipeline que roda a cada poucos minutos passa boa parte do tempo ligando máquina.
  • Sem alguém que saiba dimensionar, o caminho mais fácil diante de lentidão é aumentar o cluster. O custo sobe, a causa continua lá.

O que você recebe

  • Inventário de clusters e jobs com custo atribuído por job e por área.
  • Catálogo com dono nomeado por tabela e política de acesso escrita.
  • Pipelines versionados em repositório, com teste e com execução reproduzível.
  • Teto de custo com alerta, e o procedimento de quem é acionado quando ele é atingido.

O que fazemos com Databricks

Open source ou enterprise, a frente é a mesma.

  • Implantar

    Do zero, com a arquitetura decidida no diagnóstico e não pelo catálogo do fornecedor.

  • Migrar

    De outra ferramenta, ou de uma versão antiga, com o que já roda continuando a rodar.

  • Desenvolver em cima

    Aplicação, integração e automação construídas sobre Databricks, incluindo o que a ferramenta não faz sozinha.

  • Sustentar

    Operação, custo sob controle e correção de rota depois que entra em produção.

Perguntas diretas.

Databricks é caro?
Databricks custa o que você provisiona. A conta alta quase sempre vem de cluster interativo ligado para carga que era batch, e de consulta que varre a tabela inteira porque ninguém compactou nem particionou. O preço da plataforma raramente é o problema; o desenho do uso é.
Eu preciso mesmo de Databricks, ou um data warehouse resolve?
Se o seu dado é majoritariamente tabular, cabe num warehouse e o consumo é BI, um warehouse resolve com menos peça móvel e menos gente especializada. Databricks paga a complexidade quando existe volume que não cabe em consulta direta, dado semiestruturado, ou carga de machine learning junto do analítico. Se nada disso é o seu caso, dizer isso é mais útil do que vender a implantação.
Dá para sair do Databricks depois?
O formato de armazenamento é aberto, então o dado em si sai. O que prende é o que você construiu em volta: catálogo, orquestração proprietária e notebooks que só rodam lá dentro. Dá para reduzir esse acoplamento desde o começo, e essa é uma decisão de arquitetura que vale tomar antes, não depois.

Antes de escolher a ferramenta

A ferramenta é consequência da arquitetura. Nunca a premissa.

Esta página existe porque alguém procura por esse nome. Mas a escolha certa sai do diagnóstico do seu cenário, não do catálogo de quem vende. Se a resposta for outra ferramenta, ou nenhuma, é isso que você vai ouvir.

Não está na lista? Não é impedimento, é conversa. O que decide não é o nome do produto, é o problema que ele precisa resolver.