// stack.lumi

Dados

Spark

Processamento distribuido para dados grandes e transformacoes complexas.

// o que é

Apache Spark processa grandes volumes de dados em batch ou streaming com paralelismo distribuido. No contexto da Lumi Data, ele e indicado para pipelines pesados, enriquecimento de bases e preparacao de dados para BI e ML.

O Apache Spark surgiu como resposta às limitações do modelo MapReduce do Hadoop, que exigia escrita em disco entre cada estágio de processamento (Dean & Ghemawat, 2004). Zaharia et al. (2010) propuseram o conceito de RDD (Resilient Distributed Dataset), que mantém dados em memória distribuída e permite operações iterativas — fundamentais para algoritmos de Machine Learning — com desempenho até 100x superior ao MapReduce em certos workloads. A abstração de DataFrames e Datasets introduzida no Spark 2.x (Armbrust et al., 2015) trouxe otimização de queries via Catalyst e Tungsten, aproximando o modelo de programação do SQL sem sacrificar a expressividade da API. A unificação de batch e streaming no Structured Streaming representa um passo em direção à Kappa Architecture de Kreps (2014), tratando dados históricos e em tempo real com a mesma API e garantias de exatamente-uma-vez.

Como a Lumi enxerga:A Lumi otimiza particionamento, formato de arquivos, custos de cluster e confiabilidade dos jobs para que Spark gere escala sem desperdicio.

// na prática

Como empresas usam Spark

Empresa de telecomunicações processando logs de rede para detecção de anomalias

Jobs Spark no Databricks processam 2 TB diários de logs de CDRs e registros de rede, aplicando joins complexos e agregações para detectar padrões de fraude SIM swap e consumo anômalo. O que levava 6 horas em procedimentos SQL no DWH legado passou a rodar em 40 minutos com Spark, liberando a janela de processamento noturno e permitindo que o time de dados execute análises exploratórias ad hoc no mesmo cluster sem impactar o job de produção.

Plataforma de crédito com feature engineering para modelos de ML em escala

Spark com PySpark processa histórico transacional de 5 anos de clientes para calcular centenas de features comportamentais (média de gastos, variância de renda, padrão de pagamento) que alimentam modelos XGBoost e redes neurais. A integração nativa com MLflow no Databricks permite versionar features e modelos juntos, garantindo que o modelo em produção e o conjunto de features com que foi treinado sejam sempre rastreáveis.

Varejista com lakehouse em S3 e processamento de eventos de clickstream

Spark Structured Streaming consome eventos de navegação do Kafka e os processa em micro-batches de 30 segundos, atualizando contadores de conversão e carrinhos abandonados em quase-tempo-real. O mesmo código Spark é reutilizado em modo batch para processar o histórico completo de 18 meses quando novos modelos de recomendação precisam ser treinados, evitando manutenção de duas bases de código distintas.

// decisão técnica

Quando usar — e quando não usar

Use quando

O volume de dados a ser processado não cabe em memória de uma única máquina e a transformação exige distribuição de carga entre múltiplos workers — Spark é a escolha madura e amplamente testada para esse cenário.
O pipeline combina processamento batch e streaming e o time quer manter uma única API e base de código para ambos os padrões, usando Structured Streaming.
Feature engineering para modelos de ML envolve operações iterativas sobre grandes datasets; a abstração in-memory do Spark é significativamente mais eficiente que alternativas disk-based.
O workload já está em Databricks ou EMR e aproveitar o processamento distribuído nativo dessas plataformas elimina a necessidade de ferramentas adicionais.
Há necessidade de processar formatos abertos de lakehouse (Delta Lake, Iceberg, Hudi) com suporte a ACID, time travel e schema evolution em escala.

Evite quando

