Ferramentas de Data Mapping: ELT, Visuais ou Code-First
Compare plataformas ELT gerenciadas, mapeadores visuais e bibliotecas code-first para data mapping, com preços e tratamento de schema drift.

A maioria das listas de "melhores ferramentas de data mapping" coloca um serviço de replicação de warehouse, um mapeador visual de XML de arrastar e soltar, e uma suíte ETL enterprise no mesmo ranking. Essas ferramentas fazem trabalhos diferentes. Este guia as divide em três grupos, mostra o que a documentação de cada fornecedor diz sobre seleção de colunas, tratamento de tipos e mudanças de esquema, e termina com um plano de teste curto que você pode rodar antes de assinar um contrato.
O que é uma ferramenta de data mapping?
Uma ferramenta de data mapping conecta um campo em um sistema de origem a um campo em um sistema de destino e registra as regras para converter um no outro. A Informatica define data mapping como "o processo de conectar um campo de dados de uma origem a um campo de dados em outra origem."
O resultado é um conjunto de pares mais regras. Um par diz "a coluna de origem customer_email vai para a coluna de destino email." Uma regra diz como o valor muda no caminho: converter um campo de texto em uma data, dividir um nome completo em duas colunas, mascarar um CPF, ou preencher um valor faltando.
Na carga de warehouse, o mesmo termo cobre um trabalho maior. A ferramenta lê o esquema de origem (tabelas, colunas, tipos), cria tabelas correspondentes no BigQuery ou Snowflake, e as mantém sincronizadas conforme a origem muda. A Informatica chama isso de schema mapping: fazer o esquema de origem corresponder ao esquema de destino.
Quais são os diferentes tipos de data mapping?
Há três níveis de data mapping: schema mapping (quais tabelas e colunas existem em cada lado), field mapping (qual coluna de origem alimenta qual coluna de destino), e value ou type mapping (como cada valor é convertido). Cada nível pode ser feito manualmente ou por software.
Nível | Pergunta que responde | Exemplo |
|---|---|---|
Schema mapping | Quais tabelas e colunas existem no destino? | A tabela orders do Postgres vira a tabela raw.orders do BigQuery com as mesmas colunas |
Field mapping | Qual coluna de origem alimenta qual coluna de destino? | created_at na origem alimenta order_date no destino |
Value ou type mapping | Como cada valor é convertido? | Um numeric(12,2) do Postgres chega como NUMERIC no BigQuery, um texto "2024-01-05" vira uma DATE |
Mapeamento manual significa que uma pessoa define cada relacionamento. Mapeamento automatizado significa que o software lê o esquema de origem e constrói o esquema de destino a partir dele, sem trabalho campo a campo. A maioria dos produtos modernos mistura os dois: a ferramenta lê o esquema e propõe os pares, e uma pessoa sobrescreve os que precisam de ajuste.
Quais são os três tipos de ferramentas de data mapping?
Ferramentas de data mapping se dividem em três grupos: plataformas ELT gerenciadas que copiam esquemas de origem para um warehouse, workbenches de mapeamento visual para regras campo a campo entre formatos, e bibliotecas code-first que deixam você definir regras de esquema em Python. O grupo certo depende de se o seu trabalho é replicação, conversão de formato, ou controle customizado.
Plataformas ELT gerenciadas (Erathos, Airbyte, Fivetran, Matillion, Estuary, Weld, Kondado, Nekt) fazem schema mapping automaticamente. Você escolhe tabelas e colunas, a ferramenta cria as tabelas de destino e carrega as linhas. Renomeações de campo e regras de negócio acontecem depois da carga, no dbt ou em SQL. O próprio guia da Fivetran diz que o conector dela "não tem um editor de mapeamento; as transformações acontecem depois, geralmente no dbt ou em outra camada SQL."
Workbenches de mapeamento visual (Altova MapForce, CloverDX, Boomi, Pentaho) são feitos para field mapping. Você desenha uma linha de um campo de origem para um campo de destino e anexa funções, filtros e lookups. O MapForce mapeia XML, JSON, bancos de dados, PDF, arquivos flat, Excel, EDI e Protobuf, e um recurso opcional de IA propõe conexões de campo que você aceita ou recusa uma a uma.
Bibliotecas code-first (dlt) geram o esquema de destino a partir dos próprios dados e deixam você definir regras em código. O dlt evolui o esquema de destino "seguindo a estrutura e os tipos de dados dos dados extraídos," e seus schema contracts permitem congelar tabelas, colunas ou tipos de dados.
Quais ferramentas de data mapping você deveria comparar?
A tabela abaixo lista o que a própria documentação e as páginas de preços de cada fornecedor dizem. Uma célula que diz "não está na documentação pública" significa que as páginas do fornecedor que buscamos não dizem, então você testa isso em uma prova de conceito.
Ferramenta | Grupo | Controles de mapeamento na documentação | Preço público | Implantação |
|---|---|---|---|---|
ELT gerenciado | Seleção de coluna por job, anonimização de coluna, criação automática de tabelas e gestão de esquema, detecção de schema drift com alertas | Grátis até 1M linhas/mês; US$ 29/mês para 2M linhas; US$ 250/mês para 5M linhas mais CDC | SaaS | |
ELT gerenciado (núcleo open source) | Seleção de coluna, propagação de mudança de esquema com quatro políticas, backfill de colunas novas ou renomeadas, mapeamentos customizados no Pro | Baseado em volume no Standard, baseado em capacidade (Data Workers) no Pro; valores em dólar não estão na página | Nuvem, auto-gerenciado, on-prem ou híbrido no Enterprise Flex | |
ELT gerenciado | Mapeamento automático de tipo por padrão, travamento de tipo, mapeamento de tipo customizado por coluna (Private Preview), bloqueio de dados, hash de coluna, um filtro de linha por tabela | Não está na documentação buscada | SaaS | |
ELT gerenciado / transformação | Tratamento de schema drift de CDC para colunas novas, deletadas e com tipo alterado | Não está na documentação buscada | Não está na documentação buscada | |
ELT gerenciado (tempo real) | Evolução de esquema com uma ação configurável para mudanças incompatíveis (backfill, disable binding, disable task, abort) | Não está na documentação buscada | Não está na documentação buscada | |
ELT gerenciado | Incluir ou excluir tabelas e colunas, hash ou remoção de colunas, tabelas protegidas para mudanças de esquema | Não está na documentação buscada | Não está na documentação buscada | |
ELT gerenciado (Brasil) | Lista de destinos inclui PostgreSQL, Redshift, BigQuery, MySQL, SQL Server, Google Sheets, Excel; sincronização de 5 minutos até semanal | R$ 99/mês para 4 integrações e 1M de registros/mês; teste de 14 dias | SaaS | |
ELT gerenciado | Transformações SQL e notebooks pós-carga; CDC baseado em log e SCD Tipo 2 no Growth | Gratuito com 40 execuções/mês; Starter a partir de US$ 149/mês; Growth a partir de US$ 499/mês | SaaS; Growth pode rodar dentro do seu AWS ou GCP | |
Biblioteca code-first | Inferência de esquema, coerção de tipo ou colunas variantes, schema contracts (evolve, freeze, discard_row, discard_value), achatamento de JSON aninhado | Não está na documentação buscada | Roda onde seu Python rodar | |
Mapeador visual | Mapeamento gráfico de campo any-to-any, funções, filtros, autoconectar campos de mesmo nome, conexões sugeridas por IA | Basic a partir de US$ 349, Professional a partir de US$ 679, Enterprise a partir de US$ 1.099 (período de cobrança não está na página) | Software desktop; não é open source | |
Mapeador visual / ETL | Mapeamento visual e em código, mapeamentos de template Excel transformados em workflows, validação, anonimização | A partir de US$ 42.000/ano | Seus servidores, Docker, AWS, GCP ou Azure; sem plano SaaS | |
iPaaS | "Mapping and transformation" listado como recurso padrão de Integration; controle de versão; Python e CI/CD no Professional | Pay-as-you-go US$ 99/mês mais uso; teste grátis de 30 dias | Não está na página de preços buscada | |
ETL visual | Interface de arrastar e soltar no navegador, plugins para dados aninhados e streaming | Não está na página do produto | On premises ou nuvem (Azure, AWS, GCP), Docker e Kubernetes |
Duas coisas se destacam. Primeiro, os modelos de preço diferem por grupo. Plataformas ELT cobram por linhas ou execuções, mapeadores visuais cobram por assento ou por núcleo de servidor, e a CloverDX começa em US$ 42.000 por ano enquanto a Erathos começa em US$ 0. Segundo, a Fivetran é a única fornecedora ELT nesta lista cuja documentação descreve controle de tipo por coluna, e esse recurso ainda está em Private Preview.
Como ferramentas de data mapping lidam com tipos de origem para destino?
Plataformas ELT mapeiam tipos de origem para tipos de destino automaticamente, e só algumas deixam você sobrescrever o resultado por coluna. Bibliotecas code-first coagem valores ou dividem incompatibilidades em colunas separadas. Os casos que quebram na prática são decimais, timestamps e JSON aninhado.
O Fivetran mapeia tipos de origem para tipos de destino por padrão. O travamento de tipo congela o tipo de destino de uma coluna, então um tipo de entrada que muda é convertido para o tipo travado em vez de mudar a tabela. O mapeamento de tipo de dado customizado adiciona uma sobrescrita de tipo de destino por coluna.
O dlt segue outro caminho. Seu normalizador padrão coage entre tipos compatíveis, então um texto "123" vira um inteiro onde a coluna é um inteiro. Quando um valor não pode ser coagido, o dlt o escreve em uma coluna variante como id__v_text em vez de falhar a carga. Um segundo normalizador desliga a coerção, então toda incompatibilidade vira uma coluna variante e o valor original é mantido como recebido.
Decimais são a primeira coisa a testar. O tipo NUMERIC do BigQuery tem precisão 38 e escala 9, o FLOAT64 é uma aproximação, e inserir 1,125 em uma coluna NUMERIC(5, 2) armazena 1,13. A Snowflake diz que algumas conversões perdem informação: FLOAT para INTEGER descarta a fração e arredonda. O dlt acrescenta que um float Python como 34,7 passado para uma coluna decimal é convertido através de uma string primeiro, o que é conveniente mas "matematicamente impreciso." Dinheiro deveria sair da origem como um decimal ou uma string, nunca como um float.
Timestamps são a segunda coisa. O TIMESTAMP do BigQuery é um ponto absoluto no tempo e o DATETIME não tem fuso horário. O dlt normaliza timestamps para UTC com fuso horário e trata timestamps sem fuso como UTC, porque o BigQuery não aceita timestamps sem fuso. Uma origem que armazena hora local sem fuso vai deslocar pelo offset a menos que a ferramenta ou seu modelo dbt corrija isso.
JSON aninhado é a terceira coisa. O normalizador padrão do dlt achata dados aninhados em tabelas filhas, converte identificadores para snake_case (CamelCase vira camel_case), e encurta nomes que excedem o limite do destino. O BigQuery também consegue guardar dados aninhados como colunas JSON, ARRAY ou STRUCT. Qual você recebe depende da ferramenta, então verifique isso com um registro aninhado real.
O que acontece quando um esquema de origem muda?
Quando uma origem adiciona, remove ou muda o tipo de uma coluna, cada ferramenta aplica uma política padrão, e os padrões diferem: o Airbyte cria colunas novas e mantém as removidas como NULL, o Matillion renomeia uma coluna com tipo alterado e começa uma nova do zero, a Estuary faz backfill, o Weld cai para uma sincronização completa, e o dlt evolui o esquema a menos que um contrato diga freeze. A política importa mais do que qualquer lista de recursos.
Ferramenta | Coluna nova | Coluna removida | Mudança de tipo | Chave ou cursor removido |
|---|---|---|---|---|
Criada no destino; só linhas atualizadas recebem valores a menos que "Backfill new or renamed columns" esteja ativo, o que ressincroniza o stream inteiro | Coluna e histórico mantidos; linhas novas recebem NULL | Pode causar erros de linha; precisa de um refresh de esquema ou stream | Conexão pausada para revisão manual | |
Captada quando não vazia | Mantida no destino, não é mais carregada, NULL a partir daí | Coluna antiga renomeada com um sufixo de data e hora; nova coluna do novo tipo começa NULL | Não está na página buscada | |
Tratada pela evolução de esquema com AutoDiscover | Tratada pela evolução de esquema | Em mudança incompatível: backfill (padrão), disableBinding, disableTask, ou abort | Mudanças de chave podem criar uma nova coleção com sufixo _v2 | |
Tabelas e colunas podem ser adicionadas depois da configuração | Colunas podem ser removidas depois da configuração | Tabela desprotegida: sincronização completa automática, que pode perder dados que a origem não guarda mais. Tabela protegida: notificação e sincronização completa manual | Não está na página buscada | |
Anexada (modo evolve) ou bloqueada (freeze) | Mantida | Coagida quando possível, senão uma coluna variante; contratos podem descartar a linha ou o valor | Não está na página buscada | |
Tratada pela migração de esquema | Tratada pela migração de esquema | O tipo travado vence quando o travamento de tipo está ativo | Mudanças de chave primária fazem parte da migração de esquema | |
Detecção de schema drift com alertas | Detecção de schema drift com alertas | Detecção de schema drift com alertas | Não está na documentação buscada |
O Airbyte também deixa você escolher o quanto disso acontece sozinho: propagar só mudanças de campo, propagar todas as mudanças de campo e stream, aprovar todas as mudanças você mesmo, ou parar sincronizações futuras. Seja qual for sua escolha, um cursor ou chave primária removido pausa a conexão. O Cloud verifica o esquema de origem antes de cada sincronização no máximo a cada 15 minutos; o auto-gerenciado verifica no máximo a cada 24 horas, então uma mudança pode esperar um dia.
Dois custos se escondem nessas tabelas. Backfills automáticos releem streams inteiros, e o Airbyte observa que eles "podem gerar custos maiores no destino." A sincronização completa automática do Weld em uma tabela desprotegida pode perder linhas que a origem já deletou. Escolha uma ferramenta cujo padrão combine com o que você faria manualmente, depois confirme isso em um teste.
O que você deveria testar em uma prova de conceito de ferramenta de data mapping?
Traga uma fonte pequena com um conjunto conhecido de colunas problemáticas, carregue no destino real com cada ferramenta candidata, e verifique as tabelas resultantes. O teste inteiro cabe em uma tarde por ferramenta e responde mais do que qualquer matriz de recursos.
A tabela de origem deveria incluir:
- Uma coluna decimal com um valor em moeda com duas casas decimais.
- Uma coluna de timestamp armazenada em hora local sem fuso.
- Uma coluna JSON com pelo menos um objeto aninhado e um array.
- Uma coluna contendo dado pessoal que você precisa esconder (um e-mail ou CPF).
- Uma chave primária e um cursor de data que você pode remover depois.
Depois rode a sincronização, e depois que ela funcionar, mude a origem e sincronize de novo:
- Adicione uma coluna. Ela aparece? Linhas antigas recebem valores, e a ferramenta releu a tabela inteira para preenchê-las?
- Renomeie uma coluna. Isso é tratado como um drop mais um add, e o que acontece com o histórico?
- Mude uma coluna de inteiro para texto. A carga falha, coage, ou cria uma segunda coluna?
- Remova o cursor. A ferramenta pausa, dá erro, ou continua rodando com dados desatualizados?
Para cada resultado, anote quatro coisas: o tipo de destino de cada coluna, a contagem de linhas no destino em comparação com a origem, se a coluna de dado pessoal está com hash ou removida, e o que a ferramenta te disse. Uma ferramenta que mudou a tabela sem um alerta é uma ferramenta que você vai debugar às 2 da manhã.
Onde a Erathos se encaixa
A Erathos é uma plataforma ELT gerenciada que faz schema mapping para um warehouse e deixa renomeações de campo e regras de negócio para o dbt. Ela se encaixa no primeiro grupo deste guia: replicação recorrente de fontes de banco de dados e API para BigQuery, ClickHouse, Databricks, Redshift, Postgres, SQL Server ou Supabase, a partir de um catálogo de 139 conectores.
Os controles de mapeamento que você tem por job são seleção de coluna (todas as colunas ou um subconjunto escolhido) e anonimização de coluna para campos sensíveis, ambos definidos no modal de colunas do job. Do lado do destino, a Erathos cria as tabelas e gerencia o esquema no dataset do BigQuery que você escolher, e pipelines do BigQuery rodam incrementalmente por padrão.
Os dados se movem em três etapas. A Erathos extrai da origem, escreve o lote em um bucket temporário dentro da própria infraestrutura, carrega no warehouse com COPY ou o equivalente do destino, e apaga os arquivos temporários.
Todo conector mantido inclui detecção de schema drift e alertas mais retentativas automáticas. Para o comportamento de sincronização, você escolhe entre full refresh, partial refresh, partial overwrite, partial append e partial versioned. Os modos partial precisam de uma chave primária e um cursor de data ou datetime em fontes de banco de dados; para fontes de API, a Erathos escolhe o cursor sozinha. Postgres e MySQL também dão suporte a CDC, com um snapshot inicial ou modo somente WAL.
Para a etapa de transformação, o Control dispara um webhook ou chamada de API quando uma sincronização termina, para que um job do dbt Cloud ou um DAG do Airflow ou Dagster pegue as tabelas brutas. A mesma página cobre políticas de retentativa por conexão ou por job, backfill baseado em cursor de um intervalo de datas, e detecção de soft-delete comparando com a origem sem uma recarga completa.
O preço é por linhas escritas no warehouse, sem limite de conectores ou jobs acima do plano gratuito. O Freemium é US$ 0 para 1M de linhas por mês, 1 usuário, 5 jobs, e atualizações diárias. O Movement é US$ 29 para 2M de linhas, 3 usuários, jobs ilimitados, e atualizações a cada hora. O Pro é US$ 250 para 5M de linhas, 5 usuários, CDC, Custom Connector, backfill customizado, e atualizações a cada 5 minutos.
Teste no seu próprio esquema
A lista de prova de conceito acima cabe em uma fonte e uma tarde. Experimente a Erathos grátis por 14 dias, conecte um banco de dados Postgres ou MySQL ou um dos conectores de API, escolha suas colunas, e veja o que chega no seu warehouse.