Compartilhar via

Usar o Microsoft Fabric para criar uma solução de BI empresarial

Microsoft Fabric
Armazenamento do Blobs do Azure
Microsoft Entra ID
Power BI

Este artigo descreve como transferir dados de um data warehouse local para um ambiente de nuvem e, em seguida, usar um modelo de BI (business intelligence) para atender aos dados. Você pode usar essa abordagem como uma meta final ou como um primeiro passo para a modernização completa com componentes baseados em nuvem.

Essas diretrizes se baseiam no cenário de ponta a ponta do Microsoft Fabric. Há várias opções para extrair dados de um SQL Server local, como pipelines do Fabric Data Factory, espelhamento, trabalho de cópia e CDC (captura de dados em tempo real) do Fabric para SQL. Após a extração, os dados são transformados para análise.

Architecture

Diagrama que mostra a arquitetura de BI empresarial com o Fabric.

Baixe um arquivo do Visio dessa arquitetura.

Workflow

O fluxo de trabalho a seguir corresponde ao diagrama anterior.

Fonte de dados

Ingestão e armazenamento de dados

  • Fabric OneLake é um data lake único, unificado e lógico para toda a sua organização. Esse SaaS fornece várias opções de armazenamento de dados, como Fabric Lakehouse para cargas de trabalho lakehouse de engenharia de dados, Fabric Warehouse para cargas de trabalho de data warehouse e Fabric Eventhouse para séries temporais de alto volume e conjuntos de dados de log.

  • Os pipelines do Fabric Data Factory permitem criar fluxos de trabalho complexos de ETL (extração, transformação, carga) e data factory que podem executar muitas tarefas diferentes em escala. Os recursos de fluxo de controle são integrados em pipelines de dados que permitem criar lógica de fluxo de trabalho, fornecendo loops e condicionais. Nessa arquitetura, as estruturas controladas por metadados permitem a ingestão incremental de várias tabelas em escala.

  • O espelhamento do Fabric Data Factory permite evitar processos de ETL complexos e integrar seu ambiente existente do SQL Server com o restante dos dados no Fabric. Você pode replicar continuamente seus bancos de dados existentes do SQL Server diretamente no Fabric OneLake. O trabalho de cópia do Fabric Data Factory facilita a movimentação de dados de sua origem para seu destino sem precisar de pipelines. As transferências de dados podem ser configuradas por meio de padrões internos para cópia incremental e em lote, com suporte para desempenho escalonável.

  • Os fluxos de eventos do Fabric fornecem ingestão de dados em tempo real de alta taxa de transferência de um banco de dados do SQL Server hospedado em uma VM (máquina virtual) usando a extração CDC. Esse padrão atende a casos de uso que exigem dashboards e alertas em tempo real.

Análise e relatórios

Components

  • banco de dados SQL do Azure é um SQL Server paaS hospedado no Azure. Nessa arquitetura, o Banco de Dados SQL fornece os dados de origem e demonstra o fluxo de dados para o cenário de migração.

  • O OneLake é um data lake unificado baseado em nuvem para armazenar dados estruturados e não estruturados em toda a organização. Nessa arquitetura, o OneLake serve como a camada de armazenamento central. Ele usa artefatos como Fabric Lakehouse, Fabric Warehouse, Fabric Eventhouse e bancos de dados espelhados para persistir e organizar vários tipos de dados para análise e relatórios.

  • O Fabric Data Warehouse é uma oferta de SaaS que hospeda cargas de trabalho de data warehouse para grandes conjuntos de dados. Nessa arquitetura, o Fabric Data Warehouse serve como o repositório final para conjuntos de dados dimensional e dá suporte a análises e relatórios.

  • O Power BI é uma ferramenta de business intelligence hospedada na computação do Fabric. Ele apresenta e visualiza dados nesse cenário, permitindo que os usuários empresariais interajam com dashboards e relatórios com base em dados do Fabric Data Warehouse e outras fontes.

  • Microsoft Entra ID é um conjunto de soluções de rede e identidade multinuvem que dá suporte ao fluxo de autenticação e autorização. Nessa arquitetura, a ID do Microsoft Entra fornece acesso seguro para usuários que se conectam aos recursos do Power BI e do Fabric.

