Modelli e capacità fondamentali di Microsoft OneLake

Questo articolo introduce i modelli OneLake comuni e le capacità della piattaforma che puoi utilizzare per implementarli. Usa le informazioni contenute in questo articolo per riflettere su come vuoi organizzare il tuo ambiente dati, poi scegli i modelli che si adattano alle tue esigenze aziendali, tecniche e di governance.

Ogni pattern descrive come organizzare dati e proprietà per raggiungere un obiettivo architettonico specifico. Per implementare un pattern, si combina una o più capacità fondamentali di OneLake : virtualizzazione dei dati, interoperabilità open data, governance centralizzata e analisi integrate e IA. Ogni funzionalità, a sua volta, si basa su funzionalità specifiche del prodotto come scorciatoie, mirroring, sicurezza OneLake e modalità Direct Lake. La stessa capacità e caratteristica spesso si presenta in più di un pattern.

Note

Questo articolo si basa su modelli identificati nel white paper delle linee guida architettoniche OneLake.

Considera questi cinque motivi come mattoni fondamentali per il tuo progetto OneLake. La maggior parte degli ambienti ne combina più di uno. Scegli i modelli che corrispondono ai tuoi obiettivi:

Accesso unificato ai dati con replica minima

Se i tuoi dati sono distribuiti su più cloud, sistemi on-premises o laghi esterni, copiarli tutti in un unico posto potrebbe non essere pratico - o nemmeno possibile. L'accesso unificato ai dati con un pattern di replicazione minimo tratta OneLake come un unico livello di dati logico tra quelle fonti. Invece di creare pipeline di acquisizione per ogni origine, si utilizzano scorciatoie per fare riferimento ai dati nella loro posizione originale e il mirroring quando serve una copia sincronizzata e ottimizzata per le query.

Usare questo modello quando:

  • I tuoi dati sono distribuiti su più cloud, sistemi on-premises o laghi esterni.
  • Replicare i dati in uno store centrale creerebbe un eccessivo storage, latenza o sovraccarico di conformità.
  • Devi integrare rapidamente nuove sorgenti senza dover creare pipeline complete di extract, transform, load (ETL).
  • Vuoi preservare gli investimenti nei data lake, nei magazzini e nei negozi operativi esistenti.

Applicare l'accesso unificato ai dati

Per mettere in pratica questo schema, inizia con due approcci principali di accesso ai dati che non richiedono di costruire o gestire processi di movimento dati: la virtualizzazione rende disponibili i dati sorgente tramite OneLake senza copiarli, e lo zero-ETL mirroring porta una copia sincronizzata gestita dalla piattaforma in OneLake come tabelle Delta pronte per l'analisi. Usa strumenti di movimento dati Fabric solo quando questi approcci non supportano la fonte o non soddisfano le tue esigenze. Per ulteriori indicazioni sulla scelta e la combinazione di questi approcci, vedere Unificare i dati con le scorciatoie e il mirroring di OneLake.

  1. Inventaria le tue fonti dati per determinare quali OneLake può accedere tramite virtualizzazione o mirroring zero-ETL: archiviazione di oggetti cloud, cataloghi esterni, database operativi e Dataverse. Segnala eventuali fonti rimanenti che richiedono un approccio di spostamento dei dati.

  2. Scegli la tecnica di accesso ai dati giusta per ogni fonte supportata. Preferisci virtualizzazione quando il sorgente supporta l'accesso senza copia. Usa il mirroring zero-ETL quando l'origine richiede una copia sincronizzata ottimizzata per le query:

