Dimensionsmodellering i Lakeflow-pipelines

Dimensionsmodellering är en teknik för att organisera data i guldlagret i faktatabeller och dimensionstabeller så att analytiker och business intelligence (BI)-verktyg kan köra frågor mot dem effektivt. Den här sidan förklarar hur man bygger den modellen med Lakeflow-pipelines.

Overview

Dimensionell modellering delar upp data i två typer av tabeller:

  • Faktatabeller innehåller de händelser eller mått du bryr dig om, såsom beställningar, klick eller försäljningar. Varje rad är en förekomst av den händelsen, mestadels beskriven med nycklar och numeriska mått.
  • Dimensionstabeller håller den beskrivande kontexten kring dessa händelser, såsom kunder, produkter eller datum. Varje rad är en affärsenhet.

Ett stjärnschema är formen du får när du placerar en faktatabell i mitten och kopplar ut den till flera dimensionstabeller via deras nycklar. Layouten är enkel för analytiker och BI-verktyg att fråga och lätt för ingenjörer att resonera kring, eftersom varje tabell har ett enda, tydligt ansvar.

I Lakeflow-pipelines passar stjärnschemat naturligt in på guldlagret i medaljongarkitekturen. Brons- och silverdata hanterar intag och rengöring, och guld materialiserar dina fakta- och måtttabeller så att nedströmskonsumenter söker dem direkt. Eftersom pipelinen håller dessa tabeller uppdaterade inkrementellt får du den enkla frågemodellen hos ett stjärnschema utan ett separat steg för extrahering, transformering och inläsning (ETL) i BI-lagret.

Så här fungerar det

Du bygger dimensioner och faktatabeller som datauppsättningar i din pipeline och väljer den typ av datauppsättning som motsvarar hur var och en förändras. För de flesta guldskiktsmodeller:

  • Bygg dimensionstabeller som materialiserade vyer (eller som strömningstabeller med långsamt föränderlig dimension (SCD) typ 2 när du behöver historik). En materialiserad vy beräknas effektivt om från dina rensade silverdata när indata ändras, vilket ger dig en rad per affärsenhet.
  • Bygg faktatabeller som strömningstabeller som matas stegvis från silver, så att guldlageraggregat håller sig nära realtid. Fakta refererar till sina dimensioner med nyckel istället för att duplicera beskrivande attribut.

För mer information om de två datasetstyperna, se Materialiserade vyer och Strömningstabeller. För att spåra historik i en dimension, se AUTO CDC-API:erna: Förenkla insamling av ändringsdata med pipelines.

Nycklar och ersättningsnycklar

Föredra naturliga nycklar (en identifierare som redan finns i källdatan, såsom ett ordernummer) där källans naturliga nyckel är stabil och användbar, eftersom den klustrar och sammanfogar väl. Sträck dig endast efter en surrogatnyckel (en pipeline-genererad ersättande identifierare) när en källa återanvänder eller ändrar ID:n.

När du behöver en surrogatnyckel, undvik en hash-surrogat som sha2(natural_key). En hash är medvetet slumpmässig, vilket är dåligt för vätskeklustring och Z-ordningens prestanda eftersom fysiskt intilliggande rader hamnar utspridda över filer. Skapa i stället deterministiskt en ordningsbevarande surrogatnyckel utifrån den stabila naturliga nyckeln, så att samma affärsobjekt alltid mappas till samma surrogatnyckel. En deterministisk nyckel överlever en fullständig uppdatering eller ombyggnad av dimensionen, vilket behåller befintliga fakta-till-dimension-joins intakta.

Alternativt kan du använda en IDENTITY-kolumn när källtabellen endast fylls på och aldrig uppdateras helt. Eftersom IDENTITY-värden tilldelas när rader infogas kan en ombyggnad tilldela samma entitet andra ID:n och utan att det märks bryta fakta-till-dimension-sammanfogningarna som använde de gamla värdena.

Datummått

Bygg en dim_date som en enkel materialiserad vy som genereras med sequence() och explode() över ett datumintervall, i stället för att mata in den från en källa. Det är statisk referensdata, billig att beräkna, och det förenklar datumbaserade sammanfogningar och fönsterfunktioner i resten av modellen.

Examples

Följande exempel bygger ett litet stjärnschema med en kunddimension och en orderfaktatabell.

Dimensionstabell

En dimensionstabell är vanligtvis en materialiserad vy som bygger på rensade silverdata, med en rad per affärsobjekt, vilket visas i följande kod:

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;

Faktatabell

En faktatabell innehåller de mätbara händelserna och refererar till dimensioner med deras nycklar istället för att duplicera beskrivande attribut. Håll fakta smala (främst nycklar och numeriska mått) och använd joins för att hämta beskrivande detaljer vid frågetid, som i följande kod:

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

Bästa praxis

Några metoder håller ett stjärnschema friskt medan det växer:

  • Behåll fakta som strömningstabeller och dimensioner som materialiserade vyer om du inte specifikt behöver ändra historik, i så fall använd AUTO CDC med STORED AS SCD TYPE 2. Se API:er för AUTOMATISK CDC: Förenkla insamling av ändringsdata med pipelines.
  • Använd nedströms BI-verktyg för att direkt fråga guldmaterialiserade vyer. Lakeflow-pipelines uppdaterar dem stegvis, så du får nästan realtidsresultat utan ett separat rapporteringssteg för ETL.
  • Modellera dimensioner och fakta som separata flöden in i samma guldlager, så att varje dataset kan schemaläggas, kontrolleras och uppdateras som en del av en sammanhängande DAG. Se Läsa in och bearbeta data stegvis med Lakeflow-pipelineflöden.

Ytterligare resurser

  • Last updated on