Detalhes do cenário

Nesse cenário, uma organização tem um banco de dados SQL que contém um data warehouse local grande. A organização deseja usar o Fabric para ingerir e analisar os dados e fornecer insights analíticos aos usuários por meio do Power BI.

Quando usar essa arquitetura

Você pode usar vários métodos para atender aos requisitos de negócios para inteligência de negócios empresarial. Vários aspectos definem requisitos de negócios, como investimentos em tecnologia atuais, habilidades humanas, linha do tempo para modernização, metas futuras e se você prefere PaaS (plataforma como serviço) ou SaaS (software como serviço).

Considere as seguintes abordagens de design:

  • Uma lakehouse em Fabric

  • Fabric e a do Azure Databricks para clientes que têm investimentos existentes no Azure Databricks e no Power BI e desejam se modernizar com o Fabric

  • BI empresarial para pequenas e médias empresas que usam um ecossistema do SQL do Azure e o Fabric

  • Data warehousing de ponta a ponta no Fabric para clientes que preferem uma solução SaaS

A arquitetura neste artigo pressupõe que você use um Fabric Lakehouse ou Fabric Warehouse como a camada de persistência do modelo semântico empresarial e que você use o Power BI para inteligência de negócios. Essa abordagem saaS tem a flexibilidade de acomodar vários requisitos e preferências de negócios.

Authentication

A ID do Microsoft Entra autentica os usuários que se conectam aos painéis e aplicativos do Power BI. O SSO (logon único) conecta os usuários aos dados no fabric warehouse e no modelo semântico do Power BI. A autorização ocorre na origem.

Carregamento incremental

Ao executar um processo de ETL ou ELT automatizado, você deve carregar apenas os dados que foram alterados desde a execução anterior. Esse processo é conhecido como uma carga incremental. Por outro lado, uma carga completa carrega todos os dados. Para executar uma carga incremental, determine como identificar os dados alterados. Você pode usar uma marca de água alta abordagem de valor, que rastreia o valor mais recente de uma coluna de data/hora ou uma coluna inteiro exclusiva na tabela de origem.

Você pode usar tabelas temporais no SQL Server. Tabelas temporais são tabelas versionadas pelo sistema que armazenam o histórico de alterações de dados. O mecanismo de banco de dados registra automaticamente o histórico de todas as alterações em uma tabela de histórico separada. Para consultar os dados históricos, você pode adicionar uma cláusula FOR SYSTEM_TIME a uma consulta. Internamente, o mecanismo de banco de dados consulta a tabela do histórico, mas isso é transparente ao aplicativo.

As tabelas temporais dão suporte a dados de dimensão, que podem ser alterados ao longo do tempo. As tabelas de fatos normalmente representam transações imutáveis, como uma venda, em que manter o histórico de versão do sistema não é significativo. Em vez disso, as transações normalmente têm uma coluna que representa a data da transação. A coluna pode ser usada como o valor da marca d'água. Por exemplo, no data warehouse adventureworks, as tabelas de SalesLT.* têm um campo LastModified.

As etapas a seguir descrevem o fluxo geral do pipeline ELT:

  1. Para cada tabela no banco de dados de origem, acompanhe o tempo de corte quando o último trabalho ELT foi executado. Armazene essas informações no data warehouse. Durante a configuração inicial, todas as horas são definidas como 1-1-1900.

  2. Durante a etapa de exportação de dados, a hora de corte é passada como um parâmetro para um conjunto de procedimentos armazenados no banco de dados de origem. Esses procedimentos armazenados consultam todos os registros que são alterados ou criados após o tempo de corte. Para todas as tabelas no exemplo, você pode usar a coluna ModifiedDate.

  3. Quando a migração de dados for concluída, atualize a tabela que armazena os tempos de corte.

Pipeline de dados

Esse cenário usa o banco de dados de exemplo AdventureWorks como fonte de dados. O padrão de carga de dados incremental garante que somente os dados modificados ou adicionados após a execução mais recente do pipeline sejam carregados.

Estrutura de ingestão controlada por metadados