Dati di origine Come accedervi Trattamento dei dati
Storage di oggetti cloud (Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage) e storage on-premises compatibile con S3 Scorciatoie Virtualizzazione: Rende disponibili i dati sorgente senza copiarli
Dati gestiti in un catalogo esterno che vuoi rendere disponibile senza copiare (ad esempio, Azure Databricks Unity Catalog) Mirroring dei metadati - sincronizza solo i metadati di catalogo (schemi, tabelle) e accede ai dati sorgente tramite scorciatoie Virtualizzazione: Rende disponibili i dati sorgente senza copiarli
Database operativi che necessitano di una copia ottimizzata per query (database SQL di Azure, Azure Cosmos DB, Snowflake, PostgreSQL, SQL Server 2025, Oracle Database, Google BigQuery) Mirroring del database, o open mirroring per soluzioni personalizzate e di partner supportate Zero-ETL mirroring: crea una copia Delta sincronizzata
Dataverse (dati di Dynamics 365 e Power Platform) Scorciatoie o Link a Microsoft Fabric per accesso senza copia Virtualizzazione: Rende disponibili i dati sorgente senza copiarli

  1. Trasforma i dati sorgente quando necessario. Le trasformazioni dei collegamenti possono elaborare i file supportati esposti tramite un collegamento, sia che siano archiviati esternamente sia che siano già presenti in OneLake. Usa le trasformazioni di file con collegamenti per convertire i file strutturati in tabelle Delta oppure le trasformazioni di IA con collegamenti per elaborare testi non strutturati. Le trasformazioni scorciatoie creano output Delta trasformato e lo mantengono sincronizzato con i dati riferiti dalla scorciatoia.

  2. Usa strumenti di movimento dati Fabric quando virtualizzazione e mirroring non supportano una sorgente o quando hai bisogno di trasformazioni complesse, orchestrazione, una cadenza di movimento programmata o ingestione di streaming. Per aiuto nella scelta tra pipeline, dataflow, copy jobs ed eventstream, vedi Scegli una strategia di movimento dati.

Quando scegli di effettuare lo spostamento dei dati, salva i dati copiati in un formato di tabella aperto, come Delta Parquet o Iceberg. Il mirroring e le trasformazioni scorciatoie già generano output Delta. L'uso di formati open mantiene i dati virtualizzati, le copie sincronizzate e l'output Delta trasformato leggibili dai motori Fabric e dalle piattaforme esterne.

  1. Registra il motivo ogni volta che crei una copia sincronizzata, un output Delta trasformato o una copia tramite gli strumenti di spostamento dati di Fabric. Questo documento mantiene la decisione verificabile. Crea una copia solo quando una fonte ha bisogno di un layout fisico, ottimizzato per le query, o non riesce a soddisfare virtualmente i tuoi requisiti di freschezza, costi di trasformazione, conformità o elaborazione.

  2. Applicare la sicurezza OneLake ai dati resi disponibili tramite OneLake in modo che le stesse politiche coprano dati virtualizzati, copie sincronizzate e output Delta trasformato.

  3. Approva e descrivi gli elementi di dati risultanti nel catalogo OneLake affinché i consumatori possano trovarli e fidarsi.

Capacità di accesso unificato ai dati

  • Virtualizzazione dei dati e mirroring zero-ETL - Espongono dati presenti in altri sistemi e cloud tramite riferimenti senza necessità di copia o copie sincronizzate pronte per le analisi. Caratteristiche
  • Governance centralizzata - Applica criteri di sicurezza e discovery uniformi alle fonti virtualizzate, così come ai dati nativi di OneLake. Caratteristiche
  • Interoperabilità dei dati aperti - Mantieni i dati virtualizzati e le copie gestite dalla piattaforma leggibili sia dai motori Fabric che dalle piattaforme esterne. Caratteristiche

Architettura medaglione (bronzo, argento, oro)

Rendere disponibili i dati in OneLake è solo il primo passo. I dati grezzi provenienti dai sistemi sorgente di solito non sono sicuri da usare direttamente per analisi o intelligenza artificiale. Spesso contiene duplicati, errori, formati incoerenti o campi sensibili. Quando più team costruiscono sugli stessi dati sorgente, hanno bisogno di una definizione condivisa di ciò per cui ogni fase dei dati è affidabile.

Il motivo architettonico a medaglione organizza i dati in OneLake in tre livelli di qualità: bronzo per i dati di origine grezzi e immutabili; argento per dati purificati e conformi; e oro per tabelle certificate e pronte per l'azienda, e modelli semantici. Ogni livello è una fase definita su cui i consumatori a valle possono contare. Le tabelle silver e gold sono riutilizzabili tra i carichi di lavoro di BI, analisi e IA, quindi i team non devono ricreare la stessa logica di pulizia dei dati o di modellazione in strumenti separati.

