Architettura medaglione del data warehouse moderno in Microsoft Fabric

Microsoft Fabric

Power BI

Questo carico di lavoro di esempio descrive un'architettura medallion per un modern data warehouse (MDW) basato principalmente su SQL. Un data warehouse moderno usa archivi dati basati su SQL per organizzare i dati strutturati per l'analisi e la creazione di report. Questa architettura implementa i livelli bronzo, argento e oro in Fabric Data Warehouse e usa Fabric Data Factory per orchestrare l'inserimento e la trasformazione dei dati.

Fabric Data Warehouse archivia i dati relazionali in formato Delta in OneLake e supporta lo sviluppo T-SQL tramite tabelle, viste, transazioni e stored procedure. Power BI, client SQL e altre applicazioni utilizzano i dati curati provenienti dal livello gold.

Important

I modelli di medaglie Fabric consigliati usano una lakehouse per ogni strato o utilizzano le case di lago per i livelli bronzo e argento e un magazzino per lo strato d'oro. Questa architettura usa i warehouse per tutti e tre i livelli perché i dati rimangono strutturati e vengono trasformati usando SQL in tutto il processo. I lakehouse sono più adatti per l'elaborazione basata su Spark, i carichi di lavoro di data science e grandi volumi di dati non strutturati o semistrutturati. Per un'implementazione lakehouse-first che supporta i dati Spark e non strutturati, vedere Greenfield lakehouse in Microsoft Fabric.

Architecture

Scaricare un file PowerPoint di questa architettura.

Nel diagramma, il mirroring gestisce la replica del database operativo e le pipeline di Fabric Data Factory acquisiscono dati da origini non replicate con mirroring nel livello bronze.

Flusso di dati

Il flusso di dati seguente corrisponde al diagramma precedente:

I database operativi, le applicazioni SaaS, i file e altri sistemi di origine producono dati.
L'inserimento porta i dati di origine in Fabric attraverso due percorsi. Per i database operativi supportati, il mirroring in Fabric replica continuamente i dati in un elemento del database con mirroring in OneLake. Un passaggio di warehouse CTAS o INSERT ... SELECT salva quindi quei dati nel warehouse bronze. Per i file, le applicazioni SaaS e altre origini senza mirroring, utilizzare le pipeline di Fabric Data Factory o il linguaggio T-SQL del data warehouse, ad esempio COPY INTO, per caricare le tabelle Bronze.
Il livello bronzo archivia dati grezzi, elaborati solo in minima parte, nelle tabelle del data warehouse. I metadati di inserimento, ad esempio timestamp di caricamento e identificatori di origine, supportano il controllo e la rielaborazione.
La prima fase di trasformazione (Bronze to silver) valida e trasforma i dati del livello bronze nel livello silver.
Il livello silver contiene dati ripuliti, deduplicati e standardizzati. Quando è necessaria un'analisi storica, le tabelle silver conservano le modifiche di origine con date di decorrenza e indicatori della riga corrente.
Le stored procedure o i job di dbt in genere implementano la fase Bronze to silver usando pattern SQL come CREATE TABLE AS SELECT (CTAS), INSERT ... SELECT e MERGE.
Il livello oro fornisce schemi a stella pronti per l'uso, data mart e tabelle preaggregate.
La seconda fase di trasformazione (Silver to gold) trasforma i dati del livello silver in entità aziendali, dimensioni, fatti e aggregati nel livello gold.
Power BI utilizza i dati gold tramite modelli semantici. Altri utenti, come i client SQL, i notebook e le applicazioni, possono interrogare l'endpoint SQL del warehouse.

Components

Fabric Data Warehouse fornisce le tabelle relazionali e di calcolo T-SQL per i livelli bronzo, argento e oro.
OneLake archivia i dati del data warehouse in formato Delta e i dati replicati tramite il mirroring di Fabric.
Mirroring in Fabric replica continuamente i database operativi supportati in OneLake.
Fabric Data Factory acquisisce dati e coordina procedure archiviate, pipeline e altre attività di trasformazione.
Power BI fornisce modelli semantici, report e dashboard su dati gold curati.

Indicazioni per la progettazione

Le indicazioni seguenti descrivono come implementare i livelli bronze, silver e gold e organizzare le aree di lavoro di supporto. Adattare queste raccomandazioni alle origini dati e ai requisiti di governance del carico di lavoro e alle competenze del team.

Livello bronzo: inserimento di dati non elaborati

Il livello bronzo inserisce dati non elaborati e acquisisce tutti i dati di origine nel formato originale senza applicare alcuna logica di business. Funge da sistema di record, consentendo la tracciabilità completa e la rielaborazione. Le tabelle in questo livello rispecchiano attentamente gli schemi di origine ed evitano intenzionalmente filtri, deduplicazioni o arricchimenti. Le colonne di metadati facoltative, ad esempio timestamp di inserimento o nomi di file di origine, spesso supportano il controllo.

Per i database operativi supportati, usare il mirroring in Fabric per replicare continuamente le tabelle di origine in OneLake. Per origini costituite da file, SaaS o non supportate, usare le pipeline di Fabric Data Factory, COPY INTO per l'acquisizione in blocco oppure CTAS con OPENROWSET o INSERT ... SELECT per archiviare in modo persistente i dati di file esterni nel data warehouse Bronze.

In questa fase, l'ingestione mantiene al minimo le trasformazioni, in modo che il layer bronze rimanga il sistema di record rieseguibile. Se necessario per le origini senza mirroring, una stored procedure del livello bronze per il caricamento (o un modello dbt equivalente) può standardizzare i record in ingresso e aggiungervi i metadati di caricamento.

Le procedure consigliate per il livello bronze evidenziano la conservazione di tutti i dati non elaborati, inclusi i record non validi, l'uso dell'inserimento batch per evitare problemi di file di piccole dimensioni, l'allineamento degli schemi con i sistemi di origine e l'automazione dei flussi di lavoro di inserimento tramite pipeline di Fabric per garantire coerenza e affidabilità su larga scala.

Livello Silver: pulizia e conformità dei dati

Il livello silver si concentra sulla pulizia e sull'armonizzazione dei dati, perfezionando i dati del livello bronze mediante l'applicazione di regole di qualità dei dati, standardizzazione, deduplicazione e integrazione tra più fonti. In definitiva, produce una singola fonte di verità per i dati puliti e affidabili.

In genere, in questa fase si implementano le trasformazioni usando T-SQL e modelli quali le istruzioni CREATE TABLE AS SELECT (CTAS), INSERT … SELECT e MERGE, per supportare sia l'elaborazione batch sia quella incrementale. Anche se Fabric Data Warehouse non supporta le viste materializzate, è possibile usare viste lake materializzate, implementate tramite Spark, per generare tabelle Delta. L'endpoint di analisi SQL espone queste tabelle Delta come tabelle che il warehouse può leggere.

Le best practice per il livello silver includono la progettazione di trasformazioni idempotenti, l'applicazione coerente delle regole di qualità dei dati e l'uso di MERGE per gli aggiornamenti incrementali. Quando il carico di lavoro richiede la storicizzazione, conservare le versioni delle righe con date di inizio e fine validità e un indicatore della riga corrente. Le dimensioni Gold possono usare questa cronologia per implementare il comportamento della dimensione a modifica lenta del tipo 1 o 2.

Livello Gold: dati curati per l'analisi

Il livello oro offre dati curati e pronti per l'azienda ottimizzati per l'analisi, la creazione di report e l'utilizzo da parte di strumenti di business intelligence, ad esempio Power BI. Questo livello si basa su modelli di modellazione analitica, utilizzando comunemente schemi a stella con tabelle dei fatti e delle dimensioni, data mart specifici per dominio e tabelle di riepilogo pre-aggregate per supportare query ad alte prestazioni e analisi intuitive.

In genere, le tabelle gold si ottengono esclusivamente dai dati silver e si rendono disponibili agli utenti finali e agli strumenti di reporting.

Usare chiavi surrogate stabili per le dimensioni in modo che i fatti non dipendono dalle chiavi di sistema di origine modificabili. Fabric Data Warehouse supporta BIGINT IDENTITY colonne per la generazione di chiavi surrogate. I valori Identity sono univoci, ma non sono garantiti come sequenziali o ordinati e possono verificarsi lacune. Se tali limitazioni non sono adatte al carico di lavoro, generate e archiviate in modo persistente le chiavi surrogate nella logica di trasformazione e mantenete una mappatura persistente per ciascuna chiave naturale. Non rigenerare le chiavi surrogate durante un aggiornamento completo.

Le procedure consigliate per il livello gold includono i dati di modellazione per allinearsi strettamente ai casi d'uso analitici e aziendali, preaggregando i dati dove possibile per migliorare le prestazioni, applicando controlli di sicurezza come la sicurezza a livello di riga, la sicurezza a livello di colonna e la maschera dei dati e documentando accuratamente la derivazione e le trasformazioni dei dati.

Strategia dell'area di lavoro

Una strategia dell'area di lavoro definisce il modo in cui i livelli bronzo, argento e oro sono separati logicamente e fisicamente per bilanciare governance, sicurezza e semplicità operativa. È possibile implementare i livelli usando aree di lavoro separate per livello, che è consigliabile quando sono necessari limiti di sicurezza sicuri, proprietà chiara o rigorosa separazione delle responsabilità. Ad esempio, è consigliabile isolare l'inserimento di dati non elaborati dai dati aziendali curati.

In alternativa, è possibile implementare livelli all'interno di una singola area di lavoro usando magazzini separati per dati bronze, silver e gold. Questo approccio può ridurre il sovraccarico di gestione e semplificare lo sviluppo e il test a più livelli mantenendo al tempo stesso la separazione a livello di magazzino tra i livelli medallion.

La scelta tra questi approcci dipende in genere da fattori quali scalabilità organizzativa, requisiti di sicurezza, struttura del team e maturità della governance. Molte aziende adottano un modello ibrido man mano che l'implementazione Fabric evolve. È consigliabile usare aree di lavoro separate quando sono necessari limiti di isolamento, governance e proprietà.

Linee guida per l'implementazione

Fabric Data Warehouse fornisce coerenza transazionale e elaborazione dati affidabile tra i livelli bronzo, argento e oro. Utilizzare scritture in batch per ridurre al minimo i problemi legati ai file di piccole dimensioni e migliorare l'efficienza di archiviazione e delle query. Usare le istruzioni MERGE per gestire i dati arrivati in ritardo o modificati negli scenari di elaborazione incrementale.

Mantenere le transazioni brevi per ridurre la contenzione e ottimizzare la concorrenza, soprattutto in ambienti con elevati volumi di acquisizione. Monitora attivamente le prestazioni e lo stato operativo usando le informazioni dettagliate sulle query di Fabric e le viste di gestione dinamica (DMV). La separazione dell'architettura dei carichi di lavoro di lettura e scrittura in Fabric consente inoltre l'esecuzione simultanea di processi di inserimento e trasformazione senza bloccare le query analitiche, garantendo prestazioni prevedibili per l'analisi downstream e la creazione di report.

Usa stored procedure T-SQL e pipeline di Fabric Data Factory per la trasformazione SQL nativa e l'orchestrazione. I team che preferiscono modelli e test SQL modulari possono usare l'adattatore dbt gestito Microsoft per Fabric Data Warehouse. Eseguire test univoci, integrità referenziale e valori accettati come controlli di distribuzione o pipeline prima di pubblicare i dati nei livelli downstream.

Alternative

Questa architettura include più componenti che è possibile sostituire con altri servizi o approcci di Azure, a seconda dei requisiti funzionali e non funzionali del carico di lavoro. Prendere in considerazione le alternative seguenti e i relativi compromessi.