A estrutura de ingestão controlada por metadados nos pipelines do Fabric Data Factory carrega incrementalmente todas as tabelas contidas no banco de dados relacional. O artigo refere-se a um data warehouse como uma fonte, mas pode ser substituído por um banco de dados SQL do Azure como uma origem.

  1. Selecione uma coluna de marca d'água. Escolha uma coluna na tabela de origem que ajude a controlar registros novos ou alterados. Essa coluna normalmente contém valores que aumentam quando as linhas são adicionadas ou atualizadas (como um carimbo de data/hora ou ID). Use o valor mais alto nesta coluna como sua referência para saber de onde parou.

  2. Configure uma tabela para armazenar seu último valor de marca d'água.

  3. Crie um pipeline que inclua as seguintes atividades:

    • Duas atividades de pesquisa. A primeira atividade obtém o último valor de marca d'água (em que paramos na última vez). A segunda atividade obtém o novo valor de referência onde paramos desta vez. Ambos os valores são passados para a atividade de cópia.

    • Uma atividade de cópia que localiza linhas em que o valor da coluna de marca d'água está entre as marcas d'água antigas e novas. Em seguida, ele copia esses dados do armazém de dados para o lakehouse, criando um novo arquivo.

    • Uma atividade de procedimento armazenado que salva o novo valor da marca d'água para determinar o ponto de partida para a próxima execução do pipeline.

    O diagrama mostra um fluxograma de atividades para recuperar, usar e atualizar valores de marca d'água.

A imagem a seguir mostra um pipeline concluído. Para obter mais informações, consulte Ingestão incremental.

A captura de tela mostra um pipeline de ingestão de mídia com atividades de consulta para obter valores de marca d'água, uma atividade de cópia para dados novos e um procedimento armazenado para atualizar a marca d'água.

Carregar dados em um data warehouse do Fabric

A atividade de cópia copia dados do banco de dados SQL para o data warehouse do Fabric. O banco de dados SQL deste exemplo está no Azure, portanto, ele usa uma conexão configurada no portal do Fabric em Gerenciar Conexão e Gateways.

Usar pipelines do Fabric Data Factory

Os pipelines no Fabric Data Factory definem um conjunto ordenado de atividades para concluir um padrão de carga incremental. Gatilhos manuais ou automáticos iniciam o pipeline.

Transformar os dados

Se a transformação for necessária, use fluxos de dados do Fabric para criar transformações ETL de baixo código assistidas por IA que remodelam os dados. Os fluxos de dados do Fabric dependem do mecanismo do Power Query para aplicar essas transformações e gravar os resultados no Fabric Data Warehouse.

Em um ambiente de produção, use notebooks do Fabric para implementar transformações de ETL que funcionam bem para grandes conjuntos de dados através de uma estrutura de computação distribuída baseada no Apache Spark.

Observação

Use o mecanismo de execução nativo para executar cargas de trabalho de ETL ou engenharia de dados.

Usar o Power BI com capacidades do Fabric para acessar, modelar e visualizar dados

As capacidades do Fabric no Power BI dão suporte a vários modos de armazenamento para se conectar a fontes de dados do Azure:

  • Importação: Carrega dados no modelo semântico do Power BI para consulta na memória.

  • DirectQuery: Executa consultas diretamente no armazenamento relacional sem carregar dados na memória.

  • Modelo composto: Combina o modo de importação para algumas tabelas com o DirectQuery para outras no mesmo conjunto de dados.

  • Direct Lake: Consulta tabelas delta armazenadas no OneLake de um modelo semântico de workspace do Fabric. Ele é otimizado para análise interativa de tabelas grandes carregando dados na memória sob demanda.

Esse cenário usa o painel do DirectQuery porque ele tem uma pequena quantidade de dados e baixa complexidade de modelo. O DirectQuery delega a consulta ao mecanismo de computação subjacente e usa recursos de segurança na origem. O DirectQuery garante que os resultados sejam sempre consistentes com os dados de origem mais recentes.

O modo de importação pode fornecer a menor latência de consulta. Considere o modo de importação se os seguintes fatores forem verdadeiros:

  • O modelo se encaixa inteiramente na memória do Power BI.
  • A latência de dados entre atualizações é aceitável.
  • Você precisa de transformações complexas entre o sistema de origem e o modelo final.

