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

> ETL é o processo que leva o dado do ERP ao dashboard. Veja as etapas, a diferença para ELT, onde o pipeline falha em silêncio e como checar se o número é atual.

Fonte: https://pervian.tech/blog/etl-e-pipeline-de-dados · Pervian Tech · publicado em 2026-10-01

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](https://pervian.tech/blog/dashboard-de-vendas-indicadores), 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](https://pervian.tech/blog/data-warehouse-para-empresas-medias), 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.

| Aspecto | ETL | ELT |
|---|---|---|
| Onde ocorre o tratamento | Fora do banco analítico | Dentro do banco analítico |
| Dado bruto guardado | Nem sempre | Sim, por padrão |
| Refazer um cálculo com regra nova | Pode exigir extrair de novo da origem, se o bruto não foi guardado | Basta reprocessar o que já está carregado |
| Situação em que costuma fazer sentido | Dados sensíveis que precisam ser filtrados antes, origens muito antigas | Bancos analíticos em nuvem, regras que mudam com frequência |

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](https://pervian.tech/blog/webhook-o-que-e)**, 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](https://pervian.tech/blog/sincronizacao-de-cadastros-entre-sistemas) é um cliente ou três?
- **[Margem](https://pervian.tech/blog/margem-de-contribuicao-por-produto-e-cliente):** 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](https://pervian.tech/blog/dashboard-personalizado-ou-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](https://pervian.tech/blog/observabilidade-logs-metricas-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](https://pervian.tech/blog/qualidade-de-dados-relatorios-nao-batem):** 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](https://pervian.tech/blog/ferramenta-de-etl-ou-pipeline-proprio). A decisão não precisa ser tudo ou nada.

| Situação | Caminho que costuma funcionar |
|---|---|
| Origens populares com conector oficial e estável | Ferramenta de conectores pronta |
| ERP local, versão antiga ou banco sem API | Extração sob medida |
| Regras de negócio específicas e que mudam | Transformação versionada, feita sob medida dentro do banco analítico |
| Poucas fontes e volume pequeno | Pipeline simples, sem orquestrador pesado |
| Muitas fontes com dependências entre si | Orquestrador com reprocessamento e alertas |

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](https://pervian.tech/servicos/cloud-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](https://pervian.tech/solucoes/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](https://pervian.tech/blog/categoria/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](https://pervian.tech/#contato).