Databricks, Spark e a Nova Onda da Engenharia de Dados: Por que Todo Mundo Está Falando Disso (e o que Ninguém Conta)

O Que Me Levou a Investigar o Databricks

Eu estava rolando o Twitter, aquele habitat natural onde devs misturam desabafo com epifania, quando trombei com um comentário que me chamou atenção. A pessoa dizia algo assim:

"Primeiras impressões com o Databricks:

estou encantada

dá pra fazer tudo lá: modelar, montar pipeline, versionar

meu primeiro contato com Spark foi mágico e agora quero usar em absolutamente tudo

o free edition me limita demais na execução de jobs e clusters e isso me deixa triste."

E foi aí que bateu aquele estalo de curiosidade técnica: ok, se alguém está descrevendo Spark como "mágico", algo interessante está acontecendo. Porque, sejamos sinceros, o Spark nunca foi exatamente famoso por sua "magia". Ele é poderoso, sim; elegante, às vezes; mas mágico? Só quando tudo funciona de primeira, ou seja, quase nunca.

Então fui investigar. E quanto mais eu lia, mais percebia que o Databricks virou, nos últimos anos, aquele tipo de ferramenta que desperta um fenômeno curioso: é metade hype, metade fundamentação técnica séria, e justamente por isso merece um olhar honesto, contextualizado e até meio desconfiado.

Afinal, muita gente fala do Databricks como se fosse uma mistura de AWS com Hogwarts, mas pouca gente senta para explicar por que ele virou a plataforma preferida de engenheiros de dados, times de ML e empresas que querem fazer coisas sérias com Big Data sem sofrer (ou sofrendo um pouco menos).

E claro, quando algo começa a virar tendência, minha cabeça faz o que sempre faz: junta exemplos práticos, compara com a realidade do mercado, lembra de histórias que ninguém conta e tenta separar o que é engenharia sólida do que é romantização tecnológica.

O Conceito de Lakehouse: A Verdade Que Ninguém Conta

Para começar do jeito certo, você precisa entender o conceito que transformou o mercado: o Lakehouse.

Antes de o Databricks aparecer, a indústria vivia uma guerra meio infantil entre Data Warehouse e Data Lake:

Data Warehouse: organizado, caro, cheio de regras
Data Lake: barato, flexível e desorganizado como o meu quarto

O Databricks olhou para esse cenário e disse: por que não juntar o melhor dos dois? O resultado virou o padrão do mercado. Hoje todo mundo tenta copiar, inclusive gigantes que antes torciam o nariz.

E não é coincidência. Os criadores do Databricks são os mesmos caras do Apache Spark, que já tinha mudado o jogo uma vez. A plataforma nada mais é do que a versão premium, polida e superalimentada do Spark, reescrita e otimizada para o mundo real.

A Arquitetura: Control Plane vs Data Plane

A segunda peça que diferencia o Databricks é a arquitetura. Quem nunca se perguntou por que cargas d'água existe um Control Plane e um Data Plane? Parecem nomes inventados por alguém que queria impressionar na entrevista. Mas isso separa adultos de amadores.

Control Plane: fica com a Databricks. É a interface, as configurações, o material bonitinho.
Data Plane: fica na sua nuvem. Seus dados nunca saem da sua conta.

Isso muda o jogo porque, no final do dia, sua equipe de segurança dorme melhor. E devs gostam de dormir melhor.

O Mercado Brasileiro e a Adoção em Massa

Agora, se a gente olha para o mercado brasileiro, aí a história fica ainda mais interessante. Porque o Brasil adotou Databricks do mesmo jeito que adotou WhatsApp: foi do nada para todo mundo.

Empresas que usam Databricks no Brasil:

Itaú
Nubank
iFood
Globo
Magalu

Se existe dado, alguém ligou o Databricks em cima. E não foi só por tendência, mas por necessidade. A quantidade de dados gerados por esses players é absurda. Se você tentar processar isso com uma abordagem tradicional, vira catástrofe.

Por isso a corrida por profissionais que entendem Spark, Delta Lake, Photon e o resto da sopa de letrinhas. E por isso os salários dispararam.

A Guerra Fria: Databricks vs Snowflake

Lá fora a história é outra, mas igualmente curiosa. Databricks e Snowflake vivem uma guerra fria:

Snowflake: começou como o queridinho dos analistas de SQL
Databricks: dominou os engenheiros e cientistas

Agora os dois tentam invadir o território um do outro. Só que o Databricks percebeu uma virada antes da maioria: a era da IA generativa. E aí comprou a MosaicML por mais de um bilhão para baratear o treinamento de modelos grandes. Enquanto uns pensam em dashboards coloridos, o Databricks pensa em treinar o próximo LLM da sua empresa.

