Architettura per una piattaforma dati unificata

Questo articolo aiuta i decision maker a prendere decisioni sull'architettura per la propria Azure landing zone per creare una piattaforma dati unificata.

Le organizzazioni devono determinare quali aggiornamenti richiede la propria landing zone della piattaforma e come i carichi di lavoro di Azure devono integrarsi con la piattaforma dati unificata. Senza un'architettura chiara, i dati possono rimanere isolati tra carichi di lavoro e piattaforme o spostarsi tra di essi senza governance e sicurezza coerenti. Questo articolo fornisce indicazioni per l'aggiornamento della landing zone della piattaforma e la progettazione delle landing zone del carico di lavoro, in modo che i carichi di lavoro Azure possano produrre dati per Microsoft Fabric e consumare da Microsoft Fabric dati governati.

Architetture e albero delle decisioni

Concettuale

Architettura concettuale di una piattaforma dati unificata per intelligenza artificiale e analisi.

Dettagli

Architettura concettuale dettagliata di una piattaforma dati unificata per intelligenza artificiale e analisi.

Albero delle decisioni

Il flusso pone una serie di domande a cui rispondere con sì o no. Ogni "Sì" porta a indicazioni specifiche. La prima domanda chiede se l'organizzazione deve aiutare a comprendere le priorità dei dati o a sviluppare competenze per ottenere più valore dai dati. In caso affermativo, la guida è di preparare le persone tramite ruoli, formazione e attività di prontezza. La seconda domanda chiede se l'organizzazione necessita di un modo unificato per accedere ai dati tra cloud e carichi di lavoro per supportare l'analisi e l'intelligenza artificiale. In caso affermativo, la raccomandazione è usare Microsoft Fabric come piattaforma dati unificata. La terza domanda chiede se l'organizzazione deve aiutare a trasformare i dati operativi in valore aziendale o a inserire in modo sicuro i dati in sistemi di IA, ad esempio Microsoft Foundry. In caso affermativo, l'indicazione è di integrare i servizi di Azure con Fabric. La quarta domanda chiede se l'organizzazione deve aiutare a controllare l'accesso ai dati o a proteggere i dati in modo coerente. In caso affermativo, la guida è di definire le baseline di governance e sicurezza utilizzando Microsoft Purview e i controlli correlati. La quinta domanda chiede se l'organizzazione deve aiutare a definire standard organizzativi coerenti per elaborare, proteggere e utilizzare i prodotti dati per l'analisi e l'intelligenza artificiale. In caso affermativo, la guida è di impostare standard operativi per i prodotti di dati, la sicurezza e la gestione del ciclo di vita. Il flusso termina puntando all'adozione dell'IA e all'adozione di agenti di intelligenza artificiale una volta che sono stati applicati gli standard e la piattaforma dati unificata.

L'albero decisionale di Microsoft per orientarsi nella piattaforma dati unificata.

1. Azure landing zone

Come aggiornare la landing zone di Azure? La piattaforma dati unificata deve usare l'architettura esistente della landing zone di Azure dell'organizzazione. L'organizzazione non deve creare un'architettura di Azure separata esclusivamente per Microsoft Fabric o i carichi di lavoro dei dati.

1.1. Aggiornamenti della landing zone della piattaforma

Quali modifiche sono necessarie per la landing zone della piattaforma? La landing zone della piattaforma deve continuare a fornire le funzionalità di Azure condivise usate nell'organizzazione. L'organizzazione deve mantenere la gerarchia del gruppo di gestione esistente, a meno che un nuovo requisito normativo, di sicurezza, di sovranità o operativo non richieda un ambito dei criteri diverso.

Baseline di governance: il team della piattaforma deve valutare ogni servizio Azure introdotto dalla piattaforma dati unificata rispetto alla baseline dei criteri esistente. La verifica deve identificare se i controlli esistenti si applicano e se sono necessari controlli aggiuntivi. I riferimenti ai criteri predefiniti pertinenti includono:

• Azure Databricks
• Azure Machine Learning
• Azure Data Lake Storage
• Macchine virtuali (calcolo)
• Località consentite

1.2. Landing zone del carico di lavoro

Cosa è necessario inserire nelle landing zone del workload? Le risorse Azure che supportano la piattaforma dati unificata devono risiedere nelle landing zone del carico di lavoro, a meno che non forniscano una funzionalità di base della piattaforma Azure definita dall'architettura delle landing zone Azure dell'organizzazione.

Service	Posizionamento tipico del gruppo di gestione
Microsoft Purview	Zona di destinazione interna del carico di lavoro
Capacità di Microsoft Fabric	Zona di destinazione interna del carico di lavoro
carico di lavoro Azure (utilizzo di prodotti dati o intelligenza artificiale)	Area di destinazione interna, online o locale del carico di lavoro
Database di Azure	Area di destinazione interna, online o locale del carico di lavoro
Azure Databricks	Zona di destinazione interna del carico di lavoro
Azure Machine Learning (Apprendimento Automatico di Azure)	Zona di destinazione interna del carico di lavoro
Azure Data Lake Storage	Zona di destinazione interna del carico di lavoro
Infrastruttura di intelligenza artificiale (training/GPU)	Zona di destinazione interna del carico di lavoro

1.3 Integrazione Fabric

In che modo i carichi di lavoro di Azure si integrano con Microsoft Fabric? I carichi di lavoro di Azure devono integrarsi con Microsoft Fabric tramite modelli approvati a livello di organizzazione per rendere i dati disponibili tramite OneLake e consumare prodotti dati governati. L'integrazione con Fabric non deve modificare l'allocazione del carico di lavoro.

L'architettura deve supportare i prodotti dati creati in Fabric e prodotti dati creati tramite altre piattaforme approvate, ad esempio Azure Databricks. Il modello di integrazione deve identificare il sistema autorevole di record ed evitare la duplicazione non necessaria dell'elaborazione o dei dati. Vedere integrazione Azure Databricks con OneLake e Azure Data Lake Storage (ADLS) Gen2 collegamento.

L'organizzazione deve definire i modelli di integrazione supportati tramite gli standard operativi.

2. architettura Microsoft Fabric

In che modo l'organizzazione deve progettare Microsoft Fabric? Microsoft Fabric deve fornire la piattaforma condivisa tramite cui i domini dati creano, pubblicano e utilizzano prodotti dati. L'organizzazione deve stabilire un'architettura di Fabric comune prima che i domini dati distribuiscano i prodotti dati di produzione.

2.1 implementazione della capacità di Fabric

Come distribuire le capacità di Fabric? Ogni dominio dati deve distribuire le capacità Fabric tramite la sottoscrizione della zona di destinazione del carico di lavoro designata. Il dominio dati deve gestire la capacità Fabric entro il budget approvato e gli standard a livello di organizzazione.

• Requisiti di capacità: un dominio dati deve aggiungere Fabric capacità quando le risorse esistenti non possono soddisfare un requisito di prestazioni, isolamento, area o ciclo di vita approvato. Il dominio dati non deve aggiungere Fabric capacità solo per organizzare i prodotti dati o i team.

• Azure requisiti di sottoscrizione: un dominio dati deve usare un'altra sottoscrizione della zona di destinazione del carico di lavoro solo quando è necessaria una governance Azure distinta o un limite amministrativo. Un'altra area di lavoro, ambiente o prodotto dati non giustifica per sé un'altra sottoscrizione.

• Capacità di Fabric condivise: più domini dati possono condividere una capacità di Fabric quando le risorse condivise offrono prestazioni accettabili e un migliore utilizzo delle risorse.

• Distribuzione a livello di area: l'organizzazione deve stabilire un'area di Azure predefinita per Fabric capacità. I domini di dati devono usare tale area a meno che un requisito approvato non giustifichi un'altra area. Le eccezioni accettabili includono residenza legale, sovranità dei dati, latenza, disponibilità delle funzionalità Fabric o una progettazione approvata per il ripristino di emergenza. La posizione del team o la comodità non è sufficiente per un'altra area. Consulta il supporto multi-geo per Fabric e i modelli di distribuzione di Fabric.