Usare questo modello quando:

  • Più team costruiscono sugli stessi dati di origine e necessitano di una qualità costante.
  • Serve una discendenza tracciabile dagli input grezzi agli output certificati.
  • Serve un contratto chiaro tra i consumatori di data engineering e analytics o di intelligenza artificiale.

Per maggiori informazioni su questo modello, vedi Comprendere l'architettura medaglione per Fabric con OneLake. Quell'articolo tratta la progettazione dei livelli, i modelli di deployment, i formati di archiviazione, le viste dei laghi materializzati e l'ottimizzazione delle tabelle Delta.

Come applicarlo

Un medaglione funzionante si basa su un'idea: ogni livello è un contratto con i consumatori a valle, e i dati avanzano al livello successivo solo dopo aver rispettato gli standard di qualità di quel livello.

  1. Identifica le tue fonti di dati grezzi e gli utenti che dipendono da dati certificati.

  2. Definisci cosa appartiene a ogni livello e applica queste definizioni in modo coerente tra i domini:

    Livello Contenuto Consumatori tipici
    Bronzo Dati grezzi e immutabili catturati direttamente da fonti senza applicazione dello schema Ingegneri dati (accesso limitato)
    Argento Ripulito, deduplicato e allineato a definizioni aziendali condivise Ingegneri dei dati e analisti qualificati
    Oro Tabelle e modelli semantici curati e pronti per il business Tutti consumatori di BI, analytics e IA

  3. Creare ogni livello con il workload di Fabric appropriato, in genere Data Engineering (Spark) o Data Factory per i livelli bronze e silver, e Data Warehouse o i modelli semantici di Power BI per il livello gold. Preservare la fedeltà della sorgente in bronzo utilizzando il formato originale, una scorciatoia per i dati di origine, Parquet o Delta se appropriato. Usa le tabelle Delta per argento e oro così i carichi di lavoro Fabric possono leggere e scrivere in modo affidabile i dati raffinati.

  4. Applica politiche di accesso consapevoli dei livelli. Usa la sicurezza OneLake per gli elementi supportati e i permessi Fabric e SQL applicabili per i warehouse. Limitare l'accesso al bronzo, rendere l'argento disponibile agli analisti e concedere l'accesso all'oro in base alle esigenze dei consumatori e agli standard di minimo privilegio.

  5. Usa output di riferimento selezionati per le analisi successive. Costruisci modelli semantici a livello oro in modalità Direct Lake così Power BI può leggere i dati OneLake senza creare una copia importata o richiedere aggiornamenti programmati.

  6. Conferma che ogni produzione d'oro abbia una discendenza tracciabile attraverso l'argento fino alle sue fonti di bronzo. Poi, approva le tabelle del livello Gold e i modelli semantici come certificati nel catalogo OneLake. Questa validazione aiuta i consumatori a identificare quali dati sono pronti per l'uso in produzione.

  7. Riutilizza modelli semantici dorati per avviare le ontologie Fabric IQ. Questo passaggio fornisce agli agenti AI un contesto aziendale governato basato su dati certificati.

Funzionalità fondamentali

  • Analisi e IA integrate - i livelli Bronze, Silver e Gold alimentano ogni carico di lavoro di analisi e IA in OneLake senza copie specifiche del motore. Caratteristiche
  • Governance centralizzata - Applicare diverse politiche di accesso e porte di qualità a ogni livello affinché i consumatori vedano solo i dati appropriati al loro ruolo. Caratteristiche
  • Interoperabilità dei dati aperti - Memorizzare i livelli in formati aperti così che i motori esterni possano leggerli insieme a Fabric. Caratteristiche

Data mesh basata sul dominio su una piattaforma condivisa

Se hai più team aziendali che producono e consumano dati, instradare ogni richiesta attraverso un unico team centrale di dati può rallentare la consegna. I team aziendali spesso comprendono meglio i propri dati e requisiti, ma la decentralizzazione della proprietà senza una governance condivisa può portare a una sicurezza, qualità e lineage incoerenti.

