ETL: o que é e como o dado chega ao seu dashboard

Segunda-feira, reunião de resultados. O diretor comercial abre o painel e o faturamento da semana passada parece baixo demais. O financeiro diz que o número do ERP é outro. Meia hora depois alguém descobre que a atualização do painel parou na quinta-feira e ninguém percebeu. A reunião acaba sem decisão, e a confiança no dashboard cai mais um degrau.

O problema quase nunca está no gráfico, e sim no caminho que o dado percorre entre o sistema onde ele nasce e a tela onde ele é lido. Esse caminho tem nome técnico, ETL ou pipeline de dados, e costuma ser a parte menos visível e mais frágil de qualquer projeto de BI.

Este texto explica o que é ETL sem jargão, o que acontece em cada etapa, onde as coisas costumam quebrar em silêncio e o que perguntar à sua equipe ou fornecedor para saber se os números de hoje estão realmente atualizados.

ETL: o que é, em uma frase

ETL é o processo que extrai dados dos sistemas da empresa, transforma esses dados com as regras do negócio e carrega o resultado num lugar preparado para análise. A sigla vem do inglês: Extract, Transform, Load.

Um pipeline de dados é a versão automatizada e encadeada desse processo. Em vez de alguém exportar planilhas toda manhã, um conjunto de rotinas roda em horários definidos (ou a cada evento), executa cada etapa na ordem certa, registra o que aconteceu e avisa quando algo falha.

Na prática, quando alguém da sua empresa diz "o painel atualiza toda noite", está descrevendo um pipeline. A pergunta que importa para o gestor é: e quando ele não atualiza, quem fica sabendo?

O caminho do dado até o dashboard

Pense numa distribuidora com ERP para faturamento, CRM para o funil de vendas, uma planilha de metas mantida pelo comercial e um sistema de logística terceirizado. O diretor quer ver, num só painel, vendas por vendedor contra a meta, margem por cliente e prazo médio de entrega.

Nenhum desses sistemas tem a resposta sozinho. O caminho típico é este:

1. Origem. Os dados nascem em sistemas operacionais: ERP, CRM, e-commerce, ponto, planilhas, APIs de parceiros.
2. Extração. Uma rotina lê o que mudou em cada origem e copia para uma área de armazenamento separada, sem pesar no sistema de produção.
3. Transformação. Os dados são limpos, cruzados e calculados: o código do cliente no CRM é ligado ao CNPJ do ERP, devoluções são abatidas, a margem é calculada com a regra que o financeiro aprovou.
4. Carga. O resultado é gravado num banco analítico, muitas vezes um data warehouse, organizado para consultas rápidas.
5. Consumo. O dashboard, o relatório ou a planilha conectada lê dessa base pronta, e não dos sistemas de origem.

Cada seta entre essas etapas é um ponto em que o dado pode atrasar, duplicar, sumir ou chegar errado. O trabalho de engenharia de dados é tornar essas setas confiáveis e visíveis.

ETL e ELT em linguagem simples

Você vai ouvir as duas siglas. A diferença é só a ordem das duas últimas letras, mas ela muda a arquitetura.

• ETL (extrair, transformar, carregar): o dado é tratado no meio do caminho, por um programa ou servidor intermediário, e só o resultado final é gravado no banco analítico.
• ELT (extrair, carregar, transformar): o dado é copiado quase como está para o banco analítico e o tratamento acontece lá dentro, com consultas que geram tabelas prontas para o BI.

Para o gestor, a vantagem do ELT é que o dado bruto fica guardado: se o financeiro muda a regra de margem, dá para recalcular o histórico sem pedir nada de novo ao ERP. Com bancos analíticos em nuvem, é comum um desenho ELT com algum tratamento antes da carga, por exemplo para mascarar dados pessoais. O que importa é a pergunta: se a regra mudar, conseguimos recalcular o passado?

Extração: de onde e com que frequência

A extração é a etapa que mais depende do mundo de fora. Os sistemas de origem não foram feitos para alimentar BI, e cada um oferece uma porta diferente:

• Leitura direta do banco do ERP, quando o fornecedor permite. É rápida, mas exige cuidado para não pesar no sistema em horário de operação.
• API do sistema, comum em CRMs, plataformas de e-commerce e ERPs em nuvem. Costuma ter limite de chamadas por minuto e paginação, o que precisa ser respeitado.
• Arquivos exportados, como CSV ou planilha colocados numa pasta. Funciona, mas é a origem mais sujeita a mudança de layout sem aviso.
• Eventos e webhooks, quando o sistema avisa que algo aconteceu (um pedido foi faturado, um pagamento foi confirmado).

Carga completa ou só o que mudou

