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

Este artigo descreve como transferir dados de um data warehouse local para um ambiente de nuvem e, em seguida, usar um modelo de business intelligence (BI) para servir os dados. Pode usar esta abordagem como objetivo final ou como primeiro passo para uma modernização total com componentes baseados na cloud.

Esta orientação baseia-se no cenário de ponta a ponta do Microsoft Fabric. Existem múltiplas opções para extrair dados de um servidor SQL local, como pipelines do Fabric Data Factory, espelhamento, trabalho de cópia e captura de dados de alteração (CDC) de fluxos de eventos em tempo real do Fabric para SQL. Após a extração, os dados são transformados para análise.

Architecture

Descarregue um ficheiro Visio desta arquitetura.

Workflow

O fluxo de trabalho a seguir corresponde ao diagrama anterior.

Fonte de dados

• Um banco de dados do SQL Server no Azure contém os dados de origem. Para simular o ambiente local, os scripts de implantação para este cenário configuram um banco de dados SQL do Azure. O banco de dados de exemplo AdventureWorks é usado como o esquema de dados de origem e dados de exemplo. Para obter mais informações, consulte Copiar e transformar dados de e para o SQL Server.

Ingestão e armazenamento de dados

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

• Os pipelines do Fabric Data Factory permitem-lhe construir fluxos de trabalho complexos de extração, transformação, carregamento (ETL) que podem executar muitas tarefas diferentes em escala. As capacidades de controle de fluxo estão integradas em pipelines de dados que permitem construir lógica de fluxo de trabalho, proporcionando laços e condicionais. Nesta arquitetura, os frameworks orientados por metadados permitem a ingestão incremental de múltiplas tabelas em grande escala.

• O espelhamento do Fabric Data Factory permite-lhe evitar processos ETL complexos e integrar o seu património SQL Server existente com o resto dos seus dados no Fabric. Pode replicar continuamente as suas bases de dados SQL Server existentes diretamente no Fabric OneLake. A tarefa de cópia do Fabric Data Factory facilita a transferência de dados da sua fonte para o destino sem necessidade de pipelines. As transferências de dados podem ser configuradas através de padrões incorporados para cópia em lote e incremental, com suporte para desempenho escalável.

• Os fluxos de eventos Fabric fornecem ingestão de dados em tempo real e de alta taxa a partir de uma base de dados SQL Server alojada numa máquina virtual (VM) através da extração CDC. Este padrão adequa-se a casos de uso que exigem dashboards e alertas em tempo real.

Análise e relatórios

• A abordagem de modelagem de dados neste cenário combina o modelo empresarial e o modelo semântico de BI . Os SKUs Fabric fornecem o cálculo para modelos semânticos do Power BI. O Power BI pode aceder aos dados através de Importação, DirectQuery ou conectividade Direct Lake.

Components

• do Banco de Dados SQL do Azure é um servidor SQL PaaS hospedado no Azure. Nesta arquitetura, a Base 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 na cloud para armazenar dados estruturados e não estruturados em toda a organização. Nesta arquitetura, OneLake serve como camada central de armazenamento. Utiliza artefactos como Fabric Lakehouse, Fabric Warehouse, Fabric Eventhouse e bases de dados espelhadas para persistir e organizar vários tipos de dados para análise e relatórios.

• O Fabric Data Warehouse é uma oferta SaaS que aloja cargas de trabalho de data warehouse para grandes conjuntos de dados. Nesta arquitetura, o Fabric Data Warehouse serve como o armazenamento final para conjuntos de dados dimensionais e suporta análises e relatórios.

• O Power BI é uma ferramenta de business intelligence alojada em computação Fabric. Apresenta e visualiza dados neste cenário, permitindo que os utilizadores de negócio interajam com painéis e relatórios baseados em dados do Fabric Data Warehouse e outras fontes.

• Microsoft Entra ID é um conjunto de soluções de rede e identidade multicloud que suporta o fluxo de autenticação e autorização. Nesta arquitetura, o Microsoft Entra ID proporciona acesso seguro aos utilizadores que se ligam a recursos Power BI e Fabric.

Detalhes do cenário

Nesse cenário, uma organização tem um banco de dados SQL que contém um grande data warehouse local. A organização pretende usar o Fabric para absorver e analisar os dados e fornecer insights analíticos aos utilizadores através do Power BI.

Quando usar esta arquitetura

Pode utilizar vários métodos para cumprir os requisitos empresariais de inteligência de negócios. Vários aspetos definem os requisitos do negócio, como investimentos tecnológicos atuais, competências humanas, o calendário para modernização, objetivos futuros e se prefere plataforma como serviço (PaaS) ou software como serviço (SaaS).

Considere as seguintes abordagens de design:

• Uma casa no lago em Fabric