Per scenari che enfatizzano la progettazione dei dati su larga scala, l'analisi avanzata, l'apprendimento automatico o i dati non strutturati, un'architettura lakehouse-first in Microsoft Fabric può essere più adatta. In questo approccio, un Fabric lakehouse funge da archivio dati primario in OneLake e le trasformazioni vengono implementate principalmente usando strumenti basati su Spark, ad esempio notebook o Dataflow Gen2. Questo modello fornisce il calcolo distribuito, i notebook e gli strumenti per il machine learning, che non costituiscono l'obiettivo principale di questa architettura di data warehouse incentrata su SQL.

Per le organizzazioni con particolare attenzione all'analisi scientifica dei dati, all'intelligenza artificiale o all'elaborazione distribuita complessa, Azure Databricks è un'altra alternativa. Azure Databricks viene in genere selezionato quando i carichi di lavoro richiedono un'integrazione approfondita con framework di Machine Learning open source, controllo con granularità fine sull'esecuzione di Spark o portabilità multicloud.

Per l'analisi quasi in tempo reale o basata su eventi, Fabric Real-Time intelligence, Hub eventi di Azure o Analisi di flusso di Azure potrebbero essere più adatti rispetto a una progettazione di medallion orientata a batch centrata su Fabric Data Warehouse.

Dettagli dello scenario

Fabric Data Warehouse è una soluzione ideale per questa architettura medallion quando l'obiettivo principale è quello di offrire dati regolati e pronti per l'analisi su larga scala usando modelli SQL familiari.

Scenario 1: Semantica relazionale e prestazioni SQL per set di dati curati e pronti per l'analisi

Fabric Data Warehouse è particolarmente adatto perché fornisce tabelle relazionali e viste, transazioni ACID e operazioni T-SQL sui dati Delta. Questo set di funzionalità supporta i carichi di lavoro in cui i dati sono già puliti e conformi e devono essere sottoposti a query in modo coerente tramite SQL.

Esempio: Una compagnia aerea crea set di dati gold curati per le operazioni di volo e l'analisi dei ricavi. Gli analisti si basano su prestazioni stabili delle query SQL per valutare le tendenze della puntualità, la redditività delle rotte e l'utilizzo del personale di bordo. L'uso di tabelle e viste di warehouse garantisce la coerenza transazionale e il comportamento affidabile delle query, che è più difficile garantire con l'accesso basato su file ad hoc.

Scenario 2: governance centralizzata con un'esperienza incentrata su SQL

Fabric Data Warehouse consente la governance centralizzata tramite autorizzazioni dell'area di lavoro, sicurezza a livello di oggetto e derivazione predefinita, esponendo i dati tramite un'interfaccia SQL familiare ai team di progettazione dell'analisi. Questo approccio riduce l'attrito operativo, semplifica il controllo degli accessi e accelera l'adozione tra i team senza introdurre nuovi paradigmi di accesso.

Esempio: Un'azienda globale applica una rigorosa separazione dei compiti: i team della piattaforma gestiscono l'inserimento e le trasformazioni e i team di analisi usano solo dati curati. Esponendo solo tabelle di livello oro tramite un warehouse e regolando l'accesso centralmente, l'organizzazione evita l'accesso non controllato ai dati non elaborati o intermedi mantenendo al tempo stesso un flusso di lavoro familiare basato su SQL.

Scenario 3: utilizzo ottimizzato per BI per la creazione di report e dashboard

Il data warehouse è ottimizzato per carichi di lavoro con elevata concorrenza e a prevalenza di lettura, il che lo rende una scelta valida quando un gran numero di utenti aziendali consulta dashboard e report basati su modelli semantici coerenti. Questa ottimizzazione è particolarmente importante quando sono necessarie prestazioni, stabilità e comportamento prevedibile delle query durante il picco di utilizzo.

Esempio: I team finanziari e operativi accedono Power BI dashboard durante l'orario di ufficio per monitorare gli indicatori KPI, ad esempio ricavi, efficienza operativa e conformità del contratto di servizio. Fabric Data Warehouse isola i carichi di lavoro SELECT e non-SELECT in pool di calcolo separati, riducendo la contesa diretta tra le query del dashboard e l'ingestione nel data warehouse.

