Power Query: conheça a ferramenta de ETL do Power BI

Autor: Pedro Tebaldi PM do KeepGreen

Publicado jul/2022Atualizado set/2026

Segunda-feira de manhã, a consulta que abastece o relatório parou. Ninguém tinha mexido nela. Na origem, porém, alguém renomeou uma coluna que o relatório nem usa. Bastou isso para a atualização morrer numa etapa criada por clique meses antes.

Este texto percorre o processo de ETL do Power Query pelo código que cada clique gera. Ou seja, nada aqui é descrição de tela. Todo número saiu de laboratório próprio, no Power BI Desktop 2.155.756.0 (26.06) sobre Windows 11. A tabela de vendas é sintética, com 1.000.000 de linhas, medida em 3 de setembro de 2026.

Você vai ver a linguagem M que o editor escreve sozinho e a ordem de etapas que sobrevive a mudança na origem. Depois disso, entram duas falhas silenciosas: a mesclagem que devolve null sem avisar e o perfil de coluna que enxerga 1.000 linhas.

O que é Power Query?

O Power Query é a camada de ETL do Power BI e do Excel. Ele extrai dados de arquivos, bancos, APIs e serviços online, aplica transformações gravadas passo a passo e carrega o resultado no modelo. Cada clique na interface vira código na linguagem M. Ou seja, é esse código que roda em toda atualização.

A diferença para uma limpeza manual na planilha está na repetição. Isto é, o processo de ETL guarda a sequência inteira, portanto a carga seguinte refaz tudo sozinha. O editor mostra essa sequência no painel Etapas Aplicadas, na ordem em que cada uma nasceu.

No Power BI Desktop o editor abre pela guia Página Inicial, no botão Transformar dados. No Excel o caminho passa pela guia Dados, no grupo Obter e Transformar Dados. A janela de edição, no entanto, é a mesma nos dois produtos.

As quatro etapas e o código que cada uma escreve

São quatro etapas: conectar, transformar, combinar e carregar. Todas escrevem linhas em M dentro da mesma consulta. Ler essas linhas custa dez minutos e, por isso, evita a maior parte das quebras de atualização.

1. Conectar: o separador, a codificação e o cabeçalho

Conectar vira duas linhas de código. A primeira lê o arquivo com separador, número de colunas e codificação declarados. Em seguida, a segunda promove a linha de cima a cabeçalho.

Antes do código, porém, aparece a tela de importação com os padrões que o produto escolhe sozinho:

Vale destacar três escolhas dessa tela. A origem do arquivo veio como 1252: Europeu Ocidental, não UTF-8. Além disso, a detecção de tipo olha apenas as primeiras 200 linhas. Já o preço 26733.30 do arquivo aparece na visualização como 2673330, com o ponto decimal engolido pela cultura do sistema.

let
    Fonte = Csv.Document(File.Contents("C:\lab\Vendas.csv"),[Delimiter=";", Columns=7, Encoding=65001, QuoteStyle=QuoteStyle.None]),
    Cabecalho = Table.PromoteHeaders(Fonte, [PromoteAllScalars=true])
in
    Cabecalho

Repare no 65001: é a página de código UTF-8, o número que decide como o acento chega na visualização. Já o Columns=7 fixa a largura esperada do arquivo, gravada no dia em que você conectou.

O "en-US" no fim da conversão de tipo é o que devolve o ponto decimal ao lugar. Dessa forma, a mesma coluna carregou 26733,3 na tabela do editor. Nada disso se corrige sozinho depois: a escolha fica gravada na consulta.

2. Transformar: escolher coluna em vez de remover coluna

Aqui mora a decisão que mais rende. Ao clicar em Remover Colunas, o editor escreve Table.RemoveColumns e lista o que sai. Antes disso, porém, ele já converteu o tipo de todas as colunas do arquivo, uma a uma.

let
    Fonte = Csv.Document(File.Contents("C:\lab\Vendas.csv"),[Delimiter=";", Columns=7, Encoding=65001, QuoteStyle=QuoteStyle.None]),
    Cabecalho = Table.PromoteHeaders(Fonte, [PromoteAllScalars=true]),
    Tipos = Table.TransformColumnTypes(Cabecalho,{{"VendaID", Int64.Type}, {"Data", type date}, {"ProdutoID", Int64.Type}, {"Regiao", type text}, {"Quantidade", Int64.Type}, {"PrecoUnitario", type number}, {"Desconto", type number}},"en-US"),
    Removidas = Table.RemoveColumns(Tipos,{"VendaID","Desconto"})
in
    Removidas

Note que a etapa de tipo cita as sete colunas, incluindo VendaID e Desconto, que a linha seguinte descarta. Dessa forma, a consulta passa a depender do nome de duas colunas que o relatório nunca usa.

O caminho inverso nomeia apenas o que fica. A função Table.SelectColumns escolhe as cinco colunas úteis antes da conversão de tipo. Assim a etapa de tipo encolhe junto.

let
    Fonte = Csv.Document(File.Contents("C:\lab\Vendas.csv"),[Delimiter=";", Columns=7, Encoding=65001, QuoteStyle=QuoteStyle.None]),
    Cabecalho = Table.PromoteHeaders(Fonte, [PromoteAllScalars=true]),
    Escolhidas = Table.SelectColumns(Cabecalho,{"Data","ProdutoID","Regiao","Quantidade","PrecoUnitario"}),
    Tipos = Table.TransformColumnTypes(Escolhidas,{{"Data", type date}, {"ProdutoID", Int64.Type}, {"Regiao", type text}, {"Quantidade", Int64.Type}, {"PrecoUnitario", type number}},"en-US")