Il modello data mesh orientato ai domini attribuisce a ogni dominio aziendale la proprietà dei propri prodotti di dati, mentre tutti i domini seguono standard condivisi sulla base di OneLake. Ogni dominio pubblica i propri prodotti dati, e altri domini vi accedono tramite scorciatoie e li consumano con Fabric analytics e carichi di lavoro AI. Le politiche centralizzate di identità, sicurezza e governance si applicano uniformemente in tutti i domini.

Usare questo modello quando:

  • Un singolo team centrale di dati diventa un collo di bottiglia per la consegna.
  • Diversi domini di business hanno dati, requisiti e tempi di rilascio distinti.
  • È necessaria una chiara responsabilità per la qualità dei dati a livello di dominio senza rinunciare alla governance aziendale.

Adottare un data mesh basato sui domini

Trova il giusto equilibrio tra decentralizzazione e coerenza. Trasferire la proprietà al dominio che conosce meglio i dati e mantenere identità, sicurezza e discendenza centralizzate affinché i prodotti dati di ogni dominio rispettino gli stessi standard.

  1. Identifica i tuoi domini aziendali. Ogni dominio dovrebbe rappresentare un'area coerente dell'azienda con un team in grado di possedere e gestire i propri prodotti dati end-to-end.

  2. Crea un dominio per ogni area di business e assegna gli spazi di lavoro. Configura un dominio centrale separato per infrastrutture condivise e dati aziendali riutilizzabili.

  3. Definire standard di prodotto dati che ogni dominio deve rispettare - ad esempio, requisiti di approvazione o certificazione, schemi documentati, metadati di proprietà, versioning e accordi di livello di servizio (SLA). Questi standard rendono ogni prodotto un contratto riutilizzabile e facilmente individuabile, piuttosto che una semplice cartella dell’area di lavoro.

  4. Usa la sicurezza OneLake per applicare controlli di accesso ai dati basati su ruoli a livello di cartelle, tabelle, righe e colonne, così i produttori possono pubblicare prodotti dati senza esporre tutto nel loro spazio di lavoro.

  5. Applica la governance a livello dell'intero tenant con il catalogo OneLake per l'individuazione e la tracciabilità tra domini, e Microsoft Purview per le etichette di riservatezza e l'audit. Estendere lo stesso modello di identità e criteri agli agenti IA che consumano prodotti di dati di dominio, così che l'accesso degli agenti sia regolato come quello di qualsiasi altro consumatore.

  6. Fare in modo che i domini consumer usino scorciatoie per fare riferimento ai prodotti di dati dei producer anziché copiarli. Gli utenti possono quindi usare i prodotti dati referenziati nel workload di Fabric più adatto alle loro esigenze. Per i modelli semantici di Power BI, si utilizza la modalità Direct Lake per leggere i dati direttamente da OneLake. Usa Fabric Data Agents o Fabric IQ per creare esperienze di IA basate su prodotti dati a dominio governato.

  7. Se i domini pubblicano in cataloghi esterni a Fabric, pianifica la sincronizzazione del controllo accessi in modo che i permessi rimangano coerenti tra OneLake e il catalogo esterno.

    Tip

    L'acceleratore open source di Microsoft Policy Weaver può automatizzare questa sincronizzazione per Azure Databricks (Unity Catalog), Snowflake e sorgenti Dataverse. Rispecchia le politiche di accesso ai dati nei ruoli di sicurezza di OneLake, a complemento della funzione di mirroring (che sposta i dati ma non le autorizzazioni).

Capacità del data mesh

  • Governance centralizzata - Decentralizza la proprietà ai domini mantenendo centralizzata identità, sicurezza e discendenza. Caratteristiche
  • Virtualizzazione dei dati - Permette ai domini consumer di utilizzare prodotti dati di proprietà del produttore tramite riferimenti piuttosto che copie. Caratteristiche
  • Analisi integrate e IA - Rendere i prodotti dati di ogni dominio consumabili su tutti i carichi di lavoro Fabric. Caratteristiche

Consolidamento della piattaforma per analisi e IA

Se gestisci più piattaforme di analisi affiancate - strumenti separati per data warehousing, business intelligence, data science, analisi in tempo reale e IA - ogni strumento ha le proprie copie di dati, pipeline e modello di governance. Questa frammentazione aumenta i costi e rende difficile applicare una sicurezza coerente o ottenere una singola risposta a una domanda aziendale.

Il pattern di consolidamento della piattaforma porta questi carichi di lavoro su Fabric, dove OneLake fornisce una base di dati condivisa e governata. I carichi di lavoro Fabric accedono, trasformano, sincronizzano o analizzano i dati tramite questa base invece di affidarsi a modelli separati di dati e governance per ogni strumento.

Usare questo modello quando:

  • Stai usando più piattaforme di analisi con capacità sovrapposte.
  • Le copie dei dati e le pipeline specifiche di ciascun motore comportano costi e un maggiore onere di manutenzione.
  • Serve un unico modello di governance e sicurezza per tutti i carichi di lavoro di analytics e AI.

Applica la consolidazione della piattaforma

Punta a meno piattaforme, non a più integrazioni. Consolida i carichi di lavoro in Fabric invece di collegare gli strumenti, e collega i motori esterni solo quando non puoi ancora ritirarli.

  1. Inventaria gli strumenti e i pipeline di analytics, data warehousing, data science, business intelligence (BI) e AI che utilizzi oggi. Annota quali carichi di lavoro ogni strumento serve e quali dati copia.

  2. Associare ogni carico di lavoro esistente al carico di lavoro di Fabric che può sostituirlo:

    Carico di lavoro esistente Carico di lavoro di Fabric
    Orchestrazione dei dati e ETL Data Factory
    Notebook Spark ed elaborazione lakehouse Ingegneria dei dati
    Stoccaggio dati SQL Data Warehouse
    Streaming e analisi KQL Intelligence in tempo reale
    Addestramento del modello ML e tracciamento degli esperimenti Data Science
    Banche dati operativi Database (database SQL in Fabric e Cosmos DB in Fabric)
    Visualizzazione BI e modelli semantici Power BI con modalità Direct Lake
    IA conversazionale basata su dati aziendali Fabric Data Agents, Copilot per Fabric, Fabric IQ

  3. Stabilire un unico modello di governance e sicurezza su tutti i carichi di lavoro utilizzando la sicurezza OneLake, Microsoft Purview e il catalogo OneLake. Configurare le chiavi gestite dal cliente quando gli elementi Fabric supportati richiedono un ulteriore livello di crittografia.

  4. Consolida i dati analitici in OneLake utilizzando il formato Delta o Iceberg in modo che i carichi di lavoro possano condividere una base dati governata. Includere carichi di lavoro operativi consolidandoli su database Fabric, che rendono disponibili dati analitici sincronizzati in OneLake.

  5. Basa l'IA sui dati consolidati. Costruisci ontologie (anteprima) sopra il tuo livello dati curato ed esponile agli agenti tramite il server Ontology MCP, così Fabric Data Agents, Microsoft 365 Copilot e strumenti esterni ragionano sullo stesso contesto governato. Puoi generare definizioni di ontologie da modelli semantici Power BI in modalità Import, Direct Lake o DirectQuery. Usa la modalità Direct Lake quando hai bisogno di binding generati per dati OneLake supportati e ripassa le limitazioni attuali dell'ontologia.

  6. Per motori esterni che non puoi ancora ritirare, esponi i dati OneLake tramite l'integrazione Azure Databricks, l'interoperabilità Iceberg con Snowflake, o l'accesso e le API OneLake.

  7. Ritira gli strumenti, le copie di dati e le pipeline sostituiti dopo aver validato l'equivalente Fabric. In questo modo il consolidamento elimina i costi, le licenze e i passaggi di consegne invece di aggiungere un'altra piattaforma all'elenco.

Capacità di consolidamento della piattaforma

Condivisione esterna dei dati tra organizzazioni

Se scambi dati con partner, fornitori, clienti o altre divisioni in modo continuativo, esportazioni batch, trasferimenti di file e sistemi duplicati a valle aggiungono lacune di latenza, costi e governance. Il modello di condivisione dei dati esterni offre ai consumatori esterni alla tua organizzazione o divisione business accesso diretto ai dati curati di OneLake senza esportazioni ricorrenti. I consumatori possono accedere ai dati tramite condivisione cross-tenant Fabric o tramite piattaforme di analisi esterne come Snowflake e Azure Databricks utilizzando le capacità di interoperabilità di OneLake.

