Ferramenta de ETL ou pipeline próprio: como escolher pelas fontes

A empresa decidiu que precisa de um painel confiável, ou de um data warehouse, e alguém da equipe técnica levanta a questão inevitável: como o dado vai sair do ERP, do CRM, do e-commerce e das planilhas e chegar até lá? Uma parte da equipe sugere contratar uma ferramenta de ETL com conectores prontos. Outra parte prefere escrever o pipeline em código, sob controle da casa.

As duas posições são razoáveis, e a discussão costuma ficar presa em preferências. Este texto propõe um critério mais objetivo, baseado nas fontes que a sua empresa realmente tem. Se o conceito ainda é novo, vale ler antes ETL: o que é e como o dado chega ao seu dashboard.

Resposta curta: decida pela natureza das fontes. Se a maioria delas é sistema SaaS conhecido, com esquema estável e conector maduro no mercado, uma ferramenta de ETL resolve rápido e libera a equipe para cuidar das regras de negócio. Se as fontes principais são ERP customizado, banco legado, arquivos enviados por parceiros ou regras que só existem na empresa, o pipeline próprio compensa. O critério prático é contar quantas fontes têm conector maduro.

Extrair, transformar e carregar: onde está o trabalho de verdade

ETL quer dizer extrair, transformar e carregar. Na conversa sobre ferramentas, as três etapas costumam ser tratadas como se pesassem a mesma coisa. Não pesam.

Extrair é buscar o dado na origem: ler a API de um sistema, consultar um banco, baixar um arquivo. Para sistemas populares, esse trabalho é repetitivo e muito parecido de empresa para empresa. É exatamente o que uma ferramenta pronta faz bem.

Carregar é gravar o dado no destino, normalmente um data warehouse na nuvem. Também é uma etapa bastante padronizada.

Transformar é onde mora o negócio: unificar o cadastro de cliente que aparece de três jeitos, decidir se devolução entra no faturamento, converter unidades, aplicar a regra de rateio que o controller definiu. Nenhuma ferramenta conhece essas regras de antemão, porque elas são da sua empresa.

Muitas equipes hoje fazem ELT: extraem e carregam o dado bruto primeiro e transformam dentro do próprio data warehouse. A ordem muda, mas a conclusão é a mesma. A parte genérica (extrair e carregar) pode ser comprada. A parte específica (transformar) sempre vai exigir trabalho de quem conhece o negócio.

Por isso a pergunta "ferramenta ou código?" é, na verdade, sobre a extração. É ali que a natureza das fontes faz toda a diferença.

Conectores prontos: Fivetran, Airbyte e similares

Fivetran, Airbyte, Stitch e outras ferramentas do mesmo tipo oferecem uma biblioteca de conectores para sistemas e bancos de dados conhecidos. Em geral, você escolhe a fonte e o destino, e a ferramenta cuida da extração, da carga e do agendamento. Há opções comercializadas como serviço em nuvem e opções de código aberto que a própria empresa pode hospedar. Várias delas também permitem escrever conectores personalizados dentro da própria plataforma, o que ajuda quando falta só uma ou duas fontes, mas transfere para a sua equipe a manutenção desses conectores específicos.

O que esse tipo de ferramenta faz muito bem:

• Velocidade para começar. Para uma fonte com conector pronto, o dado pode estar no warehouse em pouco tempo, sem escrever código de extração.
• Manutenção terceirizada do conector. Quando o fornecedor do sistema de origem muda a API, quem atualiza o conector é o fornecedor da ferramenta, não a sua equipe.
• Recursos operacionais já resolvidos. Agendamento, novas tentativas em caso de falha, alertas e registro de execuções costumam vir prontos.

Os limites aparecem quando:

• O conector não existe ou é imaturo. Conectores variam muito em qualidade. Alguns são amplamente usados e bem mantidos; outros são recentes, cobrem só parte das tabelas ou foram construídos pela comunidade.
• O sistema de origem foi customizado. Um conector feito para a versão padrão de um ERP pode não enxergar os campos e as tabelas que a sua empresa acrescentou.
• O modelo de cobrança cresce com o volume. Muitas ferramentas cobram de acordo com a quantidade de dados processados ou de linhas sincronizadas. Vale simular o custo com o volume real antes de assinar e de novo quando a empresa crescer.
• Há exigências de onde o dado pode trafegar. Dados pessoais e informações sensíveis pedem atenção a onde a ferramenta processa e armazena o dado, inclusive por conta da LGPD.

Recursos, conectores disponíveis, preços e condições mudam com frequência. Confirme sempre com o fornecedor o que vale hoje para as suas fontes específicas, de preferência com um teste usando os seus próprios sistemas.

Pipeline próprio: código, agendamento e monitoramento

Pipeline próprio não é um script rodando no computador de alguém. Feito direito, ele tem pelo menos quatro partes:

1. Código de extração e carga, versionado, revisado e com testes, escrito em uma linguagem que a equipe domina.
2. Orquestração, ou seja, uma ferramenta de agendamento (Airflow, Dagster e Prefect são exemplos conhecidos de código aberto) que sabe a ordem das tarefas, refaz o que falhou e não roda a etapa seguinte sobre dado incompleto.
3. Monitoramento e alertas: saber que a carga da madrugada falhou antes da reunião das nove, e não depois.
4. Documentação: de onde vem cada tabela, com que frequência é atualizada e quem responde por ela.

A vantagem é o controle. O pipeline lê exatamente o que a fonte oferece, do jeito que ela oferece, inclusive quando isso significa um arquivo em formato próprio ou uma consulta cuidadosa em um banco antigo. O custo de operação também tende a ser mais previsível, porque depende da infraestrutura contratada e das horas de manutenção, não do volume de linhas sincronizadas. Só não confunda previsível com baixo: o tempo de quem desenvolve e mantém o pipeline é o maior custo, e precisa entrar na conta.

A desvantagem é igualmente clara: toda a manutenção é sua. Quando a API da fonte muda, quando o servidor de arquivos troca de endereço, quando alguém altera uma coluna no banco legado, é a sua equipe (ou o seu fornecedor) que precisa corrigir. Pipeline próprio sem monitoramento é a forma mais comum de dado desatualizado que ninguém percebe.

Fontes difíceis: ERP customizado, banco legado e arquivos

É aqui que a decisão costuma se resolver sozinha. Em muitas empresas médias brasileiras, o mapa de fontes tem dois grupos bem diferentes.

Fontes fáceis: plataforma de e-commerce conhecida, CRM de mercado, ferramenta de marketing, gateway de pagamento, planilha em nuvem. São sistemas usados por muitas empresas, com API documentada e, muitas vezes, conector pronto.

Fontes difíceis: o ERP que foi customizado ao longo de anos, o sistema de produção desenvolvido internamente, o banco de dados de um software que não tem mais suporte, a planilha que o parceiro envia toda segunda-feira com colunas que mudam de nome, o arquivo de retorno que só um sistema específico gera.

Para as fontes difíceis, raramente existe conector maduro. E, quando existe, ele não conhece as customizações. O trabalho de extração passa a envolver decisões que só quem olha o caso consegue tomar:

• Ler direto do banco ou por réplica? Consultas pesadas no banco de produção do ERP podem deixar o sistema lento para quem está faturando.
• Carga completa ou incremental? Sistemas antigos nem sempre têm uma coluna confiável de "última alteração", o que complica buscar só o que mudou. As saídas vão de recarregar tabelas pequenas por inteiro a ler o log de transações do banco (a chamada captura de mudanças, ou CDC), que exige acesso e configuração no servidor.
• Como lidar com arquivos de terceiros? Validar o formato na chegada, rejeitar o que vier quebrado e avisar o responsável, em vez de carregar lixo silenciosamente.
• Como não depender de tela? Quando o sistema não oferece nem banco acessível nem exportação, às vezes o caminho é uma camada intermediária. Detalhamos essas opções em como integrar um sistema legado que não tem API.

Se as suas fontes mais importantes estão nesse segundo grupo, o pipeline próprio deixa de ser preferência e passa a ser necessidade, ao menos para essas fontes.

Transformação e regras de negócio: dbt e a camada de modelagem

Independentemente de como o dado chega ao warehouse, a transformação precisa de um lar. A pior opção é espalhar regra de negócio em fórmulas de relatório, consultas soltas e planilhas de apoio. Ninguém audita, ninguém testa e cada relatório acaba com sua própria versão do número.

Ferramentas como o dbt popularizaram uma abordagem que vale para qualquer cenário: escrever as transformações em SQL, versionadas como código, com testes automáticos e documentação gerada a partir do próprio projeto. A camada de modelagem costuma ser organizada em etapas:

• Dado bruto, exatamente como veio da fonte, para que seja possível reprocessar.
• Dado tratado, com nomes padronizados, tipos corrigidos e duplicidades resolvidas.
• Dado de negócio, com as métricas oficiais calculadas uma única vez: faturamento líquido, margem, prazo de entrega, o que for relevante.

Essa camada é sempre específica da empresa, use você uma ferramenta de ETL ou pipeline próprio para extrair. É também onde se resolve boa parte das divergências descritas em qualidade de dados: por que seu relatório não bate. Testes simples, como "nenhum pedido sem cliente" ou "o total do dia não pode ser zero em dia útil", pegam problemas antes de eles chegarem à diretoria.

Tabela comparativa: ferramenta de ETL x pipeline próprio

Repare na última linha: ela é igual nos dois lados. A diferença entre as abordagens está na extração e na operação, não na modelagem.

Quando escolher cada um (e o modelo misto)

Sinais de que a ferramenta de ETL é a melhor escolha

