Avalie e otimize sua 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 fornece orientação para ajudar a otimizar a computação para cada uma das experiências do Fabric.

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

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

• O bursting e a suavização garantem que as atividades com uso intensivo de CPU sejam concluídas rapidamente sem a necessidade de uma SKU mais alta (e podem ser executadas a qualquer hora do dia).
• A limitação atrasa ou rejeita operações quando uma capacidade experimenta uma demanda sustentada e alta por 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 o uso é alocado em relação aos limites, mas é independente da execução dos trabalhos. A suavização não altera o desempenho, apenas espalha a contabilização da computação consumida por um período mais longo, de modo que uma SKU maior não seja necessária para lidar com a computação de pico.

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

Ferramentas de planeamento e orçamentação

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, quão bem elas são executadas (por exemplo, a eficiência de uma consulta DAX ou o código Python em um notebook) ou o nível de simultaneidade.

Para ajudá-lo a determinar o tamanho de capacidade correto, você pode provisionar capacidades de avaliação ou SKUs F pré-pagos para medir o tamanho real da capacidade necessária antes de comprar uma instância reservada de SKU F.

Gorjeta

É sempre uma boa estratégia começar pequeno e, em seguida, aumentar gradualmente o tamanho da sua capacidade, conforme necessário.

Monitorize as capacidades

Você deve monitorar a utilização para tirar o máximo proveito de suas capacidades. Acima de tudo, é importante entender que as operações do Fabric são interativas ou em segundo plano. Por exemplo, consultas DAX de um relatório do Power BI são solicitações sob demanda que são operações interativas, enquanto 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 de malha.

O monitoramento pode revelar que a limitação está ocorrendo. A limitação pode acontecer quando há operações interativas numerosas 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 elas são distribuídas por um período de 24 horas.

O aplicativo Fabric Capacity Metrics é a melhor maneira de monitorar e visualizar a utilização recente. O aplicativo se divide em tipo de item (modelo semântico, bloco de anotações, 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 Monitoramento de administradores 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.

Gerencie o alto 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 resolvê-la: otimizar, aumentar e reduzir.

É 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 do Power BI ou limites de linha ou configurações do espaço de trabalho do Spark).

Otimização

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

Aumentar verticalmente

Você amplia uma capacidade para aumentar temporária ou permanentemente o tamanho da SKU (com mais capacidade de computação). A expansão garante que haja recursos de computação suficientes disponíveis para todos os itens em uma capacidade e para evitar limitações.

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

Aumentar horizontalmente

Você expande movendo alguns de seus espaços de trabalho ou itens para uma capacidade de malha diferente para distribuir a carga de trabalho. Pode ser uma boa opção quando diferentes estratégias de capacidade, configurações ou administradores são necessários. O provisionamento de várias capacidades também é uma boa estratégia para ajudar a isolar a computação para itens de alta prioridade e também para conteúdo de autosserviço ou desenvolvimento. Por exemplo, os executivos da sua organização esperam relatórios e painéis altamente responsivos. Esses relatórios e painéis 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 capacidade compartilhada, desde que os consumidores tenham licenças do Power BI Pro que lhes permitam continuar a acessar o conteúdo.

Otimização de computação por experiência de malha

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

Armazém de dados de malha

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 da quantidade de tempo que os nós de front-end e back-end são provisionados.

Todas as operações de armazém de dados são operações em segundo plano e são suavizadas durante um período de 24 horas.

O ponto de extremidade de análise SQL tem como objetivo fornecer uma experiência de desempenho por padrão . Para esse fim, 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.

Aqui estão alguns pontos a considerar para ajudar a minimizar a computação.

• Escreva consultas usando o T-SQL mais ideal 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 de recursos de consulta.
• Crie tabelas para usar os menores tipos de dados possíveis. Sua escolha de tipo de dados pode influenciar fortemente os planos de consulta gerados pelo mecanismo SQL. Por exemplo, reduzir um VARCHAR campo de 500 para 25 ou mudar 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.
• Certifique-se de que as estatísticas existem e que estão atualizadas. As estatísticas desempenham um papel vital na geração do melhor plano de execução. Eles são criados automaticamente em tempo de execução, mas talvez seja necessário atualizá-los manualmente, especialmente depois que os dados são carregados ou atualizados. Considere a criação de estatísticas usando a FULLSCAN opção em vez de confiar nas estatísticas geradas automaticamente que usam amostragem.
• Use exibições internas para monitorar consultas e uso, especialmente ao solucionar problemas.
  • O sys.dm_exec_requests modo de exibição de gerenciamento dinâmico (DMV) fornece informações sobre todas as consultas em execução ativa, mas não armazena nenhuma informação histórica. A Caixa de Ferramentas de Malha fornece uma consulta que usa esse DMV e torna o resultado da consulta amigável, juntando-se a outros modos de exibição para fornecer detalhes como o texto da consulta.
  • O Query insights, que é um recurso do data warehousing do Fabric, fornece uma visão holística da atividade de consulta histórica no ponto de extremidade de análise SQL. Especificamente, a exibição queryinsights.exec_requests_history fornece informações sobre cada solicitação SQL completa. Ele apresenta todos os detalhes relevantes para cada execução de consulta que podem ser correlacionados com os IDs de operação encontrados no aplicativo de métricas de capacidade. As colunas mais importantes para monitorar o uso da capacidade são: distributed_statement_id, comando (texto de consulta), start_time e end_time.

