Técnicas de redução de dados para Modelagem de importação
Este artigo tem como destino 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 armazenados em disco pelo mecanismo de armazenamento VertiPaq. Quando os dados de origem são carregados na memória, é possível obter compactação de 10x e, portanto, é razoável esperar que 10 GB de dados de origem possam compactar para cerca de 1 GB de tamanho. Além disso, quando persistidos em disco, é possível chegar a uma redução extra de 20%.
Apesar das eficiências obtidas pelo mecanismo de armazenamento VertiPaq, você deve se esforçar para minimizar os dados carregados em seus modelos. Isso é especialmente verdade para modelos grandes ou modelos que você prevê que crescerão para se tornarem grandes ao longo do tempo. Quatro motivos convincentes incluem:
- Tamanhos de modelo maiores podem não ser compatíveis com sua capacidade. A capacidade compartilhada pode hospedar modelos de até 1 GB de tamanho, enquanto as capacidades Premium podem hospedar modelos maiores, dependendo da SKU. Para obter mais informações, consulte Modelos semânticos grandes no Power BI Premium.
- Modelos com tamanhos menores reduzem a contenção de recursos de capacidade, especificamente a memória. Muitos modelos menores em uma capacidade podem ser carregados simultaneamente por períodos mais longos, resultando em taxas de remoção mais baixas.
- Tamanhos de modelo menores permitem uma atualização de dados mais rápida, resultando em menor latência nos relatórios, maior taxa de atualização do modelo semântico e menos pressão sobre os recursos do sistema de origem e de capacidade.
- Contagens de linhas de tabela menores 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 às suas assinaturas de capacidade (P SKUs). Lembre-se de que a Microsoft está consolidando atualmente as opções de compra e desativando os SKUs do Power BI Premium por capacidade. Em vez disso, os clientes novos e existentes devem considerar a compra de SKUs (assinaturas de capacidade do Fabric).
Para obter mais informações, consulte Atualização importante chegando ao de licenciamento do Power BI Premium e Perguntas frequentes do Power BI Premium.
Remover colunas desnecessárias
As colunas das tabela de modelo têm duas finalidades principais:
- Relatórios, para obter designs de relatório adequados que filtram, agrupam e resumem dados do modelo.
- estrutura de modelo, dando suporte a relações de modelo, cálculos de modelo, funções de segurança e até mesmo formatação de cor de dados.
Você provavelmente pode remover qualquer coluna que não atenda a nenhuma dessas finalidades. Às vezes, a remoção de uma coluna de uma tabela é chamada de filtragem vertical.
Recomendamos que você projete modelos com exatamente o número certo de colunas com base em seus requisitos de relatório conhecidos. Seus requisitos podem mudar ao longo do tempo, mas tenha em mente que é mais fácil adicionar colunas mais tarde do que removê-las mais tarde. A remoção de colunas pode interromper 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 às vezes é chamada de filtragem horizontal.
- Filtragem por 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. Você pode implementar filtros do Power Query baseados em tempo com parâmetros e até defini-los para usar períodos de tempo relativos (em relação à data de atualização, por exemplo, os últimos cinco anos). Além disso, tenha em mente que uma alteração retrospectiva nos filtros de tempo não interromperá os relatórios; isso resultará em menos (ou mais) histórico de dados disponíveis em relatórios.
- A filtragem por entidade envolve o carregamento de um subconjunto de dados de origem no modelo. Por exemplo, em vez de carregar informações de vendas referentes a todas as regiões de vendas, carregue apenas informações de uma única região. Essa abordagem de design resulta em muitos modelos menores e também pode eliminar a necessidade de definir de RLS (segurança em nível de linha), mas requer a concessão de permissões de modelo semântico específicas no serviço do Power BI e a criação de relatórios duplicados que se conectam a cada modelo semântico. Você pode usar os parâmetros do Power Query e os arquivos do Modelo do Power BI para simplificar o gerenciamento 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 eficiente para reduzir o tamanho de um modelo seja carregar dados resumidos previamente. Você pode usar essa técnica para aumentar a granularidade de tabelas de fatos. No entanto, há uma compensação distinta que leva à 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 obtida resumindo todas as métricas de vendas, agrupamento por data, cliente e produto. Uma redução de dados ainda mais significativa pode ser obtida agrupando por data no nível do mês. Embora isso possa levar a uma possível redução de 99% no tamanho do modelo, mas o relatório por dia ou por pedido individual não é mais possível. Decidir resumir dados de fatos sempre envolve compensações. A compensação poderia ser atenuada por um design de modelo que inclui algumas tabelas no modo de armazenamento do DirectQuery, conforme descrito mais adiante 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 atingem as maiores otimizações para dados de coluna numérica, que usam codificação de valor. Texto e outros dados não numéricos, no entanto, usam 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, em seguida, é armazenado na estrutura de dados, exigindo uma pesquisa de hash durante o armazenamento e a consulta.
Em alguns casos específicos, você pode converter os dados de texto de origem em valores numéricos. Por exemplo, um número de pedido de vendas pode ser consistentemente prefixado por um valor de texto (por exemplo, SO123456). Nesse caso, o prefixo SO pode ser removido e o valor do número de 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. Ele ajuda a evitar a sumarização inadequada dos valores do número de pedidos.
Preferência por colunas personalizadas
O mecanismo de armazenamento VertiPaq armazena colunas calculadas do modelo (definidas no DAX) da mesma forma que colunas comuns originadas no Power Query. No entanto, as estruturas de dados internas são armazenadas de forma ligeiramente diferente e normalmente alcançam uma compactação menos eficiente. Além disso, as estruturas de dados são criadas depois que todas as tabelas do Power Query são carregadas, o que pode resultar em tempos de atualização de dados estendidos. Portanto, é menos eficiente adicionar colunas de tabela como colunas calculadas do que como colunas computadas do Power Query (definidas em M).
Sempre que possível, preferência para 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 do modelo podem ser a melhor opção. Isso é verdade quando a fórmula envolve a avaliação de medidas ou requer funcionalidades de modelagem específicas com suporte 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.
Desabilitar a carga de consulta do Power Query
As consultas do Power Query destinadas a dar suporte à integração de dados com outras consultas não devem ser carregadas no modelo. Para evitar carregar essas consultas no modelo, verifique se você desabilitou a carga de consulta nessas instâncias.
Desabilitar data/hora automática
O Power BI Desktop inclui uma opção chamada de Data/hora automática. Quando habilitado, ele cria tabelas de data/hora automática ocultas para cada coluna de data no modelo. Essa opção dá suporte a autores de relatório ao configurar filtros, agrupamento e ações de busca detalhada para períodos de tempo de calendário. As tabelas ocultas são, de fato, tabelas calculadas que aumentam o tamanho do modelo.
Para obter mais informações, consulte Diretrizes automáticas de data/hora no Power BI Desktop.
Usar o modo de armazenamento DirectQuery
O modo de armazenamento DirectQuery é uma alternativa ao modo de armazenamento de importação. 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 do modo de armazenamento Import e DirectQuery em um único modelo, ela é conhecida 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 essa abordagem de design geralmente funciona bem com a técnica Agrupar por e resumir apresentada anteriormente. Por exemplo, os dados de vendas resumidos podem ser usados para obter relatórios de resumo de alto desempenho. Uma página de detalhamento pode exibir vendas granulares para contextos de filtro específicos (e estreitos), exibindo todas as ordens de venda no contexto. Neste exemplo, a página de detalhamento pode incluir visuais baseados em uma tabela de modelo do DirectQuery para recuperar os dados de pedidos de vendas.
No entanto, há 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.
Conteúdo relacionado
Para obter mais informações relacionadas a este artigo, confira os seguintes artigos: