Avaliar e otimizar a capacidade do Microsoft Fabric

Este artigo explica como avaliar e otimizar a carga em suas capacidades do Microsoft Fabric. Ele também descreve estratégias para lidar com situações de sobrecarga e oferece orientações para ajudar a otimizar a computação para cada uma das experiências do Fabric.

Embora o modelo de capacidade do Fabric simplifique a configuração e viabilize a colaboração, há uma grande chance de esgotamento dos recursos de computação compartilhados de uma capacidade. Também pode ser o caso de você estar pagando por mais recursos do que precisa. Essas situações podem surgir quando o design de algumas experiências do Fabric não segue as melhores práticas.

É importante reduzir o risco de esgotamento de recursos compartilhados. O Fabric — como um serviço gerenciado — lida automaticamente com essas situações, de duas maneiras.

• Bursting e suavização garantem que as atividades com uso intensivo da CPU sejam concluídas rapidamente sem exigir um SKU mais alto (e podem ser executadas a qualquer hora do dia).
• A limitação atrasa ou rejeita operações quando uma capacidade enfrenta uma demanda sustentada e alta da CPU (acima do limite de SKU).

A suavização reduz a probabilidade de limitação (embora a limitação ainda possa ocorrer). A suavização é como a alocação do uso em relação aos limites, mas independente da execução de trabalhos. A suavização não altera o desempenho, apenas estende a contabilização da computação consumida por um período mais longo, de modo que um SKU maior não seja necessário para lidar com o pico de computação.

Para saber mais sobre a capacidade do Fabric, consulte Conceitos e licenças do Microsoft Fabric e Capacidades do Fabric – Tudo o que você precisa saber sobre as novidades e o que está por vir.

Ferramentas de planejamento e orçamento

Planejar o tamanho de uma capacidade pode ser um desafio. Isso porque a computação necessária pode variar muito devido às operações executadas, à qualidade da execução (por exemplo, a eficiência de uma consulta DAX ou do código Python em um notebook) ou ao nível de simultaneidade.

Para ajudar você a determinar a capacidade do tamanho correto, você pode provisionar capacidades de avaliação ou SKUs F de pagamento conforme o uso para medir o tamanho real de capacidade necessário antes de comprar uma instância reservada de SKU F.

Dica

É sempre uma boa estratégia começar devagar e depois aumentar gradualmente o tamanho da sua capacidade conforme necessário.

Monitorar capacidades

Você deve monitorar a utilização se quiser obter o máximo de suas capacidades. Acima de tudo, é importante entender que as operações do Fabric são interativas ou acontecem em segundo plano. Por exemplo, consultas DAX de um relatório do Power BI são solicitações sob demanda interativas, enquanto as atualizações de modelo semântico são operações em segundo plano. Para obter mais informações sobre operações e como elas consomem recursos no Fabric, consulte Operações do Fabric.

O monitoramento pode revelar que está ocorrendo uma limitação. A limitação pode acontecer quando há várias operações interativas ou de longa duração. Normalmente, as operações em segundo plano relacionadas às experiências SQL e Spark são suavizadas, o que significa que se estendem por um período de 24 horas.

O aplicativo Métricas de Capacidade do Fabric é a melhor maneira de monitorar e visualizar a utilização recente. O aplicativo divide em relação a tipo de item (modelo semântico, notebook, pipeline e outros) e ajuda você a identificar itens ou operações que usam altos níveis de computação (para que possam ser otimizados).

Os administradores podem usar o Espaço de trabalho de monitoramento do administrador para saber mais sobre itens usados com frequência (e adoção geral). Eles também podem usar o hub de Monitoramento para exibir atividades atuais e recentes no locatário. Mais informações sobre algumas operações também podem estar disponíveis no Log Analytics ou nos logs do gateway de dados local.

Gerenciar alto nível de uso de computação

Quando uma capacidade é altamente utilizada e começa a mostrar limitação ou rejeição, há três estratégias para resolver isso: otimizar, escalar verticalmente e expandir.

É uma boa prática configurar notificações para saber quando a utilização da capacidade excede um limite definido. Além disso, considere o uso de configurações específicas da carga de trabalho para limitar o tamanho das operações (por exemplo, tempo limite de consulta ou limites de linha do Power BI ou configurações de espaço de trabalho do Spark).

Otimizar

Os criadores de conteúdo devem sempre otimizar o design de seus itens do Fabric para garantir que ele seja eficiente e use o mínimo possível de recursos de computação. Orientações específicas para cada experiência do Fabric são apresentadas posteriormente neste artigo.

Escalar verticalmente

Você escala verticalmente uma capacidade para aumentar temporária ou permanentemente o tamanho da SKU (com mais capacidade de computação). As escalar verticalmente, você garante que haja recursos de computação suficientes disponíveis para todos os itens em uma capacidade e para evitar a limitação.

Você também pode redimensionar, pausar e retomar SKUs do Fabric F para se alinhar aos padrões de consumo.

Escalar horizontalmente

Você escala horizontalmente movendo alguns de seus espaços de trabalho ou itens para uma capacidade do Fabric diferente para espalhar a carga de trabalho. Uma boa opção para isso é quando há necessidade de diferentes estratégias de capacidade, configurações ou administradores. O provisionamento de várias capacidades também é uma boa estratégia para ajudar a isolar a computação para itens de prioridade alta e também para conteúdo de autoatendimento ou desenvolvimento. Por exemplo, os executivos de uma organização esperam relatórios e dashboards altamente responsivos. Esses relatórios e dashboards podem residir em uma capacidade separada dedicada a relatórios executivos.

Você também pode considerar mover espaços de trabalho do Power BI para a capacidade compartilhada, desde que os consumidores tenham licenças do Power BI Pro que permitam que eles continuem a acessar o conteúdo.

Otimização de computação pela experiência do Fabric

Como as experiências e os itens no Fabric funcionam de forma diferente, você não os otimiza necessariamente da mesma maneira. Esta seção lista itens do Fabric de acordo com a experiência e as ações que você pode tomar para otimizá-los.

Data Warehousing do Fabric

O data warehouse usa uma arquitetura sem servidor e seus nós são gerenciados automaticamente pelo serviço. O uso da capacidade é calculado com base em segundos de unidade de capacidade ativa por consulta, em vez de na quantidade de tempo que os nós de front-end e back-end são provisionados.

Todas as operações de data warehouse acontecem em segundo plano e são suavizadas ao longo de um período de 24 horas.

O ponto de extremidade da análise SQL visa fornecer uma experiência de desempenho por padrão. Para isso, há menos opções de ajuste de consulta disponíveis em comparação com os pools SQL dedicados do SQL Server ou do Azure Synapse Analytics.

Apresentamos aqui alguns pontos que você pode considerar para minimizar o uso de computação.

• Escreva consultas usando o T-SQL mais otimizado possível. Quando possível, limite o número de colunas, cálculos, agregações e outras operações que possam aumentar desnecessariamente o uso dos recursos de consulta.
• Crie tabelas para usar os menores tipos de dados possíveis. Sua escolha do tipo de dados pode influenciar fortemente os planos de consulta gerados pelo mecanismo SQL. Por exemplo, reduzir um campo VARCHAR de comprimento 500 para 25 ou alterar DECIMAL(32, 8) para DECIMAL(10, 2) pode resultar em uma diminuição significativa nos recursos alocados para uma consulta.
• Use o design de esquema em estrela para reduzir o número de linhas lidas e minimizar as junções de consulta.
• Verifique se as estatísticas existem e se estão atualizadas. As estatísticas desempenham um papel vital na geração do plano de execução mais otimizado. Elas são criadas automaticamente no runtime, mas talvez seja necessário atualizá-las manualmente, especialmente depois que os dados são carregados ou atualizados. Considere criar estatísticas usando a opção FULLSCAN em vez de confiar nas estatísticas geradas automaticamente que usam amostragem.
• Use modos de exibição internos para monitorar consultas e uso, especialmente ao solucionar problemas.
  • O modo de exibição de gerenciamento dinâmico (DMV) sys.dm_exec_requests proporciona informações sobre todas as consultas em execução ativa, mas não armazena nenhuma informação de histórico. A Caixa de ferramentas do Fabric fornece uma consulta que usa esse DMV e torna o resultado da consulta amigável ao se juntar a outros modos de exibição para dar detalhes, como o texto da consulta.
  • O Query Insights, que é um recurso de armazenamento de dados do Fabric, fornece uma visão holística da atividade do histórica de consultas no ponto de extremidade da análise SQL. Especificamente, o modo de exibição queryinsights.exec_requests_history traz informações sobre cada solicitação SQL completa. Ele apresenta todos os detalhes relevantes de cada execução de consulta que podem ser correlacionados com as IDs de operação encontradas no aplicativo de métricas de capacidade. As colunas mais importantes para monitorar o uso da capacidade são:distributed_statement_id, command (texto da consulta), start_time e end_time.

Engenharia de Dados do Fabric e Ciência de Dados do Fabric

As experiências de Engenharia de Dados e Ciência de Dados usam a computação do Spark para processar, analisar e armazenar dados em um lakehouse do Fabric. A computação do Spark é configurada e medida em termos de vCores. No entanto, o Fabric usa CUs como uma medida de computação consumida por vários itens, incluindo notebooks do Spark, definições de trabalho do Spark e trabalhos do lakehouse.

No Spark, uma CU se traduz em dois vCores de computação. Por exemplo, quando um cliente compra um SKU F64, 128 v-cores do Spark estão disponíveis para experiências do Spark.

Todas as operações do Spark acontecem em segundo plano e são suavizadas ao longo de um período de 24 horas.

Para mais informações, consulte Relatórios de cobrança e utilização no Spark do Fabric.

Apresentamos aqui alguns pontos que você pode considerar para minimizar o uso de computação.

• Sempre faça o melhor para escrever um código Spark eficiente. Para ver mais informações, consulte Otimizar trabalhos do Apache Spark no Azure Synapse Analytics e A necessidade de otimizar a gravação no Apache Spark.
• Reserve os executores necessários para seus trabalhos do Spark, para liberar recursos para outros trabalhos ou cargas de trabalho do Spark. Caso contrário, você aumenta a chance de que os trabalhos do Spark falhem apresentando o status HTTP 430, que significa que há solicitações além da capacidade. Você pode exibir o número de executores alocados a um notebook no hub de monitoramento do Fabric, onde também é possível determinar o número real de executores usados pelo notebook. Os trabalhos do Spark reservam apenas os nós necessários e permitem envios paralelos dentro dos limites de SKU.
• O pool do Spark só pode ser configurado para usar o número máximo de vCores compatível com SKU. No entanto, você pode expandir as cargas de trabalho de engenharia de dados aceitando trabalhos paralelos do Spark dentro dos limites de SKU. Essa abordagem é comumente conhecida como fator de disparo e é habilitada por padrão para cargas de trabalho do Spark no nível de capacidade. Para obter mais informações, confira Limitação e enfileiramento de simultaneidade.
• As sessões ativas do Spark podem acumular a utilização de CU em uma capacidade. Por esse motivo, é importante interromper as sessões ativas do Spark quando não estiverem em uso. Observe que esse período de tempo de expiração de sessão padrão é definido como 20 minutos. Os usuários podem alterar o tempo limite da sessão em um notebook ou na definição de trabalho do Spark.

Inteligência em Tempo Real

O consumo de CU do banco de dados KQL é calculado com base no número de segundos em que o banco de dados fica ativo e no número de vCores usados. Por exemplo, quando o banco de dados usa quatro vCores e fica ativo por 10 minutos, 2.400 segundos de CU (4 x 10 x 60) são consumidos.

Todas as operações do banco de dados KQL são interativas.

Um mecanismo de dimensionamento automático é utilizado para determinar o tamanho do banco de dados KQL. Ele garante o alcance do melhor desempenho e otimização de custo com base nos padrões de uso.

Para permitir que os dados fiquem disponíveis para outros mecanismos do Fabric, o banco de dados KQL se sincroniza com o OneLake. Com base no número de transações de leitura e gravação que seu banco de dados KQL executa, as CUs são utilizadas a partir de sua capacidade. São utilizados os medidores de leitura e gravação do OneLake, que são equivalentes a operações de leitura e gravação em contas do Azure Data Lake Storage (ADLS) Gen2.

Data Factory

Esta seção trata das otimizações para fluxos de dados e pipelines de dados no Data Factory.

Todas as operações acontecem em segundo plano e são suavizadas ao longo de um período de 24 horas.

Apresentamos aqui alguns pontos que você pode considerar para minimizar o uso de computação.

• Evite a lógica ineficiente do Power Query para minimizar e otimizar transformações de dados caras, como mesclagem e classificação.
• Esforce-se para conseguir fazer a dobragem de consultas sempre que possível. Ela pode melhorar o desempenho de seus fluxos de dados reduzindo a quantidade de dados que precisam ser transferidos da fonte de dados ao destino. Quando a dobragem de consultas não acontece, o Power Query recupera todos os dados da fonte de dados e executa transformações localmente, o que pode ser ineficiente e lento.
• Desabilite o preparo ao trabalhar com pequenos volumes de dados e/ou executar transformações simples. O preparo pode ser necessário em alguns casos, como quando você carrega um data warehouse.
• Evite atualizar dados com mais frequência do que a fonte de dados exige. Por exemplo, se a fonte de dados for atualizada apenas uma vez a cada 24 horas, não será de grande valor atualizar os dados de hora em hora. Em vez disso, atualize os dados em uma frequência apropriada para garantir que eles permaneçam atualizados e precisos.

Power BI

As operações do Power BI podem ser tanto interativas quanto em segundo plano.

As operações interativas a seguir geralmente resultam em alto uso de computação.

• Modelos semânticos que não seguem as melhores práticas. Por exemplo, eles talvez não adotem o design de esquema em estrela com relações em um-para-muitos. Ou ainda, podem incluir filtros de segurança em nível de linha (RLS) complexos e caros. Considere o uso do Tabular Editor e do Analisador de Práticas Recomendadas para determinar se as práticas recomendadas são seguidas.
• As medidas DAX são ineficientes.
• As páginas de relatório contêm elementos visuais demais, o que pode causar lentidão na atualização.
• Os elementos visuais de relatório exibem resultados de alta cardinalidade (muitas linhas ou colunas) ou contêm medidas demais.
• A capacidade enfrenta um alto nível de simultaneidade porque há usuários demais para o tamanho da capacidade. Desabilite a expansão de consulta para melhorar a experiência do usuário nos modelos semânticos de alto nível de simultaneidade (mas isso não resulta em mais computação total).

As operações em segundo plano a seguir geralmente resultam em alto uso de computação.

• Transformações de dados ineficientes ou excessivamente complexas na lógica do Power Query.
• Ausência de dobragem de consultas ou atualização incremental para tabelas de fatos grandes.
• Bursting de relatórios, que é quando um grande número de relatórios do Power BI ou paginados são gerados ao mesmo tempo.

Conteúdo relacionado

• Conceitos e licenças do Microsoft Fabric
• Blog: Capacidades do Fabric – Tudo o que você precisa saber sobre as novidades e o que está por vir

Mais perguntas? Experimente perguntar à Comunidade do Fabric.