Partilhar via


Técnicas de redução de dados para Importar modelação

Este artigo destina-se aos modeladores de dados do Power BI Desktop que desenvolvem e publicam modelos semânticos do Power BI. Especificamente, ele descreve várias técnicas para ajudar a reduzir os dados carregados em modelos de importação.

Os modelos de importação são carregados com dados compactados e otimizados e, em seguida, armazenados em disco pelo mecanismo de armazenamento VertiPaq. Quando os dados de origem são carregados na memória, é possível alcançar uma compressão de 10x e, portanto, é razoável esperar que 10 GB de dados de origem possam ser compactados para cerca de 1 GB de tamanho. Além disso, quando persiste no disco, uma redução extra de 20% pode ser alcançada.

Apesar das eficiências alcançadas pelo mecanismo de armazenamento VertiPaq, você deve se esforçar para minimizar os dados que são carregados em seus modelos. Isso é especialmente verdadeiro para modelos grandes, ou modelos que você prevê que crescerão para se tornarem grandes ao longo do tempo. Quatro razões imperiosas incluem:

  • Tamanhos de modelo maiores podem não ser compatíveis com a sua capacidade. A capacidade compartilhada pode hospedar modelos de até 1 GB de tamanho, enquanto as capacidades Premium podem hospedar modelos maiores, dependendo do SKU. Para obter mais informações, consulte Modelos semânticos grandes no Power BI Premium.
  • Tamanhos de modelo menores reduzem a contenção por recursos de capacidade, em particular memória. Muitos modelos menores em uma capacidade podem ser carregados simultaneamente por longos períodos de tempo, resultando em taxas de despejo mais baixas.
  • Tamanhos de modelo menores alcançam uma atualização de dados mais rápida, resultando em menor latência nos relatórios, maior eficiência na atualização do modelo semântico e menos pressão sobre o sistema de origem e sobre os recursos de capacidade.
  • Contagens menores de linhas de tabela podem levar a avaliações de cálculo mais rápidas, o que resulta em um melhor desempenho geral da consulta.

Importante

Às vezes, este artigo se refere ao Power BI Premium ou suas assinaturas de capacidade (SKUs P). Lembre-se de que a Microsoft está atualmente consolidando opções de compra e desativando as SKUs do Power BI Premium por capacidade. Em vez disso, os clientes novos e existentes devem considerar a compra de assinaturas de capacidade de malha (SKUs F).

Para obter mais informações, consulte Atualização importante chegando ao licenciamento do Power BI Premium e Perguntas frequentes sobre o Power BI Premium.

Remover colunas desnecessárias

As colunas da tabela modelo servem duas finalidades principais:

  • Reporting, para obter designs de relatório que filtrem, agrupem e resumam adequadamente os dados do modelo.
  • Estrutura do modelo, suportando relações de modelo, cálculos de modelo, funções de segurança e até mesmo formatação de cores de dados.

Você provavelmente pode remover qualquer coluna que não sirva a nenhum desses propósitos. A remoção de uma coluna de uma tabela é por vezes referida como filtragem vertical.

Recomendamos que você projete modelos com exatamente o número certo de colunas com base em seus requisitos de relatórios conhecidos. Seus requisitos podem mudar com o tempo, mas lembre-se de que é mais fácil adicionar colunas mais tarde do que removê-las mais tarde. A remoção de colunas pode quebrar relatórios ou a estrutura do modelo.

Remover linhas desnecessárias

Você deve carregar tabelas de modelo com o menor número possível de linhas. Você pode conseguir isso carregando conjuntos de linhas filtrados em tabelas de modelo por dois motivos diferentes: filtrar por tempo ou por entidade. A remoção de linhas é por vezes referida como filtragem horizontal.

  • A filtragem por de tempo envolve limitar a quantidade de histórico de dados carregados em tabelas de fatos (e limitar as linhas de data carregadas nas tabelas de data do modelo). Recomendamos que você não carregue todo o histórico disponível por padrão, a menos que seja um requisito de relatório conhecido. Pode implementar filtros do Power Query baseados no tempo com parâmetros e até defini-los para utilizar períodos de tempo relativos (relativos à data de atualização, por exemplo, os últimos cinco anos). Além disso, tenha em mente que uma alteração retrospetiva nos filtros de tempo não quebrará os relatórios; isso apenas resultará em menos (ou mais) histórico de dados disponíveis nos relatórios.
  • A filtragem por entidade envolve o carregamento de um subconjunto de dados de origem no modelo. Por exemplo, em vez de carregar fatos de vendas para todas as regiões de vendas, carregue apenas fatos para uma única região. Essa abordagem de design resulta em vários modelos mais pequenos e também pode eliminar a necessidade de definir a segurança ao nível da linha (RLS) para — mas requer conceder permissões específicas para o modelo semântico no serviço do Power BI e a criação de relatórios duplicados que se liguem a cada modelo semântico. Pode utilizar os parâmetros do Power Query e os ficheiros de Modelo do Power BI para simplificar a gestão e a publicação. Para obter mais informações, consulte Criar e usar modelos de relatório no Power BI Desktop.

Agrupar por e resumir

Talvez a técnica mais eficaz para reduzir o tamanho de um modelo seja carregar dados pré-resumidos. Você pode usar essa técnica para aumentar a granularidade das tabelas de fatos. Há um compromisso distinto, no entanto, resultando na perda de detalhes.

Considere um exemplo em que uma tabela de fatos de vendas de origem armazena uma linha por linha de pedido. Uma redução significativa de dados pode ser alcançada resumindo todas as métricas de vendas, agrupando por data, cliente e produto. Uma redução de dados ainda mais significativa pode ser alcançada agrupando por data ao nível do mês. Embora possa alcançar uma possível redução de 99% no tamanho do modelo, a geração de relatórios no nível do dia ou da linha de ordem individual não é mais possível. Decidir resumir dados de fatos sempre envolve compensações. A compensação pode ser atenuada por um design de modelo que inclua algumas tabelas no modo de armazenamento DirectQuery, que é descrito posterior neste artigo.

Otimizar tipos de dados de coluna

O mecanismo de armazenamento VertiPaq usa estruturas de dados internas separadas para cada coluna. Por design, essas estruturas de dados alcançam as mais altas otimizações para dados de colunas numéricas, que usam codificação de valor. No entanto, texto e outros dados não numéricos usam a codificação de hash . A codificação de hash requer que o mecanismo de armazenamento atribua um identificador numérico a cada valor exclusivo contido na coluna. É o identificador numérico, então, que é armazenado na estrutura de dados, exigindo uma pesquisa de hash durante o armazenamento e a consulta.

Em alguns casos específicos, você pode converter dados de texto de origem em valores numéricos. Por exemplo, um número de ordem de venda pode ser consistentemente precedido por um valor de texto (por exemplo, SO123456). Nesse caso, o prefixo SO pode ser removido e o valor do número do pedido convertido em um número inteiro. Para tabelas grandes, essa modificação pode resultar em redução significativa de dados, especialmente quando a coluna contém valores exclusivos ou de alta cardinalidade.

Neste exemplo, recomendamos que você defina a propriedade de resumo padrão da coluna como Do Not Summarize. Ajuda a evitar a sumarização inadequada dos valores do número de ordem.

Preferência por colunas personalizadas

O mecanismo de armazenamento VertiPaq armazena as colunas calculadas, definidas no DAX, no modelo , como se fossem colunas normais originadas pelo Power Query. No entanto, as estruturas de dados internas são armazenadas de forma ligeiramente diferente e, normalmente, conseguem uma compressão menos eficiente. Além disso, as estruturas de dados são criadas assim que todas as tabelas do Power Query são carregadas, o que pode resultar em tempos de atualização de dados alargados. É, portanto, menos eficiente adicionar colunas de tabela como colunas calculadas do que colunas computadas do Power Query (definidas em M).

Sempre que possível, prefira criar colunas personalizadas no Power Query. Quando a origem é um banco de dados, você pode obter maior eficiência de carga de duas maneiras: O cálculo pode ser definido na instrução SQL (usando a linguagem de consulta nativa do provedor) ou pode ser materializado como uma coluna na fonte de dados.

No entanto, em alguns casos, as colunas calculadas por modelo podem ser a melhor escolha. Isso é verdade quando a fórmula envolve a avaliação de medidas ou requer funcionalidade de modelagem específica suportada apenas em funções DAX. Para obter informações sobre um desses exemplos, consulte Noções básicas sobre funções para hierarquias pai-filho no DAX.

Desativar a carga de consulta do Power Query

As consultas do Power Query destinadas a suportar a integração de dados com outras consultas não devem ser carregadas no modelo. Para evitar carregar essas consultas no modelo, certifique-se de desabilitar a carga de consulta nessas instâncias.

Captura de ecrã do Power Query a mostrar a opção Ativar carregamento.

Desativar data/hora automática

O Power BI Desktop inclui uma opção chamada Data/hora automática. Quando ativado, cria tabelas automáticas de data/hora ocultas para cada coluna de data no modelo. Esta opção oferece suporte aos autores de relatórios ao configurar filtros, agrupamentos e ações de detalhamento para períodos de tempo do calendário. As tabelas ocultas são, na verdade, tabelas calculadas que aumentam o tamanho do modelo.

Para obter mais informações, consulte Orientação de data/hora automática no Power BI Desktop.

Usar o modo de armazenamento DirectQuery

O modo de armazenamento DirectQuery é uma alternativa ao modo de armazenamento Importar. As tabelas de modelo do DirectQuery não importam dados. Em vez disso, eles consistem apenas em metadados que definem a estrutura da tabela. Quando a tabela é consultada, as consultas nativas são usadas para recuperar dados da fonte de dados subjacente. Quando você combina tabelas de modo de armazenamento Import e DirectQuery em um único modelo, ele é conhecido como um modelo composto .

Uma técnica eficaz para reduzir o tamanho do modelo é definir o modo de armazenamento para tabelas de fatos maiores como DirectQuery. Considere que esta abordagem de design geralmente funciona bem com a técnica 'Agrupar por e resumir' introduzida anteriormente. Por exemplo, dados de vendas resumidos podem ser usados para obter relatórios resumidos de alto desempenho. Uma página de análise detalhada pode exibir vendas granulares para um contexto de filtro específico e restrito, exibindo todas as encomendas de venda no contexto. Neste exemplo, a página de análise detalhada pode incluir elementos visuais baseados numa tabela de modelo DirectQuery para recuperar os dados da ordem de venda.

Há, no entanto, muitas implicações de segurança e desempenho relacionadas ao modo de armazenamento DirectQuery e aos modelos Compostos. Para obter mais informações, consulte Usar modelos compostos no Power BI Desktop.

Para obter mais informações relacionadas a este artigo, confira os seguintes artigos: