Pipeline, Arquitetura e Modelagem: os três pilares que sustentam qualquer estratégia de dados
- #Data
# Pipeline, Arquitetura e Modelagem: os três pilares da Engenharia de Dados
> *Antes de construir dashboards ou treinar modelos, é preciso dominar os fundamentos que governam como o dado nasce, viaja e é armazenado.*
**Baseado no infográfico:** Menino dos Dados — Glossário Descomplicado: Fundamentos da Engenharia de Dados
**Temas:** Pipeline · ETL/ELT · Batch/Streaming · OLTP/OLAP · Data Warehouse · Data Lake · Star Schema · Granularidade
---
## Sumário
1. [Fundamentos: o coração do pipeline e do processamento](#1-fundamentos-o-coração-do-pipeline-e-do-processamento)
2. [Arquitetura de Dados: onde o dado é definido no tempo](#2-arquitetura-de-dados-onde-o-dado-é-definido-no-tempo)
3. [Modelagem de Dados: onde o dado ganha estrutura e significado](#3-modelagem-de-dados-onde-o-dado-ganha-estrutura-e-significado)
4. [Conclusão: a combinação que fecha o ciclo](#4-conclusão-a-combinação-que-fecha-o-ciclo)
---
## 1. Fundamentos: o coração do pipeline e do processamento
Nenhum produto analítico — seja um relatório gerencial, um modelo preditivo ou um painel em tempo real — existe sem que os dados brutos tenham passado por um processo disciplinado de extração, transformação e carga. Esse processo é o **pipeline de dados**, e compreendê-lo é o primeiro passo para qualquer profissional que lida com informação.
> *"Os dashboards morrem na lentidão porque o dado está bruto. O pipeline tem que limpar e organizar antes do BI."*
### 1.1 Pipeline de Dados (Raw)
Um pipeline parte da **entrada dos dados brutos**, passa pelas etapas de extração e limpeza — onde ferramentas como o **dbt** atuam como camada de transformação declarativa — e termina na **garantia de qualidade**. A sequência é inexorável: dado sujo na entrada equivale a decisão errada na saída.
[Dados Brutos] → [Extração] → [Limpeza / dbt] → [Garantia de Qualidade] → [BI / Analytics]
### 1.2 ETL vs. ELT
A ordem das etapas de transformação define duas abordagens arquiteturais distintas, cada uma adequada a contextos diferentes.
| | **ETL** | **ELT** |
|---|---|---|
| **Fluxo** | Extrai → Transforma → Carrega | Extrai → Carrega → Transforma |
| **Quando transforma** | Antes do destino | No destino |
| **Contexto típico** | Data Warehouses on-premise | Plataformas cloud (BigQuery, Snowflake, Redshift) |
| **Vantagem** | Dado já estruturado ao chegar | Flexibilidade e escalabilidade elástica |
| **Desvantagem** | Rígido; difícil de reiterar | Requer destino com alto poder de processamento |
O avanço dos bancos de dados cloud com processamento massivamente paralelo tornou o ELT a abordagem dominante em arquiteturas modernas, já que o custo de transformação no destino é compensado pela flexibilidade de reprocessar dados sem reingeri-los.
### 1.3 Batch vs. Streaming
A escolha entre processamento em lote e em fluxo contínuo define a **latência aceitável** para o negócio.
**Processamento Batch**
- Consolida dados acumulados e os processa em janelas de tempo definidas
- Adequado para relatórios diários, fechamentos mensais e análises históricas
- Menor custo operacional, maior latência
**Processamento Streaming**
- Processa cada evento à medida que ele acontece, sem acúmulo intermediário
- Essencial para detecção de fraudes, monitoramento de sistemas e dashboards operacionais ao vivo
- Menor latência, maior complexidade de implementação e operação
A decisão não é sempre binária: arquiteturas *lambda* e *kappa* combinam as duas abordagens para atender diferentes necessidades do mesmo sistema.
---
## 2. Arquitetura de Dados: onde o dado é definido no tempo
Uma vez processados, os dados precisam residir em algum lugar. A escolha do repositório define não só o custo e a performance, mas também quem pode acessar o dado, com que velocidade e para qual finalidade. A confusão entre esses conceitos é uma das fontes mais comuns de arquiteturas mal dimensionadas.
### 2.1 OLTP vs. OLAP
Antes de escolher o repositório, é fundamental entender a natureza do workload:
| | **OLTP** | **OLAP** |
|---|---|---|
| **Significado** | Online Transaction Processing | Online Analytical Processing |
| **Finalidade** | Operações do dia a dia | Análises estratégicas |
| **Operações típicas** | INSERT, UPDATE, SELECT pontual | SELECT com agregações sobre grandes volumes |
| **Latência esperada** | Milissegundos | Segundos a minutos |
| **Volume por consulta** | Poucos registros | Milhões a bilhões de registros |
| **Exemplo** | Sistema de vendas, ERP | Data Warehouse, cubo OLAP |
O OLTP é a **fonte** dos dados; o OLAP é o **destino analítico**. Misturar os dois workloads no mesmo banco é um erro arquitetural clássico que degrada performance em ambos os lados.
### 2.2 O ecossistema de repositórios
#### Data Warehouse
Repositório de dados estruturados, modelados e otimizados para consulta analítica. Oferece alta performance para BI, porém com custo maior de transformação e ingestão. É o padrão para ambientes que exigem governança rigorosa e queries complexas de negócio.
**Ferramentas:** Snowflake, Google BigQuery, Amazon Redshift, Azure Synapse
#### Data Lake
Armazena dados em qualquer formato — estruturado, semiestruturado ou não-estruturado. Apresenta baixo custo de ingestão e alta flexibilidade, mas exige governança disciplinada para não se transformar em um *data swamp* (pântano de dados inacessível).
**Ferramentas:** AWS S3 + Glue, Azure Data Lake Storage, Google Cloud Storage
#### Data Lakehouse
Arquitetura híbrida que combina a flexibilidade de armazenamento do Lake com as capacidades de consulta estruturada do Warehouse. Permite aplicar transações ACID e esquemas sobre dados no Lake, sem duplicação de armazenamento.
**Ferramentas:** Databricks (Delta Lake), Apache Iceberg, Apache Hudi
#### Data Mart
Subconjunto especializado do Warehouse, voltado a um domínio específico de negócio — vendas, finanças, RH, marketing. Facilita o consumo por áreas com acesso a ferramentas como Power BI e Python, reduzindo a exposição ao modelo de dados completo.
### 2.3 Como as camadas se complementam
Em organizações maduras, as arquiteturas não são exclusivas. Um padrão comum é:
[Fontes OLTP] ↓ [Data Lake] ← ingestão raw, baixo custo ↓ [Data Warehouse] ← dados modelados, consultas analíticas ↓ [Data Marts] ← acesso segmentado por área de negócio ↓ [BI / ML / Relatórios]
---
## 3. Modelagem de Dados: onde o dado ganha estrutura e significado
Ter dados armazenados não é suficiente. Para que o dado sirva ao negócio, ele precisa ser **modelado** — organizado em estruturas que traduzam a realidade operacional em consultas rápidas e compreensíveis. A modelagem dimensional é o padrão consagrado para ambientes analíticos.
### 3.1 Star Schema (Esquema Estrela)
O Star Schema organiza os dados em torno de uma **tabela fato central** — que registra os eventos transacionais, onde cada linha representa uma transação — rodeada por **tabelas dimensão**, que contextualizam esses eventos.
DIM_CLIENTE DIM_VENDEDOR
↘ ↙
[FATO_VENDAS]
(1 linha = 1 transação)
↗ ↖
DIM_PRODUTO DIM_TEMPO
**Tabela Fato** contém as métricas numéricas (valor da venda, quantidade) e as chaves estrangeiras para cada dimensão.
**Tabelas Dimensão** descrevem os atributos de cada entidade (nome do cliente, categoria do produto, trimestre da data).
#### OBT — One Big Table
Uma variação do Star Schema, o OBT pré-agrega as dimensões diretamente na tabela fato, criando uma tabela única desnormalizada com pré-agregações (*dimensions pre-aggregated*). Simplifica consultas em contextos onde a flexibilidade analítica é menos crítica que a velocidade de entrega, como em ferramentas de BI autoserviço.
### 3.2 Granularidade
Granularidade define o **nível de detalhe** de cada registro na tabela fato. A escolha é uma das decisões mais impactantes na modelagem.
| | **Alta granularidade** | **Baixa granularidade** |
|---|---|---|
| **O que representa** | Evento mínimo (ex: item de nota fiscal) | Resumo consolidado (ex: total mensal de vendas) |
| **Flexibilidade** | Alta — responde qualquer pergunta | Baixa — limitada ao nível de consolidação |
| **Volume de dados** | Alto | Baixo |
| **Performance de consulta** | Pode ser mais lenta sem indexação adequada | Consultas mais rápidas |
| **Uso típico** | Análises exploratórias, auditoria | Relatórios executivos, KPIs fixos |
A regra prática é: **modele na menor granularidade possível**, e agregue conforme necessário. O inverso — tentar detalhar dados já agregados — é impossível.
### 3.3 Características modernas de arquitetura
Arquiteturas contemporâneas de dados são projetadas com três atributos fundamentais:
- **Entrega Rápida** — As camadas do pipeline são desacopladas para que resultados analíticos estejam disponíveis com baixa latência. Transformações incrementais (como as do dbt) evitam reprocessamento completo a cada atualização.
- **Modularidade** — Cada componente do pipeline pode evoluir de forma independente, reduzindo o risco de mudanças. Isso se reflete no uso de ferramentas especializadas e orquestradores como o Apache Airflow.
- **Scalability Cloud-First** — O processamento se distribui elasticamente conforme a demanda, sem provisionamento antecipado de infraestrutura física. O custo escala com o uso, não com a capacidade instalada.
---
## 4. Conclusão: a combinação que fecha o ciclo
Os três pilares — **pipeline**, **arquitetura** e **modelagem** — formam uma cadeia interdependente:
- Um pipeline mal construído corrompe qualquer arquitetura
- Uma arquitetura mal escolhida inutiliza o modelo mais bem desenhado
- Um modelo com granularidade errada frustra até o analista mais experiente
A dupla técnica que atravessa todo esse ciclo é **SQL + Python**:
- **SQL** — para transformar e consultar dados estruturados em qualquer camada da arquitetura
- **Python** — para orquestrar, automatizar e conectar ferramentas como dbt, Airflow e os principais frameworks de machine learning
Dominar esses fundamentos não é opcional — é o alicerce sobre o qual toda Engenharia de Dados séria é construída.
---
### Stack de referência mencionada
| Ferramenta | Função |
|---|---|
| **dbt** | Transformação declarativa na camada analítica (ELT) |
| **SQL** | Consulta e transformação em qualquer camada |
| **Python** | Orquestração, automação e ML |
| **Power BI** | Consumo analítico em Data Marts |
| **Snowflake / BigQuery / Redshift** | Data Warehouse cloud |