Nesse caso, os usuários querem acesso total aos dados mais recentes sem atrasos na atualização do Power BI e desejam todos os dados históricos, o que excede a capacidade do conjunto de dados do Power BI. Um conjunto de dados do Power BI pode lidar com 25 gigabytes (GB) a 400 GB, dependendo do tamanho da capacidade. O modelo de dados no pool de SQL dedicado já está em um esquema estrela e não requer transformação, portanto, o DirectQuery é uma opção apropriada.

A captura de tela mostra um painel do Power BI com métricas de vendas, gráficos de tendências, filtros e uma tabela de dados detalhada.

Use o Power BI para gerenciar modelos grandes, relatórios paginados e pipelines de implantação. Aproveite o ponto de extremidade interno do Azure Analysis Services. Você também pode ter capacidade dedicada com uma proposta de valor exclusiva.

Quando o modelo de BI aumenta ou a complexidade do painel aumenta, você pode alternar para modelos compostos e importar partes de tabelas de pesquisa por meio de tabelas híbridase importar dados pré-configurados. Você pode habilitar de cache de consulta no Power BI para conjuntos de dados importados e usar tabelas duplas para a propriedade de modo de armazenamento.

Dentro do modelo composto, os conjuntos de dados servem como uma camada de passagem virtual. Quando os usuários interagem com visualizações, o Power BI gera consultas SQL para o Fabric Data Warehouse. O Power BI determina se o armazenamento em memória ou DirectQuery deve ser usado com base na eficiência. O mecanismo decide quando mudar da memória para o DirectQuery e envia a lógica por push para o data warehouse do Fabric. Dependendo do contexto das tabelas de consulta, elas podem servir como modelos compostos armazenados em cache (importados) ou não armazenados em cache. Você pode escolher qual tabela armazenar em cache na memória, combinar dados de uma ou mais fontes do DirectQuery ou combinar dados de origem do DirectQuery e dados importados.

Ao usar o DirectQuery com um data warehouse ou lakehouse do Fabric, execute as seguintes ações:

  • Use o Fabric Z-Order e o V-Order para melhorar o desempenho da consulta otimizando o armazenamento de dados de tabela subjacentes em arquivos de formato delta.

  • Use visões materializadas do Fabric Lakehouse para pré-calcular, armazenar e manter dados como uma tabela. Consultas que usam todos os dados ou um subconjunto dos dados em exibições materializadas podem obter um desempenho mais rápido sem a necessidade de referenciar diretamente a exibição materializada definida para usá-los.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework​, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Fiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

O artigo Confiabilidade explica como o Fabric dá suporte à confiabilidade, incluindo resiliência regional por meio de zonas de disponibilidade, juntamente com a recuperação entre regiões e a continuidade dos negócios. O Fabric fornece uma opção de recuperação de desastre na página de configurações de capacidade. Ele está disponível onde os emparelhamentos regionais do Azure se alinham com a presença do serviço Fabric. Quando a configuração de capacidade de recuperação de desastre é ativada, a replicação entre regiões é habilitada como uma funcionalidade de recuperação de desastre para dados do OneLake.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

A modernização da nuvem apresenta preocupações de segurança, como violações de dados, infecções por malware e injeção de código mal-intencionada. Você precisa de um provedor de nuvem ou uma solução de serviço que possa resolver suas preocupações porque medidas de segurança inadequadas podem criar grandes problemas.

Esse cenário aborda as preocupações de segurança mais exigentes usando uma combinação de controles de segurança em camadas, incluindo controles de rede, identidade, privacidade e autorização. Um data warehouse do Fabric armazena a maioria dos dados. O Power BI acessa os dados via DirectQuery com SSO. Use a ID do Microsoft Entra para autenticação. Também há amplos controles de segurança para autorização de dados nos pools provisionados.