Copiar tudo todo dia é simples, mas fica lento e caro conforme o volume cresce. O padrão mais saudável é a extração incremental: ler apenas o que foi criado ou alterado desde a última execução, usando uma data de atualização ou um identificador sequencial. O cuidado aqui é com registros alterados retroativamente, como uma nota cancelada dias depois ou um pedido com data de emissão editada. O pipeline precisa prever esse caso, senão o painel mostra uma venda que já não existe.

Com que frequência atualizar

A resposta honesta é: na frequência em que alguém toma decisão com o dado. Uma reunião semanal de resultados não precisa de atualização a cada cinco minutos. Um painel de expedição que orienta a separação de pedidos ao longo do dia talvez precise. Atualização mais frequente significa mais execuções, mais consumo de infraestrutura e mais pontos de falha. Defina a frequência por painel, não pela empresa inteira.

Transformação: onde moram as regras de negócio

É na transformação que o dado vira informação, e é também onde nascem as brigas de reunião. Exemplos de regras que alguém precisa decidir e registrar:

• O que conta como venda: pedido emitido, nota faturada ou pagamento recebido?
• Devoluções e cancelamentos: abatem no mês da venda ou no mês da devolução?
• Cliente único: o mesmo CNPJ com três cadastros no CRM é um cliente ou três?
• Margem: sobre o custo médio, o custo da última compra ou o custo padrão?
• Fuso e corte de dia: um pedido feito às 23h50 pelo app entra em qual dia?

São decisões de negócio que, se ficarem implícitas no código, viram números diferentes em painéis diferentes. A boa prática é ter uma definição única de cada métrica, escrita em linguagem de gestão, aprovada pela área dona do número e implementada num só lugar do pipeline.

A transformação também faz a limpeza: padroniza nomes de cidades, descarta registros de teste, corrige códigos de produto que mudaram, une tabelas de sistemas diferentes por uma chave confiável.

Carga e atualização dos painéis

Depois de transformado, o dado é gravado no banco analítico em tabelas desenhadas para leitura: vendas por dia, por cliente, por produto, já com os cálculos prontos. O dashboard não refaz contas pesadas; ele só lê.

Dois detalhes técnicos fazem diferença para quem usa o painel:

• Carga atômica. A tabela nova só substitui a antiga quando estiver completa. Sem isso, quem abrir o painel durante a atualização pode ver metade do mês.
• Ordem de dependências. Se a tabela de margem depende da tabela de custos, ela não pode rodar antes. Orquestradores de pipeline existem justamente para garantir essa sequência e repetir automaticamente uma etapa que falhou por um problema passageiro.

Se você ainda está decidindo como esses dados serão apresentados, vale ler a comparação entre dashboard personalizado e Power BI. O pipeline é o mesmo nos dois casos; o que muda é a camada de visualização.

Falhas silenciosas e como monitorar

Pipeline que quebra com erro é o caso fácil: alguém recebe um alerta e corrige. O perigoso é o pipeline que roda com sucesso e entrega o número errado. Os casos mais frequentes:

• A origem não mandou nada. A API respondeu, mas sem registros, por uma mudança de permissão ou de filtro. O pipeline grava zero vendas e marca "concluído".
• O layout mudou. A planilha de metas ganhou uma coluna nova e os valores passaram a ser lidos da coluna errada.
• Duplicidade. Uma execução repetida após uma falha carregou o mesmo dia duas vezes, e o faturamento dobrou.
• Atraso disfarçado. A atualização da madrugada parou, o painel continua mostrando os números de três dias atrás e nada na tela indica isso.
• Chave quebrada. Um cadastro novo de cliente não encontra correspondência entre CRM e ERP e as vendas dele somem do relatório por vendedor.

O remédio é tratar o pipeline como qualquer sistema em produção, com monitoramento próprio. Os conceitos são os mesmos que explicamos em observabilidade com logs, métricas e traces, aplicados a dados:

• Frescor: cada tabela registra quando foi atualizada pela última vez, e um alerta dispara se passar do prazo combinado.
• Volume: a quantidade de registros carregados é comparada com a média dos dias equivalentes; uma queda ou um salto anormal gera aviso.
• Testes de qualidade: regras simples rodam a cada carga, como "nenhum pedido sem cliente", "nenhuma nota duplicada", "total do dia bate com o total do ERP".
• Conciliação periódica: de tempos em tempos, um número-chave do painel é comparado com o relatório oficial do sistema de origem.

Como saber se os números de hoje estão atualizados

Esta é a pergunta que o gestor deveria conseguir responder sem ligar para ninguém. Um painel bem construído mostra, na própria tela, a data e a hora da última atualização bem-sucedida de cada fonte. Se o seu painel não mostra isso, é o primeiro ajuste a pedir. É pouco esforço e evita a reunião descrita no começo deste texto.

