Scegliere un modello di distribuzione Microsoft Fabric

Quando si distribuisce Microsoft Fabric, è necessario decidere come strutturare capacità, aree di lavoro ed elementi nell'organizzazione. Il modello di distribuzione corretto dipende dai requisiti di governance, sicurezza, isolamento delle prestazioni e gestione dei costi. Questa guida aiuta gli architetti e i team della piattaforma a valutare quattro modelli di distribuzione e comprendere le considerazioni e i compromessi per ognuno di essi.

Gerarchia a quattro livelli

Il diagramma seguente illustra la gerarchia a quattro livelli che definisce tutte le distribuzioni Fabric.

Scaricare un file Visio di questa architettura.

La gerarchia di distribuzione passa dal tenant Microsoft 365 fino ai singoli elementi. La scelta del modello di distribuzione determina il modo in cui si usa ogni livello.

• Livello dell'entità. Nella parte superiore è presente il tenant Microsoft 365, che funge da limite di identità e amministrativo per l'organizzazione. Il tenant Fabric esiste all'interno di questo tenant Microsoft 365 e tutte le risorse Fabric si trovano all'interno di questo limite del tenant singolo. Le impostazioni a livello di tenant, tra cui Microsoft Entra Conditional Access, collegamenti privati e etichette di sensibilità, si applicano a tutte le capacità e agli spazi di lavoro.

• Livello di capacità. Configurare almeno una capacità Fabric in un tenant Microsoft 365. Ogni capacità è associata a un'area Azure specifica e ha uno SKU F che determina le risorse di calcolo disponibili misurate in unità di capacità (CU). Le capacità controllano la residenza dei dati e forniscono limiti di fatturazione. Una singola capacità può ospitare più aree di lavoro.

• Livello dell'area di lavoro. Ogni capacità contiene una o più aree di lavoro. Le aree di lavoro sono i contenitori principali per la collaborazione e la governance. Definiscono il controllo di accesso tramite quattro ruoli dell'area di lavoro (Amministratore, Membro, Collaboratore e Visualizzatore), supportano l'integrazione Git per il controllo della versione e fungono da ambito per le pipeline di distribuzione. Un'area di lavoro appartiene a una capacità alla volta. La migrazione della capacità della stessa area è semplice. È possibile eseguire la migrazione tra aree, ma è necessario rimuovere e ricreare la maggior parte degli elementi Fabric, tra cui lakehouse, warehouse, notebook e pipeline. Pertanto, preferire la migrazione nella stessa regione.

• Livello dell'elemento Le aree di lavoro contengono elementi Fabric, ad esempio i data lakehouse, i warehouse, i notebook, le pipeline, i modelli semantici, i report e i dashboard. Per impostazione predefinita, gli elementi ereditano le autorizzazioni dell'area di lavoro. Microsoft i ruoli di sicurezza di OneLake forniscono un controllo di accesso granulare a livello di tabella, cartella, colonna e riga, ma si applicano solo agli utenti nel ruolo Visualizzatore. Gli amministratori, i membri e i collaboratori dell'area di lavoro ignorano i ruoli di sicurezza di OneLake.

I vincoli di licenza e tipo di area di lavoro seguenti spesso determinano quale modello di distribuzione è più pratico:

• Le nuove aree di lavoro iniziano con la capacità condivisa, a meno che non vengano riassegnate. Ogni tenant ha una capacità condivisa che ospita aree di lavoro personali e può ospitare aree di lavoro Power BI Pro o Premium per utente (PPU). Per implementare un modello di distribuzione Fabric regolamentato per i carichi di lavoro di produzione, in genere è necessario riassegnare le aree di lavoro a una capacità di Fabric dedicata nel tenant.

• La PPU non è un sostituto della capacità di Fabric. PPU offre funzionalità Premium di Power BI su base individuale, ma non include capacità Fabric. Per creare o eseguire elementi che non appartengono a Power BI Fabric, come lakehouse, warehouse e notebook, è necessaria una capacità F.

• Il tipo di area di lavoro influisce su ciò che il modello può ospitare. I modelli di distribuzione di Fabric in questo articolo presuppongono che gli spazi di lavoro Fabric siano supportati da SKU F. Gli SKU A e EM supportano solo elementi di Power BI, quindi non possono supportare schemi di distribuzione end-to-end di Fabric.

• Le licenze del visualizzatore di Power BI possono influenzare il costo di uno schema. Nelle capacità F64 e superiori, gli utenti con ruolo di Visualizzatore possono accedere al contenuto di Power BI con una licenza gratuita. Nelle capacità più piccole, i consumatori di Power BI necessitano di una licenza Pro, PPU o di prova. Questa soglia può ridurre l'efficacia dei costi di un modello centralizzato per i grandi lettori.

• La creazione e condivisione in Power BI richiedono almeno un utente con licenza Pro o PPU. Anche se un'area di lavoro usa capacità Fabric, le organizzazioni necessitano di utenti con licenze Pro o PPU per creare e condividere Power BI elementi.

Components

• Microsoft 365 tenant: Un'identità e un limite amministrativo per l'organizzazione. Ospita Microsoft Entra ID (in precedenza Azure Active Directory) per l'autenticazione e l'autorizzazione.

• Fabric capacity: Una risorsa di calcolo e fatturazione usata in un'area Azure specifica, ad esempio Stati Uniti orientali o Europa occidentale. Per ridurre i costi, è possibile sospendere le capacità quando non in uso.

• Fabric workspace: Un contenitore di collaborazione per gli elementi Fabric. Supporta il controllo degli accessi in base al ruolo, l'integrazione git e le pipeline di distribuzione. Per il raggruppamento logico, è possibile assegnare aree di lavoro a domini Fabric.

• Elementi di Fabric: Artefatti di dati e analisi, ad esempio lakehouses, data warehouse, notebook, pipeline, flussi di dati, modelli semantici, report e dashboard.

• Fabric domini: raggruppamenti logici che organizzano le aree di lavoro per business unit o area di interesse. I domini supportano la governance delegata e vengono visualizzati nel catalogo OneLake per l'individuazione e la supervisione.

• OneLake: Un data lake unificato e gerarchico dove i tenant includono aree di lavoro, che a loro volta comprendono elementi. Fabric archivia i dati in OneLake. OneLake supporta API Azure Data Lake Storage, collegamenti all'archiviazione esterna e integrazione con strumenti di Data Lake Storage, ad esempio Azure Storage Explorer e AzCopy.

• catalogo OneLake: Un'interfaccia centralizzata per trovare, governare e proteggere i dati di Fabric su tutto il tenant. Gli utenti possono accedere al catalogo usando strumenti come Microsoft Teams, Excel e Microsoft Copilot Studio.

Comprendere i livelli di distribuzione di Fabric

La struttura, gli obiettivi, i requisiti di sicurezza, la scalabilità, il modello di governance e il ciclo di vita dell'applicazione influenzano le decisioni a ogni livello di distribuzione. Per altre informazioni su ogni livello, vedere Gerarchia a quattro livelli.

• Le capacità controllano la residenza dei dati e la distribuzione geografica. Le organizzazioni che operano in più posizioni geografiche possono usare capacità in aree Azure diverse per controllare dove vengono archiviati i dati. Ogni capacità è associata a un'area di Azure specifica, che supporta distribuzioni geografiche multiple tra aree. Per supportare la governance centralizzata, i domini Fabric possono raggruppare le aree di lavoro e le capacità associate tra regioni.

• Le aree di lavoro fungono da limite primario di governance e sicurezza. Ogni area di lavoro definisce il controllo di accesso tramite quattro ruoli, supporta il controllo della versione tramite l'integrazione Git e funge da ambito per le pipeline di distribuzione. Per centralizzare la collaborazione e l'individuazione dei contenuti, usare il catalogo OneLake per implementare un'esperienza unificata di individuazione e governance sui dati OneLake del tenant. Gli utenti possono trovare e interagire con il contenuto da strumenti come Teams e Excel tramite questo catalogo.

• Ogni livello influenza le scelte del ciclo di vita dell'applicazione. Le funzionalità come le pipeline di distribuzione e la gestione del ciclo di vita non sono disponibili nei modelli a singola area di lavoro perché richiedono aree di lavoro separate. Le organizzazioni che usano domini per raggruppare le aree di lavoro possono delegare l'amministrazione a livello di dominio senza privilegi di amministratore tenant, che influisce sul modo in cui i team gestiscono le versioni e la governance tra le business unit.

Modelli comuni in tutte le distribuzioni

Tutti i modelli di distribuzione Fabric condividono le caratteristiche fondamentali seguenti:

• Aree di lavoro come limiti per scalabilità, governance e sicurezza. I modelli di distribuzione usano le aree di lavoro di Fabric come unità principale per l'organizzazione degli elementi, le autorizzazioni e l'ambito delle funzionalità DevOps. Indipendentemente dal modello scelto, le aree di lavoro definiscono il limite per la collaborazione e il controllo di accesso.

• Domini di Fabric per la delega tra più aree di lavoro e unità aziendali. Usare i domini Fabric per la delega. È possibile gestire più aree di lavoro che potrebbero appartenere alla stessa business unit o gestire i dati appartenenti a un dominio aziendale e si estende su più di un'area di lavoro. Per gestire e gestire i dati a livello di dominio, è possibile modificare le impostazioni a livello di tenant e usare una configurazione specifica del dominio per tali impostazioni.

• Capacità per il ridimensionamento del calcolo con capacità dedicata per area di lavoro per garantire le prestazioni. Se è necessario soddisfare livelli di prestazioni specifici, utilizzare le capacità di Fabric per ridimensionare le risorse di calcolo e offrire capacità dedicate per ciascuna area di lavoro. Le organizzazioni che richiedono l'isolamento del carico di lavoro per i processi con prestazioni sensibili possono assegnare tali aree di lavoro a una capacità separata con un'allocazione CU garantita.