Considere as seguintes preocupações comuns de segurança:

  • Defina quem pode ver quais dados.

    • Verifique se os dados estão em conformidade com as diretrizes federais, locais e da empresa para reduzir os riscos de violação de dados. O Fabric fornece recursos abrangentes de proteção de dados para dar suporte à segurança e promover a conformidade.

    • A segurança do OneLake controla todo o acesso aos dados do OneLake através de diferentes permissões que podem ser herdadas do item pai ou definidas nas permissões do workspace.

      • Um workspace é um ambiente colaborativo para criar e gerenciar itens. As funções de workspace podem ser gerenciadas nesse nível.

      • Um item é um conjunto de recursos agrupados em um único componente. Um item de dados é um subtipo de item que permite que os dados sejam armazenados nele usando o OneLake. Os itens herdam permissões das funções de workspace, mas também podem ter permissões extras. Pastas em um item são usadas para armazenar e gerenciar dados, como Tables/ ou Files/.

  • Determine como verificar a identidade de um usuário.

  • Escolha uma tecnologia de segurança de rede para proteger a integridade, a confidencialidade e o acesso de suas redes e dados.

  • Escolha ferramentas para detectar e notificar você sobre ameaças.

  • Determine como proteger dados no Fabric OneLake.

    • Ajude a proteger dados no Fabric usando rótulos de confidencialidade da Proteção de Informações do Microsoft Purview. Rótulos como Geral, Confidencial e Altamente Confidencial são amplamente usados em aplicativos do Microsoft Office, como Word, PowerPoint e Excel, para proteger informações confidenciais. Eles seguem os dados automaticamente de item para item à medida que fluem pelo Fabric, desde a fonte de dados até o usuário comercial.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

Esta seção descreve os detalhes de preços dos vários serviços usados na solução e explica as decisões tomadas para esse cenário usando um conjunto de dados de exemplo. Use a configuração inicial na calculadora de preços do Azure e ajuste-a para se ajustar ao seu cenário. Para obter mais informações sobre SKUs do Fabric, consulte a visão geral de preços do Fabric. Para obter mais informações sobre como gerar uma estimativa do consumo geral do Fabric, consulte o avaliador de capacidade do Fabric.

Arquitetura escalonável do fabric

O Fabric é uma arquitetura sem servidor para a maioria das cargas de trabalho que você pode usar para dimensionar seus níveis de computação e armazenamento de forma independente. Os recursos de computação incorrem em custos com base no uso. Você pode dimensionar ou pausar esses recursos sob demanda. Os recursos de armazenamento incorrem em custos por GB, de modo que seus custos aumentem à medida que você ingerir dados.

Pipelines de fábrica do Fabric

Três componentes principais influenciam o preço de um pipeline:

  • Atividades de pipeline de dados para orquestração: Para otimizar o custo, reduza o tempo total de orquestração implementando fluxos paralelos.

  • Dataflow Gen2 para computação: Para otimizar o custo, simplifique os pipelines de ETL filtrando dados desnecessários e processando a extração incremental.

  • Movimentação de dados para o trabalho de cópia ou atividade de cópia: Para otimizar o custo, configure o trabalho de cópia com extração incremental e ajuste a taxa de transferência para a atividade de cópia.

Para obter mais informações, consulte a guia medidores de preços da Data Factory na seção de preços do Data Factory.

O preço varia dependendo de componentes ou atividades, frequência e a computação geral associada à orquestração. Qualquer movimentação de dados resultante de atividades de pipeline ou de um trabalho de cópia gera um custo. No entanto, a computação associada à movimentação de dados por meio do espelhamento do Fabric é gratuita e o custo de armazenamento de dados espelhados é gratuito até o tamanho da capacidade. Por exemplo, se você comprar uma capacidade F64, receberá 64 TB (terabytes gratuitos) de armazenamento que é usado exclusivamente para espelhamento. O armazenamento OneLake será cobrado se o limite de armazenamento de espelhamento gratuito for excedido ou quando a capacidade for pausada.

Guia de decisão da carga de trabalho do Fabric

Use este guia de decisão para selecionar um armazenamento de dados para suas cargas de trabalho do Fabric. Todas as opções estão disponíveis no armazenamento unificado no OneLake.

