Modellazione dimensionale nelle pipeline Lakeflow

La modellazione dimensionale è una tecnica per organizzare i dati dello strato oro in tabelle di fatto e tabelle di dimensioni, così che analisti e strumenti di business intelligence (BI) possano interrogarli in modo efficiente. Questa pagina spiega come costruire quel modello con le pipeline Lakeflow.

Overview

La modellazione dimensionale separa i dati in due tipi di tabelle:

  • Le tabelle di dati conservano gli eventi o le misure che ti interessano, come ordini, click o vendite. Ogni riga è un'occorrenza di quell'evento, descritta principalmente da chiavi e misure numeriche.
  • Le tabelle delle dimensioni contengono il contesto descrittivo attorno a quegli eventi, come clienti, prodotti o date. Ogni riga rappresenta un'entità aziendale.

Uno schema a stella è la forma che ottieni quando posizioni una tabella di fatti al centro e la uneixi a diverse tabelle dimensionali tramite le loro chiavi. La struttura è facile da interrogare sia per gli analisti sia per gli strumenti di BI ed è facile da comprendere per gli ingegneri, perché ogni tabella ha un’unica responsabilità ben definita.

Nelle pipeline Lakeflow, lo schema a stella si adatta naturalmente allo strato d'oro dell'architettura a medaglione. I dataset in bronzo e argento gestiscono l'ingestione e la pulizia, e l'oro materializza le tue tabelle di fatti e dimensioni così i consumatori a valle li interrogano direttamente. Poiché la pipeline mantiene queste tabelle aggiornate in modo incrementale, si ottiene la semplicità di query di uno schema a stella senza un step separato di estrazione, trasformazione, caricamento (ETL) al livello BI.

Come funziona

Costruisci dimensioni e fatti come dataset nella tua pipeline, scegliendo il tipo di dataset che corrisponde a come ciascuno cambia. Per la maggior parte dei modelli goldlayer:

  • Crea tabelle dimensionali come viste materializzate (oppure come tabelle in streaming con dimensioni a variazione lenta (SCD) di tipo 2 quando è necessario conservare lo storico). Una vista materializzata viene ricalcolata in modo efficiente a partire dai dati silver puliti quando cambiano i dati di input, fornendo una riga per ogni entità aziendale.
  • Costruisci tabelle di fatto come tabelle di flusso alimentate incrementalmente dall'argento, così gli aggregati dello strato oro restano vicini al tempo reale. I fatti fanno riferimento alle loro dimensioni tramite elementi chiave piuttosto che duplicare attributi descrittivi.

Per maggiori informazioni sui due tipi di dataset, vedi Visualizzazioni materializzate e tabelle Streaming. Per tenere traccia della cronologia in una dimensione, vedi Le API AUTO CDC: semplificare l'acquisizione dei dati delle modifiche con pipeline.

Chiavi e chiavi sostitutive

Preferisci le chiavi naturali (un identificatore già presente nei dati sorgente, come un numero d'ordine) dove la chiave naturale della sorgente è stabile e utilizzabile, perché si raggruppa e si collega bene. Cercate una chiave surrogata (un identificatore sostituto generato dalla pipeline) solo quando una sorgente riutilizza o cambia ID.

Quando è necessario usare una chiave surrogata, evita una chiave surrogata basata su hash come sha2(natural_key). Un hash è deliberatamente casuale, il che è negativo per il clustering liquido e le prestazioni dell'ordine Z perché le righe fisicamente adiacenti finiscono per essere disperse tra i file. Invece, si deriva un surrogato che preserva l'ordine deterministicamente dalla chiave naturale stabile, così la stessa entità commerciale corrisponde sempre allo stesso surrogato. Una chiave deterministica sopravvive a un aggiornamento completo o a una ricostruzione della dimensione, mantenendo intatti i collegamenti esistenti tra fatto e dimensione.

In alternativa, puoi usare una IDENTITY colonna quando la tabella upstream è solo append-up e mai completamente aggiornata. Poiché agli ID IDENTITY vengono assegnati valori via via che vengono inserite le righe, una ricostruzione può riassegnare ID diversi alla stessa entità e compromettere silenziosamente le join tra fatti e dimensioni basate sui vecchi valori.

Dimensioni della data

Crea una dim_date come semplice vista materializzata generata con sequence() e explode() in un intervallo di date, anziché acquisirla da una fonte. Sono dati di riferimento statici, economici da calcolare, e semplificano le unioni basate sulla data e le finestre in tutto il resto del modello.

Esempi

I seguenti esempi costruiscono uno schema a piccola stella con una dimensione cliente e una tabella dati sugli ordini.

Tabella delle dimensioni

Una tabella di dimensione è in genere una vista materializzata creata a partire da dati silver ripuliti, con una riga per ciascuna entità aziendale, come nel codice seguente:

Python

from pyspark import pipelines as dp

@dp.materialized_view(name="dim_customer", comment="Customer dimension")
def dim_customer():
    return (
        spark.read.table("customers_silver")
        .select("customer_id", "customer_name", "region", "signup_date")
    )

SQL

CREATE OR REFRESH MATERIALIZED VIEW dim_customer
COMMENT "Customer dimension"
AS SELECT customer_id, customer_name, region, signup_date
FROM customers_silver;

Tabella dei fatti

Una tabella dei fatti contiene gli eventi misurabili, facendo riferimento alle dimensioni tramite le loro chiavi invece di duplicare attributi descrittivi. Mantieni i fatti stretti (principalmente chiavi e misure numeriche) e usa le unioni per inserire dettagli descrittivi al momento della query, come nel seguente codice:

Python

from pyspark import pipelines as dp

@dp.table(name="fact_orders", comment="One row per order line, keyed to dimensions")
def fact_orders():
    return (
        spark.readStream.table("orders_silver")
        .select(
            "order_id",
            "customer_id",       # foreign key to dim_customer
            "product_id",        # foreign key to dim_product
            "order_date",        # foreign key to dim_date
            "quantity",
            "amount",
        )
    )

SQL

CREATE OR REFRESH STREAMING TABLE fact_orders
COMMENT "One row per order line, keyed to dimensions"
AS SELECT
  order_id,
  customer_id,   -- foreign key to dim_customer
  product_id,    -- foreign key to dim_product
  order_date,    -- foreign key to dim_date
  quantity,
  amount
FROM STREAM(orders_silver);

Procedure consigliate

Alcune pratiche mantengono sano uno schema a stella man mano che cresce:

  • Mantieni i fatti come tabelle in streaming e le dimensioni come viste materializzate, a meno che non ti serva espressamente la cronologia delle modifiche, nel qual caso usa AUTO CDC con STORED AS SCD TYPE 2. Consulta le API AUTO CDC: semplificare la cattura dei dati modificati con le pipeline.
  • Usa strumenti di BI a valle per interrogare direttamente le viste materializzate in oro. Le pipeline Lakeflow le mantengono aggiornate incrementalmente, così ottieni risultati quasi in tempo reale senza un passaggio ETL di reportistica separato.
  • Le dimensioni e i fatti del modello confluiscono come flussi separati nello stesso livello Gold, così ogni set di dati può essere pianificato, sottoposto a checkpoint e aggiornato nell'ambito di un unico DAG coerente. Vedi Caricare ed elaborare i dati in modo incrementale con i flussi della pipeline Lakeflow.

Risorse aggiuntive

  • Last updated on