Dados são o combustível das empresas modernas, mas dados brutos sozinhos não dizem muita coisa. Imagine informações espalhadas por dezenas de sistemas diferentes: bancos de dados de produção, planilhas, logs de servidores e eventos de cliques. Para que tudo isso se torne um gráfico útil ou alimente um modelo de inteligência artificial, é preciso extrair, limpar e organizar essas peças. Esse é o papel dos data pipelines e do clássico processo de ETL (Extract, Transform, Load).
Embora o conceito seja antigo, as ferramentas e a forma como pensamos a arquitetura de dados mudaram drasticamente. Vamos mergulhar na evolução do ETL para o ELT, entender a diferença entre processamento em tempo real (streaming) e em lotes (batch), e descobrir como ferramentas como Airflow e dbt estão redefinindo o que significa "refinar" o combustível da nova economia.
1. ETL vs ELT: A Mudança de Paradigma
1.1 ETL Tradicional
No modelo tradicional, dados são extraídos de fontes, transformados (limpos, combinados, agregados) em servidores de processamento intermediários, e só então carregados no destino (data warehouse). O processamento acontece antes de chegar ao destino. Isso fazia sentido quando storage e compute em data warehouses eram extremamente caros.
1.2 O Surgimento do ELT Moderno
Com o advento de data warehouses na nuvem extremamente poderosos, como Snowflake e BigQuery, a lógica mudou. Hoje, é muito mais barato e rápido carregar os dados brutos primeiro (Extract, Load) e fazer toda a transformação pesada diretamente dentro do destino final (Transform). Isso simplifica a arquitetura: você tem menos "paradas" intermediárias e muito mais flexibilidade para reprocessar os dados caso descubra um erro ou precise de uma nova métrica.
1.3 Quando Usar Cada Um
ETL ainda faz sentido quando: transformações são muito complexas para SQL, dados precisam ser limpos antes de carregar (PII, dados sensíveis), ou o destino não tem capacidade de processamento. ELT é preferível quando: o warehouse é poderoso, transformações são expressíveis em SQL, e flexibilidade para re-transformar é valorizada.
2. Batch vs Streaming
2.1 Processamento Batch
Batch processa dados em intervalos: diariamente, horariamente, ou em janelas específicas. Você espera dados acumularem e processa em bloco. Batch é simples de implementar, fácil de debugar (reproduzível), e suficiente quando latência de horas é aceitável. A maioria dos casos de analytics é bem servida por batch.
2.2 Processamento Streaming
Streaming processa dados conforme chegam, com latência de segundos ou menos. Necessário para casos como: detecção de fraude em tempo real, dashboards de operações, personalização instantânea. Streaming é mais complexo: gerenciar estado, lidar com eventos fora de ordem, garantir exactly-once processing.
2.3 Lambda e Kappa Architectures
Lambda architecture combina batch e streaming: streaming para dados recentes (com possível imprecisão), batch para dados históricos (corretos). Kappa simplifica: apenas streaming, re-processando histórico quando necessário. Kappa é mais elegante mas exige infraestrutura de streaming robusta.
3. Orquestração: Apache Airflow
3.1 O Que É Airflow
Apache Airflow é a ferramenta de orquestração de pipelines mais popular. Você define pipelines como DAGs (Directed Acyclic Graphs) em Python: quais tarefas existem, quais suas dependências, quando devem rodar. Airflow cuida de scheduling, execução, retries, monitoramento e alertas.
3.2 Conceitos Principais
DAG: Grafo de tarefas e dependências. Operator: Tipo de tarefa (PythonOperator, BashOperator, PostgresOperator). Task: Instância de um operator em um DAG. Sensor: Tarefa que espera uma condição (arquivo aparecer, API retornar). XCom: Comunicação entre tarefas.
3.3 Quando Usar
Airflow é ideal para pipelines batch com dependências complexas: "execute A, depois B e C em paralelo, depois D se B e C sucederem". Não é ideal para streaming (use Kafka Streams, Flink) ou para pipelines muito simples (overhead desnecessário).
4. Transformação: dbt
4.1 O Que É dbt
dbt (data build tool) é uma ferramenta focada na parte "T" de ELT. Você escreve transformações em SQL, e dbt cuida de: ordenar dependências, executar no warehouse, testar dados, gerar documentação. Desenvolvido pela Fishtown Analytics (agora dbt Labs), se tornou padrão para analytics engineering.
4.2 Modelo Mental
Em dbt, você escreve "models" — arquivos SQL que definem como transformar dados brutos em tabelas analíticas. Cada model é um SELECT que dbt materializa como tabela ou view. Models podem referenciar outros models, criando DAG de transformações. dbt resolve dependências e executa na ordem correta.
4.3 Testes e Documentação
dbt inclui testes embutidos: não-nulo, único, relacionamentos entre tabelas. Você pode adicionar testes customizados. Documentação é gerada automaticamente como site navegável com lineage (de onde vem cada coluna). Isso resolve um problema histórico de data warehouses: entender o que significa cada tabela e de onde veio.
5. Processamento em Escala: Spark
5.1 O Que É Apache Spark
Quando dados são grandes demais para processar em uma única máquina, Spark distribui o processamento em clusters. Spark processa dados em memória, muito mais rápido que Hadoop MapReduce. Suporta batch (Spark SQL, DataFrames), streaming (Structured Streaming), e machine learning (MLlib).
5.2 Quando Usar
Spark é necessário quando você tem terabytes ou petabytes de dados e transformações complexas que não cabem em SQL simples. Para datasets de gigabytes, um warehouse moderno ou pandas em uma máquina grande frequentemente é suficiente e mais simples.
6. Ferramentas de Ingestão (Extract e Load)
6.1 Fivetran, Stitch, Airbyte
Ferramentas que extraem dados de fontes (SaaS APIs, bancos de dados, arquivos) e carregam em warehouses. Fivetran e Stitch são SaaS; Airbyte é open source. Conectores pré-construídos para centenas de fontes economizam meses de desenvolvimento de integrações.
6.2 CDC (Change Data Capture)
Para replicar bancos de dados transacionais, CDC captura mudanças (inserts, updates, deletes) em vez de copiar tudo a cada batch. Ferramentas como Debezium leem logs de transação e enviam eventos para Kafka, de onde podem ser consumidos para data warehouse ou outros sistemas.
7. Conclusão
Os data pipelines deixaram de ser apenas uma tarefa de fundo para se tornarem o coração estratégico de qualquer empresa que queira ser data-driven. Um stack moderno geralmente combina o melhor de cada mundo: ferramentas de ingestão como Airbyte, o poder do dbt para transformações e a orquestração robusta do Airflow, tudo desaguando em um data warehouse elástico.
A melhor recomendação é não complicar demais no início. Muitos projetos começam perfeitamente bem com scripts simples e evoluem para essas arquiteturas conforme a escala e a complexidade dos dados aumentam. O segredo é garantir que o dado chegue com qualidade e no tempo certo para quem precisa tomar decisões.
8. Apêndice A: Glossário de Termos
- Batch: Processamento em intervalos discretos.
- CDC: Change Data Capture, captura de mudanças incrementais.
- DAG: Directed Acyclic Graph, grafo de dependências.
- Data Lake: Repositório de dados brutos em formatos variados.
- Data Warehouse: Repositório otimizado para análise.
- dbt: Data build tool, ferramenta de transformação em SQL.
- ELT: Extract, Load, Transform — carregar antes de transformar.
- ETL: Extract, Transform, Load — transformar antes de carregar.
- Lineage: Rastreamento de origem e transformações de dados.
- Streaming: Processamento contínuo em tempo real.
9. Apêndice B: Referências
- Apache Airflow Documentation. airflow.apache.org.
- dbt Documentation. docs.getdbt.com.
- Apache Spark Documentation. spark.apache.org.
- Reis, J., & Housley, M. (2022). Fundamentals of Data Engineering. O'Reilly.
- Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly.
Este artigo foi desenvolvido com base em práticas de data engineering.
