Questo articolo descrive quattro modelli di distribuzione tra cui è possibile scegliere quando si distribuisce Microsoft Fabric. Informazioni su considerazioni, raccomandazioni e potenziali decisioni non valide per ogni modello di distribuzione.
Per ogni modello di distribuzione fabric sono descritte le aree di progettazione seguenti:
- Governance
- Sicurezza
- Amministrazione
- DevOps
- Usabilità
- Prestazioni e scalabilità
- Gestione di costi e fatturazione
Livelli in una distribuzione di Fabric
Una distribuzione di Fabric ha quattro livelli: tenant, capacità, area di lavoro ed elemento. Al livello superiore è il tenant di Fabric. Ogni tenant può avere una o più capacità, ogni capacità può contenere una o più aree di lavoro e ogni area di lavoro può contenere zero o più elementi fabric.
La struttura o gli obiettivi di un'organizzazione nelle aree di sicurezza, scalabilità, governance e ciclo di vita dell'applicazione possono influenzare la scelta del modello di distribuzione. I diversi modelli di distribuzione offrono flessibilità variabile ed enfasi nei livelli di una distribuzione.
Ad esempio, un'organizzazione può usare domini per raggruppare le aree di lavoro in Fabric. Analogamente, se un'organizzazione deve avere un'opzione centralizzata che può usare per collaborare e trovare contenuto, un hub dati OneLake in Fabric offre un punto di accesso centralizzato ed è integrato con altri prodotti familiari, ad esempio Microsoft Teams ed Excel.
In Fabric, un'organizzazione di grandi dimensioni con business unit in posizioni geografiche separate può usare le capacità per controllare dove risiedono i dati. Può gestire una business unit che opera da una posizione geografica diversa come una singola unità usando domini di Infrastruttura perché i domini possono estendersi su aree di lavoro in aree diverse.
Per altre informazioni sui livelli di infrastruttura e sul relativo ruolo nella scelta di un modello di distribuzione, vedere Concetti e licenze di Microsoft Fabric.
Allineamento dei modelli di distribuzione di Fabric
Tutti i modelli di distribuzione di Fabric:
- Usare le aree di lavoro di Fabric come limiti per la scalabilità, la governance e la sicurezza.
- Usare i domini di Infrastruttura per la delega, per gestire più aree di lavoro che potrebbero appartenere alla stessa business unit o quando i dati appartenenti a un dominio aziendale si estendono su più di un'area di lavoro. È possibile impostare alcune impostazioni a livello di tenant per la gestione e la governance dei dati a livello di dominio e usare la configurazione specifica del dominio per tali impostazioni.
- Usare le capacità di Infrastruttura per ridimensionare le risorse di calcolo durante il provisioning di capacità dedicate per area di lavoro quando è necessario soddisfare specifici livelli di prestazioni.
- Estendere per usare funzionalità equivalenti da un cloud Microsoft (Microsoft Azure, Microsoft 365 e altri) quando una funzionalità non è disponibile in Fabric.
- Usare un hub dati OneLake per promuovere l'individuazione e l'uso degli asset di dati.
- Usare OneSecurity per configurare i criteri di sicurezza dei dati per gli asset di dati.
Scenari basati sui requisiti aziendali
Questo articolo usa gli scenari seguenti per descrivere in che modo ogni modello di distribuzione può soddisfare diversi requisiti aziendali:
- Scenario 1: per le organizzazioni che vogliono avere tempi di commercializzazione più veloci (o più lenti) organizzando i team che possono collaborare tra loro, con restrizioni più basse sull'utilizzo dei dati. In questo scenario, un'organizzazione può trarre vantaggio usando un modello di distribuzione monolitico . L'organizzazione opera in e gestisce una singola area di lavoro. Per altre informazioni, vedere Modello 1: Distribuzione monolitica.
- Scenario 2: per le organizzazioni che vogliono fornire ambienti isolati in cui i team lavorano, con un team centrale responsabile della fornitura e della gestione dell'infrastruttura. Questo scenario è adatto anche alle organizzazioni che vogliono implementare la mesh di dati. In questo scenario, un'organizzazione può implementare più aree di lavoro che usano una capacità condivisa o hanno capacità separate. Per altre informazioni, vedere Modello 2: Più aree di lavoro supportate da una singola capacità infrastruttura e Modello 3: Più aree di lavoro supportate da capacità separate.
- Scenario 3: per le organizzazioni che vogliono un modello completamente decentralizzato che offre alle business unit o ai team la libertà di controllare e gestire le proprie piattaforme dati. In questo scenario, un'organizzazione può scegliere un modello di distribuzione in cui usa aree di lavoro separate, ognuna con capacità dedicata o eventualmente con più tenant di Fabric. Per altre informazioni, vedere Modello 3: Più aree di lavoro supportate da capacità separate e modello 4: più tenant dell'infrastruttura.
- Scenario 4: un'organizzazione potrebbe scegliere di usare un approccio ibrido in cui combina più modelli per soddisfare i requisiti. Ad esempio, un'organizzazione potrebbe configurare una singola area di lavoro per business unit specifiche (un modello di distribuzione monolitica) usando aree di lavoro dedicate separate e capacità separate per altre business unit.
Modello 1: Distribuzione monolitica
In questo modello di distribuzione viene effettuato il provisioning di una singola area di lavoro per soddisfare tutti i casi d'uso. Tutte le business unit funzionano all'interno della stessa area di lavoro singola.
Quando si effettua il provisioning di una singola capacità di Fabric e si collega una singola area di lavoro, i punti seguenti sono true:
- Tutti gli elementi fabric condividono la stessa capacità di cui è stato effettuato il provisioning. La quantità di tempo impiegato per completare una query o un processo varia perché altri carichi di lavoro usano la stessa capacità.
- Le unità di capacità massima dell'area di lavoro (CU) sono limitate al più grande possibile SKU F o SKU P. Per le esperienze di progettazione dei dati, è possibile effettuare il provisioning di pool di Spark separati per spostare la capacità di calcolo richiesta da Fabric Spark all'esterno delle UNITÀ di calcolo di cui è stato effettuato il provisioning.
- 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 multi-geografico.
- Le funzionalità che si basano su più aree di lavoro, ad esempio le pipeline di distribuzione e la gestione del ciclo di vita, non sono disponibili.
- Si applicano limitazioni associate a una singola area di lavoro.
- Si applicano limitazioni di capacità associate a uno SKU specifico.
È possibile scegliere di implementare questo modello di distribuzione per uno o più dei motivi seguenti:
- L'organizzazione non ha requisiti di progettazione complessi, ha una base di utenti di piccole dimensioni o i modelli semantici sono di piccole dimensioni.
- L'organizzazione opera in una singola area.
- Non si è interessati principalmente alla separazione organizzativa tra le business unit.
- 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 della medaglia di lakehouse. Quando l'organizzazione è limitata a una singola area di lavoro, è possibile ottenere la separazione tra i livelli bronze, silver e gold creando lakehouse separati all'interno dell'area di lavoro.
- Le business unit dell'organizzazione condividono i ruoli ed è accettabile avere le stesse autorizzazioni a livello di area di lavoro per gli utenti nell'area di lavoro. Ad esempio, quando più utenti appartenenti a 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 può tollerare i tempi di completamento dei processi variabili. Se un'organizzazione non ha requisiti per le garanzie di prestazioni (ad esempio, un processo deve terminare in un periodo di tempo specifico), è accettabile condividere una singola capacità con provisioning tra le business unit. Quando viene condivisa una capacità, gli utenti possono eseguire le query in qualsiasi momento. Il numero di CPU disponibili per l'esecuzione di un processo varia a seconda delle altre query in esecuzione sulla capacità. Può causare tempi di completamento di processi variabili.
- L'organizzazione può raggiungere tutti i requisiti aziendali (dal punto di vista cu) usando una singola capacità di Infrastruttura.
La tabella seguente presenta considerazioni che potrebbero influenzare la decisione di adottare questo modello di distribuzione:
| Aspetto | Considerazioni |
|---|---|
| Governance | - Sono necessari vincoli di governance inferiori e restrizioni per la piattaforma. - Si adatta alle organizzazioni più piccole che preferiscono tempi di commercializzazione più veloci. - Le sfide possono sviluppare se i requisiti di governance si evolvono per diventare più complessi. |
| Sicurezza - Piano dati | - I dati possono essere condivisi tra team, quindi non è necessario avere restrizioni sui dati tra i team. - I team hanno diritti di proprietà sui modelli semantici. Possono leggere, modificare e modificare i dati in OneLake. |
| Sicurezza - Piano di controllo | - Tutti gli utenti possono collaborare nella stessa area di lavoro. - Non esistono restrizioni per gli elementi. Tutti gli utenti possono leggere e modificare tutti gli elementi. |
| Amministrazione | L'organizzazione ha: - Costi di amministrazione inferiori. - Non è necessario tenere traccia e monitorare l'accesso e l'utilizzo per ogni team. - Monitoraggio del carico di lavoro infrastruttura meno rigoroso tra i team. |
| DevOps | Vantaggi di DevOps da: - Una singola versione per l'intera piattaforma. - Pipeline di versione meno complicate. |
| Usabilità - Amministrazione istratori | - È più facile per gli amministratori gestire perché hanno meno elementi da gestire. - Non è necessario altro provisioning o gestire le richieste dei team per nuove capacità o aree di lavoro. - Gli amministratori della capacità possono essere amministratori tenant, quindi non è necessario creare o gestire altri gruppi o team. |
| Usabilità - Altri ruoli | - È accettabile condividere l'area di lavoro con altri utenti. - La collaborazione tra gli utenti è incoraggiata. |
| Prestazioni | - L'isolamento dei carichi di lavoro non è obbligatorio. - Non è necessario soddisfare contratti di servizio (SLA) rigorosi. - La limitazione non è probabile. |
| Fatturazione e gestione dei costi | - Un singolo team può gestire i costi. - Non è necessario eseguire il chargeback a team diversi. |
Modello 2: più aree di lavoro supportate da una singola capacità infrastruttura
In questo modello di distribuzione si usano aree di lavoro separate. Poiché una singola capacità viene condivisa tra aree di lavoro, i carichi di lavoro eseguiti simultaneamente in qualsiasi momento potrebbero influire sulle prestazioni dei processi e delle query interattive.
Quando si effettua il provisioning di una singola capacità di Fabric e si collegano più aree di lavoro, i punti seguenti sono veri:
- Tutti gli elementi fabric condividono la stessa capacità di cui è stato effettuato il provisioning. La quantità di tempo impiegato per completare una query o un processo varia perché altri carichi di lavoro usano la stessa capacità.
- Il numero massimo di CPU che un'area di lavoro può usare è limitato allo SKU F o allo SKU P più grande possibile. Per le esperienze di progettazione dei dati, è possibile effettuare il provisioning di pool di Spark separati per spostare la capacità di calcolo richiesta da Fabric Spark all'esterno delle UNITÀ di calcolo di cui è stato effettuato il provisioning.
- 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 multi-geografico.
- È possibile usare funzionalità DevOps che richiedono aree di lavoro separate, ad esempio per le pipeline di distribuzione e la gestione del ciclo di vita.
- Si applicano limitazioni associate a una singola area di lavoro.
- Si applicano limitazioni di capacità associate a uno SKU specifico.
È possibile scegliere di implementare questo modello di distribuzione per uno o più dei motivi seguenti:
- Si vuole un'architettura hub-spoke in cui l'organizzazione centralizza alcuni aspetti del funzionamento dell'ambiente di analisi e decentralizza altri.
- Si vuole decentralizzazione da un aspetto operativo e di gestione, ma in gradi diversi. Ad esempio, è possibile scegliere di avere livelli bronzo e argento di un'architettura medallion distribuita in un'area di lavoro e il livello oro distribuito in un'area di lavoro diversa. La logica potrebbe essere che un team è responsabile dei livelli bronzo e argento e un altro team è responsabile del funzionamento e della gestione del livello oro.
- Non ci si preoccupa principalmente della gestione delle prestazioni e dell'isolamento dei carichi di lavoro dal punto di vista delle prestazioni.
- Dal punto di vista di un'architettura della medaglia del lago, l'organizzazione può creare aree di lavoro separate per implementare livelli bronzo, argento e oro.
- L'organizzazione non deve distribuire carichi di lavoro in aree geografiche diverse (tutti i dati devono trovarsi in un'unica area).
- L'organizzazione potrebbe richiedere la separazione delle aree di lavoro per uno o più dei motivi seguenti:
- 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 dati (pipeline di dati, dataflow Gen2 o progettazione dati) e creare un'area di lavoro separata per l'utilizzo tramite un data warehouse. Questa progettazione funziona bene quando i team separati sono responsabili di ognuno dei carichi di lavoro.
- Si vuole implementare un'architettura mesh di dati in cui una o più aree di lavoro vengono raggruppate in un dominio di Fabric.
- L'organizzazione potrebbe scegliere di distribuire aree di lavoro separate in base alla classificazione dei dati.
La tabella seguente presenta considerazioni che potrebbero influenzare la decisione di scegliere questo modello di distribuzione:
| Aspetto | Considerazioni |
|---|---|
| Governance | - Sono necessari vincoli e restrizioni per la governance media sulla piattaforma. - L'organizzazione necessita di un controllo più granulare per gestire reparti, team e ruoli. |
| Sicurezza - Piano dati | - Sono necessarie restrizioni per i dati ed è necessario fornire la protezione dei dati in base ai controlli di accesso per reparti, team e membri. |
| Sicurezza - Piano di controllo | - Per evitare danneggiamenti accidentali o azioni da parte di utenti malintenzionati, potrebbe essere necessario fornire l'accesso controllato agli elementi di Fabric in base al ruolo. |
| Amministrazione | - Non è necessario gestire le capacità perché si tratta di un modello a capacità singola. - È possibile usare le aree di lavoro per isolare reparti, team e utenti. |
| DevOps | - È possibile eseguire versioni indipendenti per reparto, team o carico di lavoro. - È più semplice soddisfare i requisiti di sviluppo, test, accettazione e produzione (DTAP) per i team quando viene effettuato il provisioning di più aree di lavoro per risolvere ogni ambiente di rilascio. |
| Usabilità - Amministrazione istratori | - Non è necessario effettuare il provisioning di più capacità. - Gli amministratori tenant amministrano in genere la capacità, quindi non è necessario gestire altri gruppi o team. |
| Usabilità - Altri ruoli | - Le aree di lavoro sono disponibili per ogni livello di medaglia. - Gli elementi dell'infrastruttura sono isolati per area di lavoro, che consente di evitare danneggiamenti accidentali. |
| Prestazioni | - Non è necessario soddisfare contratti di servizio con prestazioni rigorose. - La limitazione è accettabile durante i periodi di picco. |
| Fatturazione e gestione dei costi | - Non si ha un requisito specifico per eseguire il chargeback per ogni team. - Una squadra centrale ha tutti i costi. - I team dell'infrastruttura sono proprietari delle capacità di Fabric nell'organizzazione. |
Modello 3: più aree di lavoro supportate da capacità separate
In questo modello di distribuzione si ottiene la separazione tra le business unit per la governance e le prestazioni.
Quando si effettua il provisioning di più capacità di Fabric con le proprie aree di lavoro, i punti seguenti sono veri:
- Il più grande possibile SKU F o SKU P collegato a un'area di lavoro determina il numero massimo di CPU che un'area di lavoro può usare.
- Il decentramento dell'organizzazione e della gestione viene ottenuto effettuando il provisioning di aree di lavoro separate.
- Le organizzazioni possono essere ridimensionate oltre un'area effettuando il provisioning di capacità e aree di lavoro in aree geografiche diverse.
- È possibile usare le funzionalità complete di Fabric perché le business unit possono avere una o più aree di lavoro che si trovano in capacità separate e raggruppate tramite domini di infrastruttura.
- Le limitazioni associate a una singola area di lavoro si applicano, ma è possibile superare questi limiti creando nuove aree di lavoro.
- Si applicano limitazioni di capacità associate a uno SKU specifico, ma è possibile ridimensionare le UNITÀ di configurazione effettuando il provisioning di capacità separate.
- Tutti gli elementi fabric in tutte le aree di lavoro nel tenant e i relativi stati di certificazione possono essere individuati usando un hub dati OneLake.
- I domini possono raggruppare le aree di lavoro in modo che una singola business unit possa operare e gestire più aree di lavoro.
- I tasti di scelta rapida di OneLake riducono lo spostamento dei dati e riducono anche l'usabilità dei dati tra le aree di lavoro.
È possibile scegliere di implementare questo modello di distribuzione per uno o più dei motivi seguenti:
- 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, il provisioning di una capacità e di un'area di lavoro separata è la forza trainante per passare a questo modello di distribuzione multi-capacità e multi-area 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.
- Si dispone di carichi di lavoro che devono sempre terminare entro un determinato periodo di tempo o soddisfare un contratto di servizio specifico per le prestazioni. È possibile effettuare il provisioning di un'area di lavoro separata supportata da una capacità di Infrastruttura per soddisfare le garanzie di prestazioni per tali carichi di lavoro.
La tabella seguente presenta considerazioni che potrebbero influenzare la decisione di scegliere questo modello di distribuzione:
| Aspetto | Considerazioni |
|---|---|
| Governance | - Si ha un alto grado di governance e gestione e si ha bisogno di indipendenza per ogni area di lavoro. - È possibile gestire l'utilizzo per reparto o business unit. - È possibile conformarsi ai requisiti di residenza dei dati. - È possibile isolare i dati in base ai requisiti normativi. |
| Sicurezza - Piano dati | - L'accesso ai dati può essere controllato per reparto, team o utenti. - È possibile isolare i dati in base al tipo di elemento fabric. |
| Sicurezza - Piano di controllo | - È possibile fornire l'accesso controllato agli elementi di Fabric in base al ruolo per evitare danneggiamenti accidentali o azioni da parte di utenti malintenzionati. |
| Amministrazione | - Le funzionalità di amministratore granulari sono limitate a reparti, team o utenti. - È possibile accedere ai requisiti di monitoraggio dettagliati sull'utilizzo o sui modelli dei carichi di lavoro. |
| DevOps | - È possibile isolare gli ambienti DTAP usando capacità diverse. - Le versioni indipendenti si basano su un reparto, un team o un carico di lavoro. |
| Usabilità - Amministrazione istratori | - Si ottiene una visibilità granulare sull'utilizzo in base al reparto o al team. - Sono stati delegati i diritti di capacità agli amministratori della capacità per reparto o team, che consente di ridimensionare e configurare in modo granulare. |
| Usabilità - Altri ruoli | - Le aree di lavoro sono disponibili per livello di medaglia e capacità. - Gli elementi dell'infrastruttura sono isolati per area di lavoro, che consente di evitare il danneggiamento accidentale. - Sono disponibili più opzioni per impedire la limitazione causata da picchi di capacità condivisa. |
| Prestazioni | - I requisiti di prestazioni sono elevati e i carichi di lavoro devono soddisfare contratti di servizio più elevati. - È possibile aumentare le prestazioni dei singoli carichi di lavoro per reparto o team. |
| Fatturazione e gestione dei costi | - I requisiti di ricarica incrociata possono essere facilmente soddisfatti assegnando capacità dedicate a un'entità organizzativa (reparto, team o progetto). - La gestione dei costi può essere delegata ai rispettivi team da gestire. |
Modello 4: più tenant di Fabric
Quando vengono distribuiti tenant di Fabric separati, tutte le istanze di Fabric sono entità separate in relazione alla governance, alla gestione, all'amministrazione, alla scalabilità e all'archiviazione.
I punti seguenti sono true quando si usano più tenant di Fabric:
- Le risorse del tenant sono rigorosamente separate.
- I piani di gestione tra i tenant sono separati.
- I tenant sono entità separate e possono avere processi personalizzati per la governance e la gestione, ma è possibile amministrarli separatamente.
- È possibile usare pipeline di dati o funzionalità di ingegneria dei dati per condividere o accedere ai dati tra i tenant di Fabric.
È possibile scegliere di implementare questo modello di distribuzione per i motivi seguenti:
- L'organizzazione potrebbe finire con più tenant di Fabric a causa di un'acquisizione aziendale.
- L'organizzazione potrebbe scegliere di configurare un tenant di Fabric in modo specifico per una business unit o una filiale di dimensioni minori.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
- Holly Kelly | Principal Program Manager
- Gabi Mueintune | Senior Program Manager
- Sarath Sasidharan | Senior Program Manager
- Amanjeet Singh | Principal Program Manager