Dimensionale modellering in Lakeflow-pijpleidingen

Dimensionale modellering is een techniek om je goudlaagdata te organiseren in feittabellen en dimensietabellen, zodat analisten en business intelligence (BI)-tools deze efficiënt kunnen opvragen. Deze pagina legt uit hoe je dat model bouwt met Lakeflow-pijpleidingen.

Overview

Dimensionale modellering scheidt data in twee soorten tabellen:

  • Feitentabellen bevatten de gebeurtenissen of metingen die je belangrijk vinden, zoals bestellingen, klikken of verkopen. Elke rij staat voor één voorkomen van die gebeurtenis, meestal beschreven aan de hand van sleutels en numerieke meetwaarden.
  • Dimensietabellen bevatten de beschrijvende context rond die gebeurtenissen, zoals klanten, producten of data. Elke rij is één zakelijke entiteit.

Een sterschema is de vorm die je krijgt wanneer je één feitentabel in het midden plaatst en deze verbindt met meerdere dimensietabellen via hun sleutels. De lay-out is makkelijk voor analisten en BI-tools om te bevragen en makkelijk voor ingenieurs om over te redeneren, omdat elke tabel één duidelijke verantwoordelijkheid heeft.

In Lakeflow-pijpleidingen past het sterrenschema natuurlijk in de gouden laag van de medaillonarchitectuur. Brons- en zilverdatasets verzorgen de gegevensinname en opschoning, en in de goudlaag worden je feiten- en dimensietabellen gematerialiseerd zodat downstream-afnemers deze rechtstreeks kunnen bevragen. Omdat de pijplijn die tabellen stapsgewijs up-to-date houdt, krijg je de query-eenvoud van een sterschema zonder een aparte extract, transform, load (ETL) stap op de BI-laag.

Hoe werkt het?

Je bouwt dimensies en feiten als datasets in je pijplijn, waarbij je het type dataset kiest dat overeenkomt met hoe elke dataset verandert. Voor de meeste goudlaagmodellen:

  • Bouw dimensietabellen als gematerialiseerde weergaven (of als streamingtabellen met langzaam veranderende dimensie (SCD) Type 2 wanneer je geschiedenis nodig hebt). Een gematerialiseerde weergave wordt efficiënt opnieuw berekend op basis van je opgeschoonde silver-data wanneer de invoergegevens veranderen, zodat je één rij per bedrijfsentiteit hebt.
  • Bouw feittabellen als streamingtabellen die incrementeel uit zilver worden gevoed, zodat goudlaagaggregaten dicht bij realtime blijven. Feiten verwijzen naar hun afmetingen met sleutel in plaats van beschrijvende eigenschappen te dupliceren.

Voor meer informatie over de twee datasettypes, zie Gematerialiseerde weergaven en Streamingtabellen. Om geschiedenis in een dimensie bij te houden, zie De AUTO CDC API's: Vereenvoudig wijzigingsdataverzameling met pijplijnen.

Sleutels en surrogaatsleutels

Geef de voorkeur aan natuurlijke sleutels (een identificatie die al in de brondata bestaat, zoals een ordernummer) waarbij de natuurlijke sleutel van de bron stabiel en bruikbaar is, omdat deze goed clustert en joint. Grijp alleen naar een surrogaatsleutel (een door de pijplijn gegenereerde stand-in identifier) wanneer een bron de ID's hergebruikt of verandert.

Als je een surrogaatsleutel nodig hebt, vermijd dan een hash-surrogaat zoals sha2(natural_key). Een hash is opzettelijk willekeurig, wat slecht is voor liquid clustering en Z-order prestaties omdat fysiek aangrenzende rijen verspreid raken over bestanden. Leid in plaats daarvan deterministisch een ordebehoudende surrogaatsleutel af van de stabiele natuurlijke sleutel, zodat dezelfde bedrijfsentiteit altijd met dezelfde surrogaatsleutel overeenkomt. Een deterministische sleutel blijft behouden na een volledige vernieuwing of heropbouw van de dimensie, waardoor bestaande koppelingen tussen feiten en dimensies intact blijven.

Alternatief kun je een IDENTITY kolom gebruiken wanneer de upstream-tabel alleen append-only is en nooit volledig ververst. Omdat de waarden van IDENTITY worden toegewezen wanneer rijen worden ingevoegd, kan een herbouw dezelfde entiteit andere ID's toekennen en onopgemerkt de fact-naar-dimensie-koppelingen verbreken waarin de oude waarden waren opgenomen.

Datumdimensies

Bouw een dim_date op als een eenvoudige gematerialiseerde weergave die met sequence() en explode() over een datumbereik wordt gegenereerd, in plaats van deze vanuit een bron te laden. Het zijn statische referentiegegevens, goedkoop te berekenen, en het vereenvoudigt joins op basis van datums en vensterbewerkingen elders in het model.

Examples

De volgende voorbeelden bouwen een klein sterschema met een klantdimensie en een orderfeitentafel.

Dimensietabel

Een dimensietabel is doorgaans een gematerialiseerd overzicht opgebouwd uit schoongemaakte zilveren data, met één rij per bedrijfsentiteit, zoals in de volgende code:

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;

Feitentabel

Een feitentabel bevat de meetbare gebeurtenissen, waarbij dimensies worden verwezen via hun sleutels in plaats van beschrijvende attributen te dupliceren. Houd feiten smal (voornamelijk sleutels en numerieke maten) en gebruik joins om beschrijvende details op te halen tijdens het querymoment, zoals in de volgende code:

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);

Beste praktijken

Een paar praktijken houden een sterschema gezond terwijl het groeit:

Aanvullende bronnen

  • Last updated on