Função DAX CALCULATETABLE Vs FILTER

CALCULATETABLE e são ferramentas poderosas para manipular e analisar dados em consultas DAX, mas têm algumas diferenças importantes que é importante entender

Neste blog, examinaremos a função CALCULATETABLE e seu plano de consulta no DAX studio e entenderemos como ela difere da função FILTER . Ao final, você entenderá melhor como escolher a função certa para suas necessidades de análise de dados.

Para demonstrar, usaremos o código DAX abaixo.

Ao executar esse código, você obterá uma tabela mostrando Marca e Cor.

Na guia Query Plans , você obterá um código correspondente ao operador CrossApply no Formula Engine .

Ao mesmo tempo, você pode ver que o código está recuperando apenas a cor e a marca do produto na guia Horários do servidor .

Índice

• Resultado das temporizações do servidor DAX Studio para CALCULATETABLE
• Plano de consulta CALCULATETABLE no DAX Studio
• Transição de contexto para funções DAX semelhantes
  • Horários do Servidor
  • Plano de consulta
• Conclusão

Resultado das temporizações do servidor DAX Studio para CALCULATETABLE

Como exemplo, vamos filtrar a cor do produto para mostrar apenas Vermelho e/ou Preto.

Você pode fazer isso usando a função FILTRO. Ao executá-lo, o Server Timings mostrará que o argumento FILTER não é aplicado ao código xmSQL .

Mas se você usar a função CALCULATETABLE, a consulta na guia Server Timings mostrará que os resultados foram filtrados por cor do produto.

Plano de consulta CALCULATETABLE no DAX Studio

Vejamos o Plano de consulta para cada função.

O CALCULATETABLE está na primeira linha do plano de consulta lógica porque é uma função de nível superior no código e, portanto, não depende de nenhum requisito.

Ao ler o plano de consulta de uma função CALCULATETABLE, você não começa com o primeiro argumento. Você primeiro precisa entender o contexto do filtro usado. Então vamos para a linha 5.

Você pode ver que o operador VertiPaq requer a coluna de cor do produto por causa do filtro aplicado. Em seguida, ele verifica essa coluna e usa a combinação de filtro Not IsEmpty para verificar a cor do produto em cada linha.

Após a preparação do contexto do filtro, o argumento é executado.

Em retrospectiva, se você usar a função FILTER, verá um plano de consulta diferente, portanto, o argumento CROSSJOIN é executado antes de identificar o contexto do filtro.

A desvantagem dessa abordagem é que ela não envia a condição do filtro para o mecanismo de armazenamento. Você não poderá usar a cláusula WHERE dentro do xmSQL, o que sobrecarregará o Formula Engine.

E quando você estiver trabalhando com várias tabelas, a combinação de filtro da função CROSSJOIN será enorme. Isso diminui o desempenho do código DAX. Assim, na maioria dos casos, é recomendável usar a função CALCULATETABLE.

Portanto, em vez de executar todos os cálculos no Formula Engine, você pode injetar a condição de filtro dentro da classe WHERE do código XMSQL.

Transição de contexto para funções DAX semelhantes

Horários do Servidor

Este conceito também se aplica à função CALCULAR. Vamos usar o código DAX abaixo como exemplo.

Uma medida tem automaticamente uma função CALCULAR em torno dela.

Ao executar esse código, você obterá uma tabela mostrando o valor total de vendas para cada cor.

Na guia Server Timings, você pode ver que o código está executando duas consultas. A primeira consulta calcula a soma do valor de Vendas da tabela Vendas em relação à tabela Produtos.

Por outro lado, a segunda consulta recupera a cor do produto novamente da tabela Produtos. Corresponde à função no código DAX.

O Formula Engine coloca os caches de dados das duas consultas lado a lado. Ele começa recuperando os valores do segundo cache de dados e, em seguida, executa uma pesquisa no primeiro cache de dados.

Plano de consulta

Na guia Plano de Consulta, o Plano de Consulta Lógica verifica a cor do produto por causa do argumento .

Em seguida, o VertiPaq soma o valor das vendas totais dependendo da cor do produto. Ele realiza a transição de contexto que converte o valor da cor do produto em um contexto de filtro equivalente.

O filtro criado pela transição de contexto é traduzido em uma propriedade DependOnCols no Plano de Consulta. Depois que o VertiPaq verifica as colunas necessárias para calcular as vendas totais, ele multiplica a quantidade de vendas pelo preço líquido.

As vendas totais são retornadas como resultado na forma de um tipo de dados de moeda. E, finalmente, ADDCOLUMNS retorna uma tabela com duas colunas contendo a cor e o valor total de vendas.

Conclusão

O plano de consulta pode ter um impacto significativo no desempenho de uma consulta, pois diferentes planos de consulta podem ter diferentes níveis de eficiência.

Ao usar as funções CALCULATETABLE e FILTER em uma consulta DAX, o plano de consulta pode diferir dependendo do cenário específico e de vários fatores, como a expressão de fórmula específica que está sendo usada e os recursos do mecanismo de consulta.

Em geral, é uma boa ideia testar e comparar o desempenho de diferentes planos de consulta para determinar a abordagem mais eficiente para um determinado cenário.

Tudo de bom,