in
    Tipos

Ambas as consultas devolvem a mesma tabela: 1.000.000 de linhas e as mesmas cinco colunas, conferidas por COUNTROWS no modelo carregado. Além disso, a ordem das etapas não compra velocidade. Em cinco execuções cronometradas, a mediana ficou em 4.937 ms na consulta que remove colunas. A que escolhe colunas marcou 5.040 ms: 2% de diferença, dentro do ruído.

O ganho aparece em outro lugar. A segunda consulta não conhece o nome Desconto, portanto nada acontece com ela quando esse nome muda na origem.

3. Combinar: mesclar consultas sem herdar branco

Mesclar é o passo que junta duas consultas por uma chave. Duas linhas resolvem o caso mais comum: a primeira cria a coluna aninhada, em seguida a segunda expande os campos escolhidos.

    Mesclada = Table.NestedJoin(Tipos, {"ProdutoID"}, Produto, {"ProdutoID"}, "Produto", JoinKind.LeftOuter),
    Expandida = Table.ExpandTableColumn(Mesclada, "Produto", {"Categoria"}, {"Categoria"})

No laboratório, a mesclagem de 1.000.000 de linhas de vendas com a tabela de 8 produtos trouxe categoria em todas as linhas, zero em branco. Assim fica a consulta depois das seis etapas, com a coluna Categoria já vinda da outra tabela:

Neste laboratório as etapas ganharam nomes curtos, batizadas assim na criação da consulta. Vale o hábito: nome curto no painel diz o que aconteceu ali, sem obrigar ninguém a abrir a fórmula.

A mesclagem por chave de texto, contudo, falha em silêncio quando o tipo não bate dos dois lados. Ao converter ProdutoID para texto de um lado e deixar número do outro, a correspondência simplesmente não acontece. Em 1.000 linhas de amostra, o resultado foi categoria vazia em todas elas:

Por isso nenhum alerta aparece: para o motor, "3" e 3 são valores diferentes. Confira o tipo dos dois lados antes de mesclar. Além disso, a referência da função Table.NestedJoin traz os tipos de junção disponíveis.

4. Carregar: o que o perfil de coluna não olha

O botão Fechar e Aplicar leva o resultado para o modelo. Antes disso, porém, o editor oferece um painel de qualidade de dados que parece cobrir a tabela inteira.

Basta ler a barra de status: criação de perfil de coluna com base nas primeiras 1.000 linhas. São dois limites diferentes: 200 linhas para adivinhar o tipo, 1.000 para o perfil. Ou seja, um valor inválido na linha 300.000 não aparece em nenhum dos dois. A documentação das ferramentas de criação de perfil de dados mostra como trocar essa base. O preço é varrer o conjunto inteiro a cada mudança.

Quando a origem renomeia uma coluna

Para medir o estrago, o teste foi direto: renomear Desconto para PercentualDesconto no arquivo e atualizar as duas consultas. A gerada por clique parou, com o triângulo de alerta ao lado do nome:

O texto do erro aparece por extenso, com o nome da coluna que sumiu. Expression.Error: A coluna ‘Desconto’ da tabela não foi encontrada. O erro nasce em Table.TransformColumnTypes, não na etapa que remove a coluna. Ou seja, a consulta quebra na primeira linha que cita o nome perdido.

Por outro lado, a consulta que escolhe colunas atualizou no mesmo arquivo, sem alerta, mantendo as seis colunas de sempre. Nenhuma linha dela menciona a coluna renomeada, portanto a mudança passou despercebida.

Em resumo, vale como regra de escrita: nomeie o que fica, nunca o que sai. A documentação de Table.SelectColumns mostra a assinatura completa, com o parâmetro que define o comportamento diante de coluna ausente.

O que fica no M e o que sobe para o DAX

Existe uma regra de corte curta. O que dá para resolver antes da carga fica no M. Em contrapartida, o que depende da seleção do usuário no relatório fica em DAX, calculado na hora da consulta.

Assim, coluna que não entra no modelo não ocupa memória nem entra em cálculo nenhum. No entanto, quando o gargalo aparece só depois da carga, o caminho muda. A conta passa a ser medir o custo de cada visual, como no guia de custo de consulta no Power BI.

O que abrir na próxima consulta

Abra o editor numa consulta que já roda em produção e olhe o painel Etapas Aplicadas. Duas perguntas cobrem a maior parte do risco. A etapa de tipo cita colunas que o relatório não usa? A mesclagem tem os dois lados no mesmo tipo?

Trocar a ordem custa poucos minutos: escolher colunas primeiro, converter tipo depois. O ganho não é tempo de atualização, como o cronômetro mostrou. Em suma, é a consulta deixar de depender de nomes que ninguém prometeu manter.

Em ambiente com muitas origens, esse cuidado decide quantas segundas-feiras começam com relatório fora do ar. Além disso, registre a decisão junto da consulta: quem abrir o arquivo daqui a um ano não vai adivinhar a razão da ordem escolhida.

Se a sua operação depende de painéis que precisam estar de pé antes do expediente, fale com os especialistas da OpServices.