Condividi tramite

Implementare l'architettura a medaglione del lakehouse in Microsoft Fabric

  • Articolo

Questo articolo presenta l'architettura a medaglione del lake e descrive il modo in cui è possibile implementare un lakehouse in Microsoft Fabric. È pensato per più gruppi di destinatari:

  • Ingegneri dei dati: personale tecnico che progetta, compila e gestisce infrastrutture e sistemi che consentono all'organizzazione di raccogliere, archiviare, elaborare e analizzare grandi volumi di dati.
  • Center of Excellence, IT e team BI: i team responsabili della supervisione dell'analisi in tutta l'organizzazione.
  • Amministratori Fabric: amministratori responsabili della supervisione Fabric nell'organizzazione.

L'architettura a medaglione del lakehouse, comunemente nota come architettura a medaglione, è uno schema progettuale usato dalle organizzazioni per organizzare logicamente i dati in un lakehouse. È l'approccio di progettazione consigliato per Fabric.

L'architettura a medaglione comprende tre livelli distinti, o zone. Ogni livello indica la qualità dei dati archiviati nel lakehouse: i livelli più elevati rappresentano una qualità superiore. Questo approccio multi-livello consente di creare un'unica origine di riferimento per i prodotti di dati aziendali.

In particolare, l'architettura a medaglione garantisce il set di proprietà atomicità, coerenza, isolamento e durabilità (ACID) man mano che i dati progrediscono attraverso i livelli. A partire dai dati non elaborati, una serie di convalide e trasformazioni prepara i dati ottimizzati per l'analisi efficiente. Ci sono tre fasi di medaglione: bronzo (non elaborati), argento (convalidati) e oro (arricchiti).

Per altre informazioni, vedere Che cos'è l'architettura a medaglione del lakehouse?.

OneLake e lakehouse in Fabric

La base di un data warehouse moderno è un data lake. Microsoft OneLake, che è un singolo data lake logico unificato per l'intera organizzazione. Viene sottoposto automaticamente a provisioning con ogni tenant di Fabric ed è progettato per essere l'unica posizione per tutti i dati di analisi.

È possibile usare OneLake per:

  • Rimuovere i silo e ridurre il lavoro di gestione. Tutti i dati dell'organizzazione vengono archiviati, gestiti e protetti all'interno di una risorsa di data lake. Poiché viene effettuato il provisioning di OneLake con il tenant di Fabric, non sono disponibili altre risorse per il provisioning o la gestione.
  • Ridurre lo spostamento e la duplicazione dei dati. L'obiettivo di OneLake è archiviare solo una copia dei dati. Un minor numero di copie dei dati comporta un minor numero di processi di spostamento dati e ciò comporta miglioramenti nell'efficienza e riduzione della complessità. Se necessario, è possibile creare un collegamento per fare riferimento ai dati archiviati in altre posizioni, anziché copiarli su OneLake.
  • Uso con molteplici motori analitici. I dati in OneLake vengono archiviati in un formato aperto. In questo modo, i dati possono essere sottoposti a query da vari motori analitici, tra cui Analysis Services (usato da Power BI), T-SQL e Apache Spark. Anche altre applicazioni non appartenenti a Fabric possono usare API e SDK per accedere a OneLake.

Per altre informazioni, vedere OneLake, il OneDrive per i dati.

Per archiviare i dati in OneLake, si crea un lakehouse in Fabric. Un lakehouse è una piattaforma di architettura dei dati per l'archiviazione, la gestione e l'analisi di dati strutturati e non strutturati in un'unica posizione. Può essere facilmente scalabile in grandi volumi di dati di tutti i tipi e dimensioni di file e poiché vengono archiviati in un'unica posizione, vengono facilmente condivisi e riutilizzati nell'organizzazione.

Ogni lakehouse ha un endpoint di analisi SQL predefinito che sblocca le funzionalità del data warehouse senza la necessità di spostare i dati. Ciò significa che è possibile eseguire query sui dati nel lakehouse usando query SQL e senza alcuna configurazione speciale.

Per altre informazioni, vedere Che cos'è un lakehouse in Microsoft Fabric?.

Tabelle e file

Quando si crea un lakehouse in Fabric, viene eseguito automaticamente il provisioning di due posizioni di archiviazione fisiche per tabelle e file.

  • La sezione Tabelle è un'area gestita per ospitare tabelle di tutti i formati in Apache Spark (CSV, Parquet o Delta). Tutte le tabelle, create automaticamente o in modo esplicito, vengono riconosciute come tabelle nel lakehouse. Inoltre, anche tutte le tabelle Delta, ovvero file di dati Parquet con un log delle transazioni basato su file, vengono riconosciute come tabelle.
  • La sezione File è un'area non gestita per l'archiviazione dei dati in qualsiasi formato di file. Tutti i file Delta archiviati in questa area non vengono riconosciuti automaticamente come tabelle. Se si vuole creare una tabella su una cartella Delta Lake nell'area non gestita, sarà necessario creare in modo esplicito un collegamento o una tabella esterna con una posizione che indirizza alla cartella non gestita che contiene i file Delta Lake in Apache Spark.

La distinzione principale tra l'area gestita (tabelle) e l'area non gestita (file) è il processo di individuazione e registrazione automatica delle tabelle. Questo processo viene eseguito su qualsiasi cartella creata solo nell'area gestita, ma non nell'area non gestita.

In Microsoft Fabric, il Lakehouse Explorer fornisce una rappresentazione grafica unificata dell'intero Lakehouse per consentire agli utenti di spostarsi, accedere e aggiornare i dati.

Per altre informazioni sull'individuazione automatica delle tabelle, vedere Individuazione automatica delle tabelle e registrazione.

Archiviazione su Delta Lake

Delta Lake è un livello di archiviazione ottimizzato che fornisce le basi per l'archiviazione di dati e tabelle. Supporta transazioni ACID per carichi di lavoro di big data e per questo motivo è il formato di archiviazione predefinito in un lakehouse di Fabric.

In particolare, Delta Lake offre affidabilità, sicurezza e prestazioni nel lakehouse per le operazioni di streaming e batch. Internamente, archivia i dati in formato di file Parquet, ma mantiene anche i log delle transazioni e le statistiche che forniscono funzionalità e miglioramenti delle prestazioni rispetto al formato Parquet standard.

Il formato Delta Lake rispetto ai formati di file generici offre i seguenti vantaggi principali.

  • Supporto per le proprietà ACID e in particolare la durabilità per evitare il danneggiamento dei dati.
  • Query di lettura più veloci.
  • Maggiore freschezza dei dati.
  • Supporto per i carichi di lavoro in batch e in streaming.
  • Supporto per il ripristino dello stato precedente dei dati usando lo spostamento cronologico di Delta Lake.
  • Conformità e controllo normativi migliorati usando la cronologia delle tabelle di Delta Lake.

Fabric standardizza il formato di file di archiviazione con Delta Lake e, per impostazione predefinita, ogni motore del carico di lavoro in Fabric crea tabelle Delta quando si scrivono dati in una nuova tabella. Per altre informazioni, vedere Lakehouse e tabelle Delta Lake.

Architettura a medaglione in Fabric

L'obiettivo dell'architettura a medaglione è migliorare in modo incrementale e progressivo la struttura e la qualità dei dati man mano che procedono attraverso ogni passaggio.

L'architettura a medaglione è costituita da tre livelli distinti (o zone).

  • Bronze: noto anche come zona di dati non elaborati, questo primo livello archivia i dati di origine nel formato originale. I dati in questo livello sono in genere di solo accodamento e non modificabili.
  • Silver: noto anche come zona di dati arricchiti, questo livello archivia i dati originati dal livello Bronze. I dati non elaborati sono stati puliti e standardizzati, e ora sono strutturati come tabelle (righe e colonne). Potrebbero anche essere integrati con altri dati per fornire una visualizzazione aziendale di tutte le entità aziendali, ad esempio cliente, prodotto e altri.
  • Gold: noto anche come zona di dati curati, questo livello finale archivia i dati originati dal livello Silver. I dati vengono perfezionati per soddisfare specifici requisiti di analisi e business downstream. Le tabelle sono in genere conformi alla progettazione dello schema star, che supporta lo sviluppo di modelli di dati ottimizzati per prestazioni e usabilità.

Importante

Poiché un lakehouse di Fabric rappresenta una singola zona, si crea un lakehouse per ognuna delle tre zone.

Diagramma dell'architettura a medaglione di OneLake che mostra le origini dati, la preparazione e la trasformazione con tre livelli e l'analisi con SQL e Power BI.

In un'implementazione tipica dell'architettura a medaglione in Fabric, la zona Bronze archivia i dati nello stesso formato dell'origine dati. Quando l'origine dati è un database relazionale, le tabelle Delta sono una scelta ottimale. Le zone Silver e Gold contengono tabelle Delta.

Suggerimento

Per scoprire come creare un lakehouse, consultare l'esercitazione Scenario end-to-end per lakehouse.

Materiale sussidiario sul lakehouse di Fabric

Questa sezione offre indicazioni relative all'implementazione del lakehouse di Fabric usando l'architettura a medaglione.

Modello di distribuzione

Per implementare l'architettura a medaglione in Fabric, è possibile usare lakehouse (una per ogni zona), un data warehouse o una combinazione di entrambi. La decisione deve essere basata sulle preferenze e sull'esperienza del team. Fabric offre flessibilità: è possibile usare motori di analisi diversi che funzionano su una copia dei dati in OneLake.

Ecco due criteri da considerare.

  • Criterio 1: Creare ogni zona come un lakehouse. In questo caso, gli utenti aziendali accedono ai dati usando l'endpoint di analisi SQL.
  • Criterio 2: Creare le zone Bronze e Silver come lakehouse e la zona Gold come data warehouse. In questo caso, gli utenti aziendali accedono ai dati usando l'endpoint del data warehouse.

Anche se è possibile creare tutti i lakehouse in un'unica area di lavoro di Fabric, è consigliabile creare ogni lakehouse in un'area di lavoro di Fabric separata. Questo approccio offre un maggiore controllo e una migliore governance a livello di zona.

Per la zona Bronze, è consigliabile archiviare i dati nel formato originale oppure usare Parquet o Delta Lake. Quando possibile, mantenere i dati nel formato originale. Se i dati di origine provengono da OneLake, Azure Data Lake Store Gen2 (ADLS Gen2), Amazon S3 o Google, creare un collegamento nella zona Bronze invece di copiare i dati.

Per le zone Silver e Gold, è consigliabile usare tabelle Delta a causa delle capacità aggiuntive e dei miglioramenti delle prestazioni forniti. Fabric standardizza in formato Delta Lake e per impostazione predefinita ogni motore in Fabric scrive i dati in questo formato. Inoltre, questi motori usano l'ottimizzazione del tempo di scrittura V-order nel formato di file Parquet. Questa ottimizzazione consente letture estremamente veloci da parte dei motori di calcolo di Fabric, come Power BI, SQL, Apache Spark e altri. Per altre informazioni, vedere Ottimizzazione tabella Delta Lake e V-Order.

Infine, oggi molte organizzazioni affrontano una forte crescita dei volumi di dati, insieme a una crescente necessità di organizzare e gestire tali dati in modo logico, facilitando al contempo un uso e una governance più mirati ed efficienti. Ciò può portare a stabilire e gestire un'organizzazione di dati decentralizzata o federata con governance.

Per raggiungere questo obiettivo, occorre prendere in considerazione l'implementazione di un'architettura per il mesh dei dati. La mesh dei dati è uno schema architetturale incentrato sulla creazione di domini di dati che offrono dati come prodotto.

È possibile creare un'architettura per il mesh dei dati per il proprio patrimonio di dati in Fabric creando domini di dati. È possibile creare domini che eseguono il mapping ai domini aziendali, ad esempio marketing, vendite, inventario, risorse umane e altri. È quindi possibile implementare l'architettura a medaglione configurando zone di dati all'interno di ogni dominio.