• Catalogo OneLake per l'individuazione degli asset e la scheda Secure per i criteri di sicurezza dei dati. Per promuovere la scoperta e l'uso degli asset di dati all'interno del tuo tenant, usa il catalogo OneLake. Per visualizzare, monitorare e configurare i ruoli di sicurezza tra aree di lavoro ed elementi, usare la scheda Sicurezza nel catalogo di OneLake.

• Estensione delle funzionalità di Microsoft Cloud se le funzionalità native di Fabric non sono disponibili. Se una funzionalità nativa non è disponibile, i modelli di distribuzione possono estendersi per usare funzionalità equivalenti dal Microsoft Cloud, ad esempio Azure e Microsoft 365. Ad esempio, le organizzazioni possono usare Azure Pipelines o GitHub Actions per l'orchestrazione di integrazione continua e recapito continuo (CI/CD) se le pipeline di distribuzione Fabric non coprono i requisiti di automazione tra aree di lavoro. Le organizzazioni possono anche usare Microsoft Purview per la governance dei dati a livello aziendale che si estende su origini dati Fabric e non Fabric.

Selezionare un modello di distribuzione

Gli scenari seguenti descrivono i requisiti aziendali comuni e i modelli di distribuzione che li indirizzano. Usare questi scenari per identificare il modello più adatto all'organizzazione.

• Scenario 1: tempi di commercializzazione più rapidi con la collaborazione tra team. Se l'organizzazione vuole tempi di commercializzazione più rapidi, collaborazione tra team e restrizioni più basse sull'utilizzo dei dati, è possibile implementare un modello di distribuzione monolitico . In questo scenario, l'organizzazione opera in e gestisce una singola area di lavoro.

  Usare il modello 1: distribuzione monolitica.

• Scenari 2: Ambiente di team isolato con gestione centrale dell'infrastruttura. Se l'organizzazione vuole fornire ambienti del team isolati e un team di gestione dell'infrastruttura centrale, è possibile implementare più aree di lavoro che usano una capacità condivisa o capacità separate. Questo scenario è adatto anche alle organizzazioni che vogliono implementare un'architettura mesh di dati.

  Usare il modello 2: più aree di lavoro, capacità singola o modello 3: più aree di lavoro, capacità separate.

• Scenario 3: autonomia completa delle unità aziendali sulle piattaforme dati. Se l'organizzazione vuole un modello completamente decentralizzato che offre alle business unit o ai team la libertà di controllare e gestire le proprie piattaforme dati, è possibile implementare un modello di distribuzione che usa aree di lavoro separate con capacità dedicata o più tenant Fabric.

  Usare Pattern 3: più aree di lavoro, capacità separate o Pattern 4: più tenant Fabric.

• Scenario 4: approccio ibrido che combina più modelli. Se l'organizzazione vuole una soluzione ibrida che usa più modelli per soddisfare i requisiti, è possibile implementare un approccio ibrido. Ad esempio, è possibile configurare una singola area di lavoro per business unit specifiche, ad esempio in un modello di distribuzione monolitica, e separare le aree di lavoro dedicate e le capacità separate per altre business unit.

Modello 1: Distribuzione monolitica

In questo modello di distribuzione si alloca un'area di lavoro per tutti i casi d'uso. Tutte le business unit funzionano all'interno della stessa area di lavoro.

Le caratteristiche seguenti si applicano a questo modello:

• Gli articoli di tessuto condividono la stessa capacità. Il tempo necessario per una query o un processo varia a seconda degli altri carichi di lavoro che usano la stessa capacità.

• Le CPU massime dell'area di lavoro sono limitate allo SKU F più grande possibile. Per le esperienze di data engineering e data science, gli amministratori della capacità possono configurare la fatturazione con scalabilità automatica per Apache Spark per spostare la capacità di calcolo usata dal motore Spark all'esterno delle UNITÀ di calcolo allocate.

• Le funzionalità con ambito di un'area di lavoro si applicano a tutte le business unit che condividono l'area di lavoro.

• Tutti gli elementi e i dati dell'area di lavoro si trovano in un'area. Non è possibile usare questo modello per scenari geografici multipli.

• Le funzionalità che si basano su più aree di lavoro non sono disponibili, ad esempio pipeline di distribuzione e gestione del ciclo di vita.

• Si applicano le limitazioni per l'area di lavoro singola.

• Si applicano limitazioni specifiche della capacità dello SKU.

Quando usare questo modello

È possibile implementare questo modello di distribuzione se:

• L'organizzazione non ha requisiti di progettazione complessi, ha una base utente di piccole dimensioni o ha modelli semantici di piccole dimensioni.

• L'organizzazione opera in una singola area.

• Non sei principalmente preoccupato per la separazione organizzativa tra le unità aziendali.

• L'organizzazione non richiede funzionalità con ambito area di lavoro, ad esempio la condivisione di repository di codice con Git.