• A maioria das fontes é sistema SaaS de mercado com conector amplamente usado.
• Os sistemas de origem são usados de forma padrão, sem grandes customizações.
• A equipe técnica é pequena e precisa gastar o tempo na modelagem e nos indicadores, não em código de extração.
• O volume de dados é moderado e a simulação de custo com o volume real faz sentido para o orçamento.
• Não há restrição contratual ou regulatória que impeça o dado de passar pela infraestrutura do fornecedor.

Nesse cenário, escrever extração própria para sistemas com conector maduro é reinventar o que outros já mantêm.

Sinais de que o pipeline próprio compensa

• As fontes que mais importam para a gestão são ERP customizado, sistema interno ou banco legado.
• Parte relevante dos dados chega em arquivos de parceiros, fornecedores ou bancos, com formatos próprios.
• A extração precisa de cuidados específicos para não pesar no sistema de produção.
• O volume é alto e o modelo de cobrança por volume ficaria desproporcional.
• Há exigências rígidas sobre onde o dado pode ser processado e armazenado.

O modelo misto, que costuma ser a resposta

Em boa parte das empresas médias, o mapa de fontes tem os dois grupos. A arquitetura que costuma funcionar melhor é mista:

1. Ferramenta de ETL para as fontes fáceis, como e-commerce, CRM e ferramentas de marketing.
2. Pipeline próprio para as fontes difíceis, como ERP customizado, banco legado e arquivos.
3. Um único destino, o data warehouse, recebendo as duas cargas.
4. Uma única camada de modelagem, com as regras de negócio escritas uma vez e testadas.
5. Um único monitoramento, que mostra o estado de todas as cargas, venham de onde vierem.

O ponto 5 é o que faz o modelo misto dar certo. Para entender como organizar o destino dessas cargas, veja data warehouse para empresa média: por onde começar.

Um exercício para fazer antes de decidir

Liste todas as fontes de dado que alimentam os indicadores da diretoria. Para cada uma, anote: é sistema de mercado ou interno? Foi customizado? Existe conector maduro e amplamente usado para ela? Qual a importância dessa fonte para os números principais?

Se a maior parte das fontes importantes tem conector maduro, comece pela ferramenta. Se a maior parte não tem, o pipeline próprio é o centro e a ferramenta pode entrar pontualmente.

Perguntas frequentes

Qual a diferença entre ETL e ELT?

ETL transforma o dado antes de carregá-lo no destino, enquanto ELT carrega o dado bruto primeiro no data warehouse e faz a transformação lá dentro. A ordem muda, mas a decisão entre ferramenta de ETL e pipeline próprio continua a mesma: extrair e carregar podem ser comprados, e as regras de negócio sempre exigem trabalho específico da empresa.

Dá para usar ferramenta de ETL com ERP customizado?

Depende do conector. Um conector feito para a versão padrão do ERP pode não enxergar os campos e as tabelas que a empresa acrescentou ao longo dos anos. Quando o ERP customizado é a fonte mais importante dos indicadores, o mais comum é extraí-lo com pipeline próprio e usar a ferramenta de ETL apenas para os sistemas SaaS de mercado.

Pipeline próprio sai mais barato que ferramenta de ETL?

Nem sempre. O pipeline próprio tem custo de infraestrutura mais previsível, porque não depende do volume de linhas sincronizadas, mas o maior custo é o tempo de quem desenvolve e mantém o código, a orquestração e o monitoramento. A ferramenta de ETL tende a sair na frente quando as fontes têm conector maduro e o volume de dados é moderado.

Precisa de monitoramento em um pipeline de dados?

Sim. Um pipeline de dados sem monitoramento é a forma mais comum de painel desatualizado que ninguém percebe. O mínimo é ter alerta quando uma carga falha, registro de cada execução e testes que conferem o resultado, como o total do dia não ser zero em dia útil, antes que o número chegue à reunião da diretoria.

Como a Pervian Tech ajuda a decidir e a levar o dado até o painel

Começamos com um diagnóstico inicial gratuito: mapeamos as fontes de dado, verificamos quais têm conector maduro, avaliamos as customizações do ERP e os arquivos que chegam de fora, e entendemos quais indicadores a diretoria precisa. A recomendação sai desse mapa, não de preferência por ferramenta.

Quando uma ferramenta de ETL de mercado atende as suas fontes, recomendamos esse caminho e ajudamos a configurá-lo bem. Quando as fontes são difíceis, construímos o pipeline próprio com orquestração, monitoramento e documentação, e montamos a camada de modelagem com as regras de negócio testadas. Esse desenho faz parte do nosso trabalho de arquitetura de software, e o caminho até o painel final é o que entregamos em dashboards e BI sob medida. Outros textos sobre o tema estão na categoria dados e BI.

O investimento é definido sob consulta, depois de entender o número e a natureza das fontes. Se o dado da sua empresa ainda chega ao painel por exportações manuais e planilhas de apoio, conte para nós como é hoje.