Fase 6: Progettare un'architettura Delta Lake

In questa fase si progettano modelli di architettura e organizzazione dei dati di Delta Lake Storage per il lakehouse.

Progettare un'architettura medallion

L'architettura medallion organizza i dati in livelli per migliorare la qualità dei dati man mano che procede attraverso la pipeline. Questo modello è fondamentale per costruire una lakehouse ben strutturata.

Nella sua forma più semplice, l'architettura medallion è costituita da tre livelli: livello bronzo (dati non elaborati), livello argento (dati raffinati) e livello oro (dati pronti per l'azienda).

Livello bronzo (dati non elaborati)

Inserire i dati di origine nel primo livello della lakehouse e salvarli in modo permanente. Quando tutti i dati downstream vengono creati dal livello bronzo, è possibile ricompilare i livelli successivi da questo livello, se necessario.

Caratteristiche del livello bronzo

• Origine della verità: dati non elaborati esattamente come arrivano dai sistemi di origine.
• Trasformazione minima: i dati archiviati nel formato originale (o convertiti in Delta per la verificabilità).
• Non modificabile: I dati sono solo aggiunti, mai aggiornati o eliminati.
• Schema in lettura: gestione flessibile dello schema per sistemi di origine diversi.
• Audit trail: per alcune applicazioni(ad esempio GDPR o dati regolamentati), potrebbe essere opportuno convertire questo livello in formato Delta.

Migliori pratiche per lo strato bronzo

• Mantieni tutti i campi dati di origine per un controllo completo.
• Utilizzare i volumi di Unity Catalog per l'archiviazione di file non elaborati.
• Implementare l'inserimento incrementale per evitare la rielaborazione completa.
• Partizionare in base alla data di inserimento per una gestione efficiente dei dati.
• Documentare le origini dati e le pianificazioni di inserimento.

Livello argento (dati raffinati)

Lo scopo del secondo livello è contenere dati puliti, perfezionati, filtrati e aggregati.

Caratteristiche del livello Silver

• Qualità dei dati: rimuove i duplicati, gestisce i valori mancanti, applica lo schema.
• Arricchimento: unisce i dati da più origini per creare set di dati integrati.
• Standardizzazione: applica tipi di dati, formati e convenzioni di denominazione coerenti.
• Regole di business: implementa regole di convalida e logica di business.
• Servizi di analisi: base per la creazione di report, dashboard e machine learning.

Procedure consigliate per lo strato d'argento

• Implementare controlli e monitoraggio della qualità dei dati.
• Usare le tabelle gestite di Unity Catalog per i dati di livello silver.
• Partiziona in base alle dimensioni aziendali (ad esempio, data, area, prodotto).
• Logica di trasformazione dei documenti e regole business.
• Stabilire contratti di servizio per l'aggiornamento dei dati.

Livello Gold (dati pronti per l'azienda)

Il terzo livello viene creato in base alle esigenze aziendali o di progetto. Offre una visualizzazione diversa come prodotti dati per altre business unit o progetti, preparazione dei dati in base alle esigenze di sicurezza (ad esempio, dati anonimi) o ottimizzazione per le prestazioni (ad esempio, viste preaggregate).

Caratteristiche dello strato d'oro

• Specifico per il business: personalizzato per casi d'uso e consumatori specifici.
• Ottimizzato per le prestazioni: preaggregato, denormalizzato per query veloci.
• Controllo di accesso: implementa la sicurezza a livello di riga e la mascheratura di colonna.
• Pronto per il consumatore: strutturato per gli strumenti di BI, le applicazioni e i modelli di apprendimento automatico.
• Prodotti dati: pubblicati come set di dati riutilizzabili nell'organizzazione.

Procedure consigliate per lo strato d'oro

• Creare tabelle d'oro separate per unità aziendali o casi d'uso diversi.
• Usare le viste dinamiche per la sicurezza a livello di riga e a livello di colonna.
• Implementare l'ottimizzazione predittiva per le tabelle con query frequenti.
• Derivazione dei dati del documento dal bronzo all'oro.
• Pubblicare prodotti di dati tramite Unity Catalog con chiara identificazione del proprietario.

Considerazioni sulla zona di destinazione

Le pipeline in organizzazioni di grandi dimensioni hanno spesso una zona di destinazione aggiuntiva nel cloud. La zona di atterraggio riceve i file non elaborati dai sistemi esterni prima dell'inserimento nel livello bronze.

Modelli di zona di destinazione

• Archiviazione di oggetti cloud: bucket S3, ADLS Gen2 o GCS per il caricamento di file.
• Unity Catalog volumes: Garantire un accesso sicuro ai file in stile POSIX con la governance di Unity Catalog.
• Accesso di terze parti: i sistemi esterni possono scrivere direttamente nelle zone di destinazione.
• Trigger di notifica: utilizzare le notifiche di evento per attivare le pipeline di ingestione.

Per indicazioni complete sull'architettura a medaglione, vedere Che cos'è l'architettura lakehouse medallion?.

Progettare la strategia di inserimento dati

L'inserimento di dati nel livello bronzo è il primo passaggio dell'architettura medallion. Progettare la strategia di inserimento in base a origini dati, volumi e requisiti di latenza.

Metodi di inserimento

Lakeflow Connect

Lakeflow Connect è un servizio di inserimento dati gestito fornito da Azure Databricks che può sincronizzare regolarmente i dati da origini esterne in Azure Databricks senza scrivere una singola riga di codice.

Strumenti di inserimento dei partner

Strumenti come Fivetran possono anche inserire dati da origini non supportate da Lakeflow Connect. Tutti questi dati non elaborati e non strutturati devono essere archiviati nei volumi del catalogo Unity (anziché in posizioni esterne).

Pipeline di inserimento personalizzate

Per requisiti di trasformazione complessi o origini non supportate, creare pipeline di inserimento personalizzate usando Lakeflow Spark Declarative Pipelines o notebook.

Modelli di acquisizione

Inserimento batch

• Pianificare i caricamenti regolari dei dati, ad esempio oraria, giornaliera, settimanale.
• Ideale per grandi volumi di dati cronologici.
• Costo inferiore rispetto allo streaming.
• Latenza accettabile per i carichi di lavoro analitici.

Inserimento in streaming

• Inserimento continuo di dati con bassa latenza.
• Usare le pipeline dichiarative di Lakeflow Spark con il caricatore automatico per l'inserimento di file in streaming.
• Ideale per l'analisi in tempo reale e i casi d'uso operativi.
• Costi di calcolo più elevati, ma dati aggiornati.

Change Data Capture (CDC) (Cattura delle Modifiche dei Dati)

• Acquisire e applicare modifiche incrementali dai sistemi di origine.
• Efficiente per tabelle di grandi dimensioni con aggiornamenti frequenti.
• Mantiene la derivazione dei dati e il audit trail.
• Supportato dalle pipeline dichiarative di Lakeflow Connect e Lakeflow Spark.

Procedure consigliate per l'inserimento dati

• Usare le unità di archiviazione del catalogo Unity per il caricamento iniziale dei dati non elaborati prima dell'ingestione bronze.
• Implementare l'ingestione idempotente per gestire i retry in modo sicuro.
• Usare Il caricatore automatico per l'inserimento efficiente di file dall'archiviazione cloud.
• Configurare i criteri di conservazione per i dati della zona di destinazione.
• Monitorare le pipeline di inserimento per individuare errori e problemi di qualità dei dati.

Progettare la strategia di gestione delle tabelle

Le tabelle e i volumi possono essere creati come gestiti o esterni. Comprendere i compromessi consente di progettare la strategia di tabella corretta.

Tabelle gestite vs tabelle esterne

Tabelle e volumi gestiti

Unity Catalog gestisce l'accesso a tabelle e volumi esterni da Azure Databricks, ma non controlla i file sottostanti o gestisce completamente il percorso di archiviazione di tali file. Le tabelle gestite e i volumi, d'altra parte, sono completamente gestiti dal catalogo unity e archiviati in un percorso di archiviazione gestito associato allo schema contenitore.

Azure Databricks consiglia volumi gestiti e tabelle gestite per la maggior parte dei carichi di lavoro perché semplificano la configurazione, l'ottimizzazione e la governance. Le nuove funzionalità, ad esempio l'ottimizzazione predittiva e il ripristino di emergenza gestito, sono disponibili solo per le tabelle gestite.

Tabelle e volumi esterni

La differenza principale con l'esterno è che le tabelle gestite non offrono la struttura di cartelle semplice di schema_name/table_name, invece usando cartelle di tipo GUID interne. Queste cartelle devono essere accessibili solo tramite Unity Catalog.

Quando usare tabelle esterne

• I dati devono rimanere in percorsi di archiviazione cloud specifici per motivi normativi o di conformità.
• I sistemi esterni richiedono l'accesso diretto ai dati tramite i file.
• Condivisione di dati con sistemi che non possono usare la condivisione delta.
• Dati esistenti di cui non è possibile eseguire la migrazione all'archiviazione gestita.

Procedure consigliate per la gestione delle tabelle

• Usare tabelle gestite per tutti i nuovi dati del lakehouse (bronzo, argento, oro).
• Usare volumi gestiti per la zona di destinazione e i dati non strutturati non elaborati.
• Utilizzare esclusivamente tabelle esterne per i dati che devono rimanere in percorsi specifici.
• Criteri relativi alla proprietà e al ciclo di vita dei documenti per tutte le tabelle.
• Abilitare l'ottimizzazione predittiva per le tabelle gestite sottoposte a query frequenti.

Progettazione a medaglione hub-and-spoke

Il modello di progettazione hub-spoke può essere combinato con l'architettura a medaglione per implementazioni aziendali. Questo modello centralizza gli asset di dati condivisi consentendo l'elaborazione dei dati specifica del dominio.

Caratteristiche della medaglia hub-spoke

• Hub dati: inserisce, cura e gestisce asset a livello di organizzazione, ad esempio dati SAP o asset generali, ad esempio meteo o finanziari. Questi dati possono essere considerati prodotti di dati connessi all'origine.
• Domini dati: ogni dominio legge alcuni dei prodotti dati curati dall'hub e inserisce e cura i propri dati non elaborati specifici del dominio. I domini producono quindi prodotti dati specifici del dominio.
• Pubblicazione di modelli
  • Pubblicazione centralizzata: i domini pubblicano nuovamente i prodotti dati nell'hub per l'utilizzo a livello di organizzazione.
  • Pubblicazione distribuita: i domini pubblicano i prodotti dati all'interno dei propri cataloghi per uso specifico del dominio.

Medaglia hub-spoke di esempio

Data Hub (Central)
├── Bronze: Organization-wide raw data (SAP, financials, weather)
├── Silver: Curated shared datasets
└── Gold: Enterprise-wide data products

Sales Domain
├── Bronze: Sales-specific raw data + shared hub data
├── Silver: Sales analytics datasets
└── Gold: Sales data products (published to hub or domain)

Engineering Domain
├── Bronze: Engineering telemetry + shared hub data
├── Silver: Engineering metrics
└── Gold: Engineering dashboards (published within domain)

Procedure consigliate per la medaglia hub-spoke

• Usare l'hub per i dati condivisi a livello di organizzazione usati da più domini.
• Consentire ai domini di inserire e curare i propri dati specifici del dominio.
• Stabilire criteri di pubblicazione dei prodotti dati chiari (centralizzati e distribuiti).
• Usare i cataloghi di Unity Catalog per separare i dati dell'hub e del dominio.
• Usare la condivisione delta gestita da Azure Databricks per condividere i prodotti dati tra hub e domini.

Progettare la strategia di governance dei dati

La governance dei dati garantisce qualità dei dati, individuabilità e conformità in tutto il lakehouse. Progettare strategie di governance appropriate per la maturità e i requisiti dell'organizzazione.

Strategia di qualità dei dati

Indipendentemente dalla variante dell'architettura medallion, la qualità dei dati deve migliorare man mano che i dati progrediscono attraverso i livelli. Di conseguenza, la fiducia nei dati aumenterà successivamente dal punto di vista aziendale.

Strumenti di qualità dei dati

• Vincoli: assicurarsi che la qualità e l'integrità dei dati aggiunti a una tabella vengano verificati automaticamente.
• Chiavi primarie ed esterne: codificare le relazioni tra i campi nelle tabelle (informativo, non applicato).
• Aspettative di: impedire i problemi di qualità dei dati dallo scorrere downstream; attualmente con le pipeline dichiarative di Lakeflow Spark, presto applicabile a tutte le tabelle del catalogo Unity.
• Monitoraggio Lakehouse: Controllare le proprietà statistiche e la qualità dei dati in tutte le tabelle del tuo account.

Procedure consigliate per la qualità dei dati

• Implementare controlli di qualità dei dati durante l'ingestione bronzo (ad esempio, convalida dello schema, verifiche su valori nulli).
• Applicare regole di qualità più rigorose man mano che i dati passano all'argento e all'oro.
• Monitorare le metriche e le tendenze della qualità dei dati nel tempo.
• Definire contratti di servizio per la qualità dei dati per i set di dati critici.
• Automatizzare gli avvisi per le violazioni della qualità dei dati.

Evitare i silo di dati

Lo spostamento, la copia e la duplicazione dei dati richiedono tempo e possono ridurre la qualità dei dati nel lakehouse, soprattutto quando porta alla creazione di silos di dati. Per rendere chiara la distinzione tra la copia dei dati e il silo dei dati, una copia autonoma o temporanea dei dati di per sé non è dannosa. A volte è necessario aumentare l'agilità, la sperimentazione e l'innovazione. Quando queste copie diventano operative con prodotti dati aziendali a valle da cui dipendono, diventano silos di dati. Questi silo diventano presto non sincronizzati, portando infine a un data lake meno affidabile.

Procedure consigliate per evitare i silo di dati

• Usare le visualizzazioni di Unity Catalog e Delta Sharing anziché copiare i dati.
• Stabilire una singola origine di verità per ogni set di dati.
• Scoraggiare la copia e duplicazione di dati a livello di reparto.
• Usare la derivazione del catalogo Unity per tenere traccia delle dipendenze dei dati.
• Ritirare regolarmente set di dati ridondanti.

Catalogo dati e individuazione

Unity Catalog offre l'individuazione dei dati e la derivazione per l'usabilità e la governance dei dati.

Individuazione dei dati

Gli utenti di tutte le aree aziendali, in particolare in un modello self-service, devono essere in grado di individuare i dati pertinenti. Pertanto, un lakehouse necessita di un catalogo dati che copre tutti i dati rilevanti per l'azienda. Gli obiettivi principali di un catalogo dati sono:

• Consentire agli utenti di cercare e individuare i set di dati.
• Fornire metadati, descrizioni e documentazione per i set di dati.
• Mostra derivazione dei dati dall'origine all'utilizzo.
• Visualizzare le metriche sulla qualità dei dati e le informazioni sull'aggiornamento.

Tracciabilità dei dati

Tenere traccia precisa della derivazione dei dati in modo che gli utenti possano spiegare in che modo i dati sono arrivati alla forma e al modulo correnti. Il catalogo unity acquisisce automaticamente la derivazione per:

• Dipendenze da tabella a tabella.
• Notebook ed esecuzioni di processi che leggono o scrivono dati.
• Sistemi di origine upstream.
• Consumatori downstream e prodotti di dati.

Procedure consigliate per il catalogo dati

• Aggiungere descrizioni e tag a tutti i cataloghi, gli schemi e le tabelle.
• Documentare i proprietari dei dati e gli esperti in materia.
• Usare la ricerca di Unity Catalog per abilitare l'individuazione dei dati.
• Esaminare e aggiornare regolarmente i metadati.
• Usare la derivazione per comprendere le dipendenze dei dati prima di apportare modifiche.

Raccomandazioni per l'architettura delta Lake

Raccomandato

• Usare l'architettura medallion per strutturare il data lake (bronzo, argento, oro).
• Usare le tabelle gestite di Unity Catalog per tutti i dati lakehouse (bronzo fino all'oro).
• Usare i volumi del catalogo Unity per le aree di atterraggio e i dati grezzi e non strutturati.
• Implementare controlli di qualità dei dati a ogni livello (bronzo, argento, oro).
• Usare Unity Catalog per abilitare l'individuazione dei dati e il rilevamento della derivazione.
• Abilitare l'ottimizzazione predittiva per le tabelle gestite sottoposte a query frequenti.
• Stabilire politiche di pubblicazione chiare dei prodotti di dati per le architetture hub-and-spoke.

Avoid (Evita)

• Non creare silo di dati duplicando i dati operativi tra domini.
• Non usare tabelle esterne, a meno che i dati non rimangano in percorsi di archiviazione specifici.
• Non ignorare il livello bronzo (conservare sempre i dati non elaborati come fonte di verità).
• Non ignorare i controlli di qualità dei dati per rispettare le scadenze di consegna.
• Non consentire la diffusione dei dati non gestiti senza la governance del Unity Catalog.

Risultati della fase 6

Dopo aver completato la fase 6, è necessario disporre di:

• Architettura medallion progettata (bronzo, argento, strati d'oro con scopi chiari).
• Strategia di inserimento dati definita (batch, streaming o CDC in base ai requisiti).
• Strategia di gestione delle tabelle progettata (tabelle gestite e esterne).
• Architettura della medaglia hub-spoke valutata (per le organizzazioni multidominio).
• Strategia di qualità dei dati definita con controlli appropriati a ogni livello.
• Criteri di governance dei dati stabiliti, ad esempio catalogo, derivazione, individuazione.
• Architettura dell'area di atterraggio progettata (se richiesto per i sistemi esterni).
• Modello di pubblicazione del prodotto dati definito (centralizzato, distribuito o ibrido).

Fase successiva: Fase 7: Pianificare l'approccio infrastruttura distribuita come codice

Indicazioni sull'implementazione: per istruzioni dettagliate sull'implementazione della progettazione delta Lake, vedere Informazioni su Delta Lake in Azure Databricks?.