• Si vuole implementare un'architettura a medaglione del lakehouse. Se l'organizzazione usa una singola area di lavoro, si possono creare lakehouse separati all'interno dell'area di lavoro per gestire i livelli bronzo, argento e oro.

• Le business unit dell'organizzazione condividono i ruoli ed è possibile avere le stesse autorizzazioni a livello di area di lavoro per gli utenti nell'area di lavoro. Ad esempio, se più utenti di diverse business unit sono amministratori di una singola area di lavoro, hanno gli stessi diritti per tutti gli elementi nell'area di lavoro.

• L'organizzazione tollera i tempi di completamento dei processi variabili. Se una capacità è condivisa, gli utenti possono eseguire query in qualsiasi momento. Il numero di CUs disponibili per l'esecuzione di un processo dipende dalle altre query eseguite sulla capacità, il che può causare tempi di completamento dei processi variabili.

• L'organizzazione può soddisfare i suoi requisiti aziendali CU usando una singola capacità di Fabric.

Considerazioni sull'area di progettazione

La tabella seguente presenta considerazioni che potrebbero influenzare la decisione di usare questo modello di distribuzione.

Modello 2: più aree di lavoro, capacità singola

In questo modello di distribuzione si allocano più aree di lavoro in una singola capacità condivisa. Le aree di lavoro condividono tale capacità, in modo che i carichi di lavoro simultanei possano influire sulle prestazioni dei processi e delle query interattive.

Le caratteristiche seguenti si applicano a questo modello:

• Gli articoli di tessuto condividono la stessa capacità. Il tempo necessario per una query o un processo varia a seconda degli altri carichi di lavoro che usano la stessa capacità.

• Le CPU massime dell'area di lavoro sono limitate allo SKU F più grande possibile. Per le esperienze di data engineering e data science, gli amministratori della capacità possono configurare Autoscale Billing per Spark per gestire la capacità di calcolo usata dal motore Spark al di fuori delle Compute Units allocate.

• Le funzionalità con ambito di un'area di lavoro si applicano a tutte le business unit che condividono tale area di lavoro.

• Tutti gli elementi e i dati dell'area di lavoro si trovano in un'area. Non è possibile usare questo modello per scenari geografici multipli.

• È possibile usare le funzionalità devOps che richiedono aree di lavoro separate, ad esempio pipeline di distribuzione e gestione del ciclo di vita.

• Si applicano le limitazioni per l'area di lavoro singola.

• Si applicano limitazioni specifiche della capacità dello SKU.

Quando usare questo modello

È possibile implementare questo modello di distribuzione se:

• Si vuole un'architettura hub-spoke che centralizza alcuni aspetti dell'operazione dell'ambiente di analisi e decentralizza altri.

• Si vuole una decentralizzazione operativa e di gestione variabile. Ad esempio, l'organizzazione potrebbe ospitare i livelli bronzo e argento di un'architettura medallion in un'area di lavoro e il livello oro in un'area di lavoro separata. Questa separazione riflette spesso responsabilità operative distinte, ad esempio in cui un team gestisce i livelli bronzo e argento e un altro team gestisce il livello oro.

• Non si è interessati principalmente alla gestione delle prestazioni e all'isolamento del carico di lavoro.

• L'organizzazione non deve distribuire carichi di lavoro in aree geografiche diverse. Tutti i dati devono trovarsi in un'area.

• L'organizzazione potrebbe richiedere aree di lavoro separate perché:

  • I membri del team responsabile dei carichi di lavoro si trovano in aree di lavoro diverse.

  • Si vogliono creare aree di lavoro separate per ogni tipo di carico di lavoro. Ad esempio, è possibile creare un'area di lavoro per l'inserimento di dati, ad esempio pipeline di dati, flussi di dati o ingegneria dei dati e un'area di lavoro separata per l'utilizzo tramite un data warehouse. Questa progettazione funziona correttamente se i team separati sono responsabili di ogni carico di lavoro.

  • Si vuole implementare un'architettura mesh di dati che raggruppa una o più aree di lavoro in un dominio Fabric.

• L'organizzazione potrebbe distribuire aree di lavoro separate in base alla classificazione dei dati.

Considerazioni sull'area di progettazione

La tabella seguente presenta considerazioni che potrebbero influenzare la decisione di usare questo modello di distribuzione.

Modello 3: più aree di lavoro, capacità separate

In questo modello di distribuzione si allocano più aree di lavoro tra capacità di Fabric separate, che fornisce governance e isolamento delle prestazioni tra le business unit.

Le caratteristiche seguenti si applicano a questo modello:

• Il maggiore SKU F o SKU P possibile associato a un'area di lavoro determina il numero massimo di CUs che un'area di lavoro può utilizzare.

• Le aree di lavoro separate creano il decentramento dell'organizzazione e della gestione.

• Le organizzazioni possono scalare oltre un'area usando capacità e aree di lavoro in aree geografiche diverse.

• È possibile usare le funzionalità complete di Fabric perché le business unit possono avere più aree di lavoro in capacità separate e raggruppate tramite domini Fabric.

