// stack.lumi

Nuvem

Databricks

Lakehouse para engenharia de dados, ML e IA em larga escala.

// o que é

Databricks une processamento distribuido, Delta Lake, notebooks, workflows e ML em uma arquitetura lakehouse. Na Lumi Data, usamos Databricks quando dados brutos, transformacoes complexas e modelos de IA precisam conviver em uma plataforma escalavel.

A arquitetura lakehouse, formalizada por Armbrust et al. (2021) no CIDR, propõe unificar o melhor dos data lakes — baixo custo de armazenamento em object storage, suporte a dados não estruturados, flexibilidade de schema — com as garantias dos data warehouses — transações ACID, qualidade de dados, performance analítica. O Delta Lake, descrito por Armbrust et al. (2020) no VLDB, implementa um transaction log sobre object storage (S3, GCS, ADLS) que habilita atomicidade, consistência, isolamento e durabilidade sem exigir um sistema de metadados centralizado como o Apache Hive Metastore. Zaharia et al. (2016) contextualizaram o Apache Spark como motor unificado para batch, streaming, SQL e ML, que o Databricks operacionaliza como plataforma gerenciada com otimizações proprietárias (Photon engine, Delta Engine). A convergência de engenharia de dados, analytics e ML em uma única plataforma responde ao problema de fragmentação de ferramentas que Reis & Huyen (2022) identificam como um dos maiores custos operacionais de times de dados modernos.

Como a Lumi enxerga:A Lumi estrutura jobs, governanca, qualidade, modelos e consumo por BI para que Databricks seja plataforma de producao, nao apenas ambiente de notebooks.

// na prática

Como empresas usam Databricks

Empresa de telecomunicações com dados de rede, billing e clientes para churn prediction

Databricks com Delta Lake organiza dados brutos de CDRs, logs de rede e eventos de billing na camada bronze, processa e une com dados de CRM na camada silver, e treina modelos de churn prediction com MLflow na camada gold. O mesmo cluster Spark processa tanto o ETL diário quanto os jobs de retreinamento semanal do modelo, e o Unity Catalog governa quem pode acessar quais dados de cliente — atendendo LGPD sem um sistema de governança separado. O que antes exigia Hadoop para batch, Kafka+Flink para streaming e SageMaker para ML passou a rodar em uma única plataforma com uma equipe menor.

Empresa de energia com sensores IoT, manutenção preditiva e mercado livre de energia

Databricks Structured Streaming processa telemetria de 10 mil sensores industriais em tempo real, detectando anomalias que indicam risco de falha em equipamentos com modelos Prophet e LSTM treinados no mesmo ambiente. O lakehouse unifica dados de sensores, histórico de manutenções e preços do mercado de energia em um único repositório com ACID e time travel, permitindo que engenheiros reprocessem qualquer período histórico para validar novos algoritmos de manutenção preditiva sem depender de backups de dados brutos.

Plataforma de marketplace com dados de transações, comportamento e logística para pricing dinâmico

Feature Store do Databricks centraliza centenas de features calculadas sobre dados de transações, comportamento de usuários e logística, servindo tanto o treinamento de modelos de pricing quanto a inferência em tempo real via REST API. O MLflow rastreia cada experimento de modelo com o conjunto de features usado, o dataset de treino e as métricas de performance, garantindo que qualquer modelo promovido para produção seja auditável — dado que decisões de precificação têm impacto direto em receita e exigem explicabilidade para o time de negócio.

// decisão técnica

Quando usar — e quando não usar

Use quando

O projeto combina engenharia de dados em larga escala (ETL/ELT com Spark), analytics avançados e ML/AI em um único ambiente, e separar essas disciplinas em ferramentas distintas criaria custo de integração e movimentação de dados.
O volume de dados requer processamento distribuído (dezenas a centenas de terabytes) e o lakehouse com Delta Lake sobre S3 ou ADLS é mais econômico do que um warehouse MPP tradicional para esse volume.
Feature engineering iterativo para modelos de ML precisa acessar dados históricos completos com ACID e time travel, sem exportar dados para um ambiente separado de treino.
A equipe é multidisciplinar — engenheiros de dados, analistas e cientistas de dados — e manter todos em uma única plataforma com notebooks, SQL e Python reduz fricção de colaboração.
Há necessidade de processamento híbrido batch + streaming sobre os mesmos dados e a mesma camada Delta Lake, sem manter dois sistemas e dois conjuntos de código distintos.

Evite quando

