Compartilhar via


Escolher um padrão de implantação Microsoft Fabric

Ao implantar Microsoft Fabric, você precisa decidir como estruturar capacidades, workspaces e itens em toda a sua organização. O padrão de implantação correto depende de seus requisitos de governança, segurança, isolamento de desempenho e gerenciamento de custos. Este guia ajuda arquitetos e equipes de plataforma a avaliar quatro padrões de implantação e a entender as considerações e compensações para cada um deles.

Hierarquia de quatro níveis

O diagrama a seguir mostra a hierarquia de quatro níveis que define todas as implantações Fabric.

Diagrama que mostra a hierarquia de implantação do Fabric, que inclui o locatário, as capacidades, os espaços de trabalho e os itens.

Carrege um arquivo Visio desta arquitetura.

A hierarquia de implantação flui do seu tenant Microsoft 365 para os itens individuais. Sua escolha de padrão de implantação determina como você usa cada nível.

  • Nível do inquilino. No topo está seu tenant do Microsoft 365, que serve como a identidade e o limite administrativo para sua organização. Seu locatário Fabric existe nesse locatário Microsoft 365 e todos os recursos Fabric estão localizados dentro desse limite de locatário único. As configurações no nível do locatário, incluindo Microsoft Entra Conditional Access, private links e sensitivity labels, aplicam-se em todas as capacidades e workspaces.

  • Nível de capacidade. Configure pelo menos uma capacidade do Fabric em um tenant do Microsoft 365. Cada capacidade está associada a uma região Azure específica e tem uma SKU F específica que determina os recursos de computação disponíveis medidos em CUs (unidades de capacidade). As capacidades controlam a residência de dados e fornecem limites de cobrança. Uma única capacidade pode hospedar vários espaços de trabalho.

  • Nível do espaço de trabalho. Cada capacidade contém um ou mais workspaces. Workspaces são os principais contêineres para colaboração e governança. Eles definem o controle de acesso por meio de quatro funções de workspace (Administrador, Membro, Colaborador e Visualizador), dão suporte à integração do Git para controle de versão e servem como o escopo para pipelines de implantação. Um workspace pertence a uma única capacidade por vez. A migração de capacidade da mesma região é simples. A migração entre regiões é possível, mas você deve remover e recriar a maioria dos itens Fabric, incluindo lakehouses, warehouses, notebooks e pipelines. Portanto, prefira a migração dentro da mesma região.

  • Nível do item. Os espaços de trabalho contêm itens do Fabric, como lakehouses, warehouses, notebooks, pipelines, modelos semânticos, relatórios e painéis de controle. Os itens herdam permissões de workspace por padrão. Funções de segurança do Microsoft OneLake fornecem controle de acesso granular nos níveis de tabela, pasta, coluna e linha, mas são aplicadas somente aos usuários com a função de Visualizador. Administradores, membros e colaboradores do workspace ignoram as funções de segurança do OneLake.

As seguintes restrições de licenciamento e tipo de workspace geralmente determinam qual padrão de implantação é mais prático:

  • Novos espaços de trabalho começam na capacidade compartilhada, a menos que você os reatribua. Cada locatário tem uma capacidade compartilhada que hospeda Meus Workspaces e pode hospedar Power BI Pro ou workspaces PPU (Premium por Usuário). Para implementar um padrão de implantação de Fabric controlado para cargas de trabalho de produção, você normalmente precisa realocar os workspaces para uma capacidade de Fabric dedicada no locatário.

  • A PPU não substitui a capacidade de Fabric. PPU fornece recursos Premium do Power BI por usuário, mas não inclui capacidade do Fabric. Para criar ou executar itens não Power BI Fabric, como lakehouses, warehouses e notebooks, você precisa de uma capacidade F.

  • O tipo de workspace afeta o que o padrão pode hospedar. Os padrões de implantação do Fabric neste artigo pressupõem que os workspaces do Fabric são suportados pelo F SKU. Os SKUs A e EM dão suporte apenas a itens Power BI, portanto, eles não podem dar suporte a padrões de implantação de ponta a ponta Fabric.

  • Licenciamento do visualizador do Power BI pode alterar o custo de um modelo. Em capacidades F64 e maiores, os usuários com a função de Visualizador podem acessar o conteúdo do Power BI com uma licença gratuita. Em capacidades menores, os consumidores do Power BI precisam de uma licença Pro, PPU ou teste. Esse limite pode reduzir a eficácia do custo de um padrão centralizado para populações de leitores grandes.

  • A criação e o compartilhamento no Power BI requerem pelo menos um usuário Pro ou PPU. Mesmo que um workspace utilize capacidade Fabric, as organizações precisarão de usuários com licenças Pro ou PPU para criar e compartilhar itens do Power BI.

Componentes

  • Microsoft 365 tenant: Uma identidade e um limite administrativo para sua organização. Ele hospeda Microsoft Entra ID (anteriormente Azure Active Directory) para autenticação e autorização.

  • Capacidade de fabric: Um recurso de computação e de cobrança usado em uma região específica do Azure, por exemplo, Leste dos EUA ou Oeste da Europa. Para reduzir os custos, você pode pausar as capacidades quando não estiver em uso.

  • Fabric workspace: Um contêiner de colaboração para itens de Fabric. Ele dá suporte a RBAC (controle de acesso baseado em função), integração com o Git e pipelines de implantação. Você pode atribuir workspaces a domínios Fabric para agrupamento lógico.

  • Itens de Fabric: artefatos de dados e análise, como lakehouses, data warehouses, notebooks, pipelines, fluxos de dados, modelos semânticos, relatórios e painéis.

  • Fabric domains: agrupamentos lógicos que organizam espaços de trabalho por unidade de negócios ou área temática. Os domínios dão suporte à governança delegada e aparecem no catálogo do OneLake para descoberta e supervisão.

  • OneLake: Um data lake unificado e hierárquico em que os locatários contêm workspaces, que contêm itens. Fabric armazena dados no OneLake. O OneLake dá suporte a APIs Azure Data Lake Storage, atalhos para armazenamento externo e integração com ferramentas de Data Lake Storage, como Azure Storage Explorer e AzCopy.

  • Catálogo OneLake: Uma interface centralizada para localizar, governar e proteger dados do Fabric em todo o inquilino. Os usuários podem acessar o catálogo usando ferramentas como Microsoft Teams, Excel e Microsoft Copilot Studio.

Entender os níveis de implantação do Fabric

A estrutura, os objetivos, os requisitos de segurança, a escala, o modelo de governança e o ciclo de vida do aplicativo influenciam as decisões em cada nível de implantação. Para obter mais informações sobre cada nível, consulte hierarquia de quatro níveis.

  • As capacidades controlam a residência de dados e a distribuição geográfica. As organizações que operam em várias localizações geográficas podem usar capacidades em diferentes regiões Azure para controlar onde os dados são armazenados. Cada capacidade é associada a uma região Azure específica, que dá suporte a implantações de várias regiões. Para dar suporte à governança centralizada, os Domínios Fabric podem agrupar workspaces e suas capacidades associadas através de regiões.

  • Os workspaces servem como o limite principal de governança e segurança. Cada workspace define o controle de acesso por meio de quatro funções, dá suporte ao controle de versão por meio da integração do Git e serve como o escopo para pipelines de implantação. Para centralizar a colaboração e a descoberta de conteúdo, use o catálogo do OneLake para implementar uma experiência unificada de descoberta e governança nos dados do OneLake do locatário. Os usuários podem encontrar e interagir com o conteúdo de ferramentas como o Teams e Excel por meio deste catálogo.

  • Cada nível influencia as opções do ciclo de vida do aplicativo. Recursos como pipelines de implantação e gerenciamento de ciclo de vida não estão disponíveis em padrões de espaço de trabalho único, pois exigem espaços de trabalho separados. As organizações que utilizam domínios para agrupar workspaces podem delegar a administração no nível do domínio sem privilégios de administrador de locatários, o que afeta a maneira como as equipes gerenciam lançamentos de software e a governança entre as unidades de negócios.

Padrões comuns em todas as implantações

Todos os padrões de implantação Fabric compartilham as seguintes características fundamentais:

  • Workspaces como limites para escala, governança e segurança. Os padrões de implantação usam Fabric workspaces como a unidade primária para organização de itens, permissões e escopo de recursos de DevOps. Independentemente de qual padrão você escolher, os workspaces definem o limite para colaboração e controle de acesso.

  • Domínios de Fabric para delegação em vários workspaces e unidades de negócios. Use domínios do Fabric para delegação. Você pode gerenciar vários workspaces que podem pertencer à mesma unidade de negócios ou gerenciar dados que pertencem a um domínio de negócios e abrange mais de um workspace. Para gerenciar e controlar dados no nível de domínio, você pode ajustar as configurações de nível de locatário e usar uma configuração específica do domínio para essas configurações.

  • Capacidades para dimensionamento de computação com capacidade dedicada para cada workspace para garantias de desempenho. Se você precisar atender a níveis de desempenho específicos, use capacidades do Fabric para dimensionar recursos de computação e oferecer capacidades dedicadas para cada workspace. As organizações que precisam de isolamento de carga de trabalho para trabalhos sensíveis ao desempenho podem atribuir esses espaços de trabalho a uma capacidade separada que tenha uma alocação de CU garantida.

  • Catálogo do OneLake para descoberta de ativos e a aba Segurança para políticas de segurança de dados. Para promover a descoberta e o uso de ativos de dados em seu locatário, use o catálogo do OneLake. Para exibir, monitorar e configurar funções de segurança entre workspaces e itens, use a guia Proteger no catálogo do OneLake.

  • Extensão dos recursos do Microsoft Cloud se os recursos nativos do Fabric não estiverem disponíveis. Se um recurso nativo não estiver disponível, os padrões de implantação poderão ser estendidos para usar recursos equivalentes do Microsoft Cloud, como Azure e Microsoft 365. Por exemplo, as organizações podem usar Azure Pipelines ou GitHub Actions para orquestração de CI/CD (integração contínua e entrega contínua) se os pipelines de implantação Fabric não abrangerem seus requisitos de automação entre espaços de trabalho. As organizações também podem usar Microsoft Purview para governança de dados em toda a empresa que abrange fontes de dados Fabric e não Fabric.

Selecionar um padrão de implantação

Os cenários a seguir descrevem os requisitos de negócios comuns e os padrões de implantação que os abordam. Use esses cenários para ajudar a identificar o padrão que melhor se ajusta à sua organização.

  • Cenário 1: Redução do tempo de lançamento no mercado com colaboração interequipes. Se sua organização quiser um tempo mais rápido para comercializar, colaboração entre equipes e restrições mais baixas sobre o uso de dados, você poderá implementar um padrão de implantação monolítico . Nesse cenário, sua organização opera e gerencia um único workspace.

    Utilize Padrão 1: implantação monolítica.

  • Cenário 2: ambientes de equipe isolados com gerenciamento de infraestrutura central. Se sua organização quiser fornecer ambientes de equipe isolados e uma equipe central de gerenciamento de infraestrutura, você poderá implementar vários workspaces que usam uma capacidade compartilhada ou capacidades separadas. Esse cenário também atende às organizações que desejam implementar uma arquitetura de malha de dados.

    Use Padrão 2: vários espaços de trabalho, uma capacidade única ou Padrão 3: vários espaços de trabalho, capacidades separadas.

  • Cenário 3: autonomia de unidade de negócios completa sobre plataformas de dados. Se sua organização quiser um modelo totalmente descentralizado que dê às unidades de negócios ou equipes a liberdade de controlar e gerenciar suas próprias plataformas de dados, você poderá implementar um modelo de implantação que use workspaces separados com capacidade dedicada ou várias hospedagens Fabric.

    Use Padrão 3: múltiplos workspaces, capacidades separadas ou Padrão 4: múltiplos inquilinos Fabric.

  • Cenário 4: abordagem híbrida que combina vários padrões. Se sua organização quiser uma solução híbrida que use vários padrões para atender aos seus requisitos, você poderá implementar uma abordagem híbrida. Por exemplo, você pode configurar um único workspace para unidades de negócios específicas, como em um padrão de implantação monolítico, além de workspaces dedicados separados e capacidades separadas para outras unidades de negócios.

Padrão 1: implantação monolítica

Nesse padrão de implantação, você aloca um workspace para todos os casos de uso. Todas as unidades de negócios funcionam no mesmo workspace.

Diagrama que mostra um único tenant Fabric com uma única capacidade e um único workspace.

As seguintes características se aplicam a esse padrão:

  • Os itens de tecido compartilham a mesma capacidade. O tempo que uma consulta ou trabalho leva varia, dependendo das outras cargas de trabalho que usam a mesma capacidade.

  • As CUs máximas do workspace são limitadas pelo maior SKU F possível. Para experiências de engenharia de dados e ciência de dados, os administradores de capacidade podem configurar a Cobrança de Escala Automática para Apache Spark para mover a capacidade de computação utilizada pelo motor Spark para fora das unidades de capacidade (CUs) alocadas.

  • Os recursos com escopo de um espaço de trabalho se aplicam a todas as unidades de negócios que compartilham o espaço de trabalho.

  • Todos os itens e dados do workspace estão em uma região. Você não pode usar esse padrão para cenários geográficos múltiplos.

  • Recursos que dependem de múltiplos workspaces não estão disponíveis, como, por exemplo, pipelines de implantação e o gerenciamento do ciclo de vida.

  • As limitações de workspace único se aplicam.

  • As limitações de capacidade de SKU específicas se aplicam.

Quando usar esse padrão

Você poderá implementar esse padrão de implantação se:

  • Sua organização não tem requisitos complexos de engenharia, tem uma base de usuários pequena ou tem modelos semânticos pequenos.

  • A organização opera em uma única região.

  • Você não tem a preocupação principal com a separação organizacional entre unidades de negócios.

  • A organização não exige recursos com escopo de espaço de trabalho, como compartilhamento de repositórios de código com o Git.

  • Convém implementar uma arquitetura de medalhão do lakehouse. Se sua organização usar um único workspace, você poderá criar casas de lago separadas dentro do workspace para gerenciar camadas de bronze, prata e ouro.

  • As unidades de negócios da sua organização compartilham papéis, e você pode ter as mesmas permissões no nível do espaço de trabalho para os usuários no espaço de trabalho. Por exemplo, se vários usuários de unidades de negócios diferentes forem administradores de um único workspace, eles terão os mesmos direitos em todos os itens no workspace.

  • Sua organização tolera tempos de conclusão de trabalho variáveis. Se uma capacidade for compartilhada, os usuários poderão executar consultas a qualquer momento. O número de CUs disponíveis para executar uma tarefa depende das outras consultas que são executadas na capacidade, o que pode resultar em tempos variáveis para a conclusão da tarefa.

  • Sua organização pode atender aos seus requisitos de negócios CU usando uma única capacidade de Fabric.

Considerações sobre a área de design

A tabela a seguir apresenta considerações que podem influenciar sua decisão de usar esse padrão de implantação.

Aspecto Considerações
Governança São necessárias restrições e mandatos de governança mais baixos na plataforma. Ideal para organizações menores que preferem um tempo de lançamento mais rápido. Os desafios poderão ser desenvolvidos se os requisitos de governança se tornarem mais complexos.
Segurança: plano de dados Os dados podem ser compartilhados entre equipes, portanto, você não precisa restringir os dados entre as equipes. As equipes têm direitos de propriedade em modelos semânticos. Elas podem ler, editar e modificar dados no OneLake.
Segurança: plano de controle Todos os usuários podem colaborar no mesmo workspace. Não há restrições em itens. Todos os usuários podem ler e editar todos os itens.
Administração Custos de administração mais baixos. Não é necessário acompanhar e monitorar o acesso e o uso por equipe. Monitoramento de carga de trabalho do Fabric menos rigoroso entre equipes.
DevOps Uma única versão para toda a plataforma. Pipelines de lançamento mais simples.
Usabilidade: Administradores Menos itens a serem gerenciados. Não é necessária outra configuração ou lidar com solicitações de equipes para novas capacidades ou espaços de trabalho. Os administradores de capacidade podem ser administradores de locatários, portanto, você não precisa criar ou gerenciar outros grupos ou equipes.
Usabilidade: outras funções O compartilhamento de workspace é aceitável. A colaboração entre os usuários é incentivada.
Desempenho O isolamento da carga de trabalho não é obrigatório. Você não precisa atender a objetivos estritos de nível de serviço baseados em desempenho (SLOs). A limitação pode ocorrer quando as cargas de trabalho competem pelos mesmos Unidades de Computação (CUs) compartilhados. Esse padrão atende às organizações com cargas de trabalho de baixa simultaneidade ou previsíveis.
Cobrança e gerenciamento de custos Uma equipe pode lidar com os custos. Não é necessário realizar o chargeback para equipes diferentes.

Padrão 2: múltiplos espaços de trabalho, capacidade única

Nesse padrão de implantação, você aloca vários workspaces em uma única capacidade compartilhada. Os workspaces compartilham essa capacidade, portanto, cargas de trabalho simultâneas podem afetar o desempenho de tarefas e consultas interativas.

Diagrama que mostra um único tenant Fabric com uma única capacidade e dois workspaces.

As seguintes características se aplicam a esse padrão:

  • Os itens de tecido compartilham a mesma capacidade. O tempo que uma consulta ou trabalho leva varia, dependendo das outras cargas de trabalho que usam a mesma capacidade.

  • As CUs máximas do workspace são limitadas pelo maior SKU F possível. Para experiências de engenharia de dados e ciência de dados, os administradores de capacidade podem configurar a Cobrança de Dimensionamento Automático para Spark para mover a capacidade de computação usada pelo Mecanismo Spark fora das CUs alocadas.

  • Os recursos com escopo em um espaço de trabalho se aplicam a todas as unidades de negócios que compartilham esse espaço de trabalho.

  • Todos os itens e dados do workspace estão em uma região. Você não pode usar esse padrão para cenários geográficos múltiplos.

  • Você pode usar recursos de DevOps que exigem espaços de trabalho separados, como pipelines de entrega e gerenciamento de ciclo de vida.

  • Aplicam-se limitações de espaço de trabalho único.

  • As limitações de capacidade de SKU específicas se aplicam.

Quando usar esse padrão

Você poderá implementar esse padrão de implantação se:

  • Você deseja uma arquitetura hub-spoke que centralize alguns aspectos da operação de ambiente de análise e descentraliza outras.

  • Você deseja a descentralização operacional e de gerenciamento variável. Por exemplo, sua organização pode hospedar as camadas bronze e prata de uma arquitetura de medalhão em um espaço de trabalho e hospedar a camada de ouro em um espaço de trabalho separado. Essa separação geralmente reflete responsabilidades operacionais distintas, por exemplo, em que uma equipe gerencia as camadas bronze e prata e outra equipe gerencia a camada de ouro.

  • Você não está preocupado principalmente com o gerenciamento de desempenho e o isolamento da carga de trabalho.

  • Sua organização não precisa implantar cargas de trabalho em diferentes regiões geográficas. Todos os dados devem residir em uma região.

  • Sua organização pode exigir workspaces separados porque:

    • Os membros da equipe responsável por tarefas estão em espaços de trabalho diferentes.

    • Você deve criar workspaces separados para cada tipo de carga de trabalho. Por exemplo, você pode criar um espaço de trabalho para ingestão de dados, envolvendo pipelines de dados, fluxos de dados ou engenharia de dados, e um espaço de trabalho separado para consumo por meio de um data warehouse. Esse design funcionará bem se equipes separadas forem responsáveis por cada carga de trabalho.

    • Você deseja implementar uma arquitetura de malha de dados que agrupa um ou mais workspaces em um domínio Fabric.

  • Sua organização pode implantar workspaces separados com base na classificação de dados.

Considerações sobre a área de design

A tabela a seguir apresenta considerações que podem influenciar sua decisão de usar esse padrão de implantação.

Aspecto Considerações
Governança São necessários mandatos e restrições de governança moderada na plataforma. A organização precisa de um controle mais granular para governar departamentos, equipes e funções.
Segurança: plano de dados Restrições de dados são necessárias e você precisa fornecer proteção de dados com base em controles de acesso para departamentos, equipes e membros.
Segurança: plano de controle Para evitar corrupção acidental ou ações de usuários mal-intencionados, talvez seja necessário fornecer acesso controlado aos itens de Fabric por função.
Administração Você não precisa gerenciar capacidades porque é um modelo de capacidade única. Você pode usar workspaces para isolar departamentos, equipes e usuários.
DevOps Você pode fazer versões independentes por departamento, equipe ou carga de trabalho. É mais fácil atender aos requisitos de desenvolvimento, teste, aceitação e produção (DTAP) para equipes se você configurar vários workspaces para lidar com cada ambiente de versão.
Usabilidade: Administradores Você não precisa alocar várias capacidades. Os administradores de locatários normalmente administram a capacidade, portanto, você não precisa gerenciar outros grupos ou equipes.
Usabilidade: outras funções Espaços de trabalho estão disponíveis para cada camada de medalhão. Itens do Fabric são isolados em cada workspace, o que ajuda a evitar corrupção acidental.
Desempenho Você não precisa atender a SLOs de desempenho estritos. A limitação é aceitável durante os períodos de pico.
Cobrança e gerenciamento de custos Você não tem um requisito específico para fazer o chargeback por equipe. Uma equipe central é responsável pelos custos. As equipes de infraestrutura são responsáveis pelas capacidades do Fabric na organização.

Padrão 3: vários espaços de trabalho, capacidades separadas

Nesse padrão de implantação, você aloca vários workspaces através de capacidades Fabric distintas, o que fornece governança e isolamento de desempenho entre unidades de negócios.

Diagrama que mostra um único tenant do Fabric com duas capacidades, onde a primeira capacidade tem dois workspaces e a segunda capacidade tem um workspace.

As seguintes características se aplicam a esse padrão:

  • O maior SKU F ou SKU P possível anexado a um espaço de trabalho determina o número máximo de CUs que o espaço de trabalho pode usar.

  • Espaços de trabalho separados criam descentralização organizacional e gerencial.

  • As organizações podem expandir suas operações para além de uma região utilizando capacidades e espaços de trabalho em diferentes regiões geográficas.

  • Você pode usar todas as capacidades do Fabric porque as unidades organizacionais podem ter vários espaços de trabalho em capacidades distintas e agrupados por meio de domínios do Fabric.

  • As limitações de workspace para um único workspace se aplicam, mas você pode criar novos workspaces para dimensionar além desses limites.

  • Limitações específicas de capacidade de SKU se aplicam, mas você pode dimensionar as CUs usando capacidades separadas.

  • Você pode usar o catálogo OneLake para descobrir os itens do Fabric e seus status de certificação.

  • Os domínios podem agrupar workspaces, de maneira que uma única unidade de negócios possa operar e gerenciar vários workspaces.

  • Os atalhos do OneLake eliminam cópias físicas de dados para reduzir a movimentação de dados. Os atalhos do OneLake também oferecem acesso controlado entre espaços de trabalho por meio do OneLake e não transferem a propriedade dos dados subjacentes.

Quando usar esse padrão

Você poderá implementar esse padrão de implantação se:

  • Sua organização deseja implantar estruturas arquitetônicas, como malha de dados ou tecido de dados.

  • Convém priorizar a flexibilidade na maneira como você estrutura capacidades e espaços de trabalho.

  • Você opera em regiões geográficas diferentes. Nesse caso, crie uma capacidade separada e um ambiente de trabalho separado para avançar para um padrão de implantação multicapacidade e multiambiente de trabalho.

  • Você opera em grande escala e tem requisitos para expandir além dos limites de um SKU de capacidade única ou de um único workspace.

  • Você tem cargas de trabalho que sempre devem ser concluídas dentro de um tempo específico ou que precisam atender a SLOs baseados em desempenho. Você pode configurar um workspace separado com suporte de capacidade do Fabric para atender aos SLOs dessas cargas de trabalho.

Considerações sobre a área de design

A tabela a seguir apresenta considerações que podem influenciar sua decisão de usar esse padrão de implantação.

Aspecto Considerações
Governança Você possui um alto grau de governança e gestão e precisa de independência para cada espaço de trabalho. Você pode gerenciar o uso por departamento ou unidade de negócios. Você pode estar em conformidade com os requisitos de residência de dados. Você pode isolar dados com base em requisitos regulatórios.
Segurança: plano de dados Você pode controlar o acesso a dados no nível do departamento, da equipe ou do usuário. Você pode isolar dados com base no tipo de item do Fabric.
Segurança: plano de controle Você pode fornecer acesso controlado em itens de Fabric por função para evitar corrupção acidental ou ações de usuários mal-intencionados.
Administração Você restringe os recursos de administrador granular a departamentos, equipes ou usuários. Você tem acesso a requisitos de monitoramento detalhados sobre o uso ou padrões de cargas de trabalho.
DevOps Você pode isolar ambientes DTAP usando diferentes capacidades. As versões independentes baseiam-se no departamento, na equipe ou no volume de trabalho.
Usabilidade: Administradores Você obtém visibilidade granular do uso por departamento ou equipe. Você delega direitos de capacidade por departamento ou equipe para dar suporte ao escalonamento e à configuração granular.
Usabilidade: outras funções Os workspaces estão disponíveis por camada de medalhão e capacidade. Itens do Fabric são isolados em cada workspace, o que ajuda a evitar corrupção acidental. Você tem mais opções para evitar a limitação causada por aumentos na capacidade compartilhada.
Desempenho Os requisitos de desempenho são altos e as cargas de trabalho precisam atender a SLOs mais altos. Você tem flexibilidade no dimensionamento de cargas de trabalho individuais por departamento ou equipe.
Cobrança e gerenciamento de custos Você pode atender aos requisitos de cobrança cruzada usando capacidades dedicadas para cada entidade organizacional, como departamentos, equipes ou projetos. Você pode delegar o gerenciamento de custos às respectivas equipes para gerenciar.

Padrão 4: vários locatários de Fabric

Nesse padrão de implantação, todas as instâncias de Fabric são entidades separadas em relação à governança, gerenciamento, administração, escala e armazenamento.

As seguintes características se aplicam a esse padrão:

  • Os recursos do locatário são estritamente segregados.

  • Os planos de gerenciamento entre locatários são separados.

  • Os locatários são entidades separadas, cada uma com seus próprios processos de governança e gerenciamento e cada uma administrada de forma independente.

  • Você pode usar pipelines de dados ou capacidades de engenharia de dados para compartilhar ou acessar dados entre locatários do Fabric.

Quando usar esse padrão

Você poderá implementar esse padrão de implantação se:

  • Sua organização tem vários locatários do Fabric devido a uma aquisição empresarial.

  • Sua organização deseja configurar um locatário Fabric especificamente para uma unidade de negócios ou uma subsidiária menor.

Avaliar plataformas alternativas

Se os requisitos da sua organização não se alinharem com modelos de implantação baseados em Fabric, considere as seguintes alternativas restritas:

  • Azure Data Factory com Data Lake Storage ou OneLake, incluindo arquiteturas híbridas do Data Factory e Fabric

    As organizações que precisam de controle explícito de orquestração ou modernização em fases podem usar Data Factory para orquestração de ingestão e pipelines e Data Lake Storage como base de armazenamento. Em um modelo híbrido, os pipelines de dados gerenciados pelo Data Factory podem carregar dados no OneLake enquanto Fabric gerencia a criação de ativos de dados analíticos. Essa abordagem dá suporte à adoção incremental de Fabric e preserva padrões de integração estabelecidos.

  • Data Lake Storage, Azure Databricks e Power BI

    As organizações que preferem uma arquitetura baseada em PaaS (plataforma como serviço) em vez de uma plataforma saaS (software como serviço) unificada podem criar um patrimônio de dados usando Data Lake Storage para armazenamento, Azure Databricks para engenharia e análise de dados e Power BI para modelagem semântica e relatórios. Essa abordagem oferece máximo controle e flexibilidade, mas requer maior esforço de integração e aumenta a complexidade operacional e a sobrecarga de governança.

Considerações

Essas considerações implementam os pilares do 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 o Well-Architected Framework.

As tabelas por padrão anteriores neste artigo usam áreas de design específicas para Fabric decisões de implantação, como governança, segurança, administração, DevOps, usabilidade, desempenho e cobrança. As subseções a seguir fornecem diretrizes complementares organizadas pelo pilar Well-Architected Framework. Use as tabelas por padrão específico para comparar padrões. Utilize essas subseções para diretrizes arquitetônicas transversais que se aplicam independentemente do padrão escolhido.

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.

  • Resiliência regional interna. Fabric fornece resiliência regional interna por meio de zonas de disponibilidade, onde há suporte. Fabric distribui automaticamente recursos entre várias zonas sem a configuração do cliente. O suporte à zona de disponibilidade varia de acordo com a região do Azure. Para verificar se a região de destino dá suporte a zonas de disponibilidade para Fabric, consulte Fabric disponibilidade da região.

  • A recuperação de desastre (DR) requer aceitação e tem ressalvas. A recuperação entre regiões está disponível por meio de uma configuração de opt-in para recuperação de desastres na página de configurações de capacidade. Habilite a configuração de capacidade de recuperação de desastres para replicar dados do OneLake nas regiões emparelhadas do Azure usando a replicação assíncrona.

    Importante

    Algumas regiões Azure não são emparelhadas com regiões que dão suporte a Fabric, o que pode comprometer os recursos de DR mesmo que os dados sejam replicados. Como a replicação de dados é assíncrona, os dados gravados imediatamente antes de um desastre regional podem ser perdidos. Para obter mais informações, consulte Confiabilidade no Fabric.

  • Os padrões de capacidade única concentram o risco em uma região. Nos padrões 1 e 2, as cargas de trabalho estão em uma região Azure. Se a região sofrer uma interrupção, todos os workspaces serão afetados simultaneamente. Para proteger contra falhas regionais, defina a configuração de capacidade para replicar dados do OneLake para uma região emparelhada. Planeje o tempo de recuperação necessário para restaurar o serviço na região emparelhada.

  • Os padrões de multicapacidade fornecem isolamento regional natural. Nos padrões 3 e 4, as capacidades em regiões diferentes significam que uma interrupção regional afeta apenas as capacidades nessa região. As cargas de trabalho em outras regiões continuam operando. Esses padrões dão suporte aos requisitos de localização de dados e fornecem a base para estratégias regionais ativas-passivas ou ativas-ativas.

  • A pausa de capacidade afeta a confiabilidade. Se você pausar uma capacidade do Fabric para reduzir custos, todas as cargas de trabalho nessa capacidade do Fabric ficarão indisponíveis. Considere o efeito de confiabilidade antes de pausar uma capacidade que dá suporte a cargas de trabalho de produção.

  • Os atalhos do OneLake introduzem dependências externas. Atalhos para fontes de dados externas introduzem dependência da disponibilidade da fonte. Se a origem externa não estiver disponível, os itens que dependem de atalhos poderão falhar. Monitore a integridade das fontes de dados externas e planeje a degradação normal.

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.

  • O modelo de segurança em camadas abrange três níveis. Fabric implementa um modelo de segurança em camadas que abrange os níveis de inquilino, espaço de trabalho e item. Sua escolha de padrão de implantação determina como você segmenta os limites de segurança. Padrões de espaço de trabalho único, como o padrão 1, impõem acesso uniforme. Padrões multiworkspace, como os padrões 2, 3 e 4, dão suporte a limites de segurança por equipe ou por unidade de negócios.

Identidade e acesso

  • Imponha políticas de autenticação no nível do locatário usando o Acesso Condicional. Use o Acesso Condicional para impor políticas de autenticação no nível do locatário, como autenticação multifator, conformidade do dispositivo e restrições baseadas no local. O Acesso Condicional requer uma licença Microsoft Entra ID P1.

  • Use funções de workspace para controlar o acesso ao item. Atribua funções de workspace para controlar quem pode criar, editar e consumir itens em um workspace. Em padrões de vários espaços de trabalho, como os padrões 2, 3 e 4, use espaços de trabalho separados para impor limites de papéis entre unidades de negócios.

  • Aplique o acesso em nível de dados granular usando funções de segurança do OneLake. Use perfis de segurança do OneLake para aplicar o controle de acesso granular na tabela, pasta, coluna e no nível de linha para usuários na função Visualizador. Administradores, membros e colaboradores do workspace ignoram essas funções.

Segurança de rede

  • Use links privados para tráfego de entrada. Use links privados para rotear o tráfego de entrada pelo backbone da Microsoft em vez da Internet pública. Links privados no nível do locatário se aplicam a todos os espaços de trabalho. Os links privados no nível do workspace fornecem granularidade por workspace.

  • Use pontos de extremidade privados gerenciados para conexões de saída do Spark. Use pontos de extremidade privados gerenciados para proteger as conexões de saída de trabalhos do Spark para fontes de dados protegidas por firewall, como o Data Lake Storage e o Azure SQL Database.

  • Use gateways de dados de rede virtual quando os links privados no nível do locatário bloquearem gateways locais. Quando você habilita links privados no nível do locatário, os gateways de dados locais não podem se registrar. Use um gateway de dados de rede virtual em vez de bridges que conectam fontes de dados locais ou protegidas por rede virtual.

Proteção de dados

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 a Lista de verificação para revisão de design para Otimização de Custos.

  • Modele os custos antes de implantar. Os padrões de implantação afetam sua estrutura de custos. Modele os custos para seu cenário usando Fabric preços e o estimador de capacidade Fabric.

  • Rightsize sua SKU de capacidade. Rightsize sua SKU F com base na demanda de carga de trabalho. Comece com uma SKU menor e escale verticalmente conforme necessário. Monitore o consumo e identifique as capacidades superprovisionadas ou subprovisionadas usando o aplicativo Fabric Capacity Metrics.

  • Automatize a pausa de capacidade para ambientes não-produtivos. Reduza os custos pausando as capacidades de SKU F quando elas não estiverem em uso. Em ambientes de desenvolvimento/teste, pause a capacidade fora do horário de trabalho. Pausar torna todas as cargas de trabalho indisponíveis, portanto, considere a automação por meio das APIs do Azure Resource Manager Fabric ou de pipelines agendados.

  • Padrões de capacidade única, como os padrões 1 e 2, centralizam a cobrança, mas limitam o retorno de cobrança. Uma capacidade resulta em uma fatura. O gerenciamento de custos é centralizado, mas o rateio de custos para unidades de negócios individuais não é possível porque todas as cargas de trabalho compartilham a mesma capacidade.

  • Padrões de multicapacidade, como os padrões 3 e 4, dão suporte ao chargeback por equipe. Cada capacidade gera seu próprio medidor de cobrança do Azure. Você pode cobrar custos para a unidade de negócios responsável por cada capacidade. Você pode ajustar independentemente ou pausar cada capacidade com base na carga de trabalho que ela suporta.

  • Gerencie os custos de armazenamento do OneLake de forma independente. O armazenamento OneLake é cobrado a uma taxa paga conforme o uso por GB e não consome CUs. Exclua regularmente dados não utilizados, incluindo dados excluídos de forma branda, e monitore regularmente o armazenamento por meio do aplicativo de Métricas de Capacidade do Fabric.

  • Monitore a computação do Spark separadamente. Para cargas de trabalho de engenharia de dados, você pode usar pools do Spark separados para alocar a computação fora do orçamento de CU. Para evitar custos inesperados, monitore o consumo de CUs do Spark.

Excelência operacional

A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o 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 pipelines de implantação para promoção progressiva. Use Pipelines de implantação do Fabric para promover o conteúdo pelos estágios de desenvolvimento/teste e produção. Os pipelines de implantação exigem espaços de trabalho separados, assim, não estão disponíveis no padrão 1. Nos padrões 2, 3 e 4, crie espaços de trabalho dedicados para cada estágio DTAP. A estratégia de capacidade varia de acordo com o padrão.

    • No padrão 2, todos os workspaces DTAP compartilham a mesma capacidade, que é econômica, mas não fornece isolamento de desempenho entre ambientes.

    • No padrão 3, você pode usar capacidades dedicadas por ambiente para isolamento total ou balancear o custo e o isolamento usando uma capacidade compartilhada para desenvolvimento/teste com uma capacidade de produção separada.

  • Planeje ambientes de pré-produção como uma decisão de design no nível do workspace. O padrão 1 não fornece separação de pré-produção porque o desenvolvimento/teste ocorre no workspace de produção. O Padrão 2 dá suporte a workspaces de desenvolvimento, teste e produção separados em uma capacidade compartilhada, o que atende à validação funcional, mas não a testes de desempenho ou resiliência semelhantes à produção. O Padrão 3 dá suporte à validação de pré-produção semelhante à de produção por meio de workspaces alinhados ao ambiente com isolamento no nível de capacidade. O padrão 4 envolve locatários separados em vez de decisões no nível do espaço de trabalho. Cada locatário pode escolher independentemente sua própria topologia de ambiente e não precisa ser igual à de outros locatários.

  • Conecte repositórios Git aos workspaces para controle do código-fonte. Nos padrões 2 e 3, espaços de trabalho separados por equipe ou carga de trabalho se alinham com estratégias padrão de ramificação. No padrão 1, todas as equipes compartilham um único repositório, o que pode causar contenção de mesclagem.

  • Monitore a capacidade e a saúde da carga de trabalho. Utilize o aplicativo de Métricas de Capacidade do Fabric para monitorar o consumo de capacidade, como o uso de Unidades de Capacidade (CUs), estrangulamento e sobrecarga. Você pode acessar telemetria detalhada sobre cargas de trabalho individuais usando monitoramento do workspace. Em padrões de multicapacidade, como os padrões 3 e 4, você pode delegar o monitoramento à equipe responsável por cada capacidade.

  • Delegar administração por meio de domínios Fabric. Nos padrões 2 e 3, delegue configurações de locatário e gerenciamento de workspace a administradores de nível de domínio sem privilégios de administrador do locatário usando domínios Fabric. O Padrão 1 não pode usar domínios porque todos os itens estão em um workspace.

  • Gerenciar capacidades usando IaC (infraestrutura como código). Crie e gerencie Fabric capacidades usando Bicep ou Terraform. Armazene definições de infraestrutura no controle do código-fonte junto com o código do aplicativo.

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 a Lista de Verificação de Design para Eficiência de Desempenho.

  • Entenda o comportamento de dimensionamento e limitação da capacidade. Cada capacidade tem uma alocação fixa de UC determinada pelo seu SKU. Se a demanda exceder as CUs disponíveis, o Fabric aplicará limitação e colocará solicitações em fila. Monitore eventos de limitação usando o aplicativo Fabric Métricas de Capacidade e dimensione a SKU ou distribua as cargas de trabalho em várias capacidades, conforme necessário.

  • Isole cargas de trabalho sensíveis ao desempenho em uma capacidade dedicada. Nos padrões 1 e 2, todas as cargas de trabalho competem pelas mesmas Unidades de Computação (CUs). Uma consulta cara ou fluxo de dados pode degradar o desempenho de consultas interativas para outros usuários. Nos padrões 3 e 4, você pode isolar cargas de trabalho sensíveis ao desempenho em uma capacidade dedicada com uma alocação garantida de CUs.

  • Configurar os pools do Spark para cargas de trabalho de engenharia de dados. Para cargas de trabalho de engenharia de dados, use pools personalizados do Spark para controlar o número mínimo e máximo de nós e dar suporte ao dimensionamento automático. Redes virtuais gerenciadas desabilitam pools iniciais ou clusters compartilhados pré-armados, o que aumenta o tempo de início da sessão de segundos para entre 3 e 5 minutos.

  • Coloque capacidades próximas aos produtores e consumidores de dados. No padrão 3, você pode usar capacidades em regiões próximas a produtores de dados ou consumidores, o que reduz a latência entre regiões. Os atalhos do OneLake podem referenciar dados em outras regiões, mas as leituras entre regiões incorrem em custos de latência e saída.

  • Aplicar técnicas de otimização específicas da carga de trabalho. Melhore o desempenho de varredura usando o Z-Ordering e o V-Ordering para lakehouses. Para armazéns, otimize os padrões de consulta para ler lotes menores. Reduza a carga de capacidade em comparação com o modo de importação usando o modo Direct Lake para relatórios Power BI.

Matriz de funcionalidades

As tabelas a seguir resumem as principais diferenças nos recursos de cada padrão.

Governança e administração

Capacidade Padrão 1: Monolítico Padrão 2: múltiplos espaços de trabalho, capacidade única Padrão 3: vários espaços de trabalho, capacidades separadas Padrão 4: vários locatários
Complexidade da governança Baixo Medium Alto Alto
Acompanhamento de uso por departamento No Limitado 1 Sim Sim
Delegação baseada em domínio No Sim Sim N/D 2
Delegação de administrador granular No Limitado 1 Sim Sim
Conformidade de residência de dados Somente região única Somente região única Várias regiões Várias regiões
Isolamento de dados regulatórios No Limitado 1 Sim Sim

1 Os workspaces fornecem algum isolamento, mas todos os workspaces compartilham uma única capacidade, o que limita a granularidade do acompanhamento de uso e da administração.

2 O Padrão 4 usa locatários separados em vez de domínios. Cada locatário tem seu próprio modelo de administração.

Segurança

Capacidade Padrão 1: Monolítico Padrão 2: múltiplos espaços de trabalho, capacidade única Padrão 3: vários espaços de trabalho, capacidades separadas Padrão 4: vários locatários
Isolamento do plano de dados entre equipes No Sim Sim Sim
Isolamento do plano de controle (acesso no nível do item) No Sim Sim Sim
Limitações de funções do espaço de trabalho entre unidades de negócios No Sim Sim Sim
Segregação de segurança no nível do locatário N/A N/A N/A Sim

DevOps e gerenciamento de ciclo de vida

Capacidade Padrão 1: Monolítico Padrão 2: múltiplos espaços de trabalho, capacidade única Padrão 3: vários espaços de trabalho, capacidades separadas Padrão 4: vários locatários
Pipelines de implantação Não 3 Sim Sim Sim
Integração do Git Limitado 4 Sim Sim Sim
Versões independentes por equipe No Sim Sim Sim
Isolamento de ambiente DTAP No Sim Sim (em diferentes capacidades) Sim (entre locatários)

3 pipelines de implantação requerem workspaces separados, o que não está disponível em um modelo monolítico de workspace único.

4 A integração com o Git está disponível, mas todas as equipes compartilham um único repositório, o que pode criar conflito de mesclagem.

Desempenho e escala

Capacidade Padrão 1: Monolítico Padrão 2: múltiplos espaços de trabalho, capacidade única Padrão 3: vários espaços de trabalho, capacidades separadas Padrão 4: vários locatários
Isolamento de carga de trabalho para desempenho No No Sim Sim
Implantação em várias regiões geográficas No No Sim Sim
Dimensionar além dos limites de SKU únicos No No Sim Sim
Garantias de Desempenho de SLO No No Sim Sim
Limitação do risco da capacidade compartilhada Alto Alto Baixa 5 Baixo

5 O risco de limitação será baixo se as cargas de trabalho estiverem em capacidades dedicadas, mas a limitação ainda poderá ocorrer dentro de uma única capacidade se a demanda exceder as CUs disponíveis.

Cobrança e gerenciamento de custos

Capacidade Padrão 1: Monolítico Padrão 2: múltiplos espaços de trabalho, capacidade única Padrão 3: vários espaços de trabalho, capacidades separadas Padrão 4: vários locatários
Cobrança centralizada Sim Sim 6 No
Chargeback por equipe No No Sim Sim
Pausa de capacidade independente N/A (capacidade única) N/A (capacidade única) Sim Sim
Delegação de custos para equipes No No Sim Sim

6 Cada capacidade gera seu próprio medidor de cobrança, portanto, a cobrança é distribuída entre capacidades em vez de centralizada.

Contribuidores

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

Autor principal:

Outros colaboradores:

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

Próximas Etapas