• Si applicano le limitazioni dell'area di lavoro per una singola area di lavoro, ma è possibile creare nuove aree di lavoro da ridimensionare oltre questi limiti.

• Si applicano limitazioni specifiche per la capacità degli SKU, ma è possibile scalare le CUs usando capacità separate.

• È possibile usare il catalogo OneLake per individuare gli elementi Fabric e i relativi stati di certificazione.

• I domini possono raggruppare le aree di lavoro in modo che una singola business unit possa operare e gestire più aree di lavoro.

• I collegamenti a OneLake eliminano le copie fisiche dei dati per ridurre lo spostamento dei dati. I collegamenti OneLake offrono anche l'accesso controllato tra aree di lavoro tramite OneLake e non trasferiscono la proprietà dei dati sottostanti.

Quando usare questo modello

È possibile implementare questo modello di distribuzione se:

• L'organizzazione vuole distribuire framework architetturali come data mesh o data fabric.

• Si vuole assegnare priorità alla flessibilità nella struttura delle capacità e delle aree di lavoro.

• Si opera in aree geografiche diverse. In questo caso, crea una capacità e un'area di lavoro separate per passare a uno schema di distribuzione multicapacità e multiarea di lavoro.

• Si opera su larga scala e si hanno requisiti per la scalabilità oltre i limiti di uno SKU a capacità singola o di una singola area di lavoro.

• Sono presenti carichi di lavoro che devono sempre terminare entro un determinato periodo di tempo o che devono soddisfare i contratti di servizio basati sulle prestazioni. È possibile configurare un'area di lavoro Fabric con supporto di capacità per soddisfare gli obiettivi di livello di servizio per tali carichi di lavoro.

Considerazioni sull'area di progettazione

La tabella seguente presenta considerazioni che potrebbero influenzare la decisione di usare questo modello di distribuzione.

Modello 4: più tenant di Fabric

In questo modello di distribuzione, tutte le istanze di Fabric sono entità separate in relazione alla governance, alla gestione, all'amministrazione, alla scalabilità e all'archiviazione.

Le caratteristiche seguenti si applicano a questo modello:

• Le risorse del tenant sono rigorosamente separate.

• I piani di gestione tra i tenant sono separati.

• I tenant sono entità separate, ognuna con i propri processi di governance e gestione e ogni amministrata in modo indipendente.

• È possibile usare pipeline di dati o funzionalità di ingegneria dei dati per condividere o accedere ai dati tra tenant di Fabric.

Quando usare questo modello

È possibile implementare questo modello di distribuzione se:

• L'organizzazione ha più tenant Fabric a causa di un'acquisizione aziendale.

• L'organizzazione vuole configurare un tenant Fabric specificamente per una business unit o una filiale di dimensioni minori.

Valutare le piattaforme alternative

Se i requisiti dell'organizzazione non sono allineati ai modelli di distribuzione basati su Fabric, prendere in considerazione le alternative vincolate seguenti:

• Azure Data Factory con Data Lake Storage o OneLake, incluse le architetture ibride di Data Factory e Fabric

  Le organizzazioni che necessitano di un controllo di orchestrazione esplicito o una modernizzazione in più fasi possono usare Data Factory per l'orchestrazione di inserimento e pipeline e Data Lake Storage come base di archiviazione. In un modello ibrido, le pipeline di dati gestite da Data Factory possono caricare i dati in OneLake mentre Fabric gestisce la creazione di asset di dati analitici. Questo approccio supporta l'adozione incrementale di Fabric e mantiene i modelli di integrazione stabiliti.

• Data Lake Storage, Azure Databricks e Power BI

  Le organizzazioni che preferiscono un'architettura basata su Piattaforma distribuita come servizio (PaaS) anziché una piattaforma SaaS (Unified Software as a Service) potrebbero creare un patrimonio di dati usando Data Lake Storage per l'archiviazione, Azure Databricks per la progettazione e l'analisi dei dati e Power BI per la modellazione semantica e la creazione di report. Questo approccio offre il massimo controllo e flessibilità, ma richiede un maggiore impegno di integrazione e aumenta la complessità operativa e il sovraccarico di governance.

Considerazioni

Queste considerazioni implementano i pilastri di Well-Architected Framework, ovvero un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per ulteriori informazioni, vedere il Well-Architected Framework.

Le tabelle per ogni modello precedenti in questo articolo usano aree di progettazione specifiche per le decisioni di distribuzione di Fabric, come la governance, la sicurezza, l'amministrazione, il DevOps, l'usabilità, le prestazioni e la fatturazione. Le sottosezioni seguenti forniscono indicazioni complementari organizzate in base al pilastro Well-Architected Framework. Usare le tabelle basate su schemi per confrontare gli schemi. Usare queste sottosezioni per indicazioni sull'architettura trasversale che si applicano indipendentemente dal modello scelto.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