O ponto de extremidade SQL para Fabric Lakehouse ou Fabric Warehouse permite executar consultas ad hoc de análise. Ele também permite que modelos semânticos do Power BI importem ou consultem diretamente os dados. O custo associado a um lakehouse ou warehouse é equivalente ao consumo de CUs para consultas SQL no endpoint SQL. Para otimizar o custo, implemente o Z-Ordering e o V-Ordering no Fabric Lakehouse para melhorar o desempenho da consulta. Para o Data Warehouse, otimize as consultas para ler lotes menores.

Armazenamento do OneLake

O armazenamento OneLake é cobrado a uma taxa paga conforme o uso por GB de dados usados e não consome CUs (unidades de capacidade do Fabric). Itens do Fabric como lakehouses e depósitos consomem armazenamento do OneLake. Para obter mais informações, consulte os preços do Fabric.

Para otimizar os custos do OneLake, concentre-se no gerenciamento do volume de armazenamento excluindo regularmente dados não utilizados, incluindo dados no armazenamento de exclusão reversível e otimizando operações de leitura/gravação. O armazenamento OneLake é cobrado separadamente da computação, portanto, é importante monitorar o uso com o aplicativo de métricas de capacidade do Fabric. Para reduzir os custos de armazenamento, que são calculados com base no uso diário médio ao longo do mês, considere minimizar a quantidade de dados armazenados.

Power BI

Esse cenário usa workspaces do Power BI com aprimoramentos internos de desempenho para acomodar necessidades analíticas exigentes. Para otimizar o custo, implemente a atualização incremental para extração do modo de importação. Implemente o modo Direct Lake para relatórios em conjuntos de dados maiores quando possível para reduzir a carga geral nas capacidades do Fabric.

Para obter mais informações, consulte de preços do Power BI.

Excelência operacional

A Excelência operacional abrange os processos de operações que implantam uma aplicação e as mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design para Excelência Operacional.

  • Utilize um pipeline de release do Azure DevOps e o GitHub Actions para automatizar a implantação de um artefato de workspace do Fabric em vários ambientes. Para obter mais informações, consulte Integração contínua e entrega contínua para um espaço de trabalho do Fabric.

  • Coloque cada carga de trabalho em um modelo de implantação separado e armazene os recursos em sistemas de controle do código-fonte. Você pode implantar os modelos em conjunto ou individualmente como parte de um processo de CI/CD (integração contínua e entrega contínua). Essa abordagem simplifica o processo de automação. Essa arquitetura tem quatro cargas de trabalho principais:

    • O data warehouse e os recursos relacionados
    • Pipelines de Data Factory
    • Ativos do Power BI, incluindo dashboards, aplicativos e conjuntos de dados
    • Um cenário simulado do local para a nuvem

  • Considere preparar suas cargas de trabalho, quando for prático. Implante sua carga de trabalho em vários estágios. Execute verificações de validação em cada estágio antes de passar para o próximo estágio. Essa abordagem envia atualizações por push para seus ambientes de produção de forma controlada e minimiza problemas de implantação imprevistos. Use de implantação azul-verde e estratégias de de versão canário para atualizar ambientes de produção ao vivo.

  • Use uma estratégia de reversão para lidar com implantações com falha. Por exemplo, é possível reimplantar automaticamente uma implantação anterior bem-sucedida com base em seu histórico de implantações. Use o sinalizador --rollback-on-error na CLI do Azure.

  • Use o aplicativo de métricas de capacidade do Fabric para monitoramento abrangente do consumo de capacidade do Fabric. Use workspace monitoring para um exame detalhado dos logs de telemetria do workspace do Fabric.

  • Use o avaliador de capacidade do Fabric para estimar suas necessidades de capacidade do Fabric.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. Para obter mais informações, consulte Lista de verificação de revisão de design para eficiência de desempenho.

Este artigo usa a capacidade do Fabric F64 para demonstrar os recursos de BI. As capacidades dedicadas do Power BI no Fabric variam de F64 ao tamanho máximo de SKU. Para obter mais informações, consulte os preços do Fabric.

Para determinar a capacidade necessária, execute as seguintes ações:

  • Avaliar o de carga em sua capacidade.

  • Instale o aplicativo de métricas de capacidade do Fabric para monitoramento contínuo.

  • Considere usar técnicas de otimização de capacidade relacionadas à carga de trabalho.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

Outros colaboradores:

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas