Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Quando implementa Microsoft Fabric, precisa de decidir como estruturar capacidades, espaços de trabalho e itens em toda a sua organização. O padrão de implementação correto depende das suas necessidades de governação, segurança, isolamento de desempenho e gestão de custos. Este guia ajuda arquitetos e equipas de plataforma a avaliar quatro padrões de implementação e a compreender as considerações e compensações de cada um.
Hierarquia de quatro níveis
O diagrama seguinte mostra a hierarquia de quatro níveis que define todas as implementações do Fabric.
Descarregue um ficheiro Visio desta arquitetura.
A hierarquia de implementação flui desde o seu tenant Microsoft 365 até itens individuais. A tua escolha do padrão de implantação determina como usas cada nível.
Nível de inquilino. No topo encontra-se o seu tenant do Microsoft 365, que serve como identidade e limite administrativo da sua organização. O seu tenant Fabric existe dentro deste tenant Microsoft 365, e todos os recursos Fabric estão localizados dentro deste limite de inquilino único. Definições ao nível do inquilino, incluindo Microsoft Entra Conditional Access, ligações privadas e etiquetas de sensibilidade, aplicam-se a todas as capacidades e espaços de trabalho.
Nível de capacidade. Configura pelo menos uma capacidade Fabric dentro de um tenant Microsoft 365. Cada capacidade está ligada a uma região Azure específica e possui um F SKU que determina os recursos computacionais disponíveis medidos em unidades de capacidade (CUs). As capacidades controlam a residência dos dados e fornecem limites de faturação. Uma única capacidade pode alojar múltiplos espaços de trabalho.
Nível do espaço de trabalho. Cada capacidade contém um ou mais espaços de trabalho. Os espaços de trabalho são os principais recipientes para a colaboração e governação. Definem o controlo de acesso através de quatro funções de espaço de trabalho (Administrador, Membro, Contribuinte e Visualizador), suportam a integração com o Git para controlo de versões e servem como escopo para pipelines de implementação. Um espaço de trabalho pertence a uma função de cada vez. A migração de capacidade para a mesma região é simples. A migração entre regiões é possível, mas tem de remover e recriar a maioria dos itens Fabric, incluindo casas de lago, armazéns, cadernos e pipelines. Portanto, prefere migração na mesma região.
Nível de item. Os espaços de trabalho contêm itens Fabric como casas de lago, armazéns, cadernos, pipelines, modelos semânticos, relatórios e dashboards. Os itens herdam permissões de espaço de trabalho por defeito. Os papéis de segurança Microsoft OneLake fornecem controlo de acesso granular ao nível da tabela, pasta, coluna e linha, mas aplicam-se apenas a utilizadores no papel Visualizador. Administradores, membros e colaboradores do espaço de trabalho prescindem dos papéis de segurança da OneLake.
As seguintes restrições de licenciamento e tipo de espaço de trabalho determinam frequentemente qual o padrão de implementação mais prático:
Novos espaços de trabalho começam com capacidade partilhada, a menos que os realoquem. Cada inquilino tem uma capacidade partilhada que aloja os Meus Espaços de Trabalho e pode alojar espaços de trabalho Power BI Pro ou Premium Per User (PPU). Para implementar um padrão de implementação Fabric governado para cargas de trabalho de produção, normalmente é necessário reatribuir os espaços de trabalho a uma capacidade dedicada de Fabric no tenant.
A PPU não substitui a capacidade do Fabric. O PPU oferece funcionalidades Power BI Premium por utilizador, mas não inclui capacidade Fabric. Para criar ou executar itens não Power BI Fabric como casas de lago, armazéns e cadernos, é necessário uma capacidade F.
O tipo de espaço de trabalho influencia o que o padrão pode alojar. Os padrões de implementação do Fabric neste artigo assumem espaços de trabalho Fabric apoiados por SKU F. Os SKUs A e EM suportam apenas itens Power BI, pelo que não podem suportar padrões de implementação Fabric de ponta a ponta.
O licenciamento do visualizador Power BI pode alterar o custo de um padrão. Em F64 e capacidades maiores, os utilizadores com a função Visualizador podem aceder a conteúdos do Power BI com uma licença livre. Em capacidades mais pequenas, os consumidores de Power BI precisam de uma licença Pro, PPU ou de teste. Este limiar pode reduzir a relação custo-benefício de um padrão centralizado para grandes populações de leitores.
A autoria e partilha do Power BI requer pelo menos um utilizador Pro ou PPU. Mesmo que um espaço de trabalho utilize capacidade Fabric, as organizações precisam de utilizadores com licenças Pro ou PPU para criar e partilhar itens do Power BI.
Componentes
Microsoft 365 cliente: Uma identidade e barreira administrativa para a sua organização. Aloja o Microsoft Entra ID (anteriormente Azure Active Directory) para autenticação e autorização.
Capacidade de Fabric: Um recurso de computação e faturação utilizado numa região específica da Azure, por exemplo, Este dos EUA ou Oeste da Europa. Para reduzir custos, pode pausar as capacidades quando não estiver em uso.
Fabric workspace: Um contentor de colaboração para Fabric itens. Suporta controlo de acesso baseado em funções (RBAC), integração com Git e pipelines de implementação. Para agrupamento lógico, pode atribuir espaços de trabalho a domínios Fabric.
Fabric itens: Artefactos de dados e análise como lakehouses, data warehouses, cadernos, pipelines, fluxos de dados, modelos semânticos, relatórios e dashboards.
"Fabric domains": Agrupamentos lógicos que organizam espaços de trabalho por unidade de negócio ou área temática. Os domínios suportam a governação delegada e aparecem no catálogo OneLake para descoberta e supervisão.
OneLake: Um data lake unificado e hierárquico onde os inquilinos contêm espaços de trabalho, que contêm itens. O Fabric armazena dados no OneLake. O OneLake suporta APIs do Azure Data Lake Storage, atalhos para armazenamento externo e integração com ferramentas do Data Lake Storage, como Azure Storage Explorer e AzCopy.
OneLake : Uma interface centralizada para encontrar, governar e proteger dados Fabric em todo o tenant. Os utilizadores podem aceder ao catálogo utilizando ferramentas como Microsoft Teams, Excel e Microsoft Copilot Studio.
Compreender os níveis de implementação do Fabric
A estrutura, os objetivos, os requisitos de segurança, a escala, o modelo de governação e o ciclo de vida da aplicação da sua organização influenciam as decisões em cada nível de implementação. Para mais informações sobre cada nível, veja Hierarquia de quatro níveis.
As capacidades controlam a residência dos dados e a distribuição geográfica. Organizações que operam em múltiplas localizações geográficas podem usar capacidades em diferentes regiões do Azure para controlar onde os dados são armazenados. Cada capacidade está ligada a uma região específica do Azure, que suporta implantações em múltiplas regiões geográficas. Para apoiar a governação centralizada, os domínios Fabric podem agrupar espaços de trabalho e as suas capacidades associadas entre regiões.
Os espaços de trabalho servem como o principal limite de governação e segurança. Cada espaço de trabalho define controlo de acesso através de quatro funções, suporta controlo de versões através da integração com Git e serve como escopo para pipelines de implementação. Para centralizar a colaboração e a descoberta de conteúdos, utilize o catálogo OneLake para implementar uma experiência unificada de descoberta e governação sobre os dados OneLake do inquilino. Os utilizadores podem encontrar e interagir com conteúdos de ferramentas como Teams e Excel através deste catálogo.
Cada nível influencia as escolhas do ciclo de vida da aplicação. Funcionalidades como pipelines de implementação e gestão do ciclo de vida não estão disponíveis em padrões de espaço de trabalho único porque requerem espaços de trabalho separados. Organizações que utilizam domínios para agrupar espaços de trabalho podem delegar administração ao nível do domínio sem privilégios de administrador de inquilino, o que afeta a forma como as equipas gerem os lançamentos e a governação entre unidades de negócio.
Padrões comuns em todas as implementações
Todos os padrões de implementação do Fabric partilham as seguintes características fundamentais:
Espaços de trabalho como limites para escala, governação e segurança. Os padrões de implementação utilizam os espaços de trabalho Fabric como unidade principal para organização de itens, permissões e âmbito de funcionalidades DevOps. Independentemente do padrão escolhido, os espaços de trabalho definem a fronteira para colaboração e controlo de acessos.
Domínios de Fabric para delegação entre múltiplos espaços de trabalho e unidades de negócio. Use domínios Fabric para delegação. Pode gerir múltiplos espaços de trabalho que possam pertencer à mesma unidade de negócio, ou gerir dados que pertencem a um domínio empresarial e abrangem mais do que um espaço de trabalho. Para gerir e governar dados ao nível do domínio, pode ajustar as definições ao nível do locatário e usar uma configuração específica do domínio para essas definições.
Capacidades para escalabilidade computacional com capacidade dedicada por espaço de trabalho para garantias de desempenho. Se precisar de atingir níveis de desempenho específicos, utilize capacidades do Fabric para escalar recursos de computação e oferecer capacidades dedicadas por cada espaço de trabalho. Organizações que necessitam 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 garantida de UC.
Catálogo OneLake para descoberta de ativos e o separador Secure para políticas de segurança de dados. Para promover a descoberta e a utilização de ativos de dados em todo o seu locatário, utilize o catálogo OneLake. Para visualizar, monitorizar e configurar funções de segurança em espaços de trabalho e itens, utilize o separador Seguro no catálogo OneLake.
Extensão para funcionalidades da Microsoft Cloud se as funcionalidades nativas do Fabric não estiverem disponíveis. Se uma funcionalidade nativa não estiver disponível, os padrões de implementação podem estender-se para usar funcionalidades equivalentes da Microsoft Cloud, como o Azure e o Microsoft 365. Por exemplo, as organizações podem usar Azure Pipelines ou GitHub Actions para integração contínua e orquestração de entrega contínua (CI/CD) se os pipelines de implementação do Fabric não cobrirem os requisitos de automação entre espaços de trabalho. As organizações também podem usar Microsoft Purview para a governação de dados a nível empresarial que abrange fontes de dados Fabric e não Fabric.
Selecione um padrão de implementação
Os cenários seguintes descrevem requisitos comuns de negócio e os padrões de implementação que os abordam. Use estes cenários para ajudar a identificar o padrão que melhor se adequa à sua organização.
Cenário 1: Tempo de lançamento no mercado mais rápido com colaboração entre equipas. Se a sua organização quiser um tempo de lançamento no mercado mais rápido, colaboração entre equipas e menores restrições ao uso de dados, pode implementar um padrão de implementação monolítico . Neste cenário, a sua organização opera e gere um único espaço de trabalho.
Cenário 2: Ambientes de equipa isolados com gestão central de infraestruturas. Se a sua organização quiser fornecer ambientes de equipa isolados e uma equipa central de gestão de infraestrutura, pode implementar múltiplos espaços de trabalho que utilizam uma capacidade partilhada ou capacidades separadas. Este cenário também se adequa a organizações que pretendem implementar uma arquitetura de malha de dados.
Use o Padrão 2: Múltiplos espaços de trabalho, capacidade única ou Padrão 3: Múltiplos espaços de trabalho, capacidades separadas.
Cenário 3: Autonomia total das unidades de negócio sobre as plataformas de dados. Se a sua organização quiser um modelo totalmente descentralizado que dê às unidades de negócio ou equipas liberdade para controlar e gerir as suas próprias plataformas de dados, pode implementar um modelo de implementação que utilize espaços de trabalho separados com capacidade dedicada ou múltiplos inquilinos Fabric.
Use Padrão 3: Múltiplos espaços de trabalho, capacidades separadas ou Padrão 4: Múltiplos locatários Fabric.
Cenário 4: Abordagem híbrida que combina múltiplos padrões. Se a sua organização quiser uma solução híbrida que utilize múltiplos padrões para satisfazer os seus requisitos, pode implementar uma abordagem híbrida. Por exemplo, pode configurar um único espaço de trabalho para unidades de negócio específicas, como num padrão de implementação monolítico, e espaços de trabalho dedicados separados e capacidades separadas para outras unidades de negócio.
Padrão 1: Implantação monolítica
Neste padrão de implementação, aloca um espaço de trabalho para todos os casos de uso. Todas as unidades de negócio trabalham no mesmo espaço de trabalho.
As seguintes características aplicam-se a este padrão:
Os artigos de tecido partilham a mesma capacidade. O tempo que uma consulta ou tarefa demora varia, dependendo das outras cargas de trabalho que utilizam a mesma capacidade.
O máximo de CUs do workspace limita-se ao maior SKU F possível. Para experiências em engenharia de dados e ciência de dados, os administradores de capacidade podem configurar a Autoscale Billing para o Apache Spark para mover a capacidade de computação que o Spark Engine utiliza para fora das CUs alocadas.
As funcionalidades que estão relacionadas com um espaço de trabalho aplicam-se a todas as unidades de negócio que partilham o espaço de trabalho.
Todos os itens e dados do espaço de trabalho estão em uma região. Não se pode usar este padrão para cenários com múltiplos geográficos.
Funcionalidades que dependem de múltiplos espaços de trabalho não estão disponíveis, como, por exemplo, pipelines de implementação e gestão do ciclo de vida.
Aplicam-se limitações de espaço de trabalho único.
Aplicam-se limitações específicas de capacidade do SKU.
Quando utilizar este padrão
Pode implementar este padrão de implementação se:
A sua organização não tem requisitos de engenharia complexos, tem uma base de utilizadores pequena ou modelos semânticos reduzidos.
Sua organização opera em uma única região.
Você não está preocupado principalmente com a separação organizacional entre unidades de negócios.
Sua organização não precisa de recursos com escopo de espaço de trabalho, como o compartilhamento de repositórios de código com o Git.
Você deseja implementar uma arquitetura de dados em camadas do tipo lakehouse. Se a sua organização usar um único espaço de trabalho, pode criar casas de lago separadas dentro do espaço de trabalho para gerir camadas de bronze, prata e ouro.
As unidades de negócio da sua organização partilham funções, e pode ter as mesmas permissões ao nível do espaço de trabalho para os utilizadores nesse espaço. Por exemplo, se vários utilizadores de diferentes unidades de negócio forem administradores de um único espaço de trabalho, têm os mesmos direitos sobre todos os itens do espaço de trabalho.
A sua organização tolera tempos variáveis de conclusão de trabalho. Se uma capacidade for partilhada, os utilizadores podem executar consultas a qualquer momento. O número de CUs disponíveis para executar uma tarefa depende das outras consultas que ocorrem na capacidade de processamento, o que pode resultar em tempos variáveis de conclusão da tarefa.
A sua organização pode satisfazer os requisitos do seu negócio utilizando uma única capacidade Fabric.
Considerações sobre a área de design
A tabela seguinte apresenta considerações que podem influenciar a sua decisão de usar este padrão de implantação.
| Aspeto | Considerações |
|---|---|
| Governação | São necessários mandatos e restrições de governação mais baixos na plataforma. Adequa-se a organizações mais pequenas que preferem um tempo de lançamento no mercado mais rápido. Podem surgir desafios se os requisitos de governação se tornarem mais complexos. |
| Segurança: Plano de dados | Os dados podem ser partilhados entre equipas, por isso não precisas de restringir dados entre equipas. As equipas têm direitos de propriedade sobre modelos semânticos. Eles podem ler, editar e modificar dados no OneLake. |
| Segurança: Plano de controlo | Todos os utilizadores podem colaborar no mesmo espaço de trabalho. Não há restrições sobre os artigos. Todos os usuários podem ler e editar todos os itens. |
| Administração | Custos administrativos mais baixos. Não é preciso monitorizar o acesso e a utilização por equipa. Monitorização menos rigorosa da carga de trabalho do Fabric entre equipas. |
| DevOps | Um lançamento único para toda a plataforma. Pipelines de lançamento mais simples. |
| Usabilidade: Administradores | Menos itens para gerir. Não há necessidade de outra configuração ou de lidar com pedidos das equipas para novas capacidades ou espaços de trabalho. Os administradores de capacidade podem ser administradores de inquilinos, por isso não precisa de criar ou gerir outros grupos ou equipas. |
| Usabilidade: Outras funções | A partilha de espaço de trabalho é aceitável. A colaboração entre utilizadores é incentivada. |
| Desempenho | O isolamento da carga de trabalho não é obrigatório. Não tem de cumprir objetivos rigorosos de nível de serviço baseados no desempenho (SLOs). A limitação é possível quando as cargas de trabalho competem pelas mesmas unidades de computação partilhadas. Este padrão adequa-se a organizações com baixa concorrência ou cargas de trabalho previsíveis. |
| Gestão de faturação e custos | Uma equipa pode tratar dos custos. Não é preciso fazer chargeback para equipas diferentes. |
Padrão 2: Múltiplos espaços de trabalho, capacidade única
Neste padrão de implementação, aloca múltiplos espaços de trabalho numa única capacidade partilhada. Os espaços de trabalho partilham essa capacidade, pelo que cargas de trabalho concorrentes podem afetar o desempenho dos trabalhos e das consultas interativas.
As seguintes características aplicam-se a este padrão:
Os artigos de tecido partilham a mesma capacidade. O tempo que uma consulta ou tarefa demora varia, dependendo das outras cargas de trabalho que utilizam a mesma capacidade.
O máximo de CUs do workspace limita-se ao maior SKU F possível. Para experiências em engenharia de dados e ciência de dados, os administradores de capacidade podem configurar a Faturação Autoscale do Spark para mover a capacidade de computação usada pelo Spark Engine para além das CUs alocadas.
As funcionalidades com escopo para um espaço de trabalho aplicam-se a todas as unidades de negócios que compartilham esse espaço de trabalho.
Todos os itens e dados do espaço de trabalho estão em uma região. Não se pode usar este padrão para cenários com múltiplos geográficos.
Pode usar funcionalidades DevOps que exijam espaços de trabalho separados, como pipelines de implementação e gestão do ciclo de vida.
Aplicam-se limitações de espaço de trabalho único.
Aplicam-se limitações específicas de capacidade do SKU.
Quando utilizar este padrão
Pode implementar este padrão de implementação se:
Quer uma arquitetura hub-spoke que centralize alguns aspetos da operação de ambiente analítico e descentralize outros.
Queres uma descentralização operacional e de gestão variável. Por exemplo, a sua organização pode alojar as camadas de bronze e prata de uma arquitetura de medalhão em um espaço de trabalho e a camada dourada em outro espaço separado. Esta separação reflete frequentemente responsabilidades operacionais distintas, por exemplo, quando uma equipa gere as camadas bronze e prata e outra equipa gere a camada ouro.
Não estás principalmente preocupado com a gestão de desempenho e o isolamento da carga de trabalho.
A sua organização não precisa de distribuir cargas de trabalho em diferentes regiões geográficas. Todos os dados devem residir numa única região.
A sua organização pode precisar de espaços de trabalho separados porque:
Os membros da equipa responsável pelas cargas de trabalho estão em diferentes locais de trabalho.
Você deseja criar espaços de trabalho separados para cada tipo de carga de trabalho. Por exemplo, pode criar um espaço de trabalho para a ingestão de dados, como 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. Este design funciona bem se equipas separadas forem responsáveis por cada carga de trabalho.
Quer implementar uma arquitetura de malha de dados que agrupe um ou mais espaços de trabalho juntos num domínio Fabric.
A sua organização pode implementar espaços de trabalho separados com base na classificação dos dados.
Considerações sobre a área de design
A tabela seguinte apresenta considerações que podem influenciar a sua decisão de usar este padrão de implantação.
| Aspeto | Considerações |
|---|---|
| Governação | Mandatos e restrições de governação moderada são necessários na plataforma. A organização necessita de um controlo mais detalhado para governar departamentos, equipas e funções. |
| Segurança: Plano de dados | São obrigatórias restrições de dados, e é necessário fornecer proteção de dados com base nos controlos de acesso para departamentos, equipas e membros. |
| Segurança: Plano de controlo | Para evitar corrupção acidental ou ações de utilizadores maliciosos, pode ser necessário fornecer acesso controlado aos itens Fabric por função. |
| Administração | Não precisas de gerir capacidades porque é um modelo de capacidade única. Pode usar espaços de trabalho para isolar departamentos, equipas e utilizadores. |
| DevOps | Podes fazer lançamentos independentes por departamento, equipa ou carga de trabalho. É mais fácil cumprir os requisitos de desenvolvimento, teste, aceitação e produção (DTAP) para equipas se configurares múltiplos espaços de trabalho para responder a cada ambiente de lançamento. |
| Usabilidade: Administradores | Não precisas de alocar múltiplas capacidades. Os administradores de inquilinos normalmente administram a capacidade, por isso não precisa de gerir outros grupos ou equipas. |
| Usabilidade: Outras funções | Estão disponíveis espaços de trabalho para cada camada de medalhões. Os itens Fabric são isolados por cada espaço de trabalho, o que ajuda a prevenir corrupção acidental. |
| Desempenho | Não precisas de respeitar SLOs de desempenho rigorosos. A limitação do fluxo é aceitável durante os períodos de maior afluência. |
| Gestão de faturação e custos | Não tens um requisito específico de estorno por equipa. Uma equipa central é responsável pelos custos. As equipas de infraestrutura são proprietárias das capacidades da Fabric na organização. |
Padrão 3: Múltiplos espaços de trabalho, capacidades separadas
Neste padrão de implementação, aloca múltiplos espaços de trabalho em capacidades Fabric separadas, o que proporciona governança e isolamento de desempenho entre diferentes unidades de negócios.
As seguintes características aplicam-se a este padrão:
O maior SKU F ou P possível que esteja ligado a um workspace determina o número máximo de CUs que um workspace pode usar.
Espaços de trabalho separados criam descentralização organizacional e de gestão.
As organizações podem expandir-se para além de uma única região utilizando capacidades e espaços de trabalho em diferentes regiões geográficas.
Pode usar todas as capacidades do Fabric porque as unidades de negócio podem ter múltiplos espaços de trabalho em capacidades separadas e agrupados através de domínios Fabric.
As limitações do espaço de trabalho para um único espaço de trabalho aplicam-se, mas pode criar novos espaços de trabalho para ultrapassar esses limites.
Aplicam-se limitações específicas de capacidade SKU, mas podes escalar CUs usando capacidades separadas.
Pode usar o catálogo OneLake para descobrir Fabric artigos e o seu estado de certificação.
Os domínios podem agrupar espaços de trabalho para que uma única unidade de negócios possa operar e gerenciar vários espaços de trabalho.
Os atalhos OneLake eliminam cópias físicas dos dados para reduzir o movimento de dados. Os atalhos do OneLake também oferecem acesso controlado entre espaços de trabalho através do OneLake e não transferem a propriedade dos dados subjacentes.
Quando utilizar este padrão
Pode implementar este padrão de implementação se:
Sua organização deseja implantar estruturas de arquitetura, como malha de dados ou tecido de dados.
Você deseja priorizar a flexibilidade na forma como estrutura capacidades e espaços de trabalho.
Você opera em diferentes regiões geográficas. Neste caso, crie capacidades e espaços de trabalho separados para avançar para um padrão de implementação multicapacidade e multiambiente de trabalho.
Operam em grande escala e têm requisitos para escalar além dos limites de um SKU de capacidade única ou de um único espaço de trabalho.
Tens cargas de trabalho que têm sempre de terminar dentro de um prazo específico ou que precisam de cumprir SLOs baseados no desempenho. Podes configurar um espaço de trabalho separado com capacidade do Fabric para satisfazer os SLOs dessas cargas de trabalho.
Considerações sobre a área de design
A tabela seguinte apresenta considerações que podem influenciar a sua decisão de usar este padrão de implantação.
| Aspeto | Considerações |
|---|---|
| Governação | Tens um elevado grau de governação e gestão, e precisas de independência em cada espaço de trabalho. Pode gerir a utilização por departamento ou unidade de negócio. Pode cumprir os requisitos de residência de dados. Pode isolar dados com base nos requisitos regulamentares. |
| Segurança: Plano de dados | Pode controlar o acesso aos dados ao nível do departamento, equipa ou utilizador. Podes isolar dados com base no tipo de item Fabric. |
| Segurança: Plano de controlo | Pode fornecer acesso controlado aos itens do Fabric por função para evitar corrupção acidental ou ações de utilizadores maliciosos. |
| Administração | Restringe as capacidades granulares dos administradores a departamentos, equipas ou utilizadores. Tens acesso a requisitos detalhados de monitorização sobre a utilização ou padrões das cargas de trabalho. |
| DevOps | Podes isolar ambientes DTAP usando diferentes capacidades. Os lançamentos independentes dependem do departamento, equipa ou carga de trabalho. |
| Usabilidade: Administradores | Tens uma visibilidade detalhada da utilização por departamento ou equipa. Delegas direitos de capacidade por departamento ou equipa para suportar escalabilidade e configuração granular. |
| Usabilidade: Outras funções | Os espaços de trabalho estão disponíveis em cada camada de medallion e em função da capacidade. Os itens Fabric são isolados por cada espaço de trabalho, o que ajuda a prevenir corrupção acidental. Tens mais opções para evitar a limitação causada por picos na capacidade partilhada. |
| Desempenho | Os requisitos de desempenho são elevados e as cargas de trabalho precisam atender a SLOs mais exigentes. Tens flexibilidade para aumentar as cargas de trabalho individuais por departamento ou equipa. |
| Gestão de faturação e custos | Pode cumprir os requisitos de cobrança cruzada utilizando capacidades dedicadas para cada entidade organizacional, como departamentos, equipas ou projetos. Pode delegar a gestão de custos às respetivas equipas para gerir. |
Padrão 4: Múltiplos inquilinos Fabric
Neste padrão de implementação, todas as instâncias do Fabric são entidades separadas no que diz respeito à governação, gestão, administração, escala e armazenamento.
As seguintes características aplicam-se a este padrão:
Os recursos do inquilino são rigorosamente segregados.
Os planos de gestão entre inquilinos são separados.
Os inquilinos são entidades separadas, cada uma com os seus próprios processos de governação e gestão, e cada uma administrada de forma independente.
Podes usar pipelines de dados ou capacidades de engenharia de dados para partilhar ou aceder a dados entre tenants do Fabric.
Quando utilizar este padrão
Pode implementar este padrão de implementação se:
A sua organização tem múltiplos locatários no Fabric devido a uma aquisição empresarial.
A sua organização quer configurar um tenant Fabric especificamente para uma unidade de negócio ou subsidiária menor.
Avaliar plataformas alternativas
Se os requisitos da sua organização não estiverem alinhados com os modelos de implementação baseados em Fabric, considere as seguintes alternativas limitadas:
Azure Data Factory com Data Lake Storage ou OneLake, incluindo arquiteturas híbridas Data Factory e Fabric
Organizações que necessitam de controlo explícito de orquestração ou modernização faseada podem usar Data Factory para ingestão e orquestração de processos e Data Lake Storage como base de armazenamento. Num modelo híbrido, os pipelines de dados geridos pela Data Factory podem carregar dados no OneLake enquanto o Fabric gere a criação de ativos analíticos de dados. Esta abordagem apoia a adoção incremental do Fabric e preserva padrões de integração estabelecidos.
Data Lake Storage, Azure Databricks e Power BI
Organizações que prefiram uma arquitetura baseada em plataforma como serviço (PaaS) em vez de uma plataforma unificada de software como serviço (SaaS) podem construir um património de dados usando Data Lake Storage para armazenamento, Azure Databricks para engenharia e análise de dados, e Power BI para modelação semântica e relatórios. Esta abordagem oferece máximo controlo e flexibilidade, mas exige um esforço de integração acrescido e aumenta a complexidade operacional e a sobrecarga de governação.
Considerações
Estas considerações implementam os pilares do Well-Architected Framework, que é um conjunto de princípios orientadores que pode usar para melhorar a qualidade de uma carga de trabalho. Para mais informações, consulte o Quadro Well-Architected.
As tabelas por padrão anteriores neste artigo utilizam áreas de design específicas para decisões de implementação do Fabric, como governação, segurança, administração, DevOps, usabilidade, desempenho e faturação. As subsecções seguintes fornecem orientações complementares organizadas por pilar do Well-Architected Framework. Use as tabelas por padrão para comparar padrões. Use estas subsecções para orientações arquitetónicas transversales que se apliquem independentemente do padrão escolhido.
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.
Resiliência regional incorporada. A Fabric oferece resiliência regional incorporada através de zonas de disponibilidade, quando suportado. O Fabric distribui automaticamente recursos por várias zonas sem configuração do cliente. O suporte à zona de disponibilidade varia consoante a região do Azure. Para verificar se a sua região-alvo suporta zonas de disponibilidade para Fabric, veja Fabric disponibilidade regional.
A recuperação de desastres (DR) necessita de adesão e tem certas condições. A recuperação entre regiões está disponível através de uma configuração opcional de recuperação de desastres (DR) na página de definições de capacidade. Ative a definição de capacidade de DR para replicar dados do OneLake em regiões emparelhadas do Azure usando replicação assíncrona.
Importante
Algumas regiões do Azure não estão emparelhadas com regiões que suportam Fabric, o que pode comprometer as capacidades de DR mesmo que os dados sejam replicados. Como a replicação de dados é assíncrona, os dados escritos imediatamente antes de um desastre regional podem perder-se. Para mais informações, consulte Fiabilidade em Fabric.
Os padrões de capacidade única concentram o risco numa única região. Nos padrões 1 e 2, as cargas de trabalho estão numa única região Azure. Se a região sofrer uma interrupção, todos os espaços de trabalho são afetados simultaneamente. Para se proteger contra falhas regionais, configure a definição de capacidade para replicar os dados do OneLake numa região emparelhada. Planeie o tempo de recuperação necessário para restabelecer o serviço na região emparelhada.
Os padrões de múltipla capacidade proporcionam isolamento regional natural. Nos padrões 3 e 4, as capacidades em diferentes regiões significam que uma interrupção regional afeta apenas as capacidades nessa região. As cargas de trabalho noutras regiões continuam a funcionar. Estes padrões apoiam os requisitos de residência de dados e fornecem a base para estratégias regionais ativas-passivas ou ativas-ativas.
A pausa de capacidade afeta a fiabilidade. Se pausar uma capacidade Fabric para reduzir custos, todas as cargas de trabalho dessa capacidade tornam-se indisponíveis. Considere o efeito de fiabilidade antes de pausar uma capacidade que suporta cargas de trabalho em produção.
Os "atalhos OneLake" introduzem dependências externas. Atalhos para fontes de dados externas introduzem uma dependência da disponibilidade dessas fontes. Se a fonte externa não estiver disponível, os itens que dependem de atalhos podem falhar. Monitorize a saúde das fontes externas de dados e planeie uma degradação gradual.
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. O Fabric implementa um modelo de segurança em camadas que abrange os níveis de inquilino, espaço de trabalho e item. A sua escolha do padrão de implementação determina como segmenta os limites de segurança. Padrões de espaço de trabalho único, como o padrão 1, impõem acesso uniforme. Os padrões multiworkspace, como os padrões 2, 3 e 4, suportam limites de segurança por equipa ou por unidade de negócio.
Identidade e acesso
Aplicar políticas de autenticação ao nível do tenant utilizando o Acesso Condicional. Use o Acesso Condicional para aplicar políticas de autenticação ao nível do inquilino, como autenticação multifator, conformidade com dispositivos e restrições baseadas na localização. O Acesso Condicional requer uma licença Microsoft Entra ID P1.
Use funções de espaço de trabalho para controlar o acesso aos itens. Atribua papéis de espaço de trabalho para controlar quem pode criar, editar e consumir itens dentro de um espaço de trabalho. Em padrões multiworkspace, como os padrões 2, 3 e 4, utiliza-se espaços de trabalho separados para impor limites de funções entre unidades de negócio.
Aplique acesso granular ao nível dos dados utilizando funções de segurança OneLake. Utilize os papéis de segurança do OneLake para aplicar controlo de acesso granular ao nível de pasta, tabela, coluna e linha para utilizadores no papel de Visualizador. Administradores, membros e colaboradores do espaço de trabalho ignoram estes papéis.
Segurança de rede
Use links privados para tráfego de entrada. Use links privados para encaminhar o tráfego de entrada pela Microsoft backbone em vez da internet pública. Os links privados ao nível do inquilino aplicam-se a todos os espaços de trabalho. Os links privados ao nível do espaço de trabalho fornecem granularidade por cada espaço de trabalho.
Utilize pontos finais privados geridos para ligações de saída do Spark. Utilize endereços finais privados geridos para proteger as ligações de saída de cargas de trabalho do Spark para fontes de dados protegidas por firewall, como o Data Lake Storage e o Azure SQL Database.
Utilize gateways de dados de rede virtuais quando ligações privadas ao nível do inquilino bloqueiam gateways on-premises. Quando ativas ligações privadas ao nível do inquilino, os gateways de dados on-premises não conseguem registar-se. Use um gateway de dados de rede virtual em vez de pontes que ligam fontes de dados no local ou protegidas por rede virtual.
Proteção de dados
Aplique etiquetas de sensibilidade para classificação de dados de ponta a ponta. Para a classificação e proteção de dados, aplicar rótulos de sensibilidade de Microsoft Purview Information Protection aos dados que fluem no Fabric. Os rótulos seguem os dados desde a fonte até ao relatório.
Use registos de auditoria e ferramentas de conformidade para a aplicação das políticas. Para detetar e responder a violações de políticas, reveja os registos de auditoria e utilize o Microsoft Purview Compliance Manager.
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 projeto para Otimização de custos.
Modelar custos antes de implementar. Os padrões de implementação afetam a sua estrutura de custos. Modele os custos para o seu cenário usando Fabric preços e o estimador de capacidade Fabric.
Dimensione adequadamente o seu SKU de capacidade. Dimensiona corretamente o seu SKU F com base na carga de trabalho. Começa com um SKU mais pequeno e aumenta conforme necessário. Monitorize o consumo e identifique capacidades sobre-provisionadas ou sub-provisionadas utilizando a aplicação Capacity Metrics Fabric.
Automatizar a pausa de capacidade para ambientes não produtivos. Reduza custos pausando as capacidades das SKUs F quando não estão a ser utilizadas. Em ambientes de desenvolvimento/teste, pausa as capacidades fora do horário de trabalho. Pausar torna todas as cargas de trabalho indisponíveis, por isso considere a automação através das APIs do Azure Resource Manager Fabric ou de pipelines programados.
Padrões de capacidade única, como os padrões 1 e 2, centralizam a faturação mas limitam o estorno. Uma capacidade implica uma única fatura. A gestão de custos é centralizada, mas o chargeback a unidades de negócio individuais não é possível porque todas as cargas de trabalho partilham a mesma capacidade.
Padrões multicapacidade, como os padrões 3 e 4, suportam chargeback por equipa. Cada capacidade gera o seu próprio contador de faturação Azure. Pode cobrar custos à unidade de negócio responsável por cada capacidade. Podes redimensionar ou pausar cada capacidade de forma independente, consoante a carga de trabalho que suporta.
Gerir os custos de armazenamento do OneLake de forma independente. O armazenamento OneLake é faturado a uma tarifa pay-as-you-go por GB, e não consome CUs. Apague regularmente dados não utilizados, incluindo dados apagados suavemente, e monitorize o armazenamento através da aplicação Fabric Capacity Metrics.
Monitorizar a computação do Spark separadamente. Para cargas de trabalho de engenharia de dados, pode usar pools Spark separados para deslocar a computação para fora do orçamento de CU. Para evitar custos inesperados, monitorize o consumo de CUs da Spark.
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.
Use pipelines de distribuição para promoção em fases. Use os pipelines de implementação do Fabric para promover conteúdo através das fases de desenvolvimento/teste e produção. As pipelines de implementação requerem espaços de trabalho separados, por essa razão 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 etapa DTAP. A estratégia de capacidade varia consoante o padrão.
No padrão 2, todos os espaços de trabalho DTAP partilham a mesma capacidade, o que é rentável, mas não proporciona isolamento de desempenho entre ambientes.
No padrão 3, podes usar capacidades dedicadas por ambiente para isolamento total, ou podes equilibrar custo e isolamento usando uma capacidade partilhada para desenvolvimento/teste com uma capacidade de produção separada.
Planeie ambientes de pré-produção como uma decisão de design ao nível do espaço de trabalho. O Padrão 1 não fornece uma separação de pré-produção, pois o desenvolvimento/teste ocorre no espaço de trabalho de produção. O Padrão 2 suporta espaços de trabalho separados de desenvolvimento, teste e produção numa única capacidade partilhada, o que favorece validação funcional mas não testes de desempenho ou resiliência semelhantes aos de produção. O Padrão 3 suporta validação pré-produção semelhante à produção real através de espaços de trabalho alinhados ao ambiente de produção com isolamento ao nível de capacidade. O Padrão 4 envolve inquilinos separados em vez de decisões ao nível do espaço de trabalho. Cada locatário pode escolher independentemente a sua própria topologia de ambiente e não tem de corresponder a outros locatários.
Ligue espaços de trabalho a repositórios Git para controlo de versões. Nos padrões 2 e 3, espaços de trabalho separados por equipa ou carga de trabalho alinham-se com as estratégias padrão de ramificação. No padrão 1, todas as equipas partilham um único repositório, o que pode criar conflito de mesclagem.
Monitorizar a capacidade e a saúde da carga de trabalho. Utilize a aplicação Fabric Capacity Metrics para monitorizar o consumo de capacidade, como o uso, a limitação e os excessos. Pode aceder a telemetria detalhada sobre cargas de trabalho individuais utilizando monitorização do espaço de trabalho. Nos padrões multicapacidade, como os padrões 3 e 4, pode delegar a monitorização à equipa responsável por cada capacidade.
Delegar a administração através dos domínios Fabric. Nos padrões 2 e 3, delegue as configurações de inquilino e a gestão de ambientes de trabalho a administradores ao nível do domínio sem privilégios de administrador de inquilino, utilizando domínios Fabric. O Padrão 1 não pode usar domínios porque todos os itens estão num único espaço de trabalho.
Gerir capacidades utilizando infraestrutura como código (IaC). Crie e gere capacidades Fabric usando Bicep ou Terraform. Armazenar definições de infraestrutura no controlo de versões juntamente com o código da aplicação.
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.
Compreenda o dimensionamento da capacidade e o comportamento de controlo de fluxo. Cada capacidade de unidade tem uma alocação fixa de CU determinada pelo seu SKU. Se a procura exceder as CUs disponíveis, o Fabric aplica regulação e coloca os pedidos em fila de espera. Monitorize os eventos de limitação usando a aplicação Fabric Capacity Metrics e, quando necessário, amplie o SKU ou distribua as cargas de trabalho entre várias capacidades.
Isole cargas de trabalho sensíveis ao desempenho numa capacidade dedicada. Nos padrões 1 e 2, todas as cargas de trabalho competem pelas mesmas unidades de computação (CUs). Um pipeline de consultas ou de dados dispendioso pode degradar o desempenho da consulta interativa para outros utilizadores. Nos padrões 3 e 4, pode isolar cargas de trabalho sensíveis ao desempenho numa capacidade dedicada com uma alocação garantida de unidades de computação.
Configurar clusters Spark para cargas de trabalho de engenharia de dados. Para cargas de trabalho de engenharia de dados, use pools Spark personalizados para controlar o número mínimo e máximo de nós e suportar o autoscaling. Redes virtuais geridas desativam pools iniciais, ou clusters partilhados pré-aquecidos, o que aumenta o tempo de início da sessão de segundos para entre 3 e 5 minutos.
Coloque as capacidades perto dos produtores de dados e consumidores. No padrão 3, pode usar capacidades em regiões próximas de produtores ou consumidores de dados, o que reduz a latência entre regiões. Os atalhos OneLake podem referenciar dados noutras regiões, mas as leituras entre regiões têm custos de latência e tráfego de saída.
Aplique técnicas de otimização específicas para a carga de trabalho. Melhore o desempenho da varredura utilizando Ordenação Z e Ordenação em V para lakehouses. Para armazéns, otimize os padrões de consulta para ler lotes mais pequenos. Reduza a carga de capacidade em comparação com o modo de importação usando o modo Direct Lake para relatórios de Power BI.
Matriz de capacidades
As tabelas seguintes resumem as principais diferenças nas capacidades de cada padrão.
Governação e administração
| Capacidade | Padrão 1: Monolítico | Padrão 2: Múltiplos espaços de trabalho, capacidade única | Padrão 3: Múltiplos espaços de trabalho, capacidades separadas | Padrão 4: Múltiplos inquilinos |
|---|---|---|---|---|
| Complexidade da governação | Baixo | Medium | Alto | Alto |
| Monitorização de utilização por departamento | No | Limitado 1 | Sim | Sim |
| Delegação baseada em domínio | No | Sim | Sim | N/A 2 |
| Delegação de administrador granular | No | Limitado 1 | Sim | Sim |
| Conformidade com residência de dados | Apenas uma região | Apenas uma região | Multirregional | Multirregional |
| Isolamento de dados regulatórios | No | Limitado 1 | Sim | Sim |
1 Os espaços de trabalho proporcionam algum isolamento, mas todos partilham uma única capacidade, o que limita a granularidade do acompanhamento e administração dos usos.
2 O Padrão 4 usa inquilinos separados em vez de domínios. Cada inquilino tem o 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: Múltiplos espaços de trabalho, capacidades separadas | Padrão 4: Múltiplos inquilinos |
|---|---|---|---|---|
| Isolamento do plano de dados entre equipas | No | Sim | Sim | Sim |
| Isolamento do plano de controlo (acesso ao nível do item) | No | Sim | Sim | Sim |
| Limites dos papéis do espaço de trabalho entre unidades de negócio | No | Sim | Sim | Sim |
| Segregação de segurança ao nível do inquilino | N/A | N/A | N/A | Sim |
DevOps e gestão do ciclo de vida
| Capacidade | Padrão 1: Monolítico | Padrão 2: Múltiplos espaços de trabalho, capacidade única | Padrão 3: Múltiplos espaços de trabalho, capacidades separadas | Padrão 4: Múltiplos inquilinos |
|---|---|---|---|---|
| Linhas de implementação | N.o 3 | Sim | Sim | Sim |
| Integração com Git | Limitado a 4 | Sim | Sim | Sim |
| Lançamentos independentes por equipa | No | Sim | Sim | Sim |
| Isolamento do ambiente DTAP | No | Sim | Sim (em todas as capacidades) | Sim (entre inquilinos) |
3 Os canais de implantação requerem espaços de trabalho separados, que não estão disponíveis num modelo monolítico de espaço de trabalho único.
4 A integração Git está disponível, mas todas as equipas partilham um único repositório, o que pode criar conflitos de fusão.
Desempenho e dimensionamento
| Capacidade | Padrão 1: Monolítico | Padrão 2: Múltiplos espaços de trabalho, capacidade única | Padrão 3: Múltiplos espaços de trabalho, capacidades separadas | Padrão 4: Múltiplos inquilinos |
|---|---|---|---|---|
| Isolamento de cargas de trabalho para otimizar desempenho | No | No | Sim | Sim |
| Implantação multigeográfica | No | No | Sim | Sim |
| Escala para além dos limites de um único SKU | No | No | Sim | Sim |
| Garantias de desempenho SLO | No | No | Sim | Sim |
| Risco de limitação devido à capacidade partilhada | Alto | Alto | Baixo 5 | Baixo |
5 O risco de limitação é baixo se as cargas de trabalho estiverem em capacidades dedicadas, mas ainda pode ocorrer dentro de uma única capacidade se a procura exceder as CUs disponíveis.
Faturação e gestão de custos
| Capacidade | Padrão 1: Monolítico | Padrão 2: Múltiplos espaços de trabalho, capacidade única | Padrão 3: Múltiplos espaços de trabalho, capacidades separadas | Padrão 4: Múltiplos inquilinos |
|---|---|---|---|---|
| Faturação centralizada | Sim | Sim | Nº 6 | No |
| Estorno por equipa | No | No | Sim | Sim |
| Pausa independente da capacidade | N/A (capacidade individual) | N/A (capacidade individual) | Sim | Sim |
| Delegação de custos às equipas | No | No | Sim | Sim |
6 Cada capacidade gera o seu próprio contador de faturação, pelo que a faturação é distribuída entre capacidades em vez de centralizada.
Contribuidores
A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.
Autor principal:
- Amanjeet Singh | Gestor Principal de Programas
Outros contribuidores:
- Lorrin Ferdinand | Consultor Principal
- Holly Kelly | Gerente de Programa Principal
- Gabi Muenster | Gerente de Programa Senior
- Sarah Sasidharan | Gestor Sénior de Programas
Para ver perfis de LinkedIn não públicos, inicie sessão no LinkedIn.
Passos seguintes
- Conceitos e licenças do Fabric
- Espaços de Trabalho do Fabric
- Domínios de Fabrico
- O que é OneLake?
- Pipelines de implementação do Fabric
- Fiabilidade em Tecido
- Visão geral de segurança do Fabric