ETL

Dados úteis para análise raramente existem onde são gerados. O CRM produz dados de clientes. O ERP produz dados de pedidos e financeiro. A plataforma de e-commerce produz dados de comportamento digital. O sistema de suporte produz dados de atendimento. Cada um armazena seus dados em formato otimizado para seu próprio funcionamento — não para análise integrada.

ETL (Extract, Transform, Load) é o processo de mover dados de sistemas de origem para um destino analítico — tipicamente um data warehouse — realizando as transformações necessárias para torná-los consistentes, limpos e utilizáveis para análise. O nome descreve as três etapas: extrair dos sistemas de origem, transformar (limpar, padronizar, enriquecer, calcular campos derivados) e carregar no destino.

É a engenharia de encanamento dos dados — invisível quando funciona, insuportavelmente visível quando quebra. Sem ETL confiável, dashboards mostram números errados, modelos de ML treinam em dados corrompidos, e relatórios exigem reconciliação manual antes de serem apresentados.

Extract (Extração): conectar-se às fontes de dados e extrair o que é necessário. Pode ser incremental (apenas registros criados ou modificados desde a última extração — mais eficiente) ou full (extração completa da tabela — mais simples mas mais custosa). Fontes típicas: bancos de dados relacionais (via SQL ou JDBC), APIs REST, arquivos CSV/Excel, sistemas SaaS com conectores, sistemas legados com acesso mais complexo.

Desafios comuns na extração: autenticação e permissões em cada fonte, rate limits de APIs, consistência de dados em sistemas que continuam sendo escritos durante a extração (snapshot consistency), tratamento de sistemas que não oferecem incremental nativo.

Transform (Transformação): onde a maior parte do trabalho acontece — e onde o maior valor é criado ou destruído. Transformações típicas:

• Limpeza: remover duplicatas, corrigir encoding, tratar valores nulos (substituir, excluir ou sinalizar), padronizar formatos de data e telefone.
• Padronização: uniformizar categorias que o mesmo conceito representa de formas diferentes em sistemas distintos. "SP", "São Paulo", "sao paulo" → "SP". "Ativo", "A", "1" → "Ativo".
• Enriquecimento: adicionar informação que não estava na fonte — calcular margem a partir de custo e preço, adicionar informação de CEP a partir de tabela de referência, criar segmentos baseados em comportamento.
• Cálculo de métricas derivadas: ticket médio, lifetime value parcial, NPS por segmento.
• Junção e integração: unir dados de múltiplas fontes — clientes do CRM com pedidos do ERP com atendimentos do sistema de suporte — usando chaves de integração (e-mail, CPF, ID de cliente).
• Modelagem dimensional: transformar dados operacionais em schema estrela para o data warehouse — separar fatos de dimensões, criar surrogate keys.

Load (Carregamento): inserir os dados transformados no destino — data warehouse, data lake, banco de dados analítico. Pode ser append (apenas novos registros), upsert (inserir novos, atualizar existentes) ou full replace (substituir toda a tabela). A estratégia afeta performance e a capacidade de manter histórico.

A distinção entre ETL e ELT virou relevante com o advento dos data warehouses cloud, que têm poder computacional elástico e barato.

ETL (clássico): transforma antes de carregar. A transformação acontece em um servidor intermediário (ETL server ou ferramenta dedicada). Necessário quando a fonte ou o destino não suporta processamento pesado, ou quando há requisitos de privacidade que exigem mascarar dados antes que cheguem ao destino.

ELT (moderno): extrai e carrega dados brutos no destino primeiro, transforma dentro do data warehouse usando seu poder computacional. Favorecido em ambientes cloud porque DWs modernos (BigQuery, Snowflake, Redshift) são muito eficientes em transformações SQL massivas.

dbt (data build tool): a ferramenta que popularizou ELT. Define transformações como modelos SQL com dependências explícitas, versionados em Git, com testes automatizados de qualidade e documentação. Tornou-se o padrão de facto para a camada de transformação em stacks modernas de dados.

Ferramentas de extração e integração (conectores):

• Fivetran: conectores prontos para centenas de fontes (Salesforce, HubSpot, Stripe, bancos de dados). Totalmente gerenciado, schema replication automático. Alto custo de licença, mas elimina manutenção.
• Airbyte: alternativa open source ao Fivetran. Self-hosted gratuito, mais de 300 conectores. Opção cloud paga para quem não quer operar infraestrutura.
• Stitch Data: similar ao Fivetran, foco em simplicidade. Adquirido pela Talend.
• Singer: protocolo open source para conectores. Mais trabalho para configurar mas conectores reutilizáveis.

Ferramentas de transformação:

• dbt: padrão de facto para transformação ELT. Open source, SQL-based, versionado em Git.
• Apache Spark: para transformações de grande volume que precisam de processamento distribuído.
• Airflow: orquestrador de workflows. Não transforma dados diretamente — agenda e monitora pipelines.

Plataformas ETL tradicionais:

• Informatica, Talend, SSIS (Microsoft): ferramentas enterprise com interface visual. Fortes em ambientes corporativos com legados complexos. Alto custo de licença.
• Apache NiFi: ETL de código aberto com interface visual e forte foco em streaming e segurança de dados.

Ferramentas de ETL precisam de orquestração: quem garante que o pipeline roda na hora certa, na ordem correta, e que falhas são detectadas e tratadas?

Apache Airflow: o orquestrador de pipelines de dados mais adotado. DAGs (Directed Acyclic Graphs) definem dependências entre tarefas em Python. Monitoramento via UI, retry automático, alertas em falha. Robusto mas operacionalmente complexo de manter.

Prefect, Dagster: alternativas modernas ao Airflow. Interface mais amigável, melhor observabilidade nativa, mais fáceis de testar localmente.

dbt Cloud: se a stack é principalmente dbt + ELT, dbt Cloud orquestra as execuções de dbt com scheduler integrado e alertas.

ETL sem validação de qualidade é ETL não confiável. Erros silenciosos — campos que chegam vazios, valores fora do range esperado, quebra de integridade referencial — corroem a confiança nos dados ao longo do tempo.

Testes básicos em dbt: not_null (campo nunca nulo), unique (campo sem duplicatas), accepted_values (campo tem apenas valores do enum esperado), relationships (chave estrangeira referencia registro existente).

Ferramentas de data quality: Great Expectations, Soda — frameworks de validação que definem expectativas sobre os dados e alertam quando são violadas.

Monitoramento de volume e frescor: alertar quando o pipeline não rodou, quando o volume de registros é anormalmente baixo (pode indicar falha na extração) ou anormalmente alto (pode indicar duplicação).

ETL é frequentemente a diferença entre uma empresa com dados que a gestão usa e confia, e uma empresa com dados que existem mas ninguém acredita. A plataforma de BI mais sofisticada não entrega valor se o dado que a alimenta é inconsistente ou atualizado manualmente.

Para PMEs construindo capacidade de dados, a stack moderna de ELT — Airbyte (open source) ou Fivetran para extração, BigQuery ou Snowflake como destino, dbt para transformação — está ao alcance de times pequenos sem necessidade de infraestrutura complexa. O investimento mais significativo não é em licença de software — é no tempo de alguém com habilidade em SQL e dbt para modelar os dados de forma que reflita as métricas de negócio corretamente.

O critério de priorização: quais fontes de dados têm as perguntas de negócio mais urgentes? Começar com uma ou duas fontes bem integradas e modeladas entrega valor imediato — muito mais do que tentar integrar tudo de uma vez com qualidade comprometida.