Checklist para avaliar o pipeline da sua empresa

Leve estas perguntas para a próxima conversa com a equipe técnica ou com o fornecedor de BI:

1. Existe um desenho, mesmo simples, de quais sistemas alimentam quais painéis?
2. Cada painel mostra a data e hora da última atualização?
3. Alguém é avisado automaticamente quando uma carga falha ou atrasa?
4. Há verificação de volume, ou um dia com zero vendas passaria despercebido?
5. As regras de cada métrica estão escritas e têm uma área dona?
6. Se uma regra mudar, é possível recalcular o histórico?
7. Uma execução repetida pode duplicar dados, ou o pipeline é seguro para rodar de novo?
8. A extração pesa no ERP em horário de operação?
9. Dados pessoais de clientes e funcionários são tratados conforme a LGPD, com acesso restrito e só o necessário para a análise?
10. Se a pessoa que montou o pipeline sair, outra consegue mantê-lo?

Se várias respostas forem "não sei", o risco não está no gráfico, está no encanamento.

Ferramenta pronta ou pipeline sob medida

Ferramentas de mercado com conectores prontos muitas vezes resolvem bem a extração dos sistemas mais comuns, como mostramos em ferramenta de ETL ou pipeline próprio. A decisão não precisa ser tudo ou nada.

Critérios para decidir:

• Cobertura real dos conectores para os seus sistemas, incluindo campos customizados.
• Modelo de cobrança da ferramenta conforme o volume cresce; avalie a tendência, não só o mês atual.
• Onde ficam as regras de negócio: precisam estar versionadas e legíveis, não espalhadas em telas de configuração.
• Dependência de fornecedor: se trocar de ferramenta, o que se perde?
• Capacidade de manter: quem na sua empresa ou no seu parceiro vai cuidar disso daqui a dois anos?

O arranjo mais comum é híbrido: conectores prontos onde eles existem e funcionam, código próprio para as origens difíceis e para a transformação, tudo rodando numa infraestrutura de nuvem com monitoramento.

Perguntas frequentes

ETL e integração de sistemas são a mesma coisa?

Não. A integração de sistemas troca dados entre sistemas operacionais para que um processo aconteça, como enviar um pedido do e-commerce ao ERP. O ETL copia dados desses sistemas, aplica regras de negócio e carrega o resultado num banco analítico para relatórios e dashboards, sem interferir na operação do dia a dia.

Preciso de um data warehouse para fazer ETL?

Não necessariamente, mas costuma ajudar. O ETL precisa de um destino preparado para análise, separado dos sistemas de produção, e um data warehouse é a opção mais comum quando há várias fontes e histórico relevante. Com poucas fontes e volume pequeno, um banco analítico simples e um pipeline enxuto podem bastar.

Com que frequência um ETL deve rodar?

Na frequência em que alguém toma decisão com o dado. Um painel para reunião semanal pode ser atualizado uma vez por dia, enquanto um painel de expedição pode precisar de atualizações ao longo do dia. Rodar o ETL com mais frequência aumenta execuções, consumo de infraestrutura e pontos de falha, então defina a frequência por painel.

Dá para fazer ETL dentro do Power BI?

Em parte. O Power BI tem recursos próprios de transformação de dados que atendem cenários com poucas fontes e regras simples. Quando há muitas fontes, volume crescente ou regras que precisam ser versionadas e reaproveitadas por vários painéis, um pipeline de ETL separado, gravando num banco analítico, tende a ser mais confiável e fácil de monitorar.

Como a Pervian Tech trabalha engenharia de dados

Na Pervian Tech, começamos por um diagnóstico: quais sistemas existem, como cada um expõe os dados, quais decisões a diretoria precisa tomar e com que frequência. A partir disso desenhamos o pipeline sob medida, aproveitando conectores prontos quando eles atendem e escrevendo código próprio onde a origem é difícil ou a regra é específica. A infraestrutura, a orquestração e o monitoramento fazem parte do trabalho de cloud e DevOps, com alertas de frescor, volume e qualidade desde a primeira carga.

Quando o objetivo final é um painel de gestão, o pipeline é entregue junto com a camada de visualização em dashboards e BI sob medida, com a data da última atualização visível em cada tela. Outros textos sobre o tema estão em dados e BI.

O primeiro diagnóstico é gratuito, o cronograma é definido em fases depois dele e o investimento é sob consulta, porque depende do número de fontes, do volume e das regras da sua operação. Se a sua reunião de resultados ainda começa com a pergunta "esse número está certo?", conte como seus dados circulam hoje.