// dados.lumi

Dados

Da ingestão à governança: construímos pipelines de dados confiáveis que viram ativo estratégico.

A engenharia de dados moderna vai muito além de mover arquivos entre sistemas — ela define a qualidade, a confiabilidade e a velocidade com que decisões podem ser tomadas. Trabalhamos com o ecossistema moderno de dados, integrando orquestração, processamento distribuído e transformação analítica em arquiteturas que escalam com o negócio. Cada decisão de stack é guiada por rigor técnico e pelo impacto mensurável que ela gera para quem consome os dados.

Avaliar meu stack →Ver serviços Lumi

// o que é

Engenharia de dados é a disciplina responsável por projetar, construir e operar os sistemas que coletam, armazenam, transformam e disponibilizam dados para análise e decisão. Diferente do desenvolvimento de software tradicional, ela exige domínio simultâneo de sistemas distribuídos, modelagem analítica, qualidade de dados e governança. A confiabilidade de um pipeline de dados é tão crítica quanto a de qualquer serviço de produção: dados incorretos ou atrasados podem custar mais do que a ausência de dados. Com a popularização do paradigma Data Mesh (Dehghani, 2022), pipelines monolíticos centralizam responsabilidade em equipes de plataforma enquanto domínios de negócio passam a ser donos de seus próprios produtos de dado.

// tecnologias

O que compõe a stack de Dados

Transformaçãodbt

Camada de transformação SQL versionada, com testes de qualidade embutidos e documentação automática do lineage de dados.

OrquestraçãoAirflow

Orquestrador de workflows baseado em DAGs Python, responsável por agendar, monitorar e gerenciar dependências entre tarefas de pipeline.

Streaming / IngestãoKafka

Plataforma de streaming distribuído baseada em log imutável, usada para ingestão de eventos em tempo real e como backbone de arquiteturas orientadas a eventos.

ProcessamentoSpark

Motor de processamento distribuído para transformações de alto volume em batch e micro-batch, com suporte a SQL, ML e grafos.

Armazenamento / AnáliseBigQuery

Data warehouse serverless do Google Cloud, otimizado para queries analíticas de larga escala com separação de armazenamento e computação.

Armazenamento / AnáliseRedshift

Data warehouse colunar gerenciado da AWS, integrado ao ecossistema S3 via Spectrum e com suporte a workload management para concorrência.

// arquitetura

Padrões e abordagens para Dados

Arquitetura Medallion (Bronze / Silver / Gold)

Organiza os dados em camadas de refinamento progressivo: Bronze recebe dados brutos como chegam, Silver normaliza e valida, Gold entrega agregados prontos para consumo analítico. Esse padrão, popularizado pelo Databricks, simplifica rastreabilidade, facilita reprocessamento e delimita contratos claros entre produtores e consumidores de dados.

Ideal paraData lakes e lakehouses onde múltiplas equipes consomem o mesmo dado com diferentes níveis de tratamento

Lambda Architecture

Combina um batch layer de alta latência e alta correção com um speed layer de baixa latência e dados aproximados, fundidos em uma serving layer. É adequada quando existe necessidade de resultados históricos precisos e respostas em tempo real simultâneas, embora exija manutenção de dois sistemas de processamento distintos.

Ideal paraSistemas que precisam de histórico preciso e alertas near-realtime ao mesmo tempo

Kappa Architecture

Simplifica a Lambda tratando todo dado — histórico e em tempo real — como stream, eliminando o batch layer e reduzindo a complexidade operacional. O log de eventos (tipicamente Kafka) serve como fonte única da verdade e permite reprocessamento completo quando necessário.

Ideal paraTimes com maturidade em streaming que querem reduzir duplicidade de código entre batch e real-time

Data Mesh

Distribui a responsabilidade dos dados entre domínios de negócio autônomos, cada um publicando seus dados como produto com SLA e contrato de qualidade explícitos. A plataforma centralizada fornece infraestrutura self-service, mas a ownership permanece nos times de domínio, resolvendo o gargalo de equipes centrais de dados.

Ideal paraOrganizações com múltiplos domínios de negócio e equipes de dados que se tornaram gargalo de entrega

// como escolher

Escolher uma ou combinar?

Escolher o stack de dados correto depende do volume, velocidade e variedade dos dados, mas também da maturidade do time e dos SLAs de consumo. Não existe uma stack universal: a combinação certa equilibra custo operacional, velocidade de desenvolvimento e confiabilidade.

Se o volume de dados é moderado (< 1 TB/dia) e o time é pequeno

use BigQuery ou Redshift com dbt para transformações, evitando a complexidade de Spark e Kafka prematuramente

Se há necessidade de processamento de eventos em tempo real

combine Kafka para ingestão de streams com Spark Structured Streaming ou Flink para transformações, mantendo um Airflow para orquestração de jobs batch complementares