Scenario 4: Supporto per la modellazione dimensionale per un livello oro riutilizzabile

Fabric Data Warehouse si allinea naturalmente ai modelli di modellazione dimensionale, incluse le tabelle dei fatti e delle dimensioni, comunemente usate nel livello oro per esporre set di dati riutilizzabili e descrittivi per l'azienda. Questi modelli semplificano l'analisi, riducono la duplicazione della logica e promuovono definizioni di metriche coerenti tra i team.

Esempio: Un'organizzazione di vendita al dettaglio crea tabelle delle dimensioni condivise per clienti, prodotti e negozi, insieme alle tabelle dei fatti per le vendite e l'inventario. Questi set di dati gold vengono riutilizzati in più report Power BI e business unit, assicurandosi che gli indicatori KPI, ad esempio le vendite nette o il fatturato dell'inventario, vengano definiti una volta e applicati in modo coerente.

Considerations

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere l'elenco di controllo per la revisione della progettazione per l'affidabilità.

Esaminare Affidabilità in Microsoft Fabric per il modello di resilienza documentato, inclusi il comportamento verso il basso e le considerazioni a livello di area. Convalidare le aspettative di ripristino in base a queste linee guida per l'area geografica e i requisiti del carico di lavoro.

Per gli scenari di ripristino di emergenza tra aree, progettare e documentare una strategia di ripristino allineata ai requisiti dell'organizzazione e al modello di responsabilità condivisa.

Fabric Data Warehouse supporta i PRIMARY KEYvincoli di tabella , FOREIGN KEYe UNIQUE solo come NOT ENFORCED. Il magazzino non convalida l'univocità o l'integrità referenziale. La logica di inserimento e trasformazione deve rilevare record duplicati o orfani e impedirne il raggiungimento dei livelli downstream.

Security

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere l'elenco di controllo per la revisione della progettazione per la sicurezza.

Microsoft Fabric offre funzionalità per gestire, controllare e controllare le impostazioni di sicurezza in base ai requisiti dell'organizzazione. Considerare le procedure di sicurezza seguenti:

Usare Microsoft Entra ID Single Sign-On (SSO) per autenticare gli utenti e fornire una gestione coerente delle identità tra dispositivi e posizioni.
Applicare autorizzazioni basate sull'area di lavoro per controllare chi può creare, modificare o utilizzare Fabric artefatti.
Usa i controlli di sicurezza di rete in ingresso e in uscita di Fabric quando accedi a dati o servizi all'interno o all'esterno della tua rete. Questi controlli includono l'accesso condizionale, i collegamenti privati, l'accesso all'area di lavoro attendibile e gli endpoint privati gestiti.
Usa i log di audit di Fabric per tenere traccia delle attività degli utenti, delle modifiche alla configurazione e dell'accesso ai dati nell'intera piattaforma.

Per altre informazioni, consultare Sicurezza in Fabric.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere l'elenco di controllo per la revisione della progettazione per Ottimizzazione costi.

Microsoft Fabric fornisce prenotazioni di capacità per un numero definito di unità di capacità (CU). Le prenotazioni di un anno consentono di ridurre i costi per carichi di lavoro prevedibili e stabili.

Per ottimizzare l'utilizzo della capacità Fabric, prendere in considerazione le procedure seguenti:

Inizia con le capacità di prova o gli SKU F con pagamento in base all'utilizzo per comprendere il comportamento del carico di lavoro. Eseguire una proof of concept circoscritta con carichi di lavoro rappresentativi di acquisizione, trasformazione e reportistica. Monitorare il consumo di CU ed estrapolare i risultati per stimare le esigenze di produzione. È possibile ridimensionare le capacità Fabric man mano che aumenta la domanda.
Analizzare l'utilizzo cronologico per identificare i periodi di picco e di minore attività. Pianificate i carichi di lavoro non critici o in background nelle fasce di minore utilizzo per ridurre la pressione costante sulle CU.
Ridurre il consumo di calcolo non necessario ottimizzando le query SQL, le espressioni di analisi dei dati (DAX) e i processi in background.
Fabric supporta il dimensionamento elastico e la distribuzione uniforme del carico per assorbire picchi a breve termine nella domanda di risorse di calcolo e distribuire nel tempo il consumo dei carichi di lavoro in background. Queste funzionalità consentono di ridimensionare le capacità per l'utilizzo medio anziché il picco della domanda. Per ulteriori informazioni, vedere Valutare e ottimizzare la capacità di Fabric.
Coordinare le trasformazioni a esecuzione prolungata e le operazioni di aggiornamento per evitare la sovrapposizione di carichi di lavoro a elevato calcolo nella stessa capacità. Per altre informazioni, vedere Gestione del carico di lavoro in Fabric Data Warehouse.

Tenere presenti le considerazioni sui prezzi seguenti:

I modelli di archiviazione, periodo di conservazione e accesso ai dati di OneLake influiscono direttamente sul costo totale. Stimare la crescita prevista dei dati per livello medallion e allineare la conservazione ai requisiti aziendali e di conformità.
Prezzi di Microsoft Fabric si basano su una capacità F assegnata, misurata in CU. Le licenze Power BI per utente sono separate e non eseguono il provisioning della capacità di Fabric.

Usare la stima preconfigurata nel calcolatore prezzi Azure per ottenere un costo iniziale per questa architettura. Modificare i valori in modo che corrispondano al carico di lavoro previsto.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono, monitorano e mantengono un carico di lavoro nell'ambiente di produzione. Per altre informazioni, vedere l'elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Microsoft Fabric offre visibilità operativa predefinita tra i carichi di lavoro di ingegneria dei dati, warehousing e analisi. Usare l'app Fabric Capacity Metrics per monitorare il consumo di capacità, identificare gli artefatti a elevato utilizzo delle risorse e comprendere in che modo i carichi di lavoro interattivi e in background contribuiscono all'utilizzo complessivo. Queste informazioni dettagliate aiutano i team a prendere decisioni operative informate sul ridimensionamento, la pianificazione e l'ottimizzazione.

Configura avvisi proattivi in modo che gli amministratori della capacità possano identificare tempestivamente condizioni di utilizzo elevato o di limitazione e intervenire prima che si verifichino impatti per gli utenti.

Efficienza prestazionale

L'efficienza delle prestazioni si riferisce alla capacità di un carico di lavoro di ridimensionare e soddisfare in modo efficiente la domanda degli utenti. Per altre informazioni, vedere l'elenco di controllo della revisione della progettazione per l'efficienza delle prestazioni.

Microsoft Fabric include diversi meccanismi per gestire le prestazioni e l'utilizzo della capacità:

Il bursting e il smoothing consentono di gestire più rapidamente i picchi a breve termine della domanda di calcolo, distribuendo al contempo l’utilizzo nel tempo. Le operazioni interattive in genere si distribuiscono nell’arco di alcuni minuti, mentre le operazioni in background si distribuiscono su intervalli di tempo più lunghi.
La limitazione delle prestazioni viene applicata quando una capacità presenta un utilizzo delle risorse di calcolo prolungato superiore ai limiti dello SKU assegnato. La limitazione della frequenza ritarda o rifiuta nuove operazioni per proteggere la stabilità della piattaforma.
L'app Fabric Capacity Metrics fornisce visibilità dettagliata sul consumo di capacità e distingue tra operazioni interattive (ad esempio query di report) e operazioni in background (ad esempio l'inserimento o l'aggiornamento del modello). Questa distinzione consente ottimizzazioni delle prestazioni mirate per diversi tipi di carico di lavoro.

Collaboratori

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Prabhjot Kaur | Senior Cloud Solution Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Commenti e suggerimenti

Questa pagina è stata utile?