Remover duplicatas no Power Query: escolha a versão

Remover duplicatas no Power Query exige definir quais campos identificam o mesmo registro e qual informação precisa permanecer. Duas linhas iguais podem ser uma repetição de carga; duas linhas com a mesma chave e situações diferentes podem representar versões legítimas. Tratar esses casos como equivalentes pode apagar justamente a atualização que deveria chegar ao modelo.

Este roteiro usa um cadastro hipotético com chave, versão e identificador de registro. A proposta é separar repetições idênticas de conflitos e aplicar uma escolha reproduzível quando a regra de negócio permitir. Guarde os dados originais para conferir tanto o resultado mantido quanto os registros descartados.

1. Defina a chave antes de remover duplicatas no Power Query

Escreva qual combinação identifica o evento ou cadastro. Em um pedido, a chave pode exigir documento e sequência do item; o número do pedido sozinho pode reunir várias linhas reais. Em um cadastro versionado, a chave de entidade e a chave de cada registro recebido cumprem papéis diferentes.

Teste exemplos conhecidos antes de remover linhas. Dois pedidos do mesmo cliente, com valor e data iguais, não são necessariamente o mesmo pedido. Se a fonte não fornece uma identificação suficiente, registre essa limitação e revise o contrato do dado, em vez de escolher uma combinação fraca apenas porque ela reduz o número de linhas.

2. Separe repetição idêntica de versão conflitante

Comece agrupando os registros pela chave e contando ocorrências. Depois, compare os campos que podem variar. Repetições idênticas em todos os campos relevantes podem ser tratadas de uma forma; situações, valores ou datas diferentes exigem outra conferência, especialmente quando a origem registra atualizações do mesmo objeto ao longo do tempo.

Mantenha uma consulta de revisão com chave, quantidade e campos divergentes. O perfil de dados ajuda a localizar padrões, mas não decide qual versão é verdadeira. Essa decisão depende de evidência e de uma regra aprovada, como versão de origem ou momento efetivo da atualização, conforme o processo real.

3. Conheça o alcance de Remover Duplicatas

A documentação de duplicidades descreve a remoção com base nas colunas selecionadas. A escolha dessas colunas define quais linhas são consideradas repetidas. Selecione somente os campos que correspondem ao critério aprovado e confira o resultado antes de aplicar a transformação ao conjunto inteiro.

O Power Query distingue maiúsculas de minúsculas nessa comparação. Se o cadastro considera os dois formatos equivalentes, normalize uma coluna auxiliar conforme a regra da fonte e preserve o texto original. Não transforme códigos indiscriminadamente: em determinados cadastros, diferenças de representação podem ter significado que precisa ser confirmado antes da consolidação.

4. Não presuma qual linha será preservada

A referência de Table.Distinct informa que, em geral, não há garantia de qual repetição específica será mantida. Portanto, ordenar uma prévia e remover duplicatas não basta para demonstrar uma escolha de versão. O exemplo abaixo utiliza uma regra explícita dentro de cada grupo.

Primeiro defina a prioridade de negócio. Neste caso hipotético, a maior Versao é preferida e o maior RegistroID resolve empates entre versões, conforme uma convenção assumida para o teste. Esse desempate é apenas uma escolha ilustrativa; um identificador maior não prova, por si só, que um evento aconteceu depois ou contém informação mais correta.

5. Escolha a versão com ordenação dentro do grupo

A linguagem M permite combinar Table.Group, Table.Sort e Table.FirstN para agrupar, ordenar cada conjunto e selecionar uma linha. O exemplo assume chaves preenchidas, versões válidas e RegistroID único na origem, premissas que precisam ser verificadas antes de adaptar a transformação.

let
    Fonte = #table(
        type table [
            Chave = text, Versao = Int64.Type,
            RegistroID = Int64.Type, Situacao = text
        ],
        {
            {"A", 1, 10, "Aberto"},
            {"A", 2, 11, "Em análise"},
            {"A", 2, 12, "Concluído"},
            {"B", 1, 20, "Aberto"}
        }
    ),
    Grupos = Table.Group(
        Fonte, {"Chave"},
        {{"Escolhida", each Table.FirstN(
            Table.Sort(_, {
                {"Versao", Order.Descending},
                {"RegistroID", Order.Descending}
            }), 1
        )}}
    ),
    Resultado = Table.Combine(Grupos[Escolhida])