O workload é exclusivamente analítico SQL sem ML e o volume não justifica processamento distribuído; BigQuery, Redshift ou Snowflake servem com menos custo e menos complexidade operacional do que um cluster Databricks.
O time não tem familiaridade com Spark e programação distribuída; o Databricks reduz o overhead operacional do Spark mas não elimina a necessidade de entender particionamento, shuffle e otimização de jobs — código Spark mal escrito em Databricks ainda gera jobs lentos e caros.
O budget é restrito e os workloads são esporádicos; o custo de clusters Databricks (DBUs + custo de cloud) pode superar alternativas serverless quando os jobs rodam poucas vezes por semana com volumes menores.
O projeto é um primeiro passo em dados da empresa sem maturidade analítica estabelecida; começar com Databricks antes de ter dados confiáveis, pipelines estruturados e consumidores de dados reais é arquitetura prematura que gera custo sem retorno.

// visão lumi

O Databricks é a plataforma que a Lumi escolhe quando o problema exige a trifeta de engenharia de dados em escala, analytics avançado e ML em produção — e não antes. O erro mais frequente que vemos é adotar Databricks como substituto de um data warehouse simples, pagando por um jato quando uma bicicleta resolveria. Quando o Databricks entra, a primeira decisão crítica é o Unity Catalog: governança de dados na plataforma não é optional, e projetos que ignoram isso no início criam um problema de governança retroativo que é muito mais caro de resolver. Nossa abordagem com Databricks inclui sempre: Delta Live Tables para pipelines declarativos com qualidade de dados embutida, MLflow para rastreabilidade de experimentos, e Feature Store para reutilização de features entre projetos de ML.

Lumi escolhe quando

Quando o projeto une ETL em larga escala, analytics e ML e separar as disciplinas em plataformas distintas criaria custo de integração e movimentação de dados maior do que o custo do Databricks.
Quando o lakehouse com Delta Lake sobre S3 ou ADLS é a arquitetura mais custo-efetiva para o volume de dados e a necessidade de processamento distribuído é real.
Quando a empresa tem cientistas de dados que precisam de acesso a dados completos para treinamento de modelos e a Feature Store centralizada evita a criação de silos de features por time.
Quando há processamento de streaming e batch sobre os mesmos dados e a unificação em Structured Streaming com Delta Lake reduz a carga de manutenção do time.

Lumi não recomenda quando

Quando o workload é puramente analítico SQL sem ML e um warehouse serverless resolve com custo e operação inferiores.
Quando o time não tem base em Spark ou sistemas distribuídos e o projeto não inclui capacitação — Databricks não elimina a curva de aprendizado, apenas remove o overhead de infra.
Quando a empresa está em fase inicial sem dados estruturados e consumidores estabelecidos; Databricks nessa fase é arquitetura de vaidade que consome budget sem entregar valor.

// aplicações

Onde essa tecnologia gera valor

Lakehouse com Delta Lake

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

ETL/ELT com Spark

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Feature engineering e ML

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Processamento batch e streaming

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

// fundamentos

Referências acadêmicas e técnicas

Armbrust, M., Ghodsi, A., Xin, R., & Zaharia, M. (2021). Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. CIDR 2021.

Paper fundacional da arquitetura lakehouse que o Databricks implementa, unificando data lake e data warehouse em uma única plataforma.

Armbrust, M., Das, T., Sun, L., Murthy, B., Yavuz, S., Zhu, S., Ghodsi, A., Stoica, I., & Zaharia, M. (2020). Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores. VLDB 2020.

Descreve o Delta Lake como implementação de ACID e time travel sobre object storage, fundação técnica do lakehouse no Databricks.

Zaharia, M., Xin, R. S., Wendell, P., Das, T., Armbrust, M., Dave, A., Meng, X., Rosen, J., Venkataraman, S., Franklin, M. J., Ghodsi, A., Gonzalez, J., Shenker, S., & Stoica, I. (2016). Apache Spark: A Unified Engine for Big Data Processing. Communications of the ACM, 59(11), 56–65.

Contextualiza o Spark como motor unificado para batch, streaming, SQL e ML — a engine central do Databricks.

Reis, J., & Huyen, C. (2022). Fundamentals of Data Engineering. O'Reilly Media.

Identifica fragmentação de ferramentas como custo central de times de dados modernos, motivando plataformas unificadas como o Databricks.

Databricks. (2023). Delta Lake Documentation. https://docs.delta.io/latest/index.html

Documentação oficial do Delta Lake cobrindo transaction log, time travel, schema evolution e integração com Spark e Unity Catalog.

// tecnologias relacionadas

Nuvem

// próximo passo

Quer saber se esse stack faz sentido para você?

A Lumi avalia contexto, dados, equipe, custo e maturidade para recomendar a tecnologia certa e entregar com responsabilidade.

Avaliar meu stack →Voltar ao stack