I consumatori vedono gli aggiornamenti mentre li pubblichi. Controlli l'accesso ai dati sorgente tramite il meccanismo di condivisione o interoperabilità che supporta la piattaforma del consumatore.

Usare questo modello quando:

  • Scambi dati con organizzazioni esterne in modo continuativo.
  • Le esportazioni batch o i trasferimenti di file aggiungono latenza, complessità o lacune di governance.
  • Devi tracciare e revocare centralmente l'accesso esterno.

Applicare la condivisione esterna dei dati

La condivisione esterna funziona meglio quando usi la virtualizzazione invece che l'esportazione dei dati. Abbina il metodo di accesso a ciò che ogni consumatore può leggere e applica i controlli di accesso supportati da quel meccanismo di condivisione o interoperabilità.

  1. Identifica i prodotti dati che vuoi condividere esternamente e i consumatori che ne hanno bisogno (partner, fornitori, clienti). Di solito, si condividono tabelle e file curati ben definiti e documentati.

  2. Scegli l'approccio giusto per la condivisione per ogni consumatore:

    Tipo di consumatore Approccio consigliato
    Utenti di Fabric in un altro tenant Condivisione esterna dei dati per accesso cross-tenant virtualizzato in sola lettura
    Snowflake su utenti Azure Interoperabilità Iceberg con Snowflake per leggere le tabelle Fabric esposte in formato Iceberg
    Utenti di Azure Databricks Federazione del catalogo OneLake in Azure Databricks per interrogare le tabelle OneLake tramite Unity Catalog senza copiare i dati
    Applicazioni o strumenti che supportano ADLS Gen2 o API Blob Accesso OneLake e API per accedere ai dati OneLake tramite API supportate

    Per portare i dati di Dataverse in OneLake prima di condividerli, usa il modello di accesso unificato ai dati.

  3. Definisci l'ambito dell'accesso esterno in base alle autorizzazioni supportate dal meccanismo di condivisione selezionato. Per la condivisione esterna dei dati Fabric, la condivisione garantisce l'accesso in sola lettura a qualsiasi utente del tenant di origine dell'utente invitato. I criteri di sicurezza e governance lato provider, tra cui la sicurezza di OneLake, le etichette di riservatezza e i criteri di prevenzione della perdita di dati, non vengono applicati nel tenant del consumatore. Il consumatore deve gestire l'accesso a valle nel proprio ambiente.

  4. Concordate fin dall'inizio i termini di ogni relazione di condivisione: cosa si condivide, con chi e per quanto tempo. Per la condivisione dati esterna di Fabric, revoca l'accesso dalla scheda Condivisioni dati esterne nella pagina Gestione permessi. Per altri approcci, revoca l'accesso tramite il meccanismo di condivisione selezionato. Conferma che il consumatore perde visibilità.

  5. Applica etichette di sensibilità, audit e prevenzione della perdita di dati con Microsoft Purview nell'ambiente Fabric del fornitore.

  6. Approva e documenta i prodotti di dati sorgente nel catalogo OneLake così che i fornitori possano trovarli e governarli prima di condividerli. Il catalogo OneLake non pubblica prodotti di dati a tenant esterni o piattaforme di analisi.

Capacità di condivisione dati esterne

  • Virtualizzazione dei dati - Condividi i dati tramite riferimenti senza copia senza gestire pipeline di esportazione. Caratteristiche
  • Interoperabilità dei dati aperti - Condividi con i consumatori che non usano Fabric pubblicando in formati aperti. Caratteristiche
  • Governance centralizzata - Governare i dati sorgente in Fabric e controllare l'accesso esterno tramite ogni meccanismo di condivisione. Caratteristiche
    • La sicurezza di OneLake limita l'accesso ai dati di origine in Fabric.
    • Microsoft Purview applica etichette di sensibilità, audit e prevenzione della perdita di dati nell'ambiente Fabric del fornitore.
    • Il catalogo OneLake supporta la scoperta e l'approvazione lato fornitore prima della condivisione.
  • Last updated on