• Approvazione delle eccezioni: l'organizzazione deve definire chi approva un'altra area geografica o una capacità di Fabric condivisa tra domini dati. Una richiesta di eccezione deve identificare il requisito, i prodotti di dati interessati, i costi previsti e le condizioni di uscita.

2.2 Aree di lavoro di Fabric

Come usare le aree di lavoro? I workspace di Fabric devono definire i confini operativi attraverso i quali i domini di dati creano e gestiscono prodotti di dati in Microsoft Fabric. Ogni dominio dati deve determinare la struttura dell'area di lavoro all'interno degli standard a livello di organizzazione.

• Uso dell'area di lavoro: creare un'area di lavoro separata quando Fabric elementi richiedono un limite amministrativo, di accesso, distribuzione o di rete diverso.

• Organizzazione dell'area di lavoro. I domini dati devono associare le aree di lavoro correlate ai domini di Fabric. Fabric domini raggruppano logicamente Fabric aree di lavoro e supportano la governance delegata, ma l'assegnazione di dominio non determina l'accesso agli elementi Fabric. Vedere Procedure consigliate per la pianificazione e la creazione di domini in Microsoft Fabric.

3. architettura Microsoft Purview

Come progettare Microsoft Purview? L'architettura Microsoft Purview deve riflettere i domini dati dell'organizzazione senza considerare i domini di governance purview, i domini della mappa dati, le raccolte o i domini Fabric come intercambiabili.

3.1 Microsoft Purview posizionamento dell'account

Dove distribuire l'account Purview? L'organizzazione deve inserire la risorsa Azure Microsoft Purview in una landing zone interna del carico di lavoro. La sottoscrizione e l'area selezionate devono soddisfare i requisiti normativi e operativi dell'organizzazione.

L'organizzazione deve assegnare la responsabilità per il servizio Purview centralmente. I domini dati devono ricevere l'autorità delegata per i relativi metadati e concetti aziendali tramite i ruoli purview approvati. Non devono distribuire ambienti Purview separati esclusivamente per ottenere autonomia amministrativa.

Vedere Microsoft Purview domande frequenti.

3.2 Struttura di Purview

Come dovremmo strutturare Purview? L'organizzazione deve stabilire i domini di governance e la struttura Data Map prima che i domini dati inizino a registrare le origini dati e pubblicare i prodotti dati.

• Domini di governance: i domini di governance forniscono il contesto aziendale per i prodotti dati e i concetti correlati. Possono includere termini di glossario, obiettivi e risultati chiave e elementi di dati critici. I domini di governance devono essere inizialmente allineati ai domini dati dell'organizzazione. Usare un perimetro diverso quando la proprietà della governance lo richiede. Vedi Domini di governance.

• Struttura mappa dati: i domini mappa dati devono rappresentare limiti di amministrazione tecnica o ciclo di vita di primo livello. Poiché i domini Data Map sono limitati, usateli per limiti di amministrazione tecnica generali anziché per il mirroring dei domini dati dell'organizzazione.

• Raccolte: le raccolte devono fornire un accesso più granulare ai metadati e all'amministrazione all'interno di un dominio mappa dati. L'organizzazione deve usare le raccolte quando i team operativi devono avere la responsabilità delegata per la registrazione e la scansione delle origini dati. Le raccolte possono anche separare le fonti di produzione da quelle non di produzione qualora tali fonti non giustifichino un altro dominio di Data Map. Ogni origine dati deve essere registrata in una raccolta all'interno di un dominio Data Map. Gli asset analizzati da quella sorgente rimangono associati a tale struttura. L'organizzazione deve quindi definire le regole di posizionamento delle origini prima dell'onboarding generale.

Vedere Domini di governance e raccomandazioni sui domini e Microsoft Purview domini e raccolte e procedure consigliate.