Os dados raramente nascem prontos para análise. Eles chegam de APIs, bancos transacionais, planilhas e logs, cada um com seu formato e suas sujeiras. O trabalho de levar esse material bruto até uma tabela limpa e confiável é o que chamamos de pipeline de dados — e entender ETL é central no trabalho de qualquer profissional pleno.
ETL: Extract, Transform, Load
O padrão clássico tem três etapas:
- Extract — extrair os dados das fontes de origem.
- Transform — limpar, padronizar, juntar, calcular. É onde mora a maior parte da complexidade.
- Load — carregar o resultado no destino (um data warehouse, por exemplo).
No ETL tradicional, a transformação acontece antes da carga, em um servidor intermediário.
ELT: a inversão que o warehouse moderno trouxe
No ELT, você inverte a ordem: carrega os dados brutos primeiro e transforma dentro do data warehouse. Por que isso cresceu? Porque warehouses modernos (BigQuery, Snowflake, Redshift) têm poder de processamento massivo e barato. Em vez de manter um servidor separado para transformar, você joga o dado bruto lá dentro e usa SQL para transformar com toda a potência do warehouse.
| Aspecto | ETL | ELT |
|---|---|---|
| Ordem | Transforma antes de carregar | Carrega bruto, transforma depois |
| Onde transforma | Servidor intermediário | Dentro do warehouse |
| Dado bruto preservado? | Geralmente não | Sim |
| Quando brilha | Recursos de destino limitados | Warehouse moderno e escalável |
Os estágios e o fluxo raw → staging → analytics
Um pipeline maduro organiza os dados em camadas, cada uma com um propósito:
Fontes raw staging analytics
+-------+ +-------+ +----------+ +-----------+
| API |───▶| dados |─────▶| limpo, |───▶| modelos |
| BD | | brutos| | padroniz.| | p/ negócio|
| CSV | | (cópia| | tipado | | (fato/dim)|
+-------+ | fiel) | +----------+ +-----------+
+-------+A camada raw guarda uma cópia fiel da origem (útil para reprocessar); a staging limpa e padroniza; a analytics entrega tabelas prontas para consumo, frequentemente no modelo dimensional.
Orquestração: quem manda rodar e em que ordem
Pipelines têm dependências: você não pode transformar antes de extrair. Um orquestrador coordena isso modelando as tarefas como um DAG (grafo acíclico dirigido) — uma teia de "essa tarefa só roda depois daquela". O Airflow é a ferramenta mais conhecida para definir e agendar esses DAGs.
Idempotência e reprocessamento
Pipelines falham — rede cai, fonte fica indisponível. Por isso uma tarefa deve ser idempotente: rodá-la duas vezes produz o mesmo resultado que rodá-la uma vez, sem duplicar dados. Pense numa lâmpada: apertar "ligar" três vezes ainda deixa a luz ligada, não "três vezes ligada". Na prática, isso significa sobrescrever uma partição em vez de só inserir — assim você pode reprocessar um dia com segurança.
Data quality: confiança no que sai
Um pipeline que entrega dado errado é pior que nenhum, porque ninguém percebe. Por isso embutimos verificações de qualidade: a coluna de chave tem nulos? A contagem de linhas caiu de repente? Os valores estão no intervalo esperado? Falhar o pipeline cedo é melhor que poluir o relatório do diretor.
Um bom pipeline não é o que roda quando tudo dá certo — é o que falha de forma segura, pode ser reprocessado sem duplicar nada, e avisa quando o dado parece errado.
É comum em entrevista perguntarem a diferença entre ETL e ELT e por que ELT virou padrão — e também o que torna uma tarefa idempotente. No dia a dia isso aparece quando um pipeline falha às 3h da manhã e você precisa reprocessá-lo de manhã sem medo de bagunçar os dados.
Conclusão
ETL e ELT descrevem como mover e transformar dados; as camadas raw/staging/analytics organizam essa jornada; orquestração via DAG garante a ordem; e idempotência mais data quality garantem que o resultado seja confiável e reprocessável. Esses princípios valem para qualquer ferramenta — entendê-los é o que faz você construir pipelines que não quebram silenciosamente.
Data rarely comes ready for analysis. It arrives from APIs, transactional databases, spreadsheets and logs, each with its own format and its own mess. The work of taking this raw material to a clean, trustworthy table is what we call a data pipeline — and understanding ETL is central to the work of any mid-level professional.
ETL: Extract, Transform, Load
The classic pattern has three steps:
- Extract — pull the data from the source systems.
- Transform — clean, standardize, join, calculate. This is where most of the complexity lives.
- Load — load the result into the destination (a data warehouse, for example).
In traditional ETL, the transformation happens before loading, on an intermediate server.
ELT: the inversion the modern warehouse brought
In ELT, you flip the order: load the raw data first and transform it inside the data warehouse. Why did this take off? Because modern warehouses (BigQuery, Snowflake, Redshift) have massive, cheap processing power. Instead of maintaining a separate server to transform, you dump the raw data in and use SQL to transform it with the full power of the warehouse.
| Aspect | ETL | ELT |
|---|---|---|
| Order | Transforms before loading | Loads raw, transforms afterwards |
| Where it transforms | Intermediate server | Inside the warehouse |
| Raw data preserved? | Usually not | Yes |
| When it shines | Limited destination resources | Modern, scalable warehouse |
The stages and the raw → staging → analytics flow
A mature pipeline organizes data in layers, each with its own purpose:
Sources raw staging analytics
+-------+ +-------+ +----------+ +-----------+
| API |───▶| raw |─────▶| cleaned, |───▶| business |
| DB | | data | | standard.| | models |
| CSV | | (exact| | typed | | (fact/dim)|
+-------+ | copy) | +----------+ +-----------+
+-------+The raw layer keeps an exact copy of the source (useful for reprocessing); staging cleans and standardizes; analytics delivers tables ready for consumption, often in the dimensional model.
Orchestration: who says what runs, and in what order
Pipelines have dependencies: you can't transform before extracting. An orchestrator coordinates this by modeling tasks as a DAG (directed acyclic graph) — a web of "this task only runs after that one". Airflow is the best-known tool for defining and scheduling these DAGs.
Idempotency and reprocessing
Pipelines fail — the network goes down, a source becomes unavailable. That's why a task should be idempotent: running it twice produces the same result as running it once, without duplicating data. Think of a light switch: pressing "on" three times still leaves the light on, not "three times on". In practice, this means overwriting a partition instead of just inserting — so you can safely reprocess a day.
Data quality: trust in what comes out
A pipeline that delivers wrong data is worse than none, because nobody notices. That's why we build in quality checks: does the key column have nulls? Did the row count suddenly drop? Are the values within the expected range? Failing the pipeline early is better than polluting the director's report.
A good pipeline isn't the one that runs when everything goes right — it's the one that fails safely, can be reprocessed without duplicating anything, and warns you when the data looks wrong.
In interviews it's common to be asked the difference between ETL and ELT and why ELT became the standard — and also what makes a task idempotent. Day to day, this shows up when a pipeline fails at 3 a.m. and you need to reprocess it in the morning without fear of messing up the data.
Conclusion
ETL and ELT describe how to move and transform data; the raw/staging/analytics layers organize that journey; DAG orchestration guarantees the order; and idempotency plus data quality guarantee the result is trustworthy and reprocessable. These principles hold for any tool — understanding them is what lets you build pipelines that don't break silently.