O Universo Escondido Por Trás da Interface

Muita gente usa Databricks como se fosse um Jupyter Notebook com esteroides e acha que já está sendo avançada. Mas existe um universo escondido por trás da interface que separa senior de iniciante:

Asset Bundles: a magia de declarar infra inteira como código. Se você ainda está clicando para criar job, está brincando.
Delta Live Tables: transforma pipelines quebradiços em fluxos declarativos e resilientes.
Z-Ordering e Liquid Clustering: otimizações físicas que resolvem dores que ninguém percebe até a conta de armazenamento e processamento estourar.
Time Travel: salva carreiras quando alguém apaga uma tabela por engano.
Funções de IA direto no SQL: deixam qualquer analista parecer um mago.

O Poder do Photon

E aí vem o Photon. Aqui é onde o Databricks mostra o músculo.

O Spark nasceu na JVM. Fantástico, elegante, robusto. Só que limitado. A Databricks reescreveu o motor inteiro em C++ e o batizou de Photon.

Resultado:

Consultas que rodam vezes mais rápido
Redução de custo porque o cluster vive menos tempo
Menos tempo ligado = menos dinheiro queimado

A História Por Trás do Databricks

Essa história toda não é só técnica. Tem bastidor:

O projeto nasceu em Berkeley
Virou open source
Cresceu num laboratório acadêmico
Migrou para uma startup bilionária
Hoje dita padrões como o Delta Lake

A Databricks até abriu o Delta Lake para evitar que dissessem que estavam prendendo clientes.

Pontos Fortes e Fracos

Pontos Fortes

Rápido, flexível, escalável
Une todo mundo numa plataforma só
Facilita governança
Cria uma cultura de dados mais madura

Pontos Fracos

Custo traiçoeiro: basta um cluster esquecido no fim de semana para a cobrança vir do tamanho de uma dívida com o nubank.
Curva de aprendizado íngreme para quem só sabe SQL
Clusters demorando minutos para ligar irritam qualquer pessoa que já usou BigQuery ou Snowflake (embora o serverless esteja melhorando isso)

Como Começar

Para começar, o caminho é simples, mas não fácil:

Use a Community Edition
Aprenda PySpark de verdade
Entenda o Delta Lake
Explore DABs e DLT antes de achar que está pronto
Faça certificação não porque o mercado exige, mas porque vai te obrigar a aprender de forma forçada, organizada e consistente

Se você leu meus outros artigos, já sabe que o meu objetivo aqui não é vender promessa. É mostrar o que acontece nessa loucura sem sentido que é o ramo da tecnologia.

E o Databricks merece sinceridade. Não é uma ferramenta qualquer. É uma peça central no futuro dos dados. Mas não espere glamour, não espere atalhos e não espere que ele resolva tudo sozinho. No fim do dia, o Databricks é só um martelo poderoso. Entender como usá-lo é o que diferencia quem bate o prego de quem constrói a casa inteira.

Conclusão

No fim das contas, trabalhar com dados, código e infraestrutura sempre volta para a mesma pergunta: você está usando a ferramenta certa para o problema certo? Porque, se não estiver, o preço chega. E chega rápido. Já vi gente montar um CRUD simples com Kafka, Spark e três filas assíncronas só porque parecia profissional. O resultado foi exatamente o esperado: um projeto pesado, caro, lento e impossível de manter, tudo para resolver algo que meia dúzia de rotas em .NET ou Rails entregariam com folga. Do outro lado, também já vi o oposto. Sistemas enormes, cheios de eventos, alto tráfego, múltiplas integrações, tudo rodando em algo pequeno demais. Um monolito em PHP resolvendo coisas que exigiam paralelismo e processamento distribuído. Funcionou por um tempo, até o tráfego dobrar. Aí vieram filas estourando, timeouts, deploys que derrubavam o sistema inteiro. Escalabilidade não é sobre ser chique, é sobre não implodir quando o número de usuários muda.

E nesse ponto entra a parte que ninguém fala. Não adianta montar um exército arquitetural quando seu time tem três pessoas. Não adianta dividir o produto em dez microsaas se você não tem gente para manter dez repositórios, dez pipelines, dez deploys e dez fontes de bugs. Isso vira dívida, vira custo, vira burnout. Já escrevi sobre isso no artigo sobre microservices. O resumo é simples. Use a ferramenta que resolve o problema do tamanho que o problema realmente tem. Se a solução parece sofisticada demais para algo simples, você está cavando o próprio buraco. Se parece simples demais para algo complexo, você está pedindo para sofrer daqui alguns meses. A maturidade técnica não está em escolher a tecnologia mais famosa. Está em escolher a mais adequada.