Visão geral do ecossistema
Engenharia de dados é a disciplina de construir sistemas confiáveis que movem, armazenam e preparam dados para consumo analítico e operacional. O mercado se organizou em camadas bem definidas — e entender essas camadas vale mais do que decorar nomes de ferramentas, porque as ferramentas mudam, mas as camadas permanecem.
As camadas do stack moderno
| Camada | Pergunta que responde | Exemplos de ferramentas |
|---|---|---|
| Ingestão / Integração | Como trago dados das fontes (APIs, bancos, SaaS, eventos) para dentro? | Airbyte, Fivetran, Kafka, Debezium, NiFi |
| Armazenamento | Onde os dados vivem? Warehouse, lake ou lakehouse? | Snowflake, BigQuery, Redshift, Databricks, S3 + Iceberg/Delta |
| Transformação | Como limpo, modelo e agrego dados brutos em dados confiáveis? | dbt, Spark, DuckDB, Polars |
| Processamento em streaming | Como processo eventos em tempo (quase) real? | Kafka, Flink, Spark Structured Streaming, Redpanda |
| Orquestração | Quem dispara o quê, em que ordem, e o que acontece quando falha? | Airflow, Dagster, Prefect, Mage |
| Qualidade & Observabilidade | Os dados estão corretos, completos e atualizados? | Great Expectations, Soda, Monte Carlo, testes do dbt |
| Catálogo & Governança | Que dados existem, quem é dono, quem pode acessar, de onde vieram (linhagem)? | DataHub, OpenMetadata, Unity Catalog, Atlan |
| Consumo / BI | Como as pessoas enxergam e usam os dados? | Power BI, Looker, Tableau, Metabase, Superset |
ETL vs. ELT — a mudança de paradigma
No modelo clássico ETL (Extract → Transform → Load), a transformação acontecia antes de carregar no destino, em servidores dedicados — porque armazenamento e computação no warehouse eram caros. Com warehouses em nuvem que separam armazenamento de computação (Snowflake, BigQuery), o mercado migrou para ELT: carrega-se o dado bruto primeiro e transforma-se dentro do warehouse, com SQL versionado (tipicamente dbt). Isso simplificou pipelines, preservou o dado bruto como fonte de auditoria e deu origem ao chamado Modern Data Stack.
Open-source vs. pago — como ler os badges deste guia
| Badge | Significado | Implicação prática |
|---|---|---|
| Open-source | Código aberto, você opera (self-hosted) | Sem custo de licença, mas custo de operação (infra, upgrades, on-call) é seu |
| Híbrido | Núcleo open-source + versão gerenciada paga | Você escolhe: operar de graça ou pagar para terceirizar a operação (ex.: Airflow → Astronomer/MWAA, Kafka → Confluent) |
| Pago / SaaS | Produto comercial, fechado, gerenciado | Zero operação, time-to-value rápido, mas custo cresce com uso e há lock-in |
Ingestão & Integração de dados
A camada que conecta fontes (bancos transacionais, APIs, SaaS, arquivos, eventos) ao destino analítico. Divide-se em duas famílias: batch/ELT (sincronizações periódicas de conectores) e CDC/streaming (captura de mudanças em tempo real a partir do log de transações do banco).
Plataforma de ELT com 600+ conectores. Roda self-hosted (gratuito) ou em nuvem gerenciada. Conectores são containers padronizados, e o CDK permite criar conectores próprios rapidamente — útil para APIs brasileiras sem conector pronto.
Referência em ELT gerenciado: conectores de altíssima confiabilidade, schema drift tratado automaticamente, zero manutenção. Cobra por linhas ativas mensais (MAR), o que pode encarecer com volume.
Plataforma distribuída de streaming de eventos — o "sistema nervoso" de dados em tempo real. Produtores publicam em tópicos particionados; consumidores leem de forma independente. Kafka Connect adiciona conectores de entrada/saída. Versão gerenciada: Confluent Cloud, Amazon MSK.
Padrão de mercado para CDC (Change Data Capture): lê o log de transações de MongoDB (oplog/change streams), PostgreSQL (WAL), MySQL (binlog) e outros, e publica cada mudança como evento — tipicamente no Kafka.
Ferramenta visual de fluxo de dados (drag-and-drop) com proveniência nativa — cada dado carrega seu histórico. Forte em ambientes corporativos/governamentais com requisitos de rastreabilidade e roteamento complexo.
Biblioteca Python para construir pipelines de ingestão como código — sem servidor, sem UI. Inferência automática de schema, carga incremental e destino plugável. Cresceu muito como alternativa leve a plataformas inteiras.
Serviços de integração nativos das nuvens. ADF é visual e forte no ecossistema Microsoft; Glue é serverless, baseado em Spark, com catálogo de dados integrado ao ecossistema AWS.
Comparativo — Ingestão
| Ferramenta | Modelo | Paradigma | Curva | Melhor para |
|---|---|---|---|---|
| Airbyte | OSS + Cloud | ELT batch (conectores) | ●●●●● | ELT com controle de custo e conectores customizados |
| Fivetran | SaaS pago | ELT batch gerenciado | ●●●●● | Confiabilidade máxima sem time de manutenção |
| Kafka | OSS + gerenciado | Streaming de eventos | ●●●●● | Backbone de eventos de alto volume |
| Debezium | OSS | CDC (log-based) | ●●●●● | Replicação de bancos OLTP em near-real-time |
| NiFi | OSS | Fluxo visual | ●●●●● | Integrações heterogêneas com proveniência |
| dlt | OSS | ELT como código Python | ●●●●● | Pipelines leves, versionados, Python-first |
| ADF / Glue | SaaS pago | ETL/ELT nativo de nuvem | ●●●●● | Ecossistemas 100% Azure ou AWS |
Armazenamento analítico
Três arquiteturas dominam: o data warehouse (SQL gerenciado, dados estruturados), o data lake (arquivos baratos em object storage) e o lakehouse (lake + formatos de tabela transacionais como Delta e Iceberg, unindo o melhor dos dois).
Warehouse em nuvem que popularizou a separação total entre armazenamento e computação: múltiplos "virtual warehouses" escalam de forma independente sobre os mesmos dados. SQL completo, Time Travel, compartilhamento de dados entre contas e suporte a Iceberg.
Warehouse serverless: você não gerencia cluster nenhum, paga por dados escaneados (ou capacidade reservada). Escala a petabytes sem tuning, com ML embutido (BQML) e integração nativa com o ecossistema Google.
Plataforma lakehouse construída sobre Spark + Delta Lake, com Unity Catalog para governança, notebooks colaborativos e forte integração de engenharia + ciência de dados + ML no mesmo ambiente.
Warehouse da AWS, colunar e baseado em PostgreSQL (dialeto). Evoluiu com RA3 (armazenamento separado), Serverless e Spectrum (consulta direta ao S3). Integração profunda com o ecossistema AWS.
Banco colunar open-source absurdamente rápido para analytics em tempo real: agregações sobre bilhões de linhas em milissegundos. Ideal para dashboards de alta concorrência e dados de eventos/observabilidade.
O banco relacional de propósito geral mais respeitado do mercado. Para volumes pequenos e médios, é também um warehouse analítico perfeitamente viável — e a fundação conceitual (MVCC, planos de execução, índices) que todo engenheiro de dados precisa dominar.
Formatos de tabela do lakehouse
Formato de tabela aberto que virou padrão neutro do mercado: transações ACID sobre arquivos Parquet, evolução de schema e partição, time travel. Suportado por Snowflake, BigQuery, Databricks, Trino, Spark e Flink.
Formato transacional criado pela Databricks (hoje open-source na Linux Foundation). Integração mais profunda do ecossistema Spark/Databricks, com MERGE eficiente, time travel e otimizações como Z-Ordering e Liquid Clustering.
Pioneiro em upserts incrementais no data lake (criado na Uber). Forte em ingestão contínua com atualizações frequentes (modos Copy-on-Write e Merge-on-Read) e consultas incrementais.
Comparativo — Armazenamento
| Ferramenta | Arquitetura | Modelo de custo | Operação | Melhor para |
|---|---|---|---|---|
| Snowflake | Warehouse (multi-cloud) | Créditos por compute + storage | Zero infra | Analytics corporativo concorrente |
| BigQuery | Warehouse serverless | Por TB escaneado ou capacidade | Zero infra | Cargas elásticas, times enxutos |
| Databricks | Lakehouse (Spark + Delta) | DBUs + infra da nuvem | Baixa/média | Dados + ML unificados, grande escala |
| Redshift | Warehouse (AWS) | Por nó ou serverless (RPU) | Baixa/média | Ecossistema AWS consolidado |
| ClickHouse | OLAP colunar | OSS grátis / Cloud pago | Média (self-hosted) | Real-time e analytics user-facing |
| PostgreSQL | Relacional geral | Grátis (infra por sua conta) | Média | OLTP + analytics de pequeno/médio porte |
Caso especial — Databricks: a plataforma que atravessa as camadas
O Databricks está classificado aqui em Armazenamento porque o lakehouse (object storage + Delta Lake) é o coração da proposta — mas ele é um caso à parte neste guia: não é uma ferramenta de uma camada só, e sim uma plataforma que cobre quase todas elas. Entender esse mapa evita comparações injustas ("Databricks vs. dbt" não faz sentido; "Databricks vs. o conjunto Snowflake + dbt + Airflow + catálogo" sim).
| Camada do stack | O que o Databricks oferece | Equivalente "peça a peça" |
|---|---|---|
| Armazenamento | Lakehouse: seu object storage (S3/ADLS/GCS) + Delta Lake com ACID, time travel e schema enforcement | Snowflake, BigQuery, S3 + Iceberg |
| Transformação | Apache Spark (a empresa foi fundada pelos criadores) + Photon, engine vetorizada proprietária que acelera SQL; também roda dbt via SQL Warehouse | Spark gerenciado, dbt + warehouse |
| Streaming | Structured Streaming e pipelines declarativas (antigo Delta Live Tables, hoje parte do Lakeflow) para ingestão e processamento contínuo | Kafka + Flink/Spark Streaming |
| Orquestração | Workflows / Lakeflow Jobs: agendamento, dependências, retries e alertas — pipelines internos muitas vezes dispensam Airflow | Airflow, Dagster |
| Governança | Unity Catalog: catálogo unificado, linhagem automática e controle de acesso fino (tabelas, arquivos, modelos) | DataHub, OpenMetadata |
| Qualidade | Expectations nas pipelines declarativas + constraints em tabelas Delta | Great Expectations, Soda |
| BI & ML | Dashboards AI/BI, notebooks colaborativos, MLflow (ciclo de vida de modelos) e feature store | Power BI/Looker + MLflow self-hosted |
Transformação & Processamento
Onde o dado bruto vira dado confiável. Duas filosofias convivem: transformação in-warehouse com SQL (dbt) e processamento programático (Spark, Polars, DuckDB) — e a escolha depende do volume, da latência e da equipe.
A ferramenta que trouxe engenharia de software para o SQL: modelos versionados no Git, dependências resolvidas automaticamente (DAG), testes de dados, documentação gerada e ambientes dev/prod. dbt Core é open-source; dbt Cloud/Platform adiciona IDE, agendamento e semantic layer.
O motor distribuído de propósito geral: processa de gigabytes a petabytes em cluster, com APIs em Python (PySpark), SQL, Scala e R. Cobre batch, streaming (Structured Streaming) e ML (MLlib). Gerenciado em Databricks, EMR, Dataproc e Synapse.
"O SQLite do analytics": banco OLAP colunar embarcado, sem servidor, que consulta Parquet/CSV/JSON direto do disco ou do S3 com performance impressionante. Virou peça central do movimento de processamento single-node.
DataFrames em Rust com API Python: execução paralela, lazy evaluation com otimizador de query e uso de memória muito menor que pandas. Para transformações programáticas single-node, é o novo padrão de performance.
A biblioteca de manipulação de dados mais usada do mundo Python. Não é a mais rápida nem a mais econômica em memória, mas é vocabulário universal — todo notebook, tutorial e entrevista assume que você a conhece.
Concorrente moderno do dbt: entende SQL semanticamente (via SQLGlot), oferece ambientes virtuais de dados, detecção de mudanças que quebram contratos e backfills incrementais mais inteligentes.
Comparativo — Transformação
| Ferramenta | Linguagem | Escala | Curva | Melhor para |
|---|---|---|---|---|
| dbt | SQL + Jinja | A do warehouse | ●●●●● | Modelagem ELT versionada e testada |
| Spark | Python/SQL/Scala | TB–PB (cluster) | ●●●●● | Processamento distribuído de grande volume |
| DuckDB | SQL | GB–centenas de GB (1 máquina) | ●●●●● | Analytics local rápido sobre arquivos |
| Polars | Python (Rust por baixo) | GB–centenas de GB (1 máquina) | ●●●●● | DataFrames de alta performance |
| pandas | Python | Até poucos GB | ●●●●● | Exploração e prototipagem |
| SQLMesh | SQL/Python | A do warehouse | ●●●●● | Alternativa avançada ao dbt |
Processamento em Streaming
Quando minutos de atraso não são aceitáveis: detecção de fraude, personalização, monitoramento. O padrão arquitetural típico é transporte (Kafka/Redpanda/Kinesis) + processamento (Flink/Spark Streaming) + serving (ClickHouse/warehouse).
O motor de referência para stream processing verdadeiro (evento a evento): estado gerenciado, semântica exactly-once, event time com watermarks e janelas sofisticadas. APIs em SQL, Java e Python (PyFlink).
Streaming por micro-batches sobre o mesmo motor e API do Spark batch. Latência típica de segundos — suficiente para a maioria dos casos "near real-time" — com a vantagem de reutilizar código e conhecimento do time.
Reimplementação do protocolo Kafka em C++, sem ZooKeeper e sem JVM: um único binário, operação muito mais simples e latência menor. Compatível com todo o ecossistema de clientes Kafka.
Streaming totalmente gerenciado da AWS (Data Streams + Firehose para entrega direta em S3/Redshift). Menos flexível que Kafka, mas zero operação e integração nativa com IAM e Lambda.
Mensageria + streaming com arquitetura que separa serving (brokers) de storage (BookKeeper), multi-tenancy nativo e geo-replicação. Tecnicamente elegante, com comunidade menor que a do Kafka.
Comparativo — Streaming
| Ferramenta | Papel | Latência típica | Operação | Melhor para |
|---|---|---|---|---|
| Kafka | Transporte (log de eventos) | ms | Alta (self) / baixa (Confluent) | Backbone de eventos padrão de mercado |
| Redpanda | Transporte (compatível Kafka) | ms | Baixa | Kafka simplificado |
| Kinesis | Transporte gerenciado | ms–s | Zero | Eventos no ecossistema AWS |
| Flink | Processamento stateful | ms | Alta | Streaming verdadeiro, lógica complexa |
| Spark Str. Streaming | Processamento micro-batch | s | Média | Near real-time em stack Spark |
| Pulsar | Transporte + filas | ms | Alta | Multi-tenancy e geo-replicação |
Orquestração de pipelines
O "maestro" do stack: agenda execuções, resolve dependências (DAGs), trata falhas com retries, alerta e dá visibilidade. É a camada onde a confiabilidade do pipeline é ganha ou perdida.
O padrão de mercado há quase uma década: DAGs definidos em Python, ecossistema gigantesco de providers (operadores prontos para tudo) e presença em praticamente toda vaga de engenharia de dados. O Airflow 3 modernizou a plataforma (nova UI, versionamento de DAGs, event-driven scheduling). Gerenciado via Astronomer, AWS MWAA e GCP Composer.
Orquestrador "asset-centric": em vez de orquestrar tarefas, você declara os ativos de dados (tabelas, arquivos, modelos) e o Dagster materializa o que estiver desatualizado. Tipagem, testes locais de primeira classe e integração elegante com dbt.
Filosofia "Python puro": qualquer função vira flow com um decorator, sem DSL rígida. Excelente para fluxos dinâmicos, irregulares e event-driven que não se encaixam bem no modelo de DAG estático.
Orquestrador com IDE de notebooks embutida: cada bloco do pipeline é editável e testável interativamente na UI. Aposta forte em experiência amigável para construir ELT rapidamente.
Orquestrador declarativo em YAML, event-driven, com centenas de plugins. A definição em YAML facilita governança e geração automatizada de pipelines, sem exigir Python da equipe.
Comparativo — Orquestração
| Ferramenta | Paradigma | Definição | Curva | Melhor para |
|---|---|---|---|---|
| Airflow | Task-centric (DAG) | Python | ●●●●● | Padrão de mercado, batch em produção |
| Dagster | Asset-centric | Python tipado | ●●●●● | Stacks dbt/ELT modernos com linhagem |
| Prefect | Flow-centric | Python puro | ●●●●● | Workflows dinâmicos e irregulares |
| Mage | Notebook-centric | UI + Python/SQL | ●●●●● | Prototipagem e times pequenos |
| Kestra | Event-driven declarativo | YAML | ●●●●● | Orquestração sem dependência de Python |
Qualidade, Observabilidade & Governança
A camada que separa um stack amador de um stack profissional: garantir que os dados estão corretos (qualidade), saber quando deixaram de estar (observabilidade) e saber o que existe, de onde veio e quem pode acessar (catálogo e governança).
Qualidade & Observabilidade
Framework Python de validação declarativa: você define "expectativas" (coluna não nula, valores dentro de faixa, unicidade) e o GX valida, documenta e reporta. Integra-se a Airflow, Spark e warehouses.
Checks de qualidade em YAML legível (SodaCL) executados direto no warehouse. Mais simples de adotar que o GX, com versão Cloud para monitoramento contínuo e alertas.
O dbt já traz testes nativos (unique, not_null, relationships, accepted_values) e pacotes como dbt-expectations e elementary adicionam testes avançados, detecção de anomalias e relatórios de observabilidade — tudo dentro do projeto dbt.
Líder da categoria "data observability": monitora automaticamente frescor, volume, schema e distribuição usando ML, detectando anomalias sem que você escreva regras — análogo ao Datadog, mas para dados.
Catálogo, Linhagem & Governança
Catálogo de metadados criado no LinkedIn: descoberta de dados, linhagem ponta a ponta, ownership e glossário de negócio, com ingestão de metadados de dezenas de fontes (warehouses, BI, orquestradores).
Catálogo open-source unificado com arquitetura mais simples que a do DataHub, incluindo qualidade de dados e profiling embutidos, além de colaboração (tarefas, anúncios) na própria plataforma.
Camada de governança do ecossistema Databricks (com núcleo open-source): controle de acesso fino, linhagem automática e catálogo unificado para tabelas, arquivos, modelos de ML e funções.
Catálogo SaaS "ativo": além de descoberta e linhagem, integra-se ao fluxo de trabalho (Slack, Jira) e automatiza políticas de governança. Forte apelo de usabilidade para usuários de negócio.
Comparativo — Qualidade & Governança
| Ferramenta | Categoria | Abordagem | Melhor para |
|---|---|---|---|
| Testes dbt | Qualidade | Declarativa, dentro do projeto dbt | Primeiro passo de qualidade em qualquer stack ELT |
| Great Expectations | Qualidade | Expectativas em Python, docs geradas | Validação rica e contratos de dados |
| Soda | Qualidade | Checks em YAML no warehouse | Adoção rápida, checks acessíveis a analistas |
| Monte Carlo | Observabilidade | Detecção automática por ML | Escala enterprise sem regras manuais |
| DataHub | Catálogo | Plataforma de metadados completa | Descoberta e linhagem em ambientes grandes |
| OpenMetadata | Catálogo | Tudo-em-um, instalação mais simples | Catálogo self-hosted unificado |
| Unity Catalog | Governança | Nativa do lakehouse Databricks | Controle de acesso e linhagem no Databricks |
| Atlan | Catálogo | SaaS colaborativo | Governança pronta para o negócio |
BI & Visualização
A ponta final do pipeline — onde o trabalho de engenharia vira decisão. Para o engenheiro de dados, importa entender como cada ferramenta consome o warehouse (live query vs. modelo importado) e o que isso exige da modelagem.
Dominante no mercado corporativo (e no Brasil): modelo semântico tabular (VertiPaq), DAX para medidas, Power Query (M) para preparação e integração total com Microsoft 365/Fabric. Licenciamento acessível na entrada.
Referência histórica em visualização exploratória: a experiência drag-and-drop de análise visual ainda é considerada a melhor da categoria. Parte do ecossistema Salesforce.
BI governado por código: a camada semântica LookML define métricas uma única vez, versionadas no Git, e tudo consulta o warehouse ao vivo. Hoje parte do Google Cloud.
O BI open-source mais amigável: sobe em minutos, perguntas em interface visual ou SQL, dashboards e alertas. Perfeito para dar autonomia a usuários de negócio sem custo de licença.
Plataforma de BI open-source mais completa (criada no Airbnb): dezenas de tipos de gráfico, SQL Lab para exploração e permissões granulares. Mais poderosa — e mais trabalhosa de operar — que o Metabase.
Caminhos "data apps como código": Streamlit transforma scripts Python em aplicações interativas; Evidence gera relatórios a partir de SQL + Markdown. Ótimos para entregar análises sob medida sem plataforma de BI.
Comparativo — BI
| Ferramenta | Modelo | Filosofia | Custo | Melhor para |
|---|---|---|---|---|
| Power BI | Pago | Modelo semântico importado (DAX) | Baixo na entrada | Corporativo Microsoft, mercado BR |
| Tableau | Pago | Exploração visual | Médio/alto | Visualização exploratória avançada |
| Looker | Pago | Métricas como código (LookML) | Alto | Governança de métricas em escala |
| Metabase | OSS + Cloud | Simplicidade self-service | Grátis (OSS) | Primeiro BI, PMEs, embed simples |
| Superset | OSS | Plataforma completa self-hosted | Grátis | BI técnico sem licenças |
| Streamlit/Evidence | OSS | Data apps como código | Grátis | Análises sob medida por engenheiros |
Arquiteturas de referência
Ferramentas são peças; arquiteturas são as plantas que resolvem problemas reais. Cada padrão abaixo nasceu de uma dor concreta do mercado — entender qual problema cada um resolve (e quando ele é exagero) é o que diferencia um engenheiro de dados de um colecionador de ferramentas.
Organização do dado
Arquitetura Medallion (Bronze → Silver → Gold)
Problema real: "transformamos o dado direto na ingestão e, quando a regra mudou, não tínhamos mais o original para reprocessar." A camada Bronze preserva o dado bruto como fonte de auditoria e reprocessamento; cada camada seguinte adiciona qualidade de forma incremental e rastreável.
Quando usar: praticamente qualquer lakehouse (é o padrão do Databricks) e também warehouses (staging → intermediate → marts no dbt é o mesmo princípio). Cuidado: camadas demais viram burocracia — três bastam na maioria dos casos.
Modelagem dimensional — Star Schema (Kimball)
Problema real: "o BI está lento e cada analista calcula receita de um jeito." Separar fatos (números que se somam) de dimensões (contexto pelo qual se filtra) produz modelos que o usuário de negócio entende e que warehouses e ferramentas de BI (especialmente o VertiPaq do Power BI) otimizam muito bem.
Quando usar: na camada Gold / de consumo, sempre. É conhecimento de 1996 (Kimball) que continua sendo a base de todo dashboard bem feito — e presença garantida em entrevistas.
Data Vault 2.0
Problema real: "temos dezenas de sistemas-fonte que mudam o tempo todo, e auditoria/regulação exige histórico completo de tudo." O Data Vault desacopla chaves, relações e atributos, permitindo absorver novas fontes sem reestruturar o modelo e mantendo trilha de auditoria nativa (insert-only).
Quando usar: EDWs de grande porte em setores regulados (bancos, seguros, saúde). Cuidado: a explosão de tabelas e joins tem custo alto — para empresas menores, é quase sempre exagero. Tipicamente serve de camada intermediária, com star schema por cima para consumo.
Latência: batch vs. tempo real
ELT em batch (Modern Data Stack)
Problema real: "precisamos de dados confiáveis para decisão, e D-1 ou atualização horária é suficiente." É a arquitetura de melhor custo-benefício do mercado — simples de operar, fácil de testar, e cobre a imensa maioria dos casos analíticos reais.
Quando usar: como ponto de partida padrão. Só saia dela quando a latência comprovadamente não atender o negócio.
Arquitetura Lambda
Problema real: "preciso de números em tempo real e de números exatos consolidados — e o streaming sozinho não garantia exatidão." A Lambda processa tudo duas vezes: o batch corrige periodicamente o que o streaming aproximou.
Quando usar: cada vez menos — manter duas bases de código para a mesma lógica é caro e propenso a divergência. Importante conhecer porque existe em produção em muitas empresas, mas projetos novos tendem à Kappa ou a soluções unificadas.
Arquitetura Kappa
Problema real: "manter a lógica duplicada da Lambda virou um pesadelo." A Kappa trata tudo como stream: batch é só um stream limitado, e reprocessamento histórico é reler o log do início. Uma base de código, um motor.
Quando usar: quando o tempo real é requisito central (fraude, monitoramento, personalização) e a equipe domina streaming. Exige maturidade operacional considerável.
Movimento e integração
CDC + replicação analítica (event-driven)
Problema real: "as queries de extração estão derrubando o banco de produção" ou "o batch noturno chega tarde demais." O CDC lê o log de transações — praticamente sem custo para o banco de origem — e replica cada mudança em near real-time, preservando até os deletes que o batch não enxerga.
Quando usar: replicação contínua de bancos transacionais para analytics. Para quem conhece oplog e WAL por dentro, é o padrão arquitetural mais natural de dominar — e um diferencial raro no mercado.
Reverse ETL (ativação de dados)
Problema real: "o dashboard mostra os clientes em risco de churn, mas o time de vendas não vive no dashboard — vive no CRM." O reverse ETL fecha o ciclo: leva o dado tratado do warehouse de volta para as ferramentas operacionais onde a ação acontece.
Quando usar: quando o valor do dado está em agir, não só em ver. Pressupõe um warehouse já maduro e bem modelado.
Organização de pessoas e domínios
Data Mesh
Problema real: "o time central de dados virou gargalo — todo pedido entra numa fila de meses, e quem entende do dado é o domínio, não a plataforma." O Data Mesh descentraliza: cada domínio publica seus dados como produto (com SLA, documentação e qualidade), sobre uma plataforma comum.
Quando usar: organizações grandes, com muitos domínios e maturidade técnica distribuída. Cuidado: é mais um modelo organizacional do que uma arquitetura técnica — adotar o vocabulário sem mudar a estrutura de times não resolve nada, e para empresas pequenas é claramente exagero.
Comparativo — qual arquitetura para qual dor
| Dor do negócio | Arquitetura indicada | Latência | Complexidade |
|---|---|---|---|
| "Preciso de relatórios confiáveis; D-1 atende" | ELT batch + medallion + star schema | Horas | ●●●●● |
| "Perdi o dado bruto e não consigo reprocessar" | Medallion (camada Bronze) | — | ●●●●● |
| "O BI está lento e as métricas divergem" | Star schema (Kimball) na camada Gold | — | ●●●●● |
| "A extração está derrubando o banco de produção" | CDC (Debezium) → lake/warehouse | Segundos–minutos | ●●●●● |
| "Fraude/monitoramento exige reação em segundos" | Kappa (Kafka + Flink) | Milissegundos–segundos | ●●●●● |
| "Tempo real + números exatos consolidados (legado)" | Lambda | Mista | ●●●●● |
| "Auditoria exige histórico completo de fontes que mudam" | Data Vault 2.0 (+ star schema no consumo) | Horas | ●●●●● |
| "O insight existe, mas ninguém age sobre ele" | Reverse ETL | Minutos–horas | ●●●●● |
| "O time central de dados virou gargalo da empresa" | Data Mesh | — | ●●●●● |
Stacks de referência & Trilha de estudo
Ferramentas fazem sentido em conjunto. Abaixo, quatro stacks reais que você encontrará no mercado — e uma trilha de estudo progressiva para dominá-las.
Stacks típicas do mercado
1. Stack de aprendizado (custo zero, roda no seu notebook)
Cobre todos os conceitos do stack moderno sem gastar um centavo nem depender de nuvem. É a melhor forma de construir portfólio: o raciocínio é idêntico ao de produção, só muda a escala.
2. Modern Data Stack (o mais comum em empresas digitais)
ELT clássico: ingestão por conectores, transformação SQL versionada dentro do warehouse, BI consultando modelos prontos. É o perfil de vaga mais frequente hoje.
3. Lakehouse (big data + ML)
Arquitetura medallion (bronze → silver → gold) sobre object storage. Dominante onde volume é grande e engenharia de dados convive com ciência de dados.
4. Real-time analytics
Para fraude, monitoramento e personalização. Stack especializada — só faz sentido quando segundos importam de verdade.
Trilha de estudo sugerida
| Fase | Foco | Ferramentas | Resultado |
|---|---|---|---|
| 1. Fundamentos | SQL avançado, modelagem (estrela/normalização), Python, Linux, Git | PostgreSQL, pandas | Base que sustenta todo o resto — não pule esta fase |
| 2. Stack local | ELT ponta a ponta no notebook | dlt, DuckDB, dbt Core, Metabase | Primeiro projeto de portfólio completo |
| 3. Orquestração | DAGs, retries, agendamento, idempotência | Airflow (e depois Dagster) | Pipelines confiáveis em produção |
| 4. Nuvem & warehouse | Uma nuvem a fundo + um warehouse | BigQuery ou Snowflake + S3/GCS | Stack moderno completo na nuvem |
| 5. Escala | Processamento distribuído e lakehouse | Spark, Delta/Iceberg, Databricks | Capacidade para grandes volumes |
| 6. Tempo real | Eventos, CDC e streaming stateful | Kafka, Debezium, Flink | Perfil sênior/especialista |
| 7. Confiabilidade | Qualidade, observabilidade, catálogo, IaC | GX/Soda, DataHub, Terraform, Docker | Maturidade de plataforma de dados |