• Resilienza regionale integrata. Fabric offre resilienza regionale integrata tramite le zone di disponibilità, se supportate. Fabric distribuisce automaticamente le risorse tra più zone senza la configurazione del cliente. Il supporto della zona di disponibilità varia in base all'area di Azure. Per verificare se l'area di destinazione supporta le zone di disponibilità per Fabric, vedere Fabric disponibilità dell'area.

• Il ripristino di emergenza richiede il consenso esplicito e presenta avvertenze. Il ripristino tra aree è disponibile come impostazione di DR facoltativa nella pagina delle impostazioni della capacità. Abilitare l'impostazione della capacità DR per replicare i dati di OneLake tra le aree accoppiate di Azure utilizzando la replica asincrona.

  Importante

  Alcune aree Azure non sono associate alle aree che supportano Fabric, che potrebbero compromettere le funzionalità di ripristino di emergenza anche se i dati vengono replicati. Poiché la replica dei dati è asincrona, i dati scritti immediatamente prima di un'emergenza a livello di area potrebbero essere persi. Per altre informazioni, vedere Reliability in Fabric.

• I modelli a capacità singola concentrano il rischio in un'unica area. Nei modelli 1 e 2 i carichi di lavoro si trovano in un'area Azure. Se si verifica un'interruzione dell'area, tutte le aree di lavoro vengono interessate contemporaneamente. Per proteggersi da errori a livello di area, configurare l'impostazione di capacità per replicare i dati di OneLake in un'area abbinata. Pianificare il tempo di ripristino necessario per ripristinare il servizio nell'area abbinata.

• I modelli a capacità multipla offrono un isolamento naturale regionale. Nei modelli 3 e 4, le capacità in aree diverse indicano un'interruzione a livello di area influisce solo sulle capacità in tale area. I carichi di lavoro in altre aree continuano a funzionare. Questi modelli supportano i requisiti di residenza dei dati e forniscono le basi per strategie regionali attive-passive o attive.

• La sospensione della capacità ha un'incidenza sull'affidabilità. Se si sospende una capacità Fabric per ridurre i costi, tutti i carichi di lavoro su tale capacità non saranno più disponibili. Considerare l'effetto sull'affidabilità prima di sospendere una capacità che supporti i carichi di lavoro di produzione.

• Le scorciatoie di OneLake possono introdurre dipendenze esterne. Le scorciatoie alle origini dati esterne introducono la dipendenza dalla disponibilità delle origini. Se l'origine esterna non è disponibile, gli elementi che si basano su scorciatoie potrebbero non riuscire. Monitorare l'integrità delle origini dati esterne e pianificare una degradazione controllata.

sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

• Il modello di sicurezza a più livelli si estende su tre livelli. Fabric implementa un modello di sicurezza a più livelli che si estende sui livelli di tenant, area di lavoro e elemento. La scelta del modello di distribuzione determina la modalità di segmentazione dei limiti di sicurezza. I modelli a singola area di lavoro, ad esempio il modello 1, applicano l'accesso uniforme. Modelli multiworkspace, ad esempio modelli 2, 3 e 4, supportano i limiti di sicurezza per team o per unità di business.

Identità e accesso

• Applicare i criteri di autenticazione a livello di tenant usando l'accesso condizionale. Usare l'accesso condizionale per applicare criteri di autenticazione a livello di tenant, ad esempio l'autenticazione a più fattori, la conformità dei dispositivi e le restrizioni basate sulla posizione. L'accesso condizionale richiede una licenza Microsoft Entra ID P1.

• Usare i ruoli dell'area di lavoro per controllare l'accesso agli elementi. Assegnare i ruoli dell'area di lavoro per controllare chi può creare, modificare e utilizzare elementi all'interno di un'area di lavoro. Nei modelli multiworkspace, ad esempio i modelli 2, 3 e 4, usano aree di lavoro separate per applicare limiti di ruolo tra le business unit.

• Applicare l'accesso granulare a livello di dati usando i ruoli di sicurezza di OneLake. Usare i ruoli di sicurezza di OneLake per applicare un controllo di accesso granulare a livello di tabella, cartella, colonna e riga per gli utenti nel ruolo Visualizzatore. Gli amministratori, i membri e i collaboratori dell'area di lavoro ignorano questi ruoli.

Sicurezza della rete

• Usare collegamenti privati per il traffico in ingresso. Usare private links per instradare il traffico in ingresso sul backbone Microsoft anziché su Internet pubblico. I collegamenti privati a livello di tenant si applicano a tutte le aree di lavoro. I collegamenti privati a livello di area di lavoro offrono una granularità a livello di singola area di lavoro.

• Usare endpoint privati gestiti per le connessioni Spark in uscita. Usare endpoint privati gestiti per proteggere le connessioni in uscita dai carichi di lavoro Spark verso origini dati protette da firewall, come Data Lake Storage e Azure SQL Database.

• Usare i gateway dati di rete virtuale quando i collegamenti privati a livello di tenant bloccano i gateway locali. Quando si abilitano i collegamenti privati a livello di tenant, i gateway dati locali non possono eseguire la registrazione. Usare un gateway di rete virtuale per i dati invece di bridge che connettono origini dati locali o protette da una rete virtuale.

Protezione dei dati

• Applicare etichette di riservatezza per una classificazione dei dati integrale. Per la classificazione e la protezione dei dati, applicare etichette di sensitivity da Microsoft Purview Information Protection ai dati trasmessi attraverso Fabric. Le etichette seguono i dati dalla fonte al report.

• Usare i log di controllo e gli strumenti di conformità per l'applicazione dei criteri. Per rilevare e rispondere alle violazioni dei criteri, esaminare audit logs e usare Microsoft Purview Compliance Manager.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

• Costi del modello prima della distribuzione. I modelli di distribuzione influiscono sulla struttura dei costi. Modellare i costi per lo scenario usando Fabric prezzi e lo strumento di stima della capacità Fabric.

• Adatta (o Ottimizza) il tuo SKU di capacità. Ottimizza il tuo SKU F in base alla domanda del carico di lavoro. Iniziare con uno SKU più piccolo e aumentare le prestazioni in base alle esigenze. Monitorare il consumo e identificare le capacità con provisioning eccessivo o insufficiente tramite l'app Fabric Capacity Metrics.

• Automatizzare la sospensione della capacità per gli ambienti non di produzione. Ridurre i costi sospendo le capacità degli SKU F quando non sono in uso. Negli ambienti di sviluppo/test, sospendere le risorse al di fuori dell'orario lavorativo. La sospensione rende tutti i carichi di lavoro indisponibili, quindi si consiglia di considerare l'automazione tramite Azure Resource Manager Fabric APIs o pipeline pianificate.

• Modelli a capacità singola, ad esempio i modelli 1 e 2, centralizzano la fatturazione ma limitano il riaddebito. Una singola capacità implica una fattura unica. La gestione dei costi è centralizzata, ma il chargeback alle singole business unit non è possibile perché tutti i carichi di lavoro condividono la stessa capacità.

• Modelli di multicapacità, ad esempio i modelli 3 e 4, supportano la riassegnazione dei costi per team. Ogni capacità genera un proprio contatore di fatturazione Azure. È possibile addebitare costi all'unità aziendale responsabile di ogni capacità. Puoi ottimizzare o sospendere indipendentemente ogni capacità in base al carico di lavoro che supporta.

• Gestire i costi di archiviazione di OneLake in modo indipendente. L'archiviazione OneLake viene fatturata con una tariffa con pagamento in base al consumo per GB e non usa unità di calcolo. Eliminare regolarmente i dati inutilizzati, inclusi i dati eliminati in modo soft, e monitora l'archiviazione tramite l'app Fabric Capacity Metrics.

• Monitorare separatamente le risorse di calcolo spark. Per i carichi di lavoro di ingegneria dei dati, è possibile usare pool di Spark separati per spostare le risorse di calcolo al di fuori del budget cu. Per evitare costi imprevisti, monitorare l'utilizzo di Spark CU.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

• Usare le pipeline di distribuzione per la promozione graduale in fasi. Usare pipeline di distribuzione Fabric per promuovere il contenuto tramite le fasi di sviluppo/test e di produzione. Le pipeline di distribuzione richiedono aree di lavoro separate, quindi non sono disponibili nel modello 1. Nei modelli 2, 3 e 4 creare aree di lavoro dedicate per ogni fase DTAP. La strategia di capacità varia in base al modello.

  • Nel modello 2, tutte le aree di lavoro DTAP condividono la stessa capacità, che è conveniente ma non fornisce l'isolamento delle prestazioni tra gli ambienti.

  • Nel modello 3 è possibile usare capacità dedicate per ogni ambiente per l'isolamento completo oppure bilanciare i costi e l'isolamento usando una capacità condivisa per lo sviluppo/test con una capacità di produzione separata.

• Pianificare gli ambienti di preproduzione come decisione di progettazione a livello di area di lavoro. Il modello 1 non fornisce alcuna separazione di preproduzione perché lo sviluppo/test si verifica nell'area di lavoro di produzione. Il modello 2 supporta aree di lavoro di sviluppo, test e produzione separate in una capacità condivisa, adatta alla convalida funzionale, ma non ai test di resilienza o prestazioni simili alla produzione. Il modello 3 supporta la convalida della preproduzione simile alla produzione tramite aree di lavoro allineate all'ambiente con isolamento a livello di capacità. Il modello 4 prevede tenant separati anziché decisioni a livello di area di lavoro. Ogni tenant può scegliere indipendentemente la propria topologia di ambiente e non deve adattarsi agli altri.

• Connettere le aree di lavoro ai repository Git per il controllo del codice sorgente. Nei modelli 2 e 3, aree di lavoro separate per team o carico di lavoro sono allineate alle strategie di diramazione standard. Nel modello 1, tutti i team condividono un singolo repository, che può creare conflitti di merge.