• Fabric e Azure Databricks para clientes que têm investimento existente no Azure Databricks e no Power BI e desejam se modernizar com o Fabric

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

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

A arquitetura deste artigo assume que utilizas uma casa de lago Fabric ou um armazém Fabric como camada persistente do modelo semântico empresarial e que utilizas Power BI para inteligência de negócio. Esta abordagem SaaS tem flexibilidade para acomodar vários requisitos e preferências empresariais.

Authentication

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

Carregamento incremental

Quando executas um processo automatizado de ETL ou ELT, deves carregar apenas os dados que mudaram desde a execução anterior. Este processo é conhecido como 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 abordagem de marca d'água valor alto, que rastreia o valor mais recente de uma coluna de data e hora ou uma coluna inteira exclusiva na tabela de origem.

Você pode usar tabelas temporais no SQL Server. As tabelas temporais são tabelas versionadas pelo sistema que armazenam o histórico das alterações de dados. O mecanismo de banco de dados registra automaticamente o histórico de cada alteração 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 de histórico, mas é transparente para o aplicativo.

As tabelas temporais suportam dados de dimensão, que podem mudar ao longo do tempo. As tabelas de factos normalmente representam transações imutáveis, como uma venda, onde manter o histórico de versões 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 SalesLT.* têm um campo LastModified.

Os passos abaixo descrevem o fluxo geral do pipeline ELT:

1. Para cada tabela no banco de dados de origem, controle o tempo de corte quando o último trabalho ELT foi executado. Armazene essas informações no data warehouse. Na configuração inicial, todos os horários são definidos como 1-1-1900.

2. Durante a etapa de exportação de dados, o tempo de corte é passado 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 ModifiedDate coluna.

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

Fluxo de dados

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

Estrutura de ingestão orientada por metadados

O framework de ingestão orientado por metadados dentro dos pipelines da Fabric Data Factory carrega incrementalmente todas as tabelas contidas na base de dados relacional. O artigo refere-se a um data warehouse como fonte, mas pode ser substituído por uma base de dados Azure SQL como fonte.

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

2. Cria uma tabela para guardar o teu último valor da marca de água.

3. Construir um pipeline que inclua as seguintes atividades:

   • Duas atividades de consulta. A primeira atividade recebe o último valor da marca d'água (onde paramos da última vez). A segunda atividade recebe o novo valor da marca de água (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. Depois, copia esses dados do seu armazém de dados para o lakehouse como um novo ficheiro.

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

   

A imagem seguinte mostra um oleoduto concluído. Para mais informações, veja Ingestão incremental.

Carregar dados num armazém de dados Fabric

A atividade de cópia copia dados da base de dados SQL para o armazém de dados Fabric. A base de dados SQL deste exemplo está no Azure, por isso utiliza uma ligação configurada dentro do portal Fabric em Gerenciar Conexão e Gateways.

Utilizar os pipelines da Fabric Data Factory

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

Transformar os dados

Se for necessária transformação, utilize fluxos de dados Fabric para desenhar transformações ETL assistidas por IA low-code que remodelem os dados. Os fluxos de dados Fabric dependem do motor Power Query para aplicar essas transformações e escrever os resultados no Fabric Data Warehouse.

Num ambiente de produção, utilize cadernos Fabric para implementar transformações ETL que funcionem bem para grandes conjuntos de dados através de um framework de computação distribuída impulsionado pelo Apache Spark.

Use o Power BI com capacidades Fabric para aceder, modelar e visualizar dados

As capacidades do Fabric no Power BI suportam múltiplos modos de armazenamento para ligação a fontes de dados Azure:

• Importado: Carrega dados no modelo semântico do Power BI para consultas em memória.

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

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

• Direct Lake: Consulta tabelas delta armazenadas no OneLake a partir de um modelo semântico no espaço de trabalho Fabric. Está otimizado para análise interativa de tabelas grandes, carregando dados na memória a pedido.

Este cenário usa o painel do DirectQuery porque ele tem uma pequena quantidade de dados e baixa complexidade do 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 Importação se os seguintes fatores forem verdadeiros:

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

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

Use o Power BI para gerir modelos grandes, relatórios paginados e pipelines de implementação. Aproveite o ponto de extremidade interno do Azure Analysis Services. Também pode ter capacidade dedicada com uma proposta de valor única.

Quando o modelo de BI cresce ou a complexidade do painel aumenta, você pode alternar para modelos compostos e importar partes de tabelas de pesquisa por meio de tabelas híbridas e importar dados pré-agregados. Você pode habilitar de cache de consulta no Power BI para conjuntos de dados importados e usar de 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 utilizadores interagem com visualizações, o Power BI gera consultas SQL para o Fabric Data Warehouse. O Power BI determina se o armazenamento na memória ou DirectQuery deve ser usado com base na eficiência. O motor decide quando mudar da memória para o DirectQuery e envia a lógica para o armazém de dados Fabric. Dependendo do contexto das tabelas de consulta, podem servir como modelos compostos 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 DirectQuery ou combinar dados de origem do DirectQuery e dados importados.

Quando usar o DirectQuery com um armazém de dados Fabric ou lakehouse, tome as seguintes ações:

• Utilize Fabric Ordem Z e V-Ordem para melhorar o desempenho das consultas, otimizando o armazenamento dos dados subjacentes das tabelas em ficheiros com formato delta.

• Use as vistas materializadas do Fabric lakehouse para pré-calcular, armazenar e manter dados como uma tabela. As consultas que usam todos os dados ou um subconjunto dos dados em exibições materializadas podem alcançar um desempenho mais rápido sem a necessidade de fazer referência direta à exibição materializada definida para usá-la.

Considerações

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

Reliability

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

O artigo Fiabilidade explica como o Fabric apoia a fiabilidade, incluindo a resiliência regional através das zonas de disponibilidade, juntamente com a recuperação inter-região e a continuidade do negócio. O Fabric fornece uma opção de recuperação de desastres na página de configurações de capacidade. Está disponível onde os emparelhamentos regionais Azure se alinham com a presença do serviço Fabric. Quando a definição de capacidade de recuperação de desastres está ativada, a replicação entre regiões é ativada como capacidade de recuperação de desastres para os 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 introduz preocupações de segurança, como violações de dados, infeções por malware e injeção de código mal-intencionado. Você precisa de um provedor de nuvem ou solução de serviço que possa resolver suas preocupações, porque medidas de segurança inadequadas podem criar grandes problemas.

Este cenário aborda as preocupações de segurança mais exigentes utilizando uma combinação de controlos de segurança em camadas, incluindo controlos de rede, identidade, privacidade e autorização. Um armazém de dados Fabric armazena a maior parte dos dados. O Power BI acede aos dados através do DirectQuery através do SSO. Use o ID Microsoft Entra para autenticação. Há também controles de segurança abrangentes para autorização de dados dentro dos pools provisionados.

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

• Defina quem pode ver quais dados.

  • Certifique-se de que seus dados estejam em conformidade com as diretrizes federais, locais e da empresa para mitigar os riscos de violação de dados. A Fabric oferece capacidades abrangentes de proteção de dados para apoiar a segurança e promover a conformidade.

  • A segurança do OneLake controla todo o acesso aos dados do OneLake com diferentes permissões herdadas do item pai ou do espaço de trabalho.

    • Um espaço de trabalho é um ambiente colaborativo para criar e gerir itens. Os papéis de espaço de trabalho podem ser geridos neste nível.

    • Um item é um conjunto de capacidades agrupadas num único componente. Um item de dados é um subtipo de item que permite armazenar dados dentro dele através do OneLake. Os itens herdam permissões das funções do espaço de trabalho, mas podem também ter permissões extra. Pastas dentro de um item são usadas para armazenar e gerir dados, como Tables/ ou Files/.

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

  • Use o Fabric para controlar quem pode aceder a que dados através do controlo de acesso e autenticação.

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

  • Ajude a proteger o Fabric utilizando opções de segurança de rede .

• Escolha ferramentas para detetar e notificá-lo de ameaças.

  • O Fabric não tem deteção de ameaças incorporada. Recomendamos que utilize a combinação do Microsoft Purview Compliance Manager para configurar alertas e rever registos de auditoria para acompanhar as atividades dos utilizadores.

• Determine como proteger os dados no Fabric OneLake.

  • Ajude a proteger os dados no Fabric utilizando etiquetas de sensibilidade do Microsoft Purview Information Protection. Rótulos como Geral, Confidencial e Altamente Confidencial são amplamente usados em aplicações do Microsoft Office como Word, PowerPoint e Excel para proteger informações sensíveis. Eles seguem automaticamente os dados de item para item à medida que fluem através do Fabric, desde a fonte de dados até ao utilizador do negócio.

Otimização de Custos

A Otimização de Custos concentra-se em formas 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 secção descreve detalhes de preços para os vários serviços utilizados na solução e explica as decisões tomadas neste cenário utilizando um conjunto de dados de exemplo. Use a configuração inicial no calculador de preços do Azure e ajuste-a para se adequar ao seu cenário. Para mais informações sobre SKUs do Fabric, consulte Visão Geral de Preços do Fabric. Para mais informações sobre como gerar uma estimativa do consumo global de Tecido, consulte o estimador de capacidade de Tecido.

Arquitetura escalável de tecido

O Fabric é uma arquitetura serverless para a maioria das cargas de trabalho que pode usar para escalar os 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 geram custos por GB, por isso os seus custos aumentam à medida que ingere dados.

Linhas de produção de fábricas de tecidos

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

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

• Dataflow Gen2 para computação: Para otimizar custos, simplifique pipelines ETL filtrando dados desnecessários e processando extrações incrementais.

• Movimentação de dados para trabalho de cópia ou atividade de cópia: Para otimizar custos, configure o trabalho de cópia com extração incremental e ajuste a largura de banda para a atividade de cópia.

Para mais informações, consulte o separador "Medidores de preços" no separador "Preços da Data Factory".

O preço varia consoante os componentes ou atividades, a frequência e o cálculo global associado à orquestração. Qualquer movimento de dados resultante de atividades de pipeline ou de um trabalho de cópia gera um custo. No entanto, o processamento associado ao movimento de dados através do Fabric mirroring é gratuito, e o custo de armazenamento dos dados espelhados é gratuito até ao limite da capacidade. Por exemplo, se comprar uma capacidade F64, recebe gratuitamente 64 terabytes (TB) de armazenamento que são exclusivamente destinados ao espelhamento. O armazenamento do OneLake é faturado se o limite de armazenamento gratuito para espelhamento for ultrapassado ou quando a capacidade estiver pausada.

Guia de decisão de carga de trabalho em tecido

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

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

Armazenamento OneLake

O armazenamento OneLake é faturado a uma tarifa pay-as-you-go por GB de dados usados e não consome unidades de capacidade Fabric (CUs). Itens de tecido como casas de lago e armazéns consomem armazenamento OneLake. Para mais informações, consulte Preços de tecidos.

Para otimizar os custos do OneLake, foque-se na gestão do volume de armazenamento eliminando regularmente dados não utilizados, incluindo dados em armazenamento soft delete , e otimizando as operações de leitura/escrita. O armazenamento OneLake é faturado separadamente da computação, por isso é importante monitorizar a utilização com a aplicação de métricas de capacidade do Fabric. Para reduzir os custos de armazenamento, que são calculados com base no uso médio diário ao longo do mês, considere minimizar a quantidade de dados armazenados.

Power BI

Este cenário utiliza espaços de trabalho Power BI com melhorias de desempenho incorporadas para acomodar necessidades analíticas exigentes. Para otimizar custos, implemente refresh incremental para extração em modo de importação. Implementar o modo Direct Lake para reportar conjuntos de dados maiores sempre que possível, de modo a reduzir a carga total 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 operacionais que implantam um aplicativo e o mantêm em execução na 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 lançamento do Azure DevOps e GitHub Actions para automatizar a implementação de um artefato do Fabric workspace em múltiplos ambientes. Para mais informações, consulte Integração contínua e entrega contínua para um espaço de trabalho 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 juntos ou individualmente como parte de um processo de integração contínua e entrega contínua (CI/CD). Essa abordagem simplifica o processo de automação. Essa arquitetura tem quatro cargas de trabalho principais:

  • O armazém de dados e recursos relacionados
  • Pipelines de Data Factory
  • Ativos do Power BI, incluindo painéis, aplicativos e conjuntos de dados
  • Um cenário simulado no local para a nuvem

• Considere preparar suas cargas de trabalho onde 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 para seus ambientes de produção de forma controlada e minimiza problemas de implantação imprevistos. Use de implantação azul-verde e canary release estratégias para atualizar ambientes de produção ao vivo.

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

• Use a aplicação de métricas de capacidade Fabric para monitorizar de forma abrangente o consumo de capacidade de Fabrico. Utilize a monitorização do espaço de trabalho para uma monitorização detalhada dos registos de telemetria do espaço de trabalho Fabric.

• Use o estimador de capacidade de tecido para estimar as suas necessidades de capacidade de tecido.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da sua carga de trabalho de escalar para atender às demandas dos usuários de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.

Este artigo utiliza a capacidade do Fabric F64 para demonstrar capacidades de BI. As capacidades dedicadas do Power BI no Fabric variam desde F64 até ao tamanho máximo do SKU. Para mais informações, consulte Preços de tecidos.

Para determinar quanta capacidade precisa, tome as seguintes ações:

• Avalie a carga na sua capacidade.

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

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

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Bibhu Acharya | Arquiteto Principal de Soluções Cloud

Outros contribuidores:

• Jim McLeod - Brasil | Arquiteto de Soluções Cloud
• Miguel Myers - Portugal | Gerente de Programa Sênior
• Galina Polyakova - Brasil | Arquiteto de Soluções Cloud Sênior
• George Stevens | Engenheiro de Soluções

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

• O que é o Power BI Premium?
• O que é o Microsoft Entra ID?
• O que é Fabric?
• O que é o Data Factory no Fabric?
• O que é o Azure SQL?

Recursos relacionados

• Projeto de arquitetura de bancos de dados
• Análise de ponta a ponta com Microsoft Fabric