O dataset tem menos de alguns gigabytes e uma query SQL no BigQuery, Redshift ou DuckDB processa com custo e latência inferiores sem nenhuma infraestrutura de cluster para gerenciar.
A transformação é simples — limpeza básica, cast de tipos, joins triviais — e o overhead de um cluster Spark (custo, tempo de inicialização, debugging) não se justifica frente ao problema resolvido.
O time não tem familiaridade com programação distribuída e os conceitos de particionamento, shuffle, skew e UDFs não serializable; Spark mal usado (ex: collect() em grandes datasets) é pior do que não usar Spark.
O orçamento é restrito e o workload pode ser resolvido por um warehouse serverless moderno (BigQuery, Athena, Redshift Serverless) que cobra por query sem custo de cluster idle.

// visão lumi

A Lumi posiciona Spark onde o volume e a complexidade realmente exigem processamento distribuído — e não como padrão para todo pipeline de dados. Vemos muitos projetos usando Spark para processar 500 MB de dados que uma query BigQuery resolveria em 10 segundos. Quando Spark entra, preferimos o ambiente gerenciado do Databricks ou EMR, que eliminam o trabalho operacional de configuração de cluster e otimização de Spark versão por versão. Um sinal de projeto saudável é quando o time consegue articular por que o processamento precisa ser distribuído — volume, algoritmos iterativos, latência de streaming — em vez de simplesmente replicar o que o colega de outra empresa usa.

Lumi escolhe quando

Quando o volume de dados processado diariamente supera dezenas de gigabytes e queries SQL no warehouse são lentas ou caras demais para o workload.
Quando o projeto envolve feature engineering em larga escala para modelos de ML e a integração nativa com MLflow e Delta Lake no Databricks agrega valor real.
Quando a arquitetura é lakehouse (S3/GCS/ADLS com Delta Lake ou Iceberg) e Spark é o motor de processamento nativo dessas camadas.
Quando há processamento híbrido batch + streaming no mesmo pipeline e manter uma única API reduz a carga cognitiva e de manutenção do time.

Lumi não recomenda quando

Quando o dataset cabe em memória de uma única máquina e uma ferramenta como DuckDB ou pandas resolve com zero overhead operacional.
Quando o time não tem experiência com sistemas distribuídos e o projeto não inclui capacitação — Spark mal configurado gera custos altos e resultados lentos.
Quando o orçamento não comporta um cluster sempre ativo e o workload é esporádico; nesses casos, engines serverless são mais econômicas.

// aplicações

Onde essa tecnologia gera valor

ETL de alto volume

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 de logs e eventos

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

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

Jobs em Databricks, EMR ou Kubernetes

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

Zaharia, M., Chowdhury, M., Franklin, M. J., Shenker, S., & Stoica, I. (2010). Spark: Cluster Computing with Working Sets. HotCloud 2010.

Paper original do Spark, introduzindo RDDs e o modelo in-memory como alternativa ao MapReduce disk-based.

Zaharia, M., Das, T., Li, H., Shenker, S., & Stoica, I. (2012). Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing. NSDI 2012.

Formalização do RDD com garantias de tolerância a falhas, base da abstração de processamento distribuído do Spark.

Armbrust, M., Xin, R. S., Lian, C., Huai, Y., Liu, D., Bradley, J. K., Meng, X., Kaftan, T., Franklin, M. J., Ghodsi, A., & Zaharia, M. (2015). Spark SQL: Relational Data Processing in Spark. ACM SIGMOD 2015.

Apresenta DataFrames e o otimizador Catalyst, aproximando Spark de uma engine SQL sem sacrificar expressividade programática.

Dean, J., & Ghemawat, S. (2004). MapReduce: Simplified Data Processing on Large Clusters. OSDI 2004.

Paradigma MapReduce original do Google que o Spark superou, contextualizando a motivação para in-memory computing.

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 Delta Lake como formato de armazenamento com ACID sobre object storage, contextualizando o ecossistema Spark/Databricks.

// tecnologias relacionadas

Dados

// 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