Se o time é familiar com SQL e não tem engenheiros de dados Spark

adote dbt como camada de transformação principal — ele permite que analistas escrevam transformações testáveis sem precisar de um motor distribuído separado

Se a organização tem múltiplos domínios de negócio com dados siloed

considere Data Mesh com Airflow para orquestração federada e dbt para contratos de transformação por domínio

Se o volume cresce para dezenas de TB/dia com pipelines complexos

introduza Spark no Databricks ou EMR para processamento distribuído, mantendo Airflow para orquestração e dbt para a camada gold de transformação analítica

Se há reprocessamento histórico frequente de grandes volumes

prefira arquitetura Kappa com Kafka como log central, permitindo replay completo sem manter um batch layer separado

Na prática, a stack de dados moderna combina múltiplos componentes em camadas complementares: Kafka para ingestão de eventos, Airflow para orquestração de workflows, Spark para processamento pesado e dbt para transformações analíticas — cada um resolvendo um problema específico no pipeline. BigQuery e Redshift não são substitutos um do outro mas sim opções de serving layer que se integram com os demais componentes via conectores nativos. A chave é não introduzir complexidade antes que o volume e os requisitos justifiquem: times jovens entregam mais valor com BigQuery + dbt do que com uma stack Kafka + Spark prematuramente adotada.

// como a Lumi atua

Na Lumi Data Hub, tratamos dados como produto — não como subproduto de outras iniciativas. Cada pipeline que construímos tem owner definido, SLA documentado, testes automatizados e lineage rastreável do dado bruto até o painel de decisão. Nossa abordagem elimina o "pipeline spaghetti" que paralisa times de dados em estágios de crescimento.

Princípios que aplicamos

Implementar testes de qualidade de dado (not_null, unique, referential integrity) em dbt antes de qualquer dado chegar ao consumidor final
Versionar todos os modelos de transformação em Git com CI/CD, tratando o código de dados com a mesma disciplina do código de aplicação
Documentar o lineage de cada coluna crítica de negócio para rastrear impacto de mudanças upstream antes de promover alterações
Estabelecer contratos de dado explícitos (schema, SLA, owner) entre produtores e consumidores antes de iniciar o desenvolvimento do pipeline
Monitorar freshness e row count de tabelas críticas com alertas proativos, não reativos

Armadilhas que evitamos

Construir pipelines sem testes de qualidade e descobrir dados incorretos apenas quando um KPI do board está errado
Criar um data warehouse sem modelagem dimensional clara, resultando em queries lentas e métricas inconsistentes entre times
Usar Spark para datasets que cabem em um único nó, adicionando complexidade operacional sem ganho de performance
Ignorar particionamento e clustering em BigQuery/Redshift, gerando custos de query desnecessários à medida que o volume cresce

// fundamentos

Referências acadêmicas e da indústria

Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media.

Referência canônica sobre sistemas de dados distribuídos, cobrindo replicação, particionamento, consistência e streams como fundamentos de toda engenharia de dados moderna.

Marz, N., & Warren, J. (2015). Big Data: Principles and Best Practices of Scalable Real-Time Data Systems. Manning Publications.

Introduz a Lambda Architecture e estabelece princípios de sistemas de dados que separam batch de speed layers para tolerância a falhas.

Kreps, J. (2014). Questioning the Lambda Architecture. O'Reilly Radar.

Artigo seminal que questiona a complexidade da Lambda Architecture e propõe a Kappa Architecture baseada em log unificado com Kafka.

Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. O'Reilly Media.

Formaliza o paradigma Data Mesh com ownership distribuída de dados por domínio, infraestrutura self-service e governança federada como solução para escala organizacional.

Reis, J., & Huyen, C. (2022). Fundamentals of Data Engineering: Plan and Build Robust Data Systems. O'Reilly Media.

Define o ciclo de vida de engenharia de dados e avalia componentes do ecossistema moderno incluindo dbt, Airflow, Spark e data warehouses cloud.

Inmon, W. H. (2002). Building the Data Warehouse (4th ed.). Wiley.

Obra fundacional da arquitetura de data warehouse com abordagem top-down (CIF), contrastando com a abordagem dimensional de Kimball e influenciando gerações de arquiteturas de dados.

Armbrust, M., et al. (2021). Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. CIDR 2021.

Paper que formaliza o conceito de Lakehouse, unindo a flexibilidade do data lake com as garantias ACID e performance do data warehouse — base do Databricks Delta Lake.

// próximo passo

Transforme seus dados em ativo estratégico

Avaliamos sua arquitetura atual, identificamos gargalos de qualidade e confiabilidade, e desenhamos o roadmap de engenharia de dados ideal para o tamanho e maturidade do seu negócio.

Avaliar meu stack →Ver todas as stacks