Per altre informazioni sui domini, vedere Domini.

Informazioni sull'archiviazione dei dati delle tabelle Delta

Questa sezione descrive altri argomenti relativi all'implementazione di un'architettura a medaglione del lakehouse in Fabric.

Dimensioni file

In genere, una piattaforma di big data offre prestazioni migliori quando ha un numero ridotto di file di grandi dimensioni, anziché un numero elevato di file di piccole dimensioni. Ciò è dovuto al fatto che si verifica una riduzione del livello delle prestazioni quando il motore di calcolo deve gestire molte operazioni sui metadati e sui file. Per migliorare le prestazioni delle query, è consigliabile puntare a file di dati di dimensioni di circa 1 GB.

Delta Lake ha una funzionalità denominata ottimizzazione predittiva. L'ottimizzazione predittiva elimina la necessità di gestire manualmente le operazioni di manutenzione per le tabelle Delta. Quando questa funzionalità è abilitata, Delta Lake identifica automaticamente le tabelle che potrebbero trarre vantaggio dalle operazioni di manutenzione e quindi ne ottimizza lo spazio di archiviazione. Può unire in modo trasparente molti file più piccoli in file di grandi dimensioni e senza alcun impatto su altri lettori e scrittori dei dati. Anche se questa funzionalità deve far parte dell'eccellenza operativa e del lavoro di preparazione dei dati, Fabric ha la capacità di ottimizzare questi file di dati anche durante la scrittura dati. Per altre informazioni, vedere Ottimizzazione predittiva per Delta Lake.

Conservazione cronologica

Per impostazione predefinita, Delta Lake mantiene una cronologia di tutte le modifiche apportate. Ciò significa che le dimensioni dei metadati cronologici aumentano nel tempo. In base ai requisiti aziendali, è consigliabile mantenere i dati storici solo per un determinato periodo di tempo per ridurre i costi di archiviazione. Valutare la possibilità di conservare i dati storici solo per l'ultimo mese o per un altro periodo di tempo appropriato.

È possibile rimuovere i dati storici più vecchi da una tabella Delta usando il comando VACUUM. Tuttavia, occorre tenere presente che per impostazione predefinita non è possibile eliminare i dati storici negli ultimi sette giorni, al fine di mantenere la coerenza nei dati. Il numero predefinito di giorni è controllato dalla proprietà delta.deletedFileRetentionDuration = "interval <interval>" della tabella. Determina il periodo di tempo in cui un file deve essere eliminato prima che possa essere considerato un candidato per un'operazione VACUUM.

Partizioni di tabella

Quando si archiviano i dati in ogni zona, è consigliabile usare una struttura di cartelle partizionata, laddove applicabile. Questa tecnica consente di migliorare la gestibilità dei dati e le prestazioni delle query. In genere, i dati partizionati in una struttura di cartelle determinano una ricerca più rapida di voci di dati specifiche grazie all'eliminazione delle partizioni.

In genere, si aggiungono dati alla tabella di destinazione man mano che arrivano nuovi dati. Tuttavia, in alcuni casi, è possibile unire i dati perché è necessario aggiornare i dati esistenti allo stesso tempo. In tal caso, è possibile eseguire un'operazione di upsert usando il comando MERGE. Quando la tabella di destinazione è partizionata, assicurarsi di usare un filtro di partizione per velocizzare l'operazione. In questo modo, il motore può eliminare le partizioni che non richiedono l'aggiornamento.

Accesso ai dati

Infine, è necessario pianificare e controllare chi deve accedere a dati specifici nel lakehouse. È anche necessario comprendere i vari criteri di transazione che verranno usati durante l'accesso a questi dati. È quindi possibile definire lo schema di partizione corretto della tabella e la collocazione dei dati con gli indici di ordine Z di Delta Lake.

Contenuto correlato

Per altre informazioni sull'implementazione di un lakehouse di Fabric, vedere le risorse seguenti.