• Monitorare la capacità e la salute del carico di lavoro. Usare l'app Fabric Capacity Metrics per monitorare il consumo di capacità, come utilizzo dei CU, limitazioni e superamenti. È possibile accedere ai dati di telemetria dettagliati sui singoli carichi di lavoro usando il monitoraggio dell'area di lavoro. Nei modelli di multicapacity, ad esempio i modelli 3 e 4, è possibile delegare il monitoraggio al team responsabile di ogni capacità.

• Delegare l'amministrazione tramite domini di Fabric. Nei modelli 2 e 3, bisogna delegare le impostazioni tenant e la gestione dell'area di lavoro agli amministratori a livello di dominio senza privilegi di amministratore tenant usando i domini Fabric. Il modello 1 non può usare domini perché tutti gli elementi si trovano in un'unica area di lavoro.

• Gestire le capacità usando l'infrastruttura come codice (IaC). Creare e gestire capacità di Fabric usando Bicep o Terraform. Archiviare le definizioni dell'infrastruttura nel controllo del codice sorgente insieme al codice dell'applicazione.

Efficienza prestazionale

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

• Comprendere il dimensionamento della capacità e il suo comportamento di regolazione. Ogni capacità ha un'allocazione cu fissa determinata dal relativo SKU. Se la richiesta supera le CU disponibili, Fabric applica throttling e accoda le richieste. Monitorare gli eventi di limitazione usando l'app Fabric Capacity Metrics e aumentare le prestazioni dello SKU o distribuire i carichi di lavoro tra più capacità in base alle esigenze.

• Isolare i carichi di lavoro sensibili alle prestazioni in una capacità dedicata. Nei modelli 1 e 2, tutti i carichi di lavoro competono per le stesse CPU. Una query o una pipeline di dati costosa può compromettere le prestazioni delle query interattive per altri utenti. Nei modelli 3 e 4, è possibile isolare i carichi di lavoro sensibili alle prestazioni in una capacità dedicata con un'allocazione garantita di CU.

• Configurare i pool di Spark per i carichi di lavoro di progettazione dei dati. Per i carichi di lavoro di progettazione dei dati, usare pool di Spark personalizzati per controllare il numero minimo e massimo di nodi e supportare la scalabilità automatica. Le reti virtuali gestite disabilitano i pool di avvio o i cluster condivisi preavvisi, aumentando così l'ora di inizio della sessione da secondi a 3 e 5 minuti.

• Posizionare le capacità vicino ai produttori di dati e ai consumer. Nel modello 3 è possibile usare le capacità nelle aree vicine ai produttori di dati o ai consumer, riducendo la latenza tra aree. I collegamenti OneLake possono fare riferimento ai dati in altre regioni, ma le letture tra regioni comportano costi di latenza e di trasferimento.

• Applicare tecniche di ottimizzazione specifiche del carico di lavoro. Migliorare le prestazioni di analisi usando Z-Ordering e V-Ordering per i lakehouse. Per i warehouse, ottimizzare i modelli di query per leggere batch più piccoli. Ridurre il carico di capacità rispetto alla modalità importazione usando la modalità Direct Lake per i report di Power BI.

Matrice delle funzionalità

Le tabelle seguenti riepilogano le differenze principali nelle funzionalità di ogni modello.

Governance e amministrazione

¹ Le aree di lavoro offrono un isolamento, ma tutte le aree di lavoro condividono una singola capacità, che limita la granularità del rilevamento e dell'amministrazione dell'utilizzo.

² Il modello 4 usa tenant separati anziché domini. Ogni tenant ha un proprio modello di amministrazione.

sicurezza

DevOps e gestione del ciclo di vita

³ Le pipeline di distribuzione richiedono aree di lavoro separate, che non sono disponibili in un modello monolitico a singola area di lavoro.

⁴ L'integrazione git è disponibile, ma tutti i team condividono un singolo repository, che può creare conflitti di merge.

Prestazioni e scalabilità

⁵ Il rischio di limitazione è basso se i carichi di lavoro si trovano in capacità dedicate, ma la limitazione può comunque verificarsi all'interno di una singola capacità se la domanda supera le CPU disponibili.

Gestione di costi e fatturazione

⁶ Ogni capacità genera un proprio contatore di fatturazione, quindi la fatturazione viene distribuita tra capacità anziché centralizzata.

Contributori

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

• Amanjeet Singh | Principal Program Manager

Altri contributori:

• Lorrin Ferdinand | Consulente principale
• Holly Kelly | Responsabile del programma principale
• Gabi Muenster | Senior Program Manager
• Sarah Sasidharan | Senior Program Manager

Per visualizzare i profili di LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Concetti e licenze di Fabric
• spazi di lavoro Fabric
• Fabric domains
• Che cos'è OneLake?
• pipeline di distribuzione Fabric
• Reliability in Fabric
• panoramica della sicurezza di Fabric

" output is necessary.)

• Panoramica delle scelte tecnologiche
• Analisi completa con Fabric
• Business intelligence aziendale con Fabric
• Costruisci un lakehouse ex novo utilizzando Fabric