Engenharia de dados de malha e ciência de dados de malha

As experiências de Engenharia de Dados e Ciência de Dados usam a computação Spark para processar, analisar e armazenar dados em um lago 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 blocos de anotações Spark, definições de trabalho Spark e trabalhos lakehouse.

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

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

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

Aqui estão alguns pontos a considerar para ajudar a minimizar a computação.

• Sempre se esforce para escrever código Spark eficiente. Para obter 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 com um status HTTP 430, o que significa muitas solicitações para a capacidade. Você pode exibir o número de executores alocados a um bloco de anotações no hub de monitoramento de malha, onde também pode determinar o número real de executores usados pelo bloco de anotações. 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 suportados pelo SKU. No entanto, você pode expandir cargas de trabalho de engenharia de dados aceitando trabalhos paralelos do Spark dentro dos limites de SKU. Essa abordagem é comumente conhecida como fator de intermitência e é habilitada por padrão para cargas de trabalho do Spark no nível de capacidade. Para obter mais informações, consulte Limitação e fila de simultaneidade.
• As sessões ativas do Spark podem acumular a utilização da em uma capacidade. Por esse motivo, é importante interromper as sessões ativas do Spark quando não estiverem em uso. Observe que o tempo de expiração da sessão padrão do Spark é definido como 20 minutos. Os usuários podem alterar o tempo limite da sessão em um bloco de anotações ou a definição de trabalho do Spark.

Informação em Tempo Real

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

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

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

Para permitir que os dados fiquem disponíveis para outros mecanismos de malha, o banco de dados KQL 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. Ele utiliza os medidores de leitura e gravação do OneLake, que são equivalentes a operações de leitura e gravação em contas Gen2 do Azure Data Lake Storage (ADLS).

Data Factory

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

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

Aqui estão alguns pontos a considerar para ajudar a minimizar a computação.

• Evite a lógica ineficiente do Power Query para minimizar e otimizar transformações de dados dispendiosas, como fusão e classificação.
• Esforce-se para conseguir dobrar consultas sempre que possível. Ele pode melhorar o desempenho de seus fluxos de dados, reduzindo a quantidade de dados que precisam ser transferidos entre a fonte de dados e o destino. Quando a dobragem de consulta não ocorre, o Power Query recupera todos os dados da fonte de dados e executa transformações localmente, o que pode ser ineficiente e lento.
• Desative 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, atualizar os dados de hora em hora não fornecerá mais valor. Em vez disso, considere atualizar os dados com uma frequência apropriada para garantir que estejam atualizados e precisos.

Power BI

As operações do Power BI são interativas ou em segundo plano.

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

• Modelos semânticos que não seguem as melhores práticas. Por exemplo, eles podem não adotar o design de esquema de estrela com relações um-para-muitos. Ou podem incluir filtros de segurança em nível de linha (RLS) complexos e caros. Considere o uso do Editor de Tabelas 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 muitos elementos visuais, o que pode resultar em uma atualização visual lenta.
• Os visuais de relatório exibem resultados de cardinalidade alta (muitas linhas ou colunas) ou contêm muitas medidas.
• A capacidade experimenta alta simultaneidade porque há muitos usuários para o tamanho da capacidade. Considere habilitar a expansão da consulta para melhorar a experiência do usuário para modelos semânticos de alta simultaneidade (mas isso não resulta em mais computação total).

As operações em segundo plano a seguir normalmente 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 consulta ou atualização incremental para tabelas de fatos grandes.
• Interrupção de relatórios, que é quando um grande número de relatórios do Power BI ou relatórios paginados são gerados ao mesmo tempo.

Conteúdos relacionados

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

Tem dúvidas? Tente perguntar à Comunidade Fabric.