Implementare l'architettura del lakehouse medallion in Microsoft Fabric

  • Articolo

Questo articolo presenta l'architettura del lago medallion e descrive come implementare una lakehouse in Microsoft Fabric. È destinato a più destinatari:

  • Data engineer: personale tecnico che progetta, compila e gestisce infrastrutture e sistemi che consentono all'organizzazione di raccogliere, archiviare, elaborare e analizzare grandi volumi di dati.
  • Centro di eccellenza, IT e team bi: i team responsabili della supervisione dell'analisi in tutta l'organizzazione.
  • Amministratori dell'infrastruttura: amministratori responsabili della supervisione dell'infrastruttura nell'organizzazione.

L'architettura medallion lakehouse, comunemente nota come architettura medallion, è un modello di progettazione usato dalle organizzazioni per organizzare logicamente i dati in una lakehouse. Si tratta dell'approccio di progettazione consigliato per Fabric.

L'architettura medallion comprende tre livelli distinti, o zone. Ogni livello indica la qualità dei dati archiviati nella lakehouse, con livelli più elevati che rappresentano una qualità superiore. Questo approccio multi-layer consente di creare un'unica fonte di verità per i prodotti di dati aziendali.

Importante, l'architettura medallion garantisce il set ACID di proprietà (Atomicità, Coerenza, Isolamento e Durabilità) man mano che i dati progredisce 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 medaglia: bronzo (crudo), argento (convalidato) e oro (arricchito).

Per altre informazioni, vedere What is the medallion lakehouse architecture?.

OneLake e lakehouse in Fabric

La base di un data warehouse moderno è un data lake. Microsoft OneLake, che è un singolo data lake unificato e logico per l'intera organizzazione. Viene eseguito automaticamente il 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 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 una sola copia di dati. Un minor numero di copie dei dati comporta un minor numero di processi di spostamento dei 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 in OneLake.
  • Usare con più 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 Spark. Altre applicazioni non di infrastruttura possono usare API e SDK per accedere anche a OneLake .

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

Per archiviare i dati in OneLake, creare una 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 ridimensionato in volumi di dati di grandi dimensioni e tipi di file e perché vengono archiviati in un'unica posizione, è facilmente condiviso e riutilizzato 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'è una lakehouse in Microsoft Fabric?.

Tabelle e file

Quando si crea una lakehouse in Fabric, viene eseguito automaticamente il provisioning di due percorsi di archiviazione fisici per tabelle e file.

  • Le tabelle sono un'area gestita per ospitare tabelle di tutti i formati in Spark (CSV, Parquet o Delta). Tutte le tabelle, create automaticamente o in modo esplicito, vengono riconosciute come tabelle nella lakehouse. Inoltre, tutte le tabelle Delta, ovvero file di dati Parquet con un log delle transazioni basato su file, vengono riconosciute anche come tabelle.
  • I file sono 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 in una cartella Delta Lake nell'area non gestita, è necessario creare in modo esplicito un collegamento o una tabella esterna con un percorso che punta alla cartella non gestita che contiene i file Delta Lake in Spark.

La principale distinzione 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, Lakehouse Explorer fornisce una rappresentazione grafica unificata dell'intera Lakehouse per consentire agli utenti di spostarsi, accedere e aggiornare i dati.

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

Delta Lake Storage

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 big data e per questo motivo è il formato di archiviazione predefinito in un'infrastruttura lakehouse.

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 vantaggi principali seguenti.

  • Supporto per le proprietà ACID e soprattutto la durabilità per evitare il danneggiamento dei dati.
  • Query di lettura più veloci.
  • Maggiore aggiornamento dei dati.
  • Supporto sia per i carichi di lavoro batch che per i carichi di lavoro di streaming.
  • Supporto per il rollback dei dati usando il tempo di spostamento in Delta Lake.
  • Conformità e controllo normativi migliorati usando la cronologia delle tabelle 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 Tabelle Lakehouse e Delta Lake.

Architettura medallion in Fabric

L'obiettivo dell'architettura medallion è migliorare in modo incrementale e progressivo la struttura e la qualità dei dati man mano che procede attraverso ogni fase.

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

  • Bronzo: noto anche come zona non elaborata, questo primo livello archivia i dati di origine nel formato originale. I dati in questo livello sono in genere di sola accodamento e non modificabili.
  • Argento: noto anche come zona arricchita, questo livello archivia i dati originati dal livello bronzo. I dati non elaborati sono stati puliti e standardizzati e ora sono strutturati come tabelle (righe e colonne). Può anche essere integrato con altri dati per fornire una visualizzazione aziendale di tutte le entità aziendali, ad esempio cliente, prodotto e altri.
  • Oro: noto anche come zona curata, questo livello finale archivia i dati originati dal livello argento. 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 fabric rappresenta una singola zona, si crea una lakehouse per ognuna delle tre zone.

Diagramma di un esempio di architettura di OneLake medallion che mostra le origini dati, la preparazione e la trasformazione con livelli bronze, silver e gold e l'analisi con l'endpoint di analisi SQL e Power BI.

In un'implementazione tipica dell'architettura medallion 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 informazioni su come creare un lakehouse, usare l'esercitazione sullo scenario end-to-end lakehouse.

Materiale sussidiario sul lakehouse dell'infrastruttura

In questa sezione vengono fornite indicazioni relative all'implementazione di Fabric lakehouse tramite l'architettura medallion.

Modello di distribuzione

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

Ecco due modelli da considerare.

  • Modello 1: Creare ogni zona come una lakehouse. In questo caso, gli utenti aziendali accedono ai dati usando l'endpoint di analisi SQL.
  • Modello 2: Creare le zone bronze e silver come lakehouse e la zona oro 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 Infrastruttura, è consigliabile creare ogni lakehouse in un'area di lavoro infrastruttura 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 funzionalità aggiuntive e dei miglioramenti delle prestazioni forniti. L'infrastruttura 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 dell'ordine V nel formato di file Parquet. Questa ottimizzazione consente letture estremamente veloci dai motori di calcolo di Fabric, ad esempio Power BI, SQL, 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, semplificando 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 soddisfare questo obiettivo, prendere in considerazione l'implementazione di un'architettura mesh di dati. La mesh di dati è un modello architetturale incentrato sulla creazione di domini dati che offrono dati come prodotto.

È possibile creare un'architettura di mesh di dati per il proprio patrimonio di dati in Fabric creando domini 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 medallion configurando le zone 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 aggiuntivi relativi all'implementazione di un'architettura lakehouse medallion in Fabric.

Dimensioni file

In genere, una piattaforma 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 delle prestazioni quando il motore di calcolo deve gestire molte operazioni sui metadati e sui file. Per migliorare le prestazioni delle query, è consigliabile puntare ai 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 writer dei dati. Anche se questa funzionalità deve far parte dell'eccellenza operativa e del lavoro di preparazione dei dati, Fabric ha la possibilità di ottimizzare questi file di dati anche durante la scrittura dei 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 cronologici solo per un determinato periodo di tempo per ridurre i costi di archiviazione. Valutare la possibilità di conservare i dati cronologici solo per l'ultimo mese o per un altro periodo di tempo appropriato.

È possibile rimuovere i dati cronologici precedenti da una tabella Delta usando il comando VACUUM. Tenere tuttavia presente che per impostazione predefinita non è possibile eliminare i dati cronologici negli ultimi sette giorni, ovvero 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 ovunque 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 comportano una ricerca più veloce di voci di dati specifiche grazie all'eliminazione/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 contemporaneamente. In tal caso, è possibile eseguire un'operazione 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 nella lakehouse. È anche necessario comprendere i vari modelli di transazione che useranno durante l'accesso a questi dati. È quindi possibile definire lo schema di partizionamento della tabella corretto e la collocazione dei dati con gli indici delta Lake Z order.

Contenuto correlato

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