in
    Resultado

Espere A com versão 2 e RegistroID 12, e B com versão 1 e RegistroID 20. Table.Combine reúne as tabelas selecionadas. A regra determina quais registros permanecem, sem depender da posição em que apareceram inicialmente na prévia; a ordem final das linhas pode ser configurada separadamente para conferência.

6. Bloqueie empates que a regra não consegue resolver

Acrescente um teste para chave, versão e RegistroID repetidos com atributos diferentes. Nesse caso, a regra do exemplo deixou de oferecer um desempate completo. Encaminhe o conflito à revisão e preserve os registros, pois escolher qualquer um esconderia uma ambiguidade que continua presente na origem.

Trate também versões ausentes, chaves vazias e tipos incompatíveis antes da seleção. Uma linha sem chave não deve disputar com todas as outras linhas sem identificação como se fossem a mesma entidade. Separe esses casos da base elegível e informe quanto ficou pendente, mantendo a relação com arquivo e registro recebidos.

7. Mantenha histórico quando a pergunta exigir

Escolher a versão atual pode atender a um cadastro de situação vigente, mas não reconstrói o histórico de mudanças. Se a análise precisa explicar como um pedido evoluiu, preserve os eventos ou versões em uma tabela própria. A escolha de uma linha por entidade deve corresponder à pergunta do modelo, não a uma tentativa genérica de reduzir volume.

Documente a referência utilizada: maior versão recebida, versão efetiva em determinada data ou outra condição aprovada. Um arquivo recebido hoje pode conter uma correção antiga; ordem de chegada e vigência podem divergir. Sem essa definição, dois analistas podem escolher registros diferentes e ambos acreditar que estão mostrando a informação mais recente.

8. Concilie quantidades antes e depois

Registre linhas recebidas, chaves válidas, chaves distintas, linhas selecionadas e conflitos isolados. Confira se a base final contém a quantidade esperada para a granularidade escolhida. Uma redução expressiva não é automaticamente um sucesso: ela pode indicar que a chave foi definida de forma ampla e reuniu eventos que deveriam permanecer separados.

Para arquivos recorrentes, consulte a consolidação de arquivos e verifique reenvios ou sobreposição de períodos. A deduplicação pode controlar repetições já recebidas, mas a correção da origem evita que a mesma falha continue aparecendo a cada atualização e exigindo investigação repetida.

9. Confira relações e execução na fonte real

Depois de escolher os registros, teste as relações com as demais tabelas e confira chaves sem correspondência. O roteiro de mesclagem sem multiplicar vendas ajuda a conferir os vínculos. Uma base com uma linha por chave ainda pode produzir multiplicações quando encontra um cadastro associado que mantém várias versões sem filtro adequado.

Avalie a execução com uma amostra representativa da fonte real, observando o resultado e o tempo de atualização. O artigo de query folding complementa essa conferência. Não apresente o exemplo didático como garantia de desempenho em qualquer conector ou volume; preserve os testes que comprovam seu funcionamento no ambiente utilizado.

10. Guarde uma trilha de seleção e de rejeição

Produza uma saída com a chave, o registro escolhido e o critério aplicado. Mantenha uma segunda relação dos casos descartados ou bloqueados, com motivo. Essa trilha permite explicar por que um valor mudou e distinguir uma atualização legítima de uma exclusão feita por regra incorreta durante a preparação dos dados.

Repita os testes ao incluir uma nova versão, um empate e um registro fora do contrato. Confira também a saída vazia e o esquema esperado pelas etapas seguintes. A remoção confiável de duplicatas termina com uma escolha justificável e reproduzível, deixando visíveis as situações que a regra ainda não consegue resolver com a evidência disponível.

Documentação técnica da Microsoft consultada em 19/10/2026.