Dimensionsmodellierung in Lakeflow-Pipelines

Dimensionale Modellierung ist eine Technik, um Ihre Goldschicht-Daten in Faktentabellen und Dimensionstabellen zu organisieren, sodass Analysten und Business-Intelligence-(BI)-Tools sie effizient abfragen können. Diese Seite erklärt, wie man dieses Modell mit Lakeflow-Pipelines aufbaut.

Overview

Die dimensionale Modellierung teilt Daten in zwei Arten von Tabellen auf:

  • Faktentabellen enthalten die Ereignisse oder Maße, die Ihnen wichtig sind, wie Bestellungen, Klicks oder Verkäufe. Jede Zeile ist ein Vorkommen dieses Ereignisses, das größtenteils durch Schlüssel und numerische Maße beschrieben wird.
  • Dimensionstabellen enthalten den beschreibenden Kontext zu diesen Ereignissen, wie zum Beispiel Kunden, Produkte oder Daten. Jede Zeile ist eine Geschäftseinheit.

Ein Sternschema ist die Form, die man erhält, wenn man eine Faktentabelle in der Mitte platziert und sie über deren Schlüssel mit mehreren Dimensionstabellen verbindet. Das Layout ist für Analysten und BI-Tools leicht abzufragen und für Ingenieure leicht zu überlegen, da jede Tabelle eine einzige, klare Verantwortung hat.

In Lakeflow-Pipelines passt das Sternschema natürlich in die Gold-Schicht der Medallion-Architektur. Bronze- und Silber-Datasets übernehmen die Erfassung und Bereinigung, und Gold materialisiert Ihre Fakten- und Dimensionstabellen, sodass nachgeschaltete Consumer sie direkt abfragen können. Da die Pipeline diese Tabellen schrittweise aktuell hält, profitieren Sie von den einfachen Abfragemöglichkeiten eines Sternschemas, ohne dass in der BI-Schicht ein separater Extraktions-, Transformations- und Ladeschritt (ETL) erforderlich ist.

So funktioniert es

Du baust Dimensionen und Fakten als Datensätze in deiner Pipeline auf und wählst den Datensatztyp, der mit der Änderung jedes einzelnen übereinstimmt. Für die meisten Goldschicht-Modelle:

  • Baue Dimensionstabellen als materialisierte Ansichten (oder als Streaming-Tabellen mit langsam wechselnder Dimension (SCD) Typ 2, wenn du eine Historie brauchst). Eine materialisierte Sicht wird effizient aus Ihren bereinigten Silber-Daten neu berechnet, wenn sich Eingaben ändern, sodass Sie eine Zeile pro Geschäftsentität erhalten.
  • Erstelle Faktentabellen als Streaming-Tabellen, die schrittweise aus Silber gespeist werden, damit Goldschichtaggregate nahe an Echtzeit bleiben. Fakten beziehen sich auf ihre Dimensionen durch Schlüssel, anstatt beschreibende Attribute zu duplizieren.

Weitere Informationen zu den beiden Datensatztypen finden Sie unter Materialisierte Ansichten und Streaming-Tabellen. Informationen zum Nachverfolgen des Verlaufs in einer Dimension finden Sie unter Die AUTO CDC-APIs: Vereinfachen der Change Data Capture mit Pipelines.

Schlüssel und Ersatzschlüssel

Bevorzugen Sie natürliche Schlüssel (eine bereits in den Quelldaten vorhandene Identifikator, wie z. B. eine Bestellnummer), bei denen der natürliche Schlüssel stabil und nutzbar ist, weil er sich gut clustert und verbindet. Verwenden Sie einen Surrogatschlüssel (einen von der Pipeline generierten Ersatzbezeichner) nur dann, wenn eine Quelle ihre IDs wiederverwendet oder ändert.

Wenn du einen Surrogatschlüssel brauchst, vermeide einen Hash-Surrogatschlüssel wie sha2(natural_key). Ein Hash ist absichtlich zufällig, was schlecht für Liquid-Clustering und Z-Ordnungs-Performance ist, weil physisch benachbarte Zeilen über Dateien verteilt sind. Stattdessen wird aus dem stabilen natürlichen Schlüssel deterministisch ein ordnungserhaltendes Surrogat abgeleitet, so dass dasselbe Geschäftsobjekt immer auf dasselbe Surrogat abgebildet wird. Ein deterministischer Schlüssel übersteht eine vollständige Aktualisierung oder Neuerstellung der Dimension, wodurch vorhandene Fakten-zu-Dimension-Joins intakt bleiben.

Alternativ können Sie eine IDENTITY-Spalte verwenden, wenn die Upstreamtabelle nur zum Anfügen dient und nie vollständig aktualisiert wird. Da IDENTITY-Werte beim Einfügen von Zeilen zugewiesen werden, kann eine Neuerstellung derselben Entität unterschiedliche IDs zuweisen und die Fakten-zu-Dimension-Joins, die die alten Werte enthielten, unbemerkt unterbrechen.

Datumsdimensionen

Erstellen Sie eine dim_date als einfache materialisierte Sicht, die mit sequence() und explode() über einen Datumsbereich generiert wird, anstatt sie aus einer Quelle zu erfassen. Es handelt sich um statische Referenzdaten, die kostengünstig zu berechnen sind und datumsbasierte Joins und Fensterfunktionen überall sonst im Modell vereinfachen.

Examples

Die folgenden Beispiele erstellen ein kleines Sternschema mit einer Kundendimension und einer Bestellfaktentabelle.

Dimensionstabelle

Eine Dimensionstabelle ist typischerweise eine materialisierte Ansicht, die aus bereinigten Silberdaten erstellt wird, mit einer Zeile pro Geschäftseinheit, wie im folgenden 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;

Faktentabelle

Eine Faktentabelle enthält die messbaren Ereignisse und bezieht sich auf Dimensionen anhand ihrer Schlüssel, anstatt beschreibende Attribute zu duplizieren. Halten Sie die Fakten schlank (meist auf Schlüssel und numerische Kennzahlen beschränkt) und verwenden Sie Joins, um bei der Abfrage beschreibende Details hinzuzuziehen, wie im folgenden 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);

Bewährte Methoden

Einige Praktiken halten ein Sternschema gesund, während es wächst:

  • Behalten Sie Fakten als Streaming-Tabellen und Dimensionen als materialisierte Ansichten bei, es sei denn, Sie benötigen ausdrücklich einen Änderungsverlauf; verwenden Sie in diesem Fall AUTO CDC mit STORED AS SCD TYPE 2. Siehe Die AUTO CDC-APIs: Vereinfachen der Änderungsdatenerfassung mit Pipelines.
  • Verwenden Sie nachgeschaltete BI-Tools, um materialisierte Gold-Sichten direkt abzufragen. Lakeflow-Pipelines aktualisieren sie schrittweise, sodass Sie nahezu Echtzeit-Ergebnisse erhalten, ohne einen separaten Berichts-ETL-Schritt.
  • Modellieren Sie Dimensionen und Fakten als separate Flows in dieselbe Gold-Schicht, sodass jedes Dataset als Teil eines kohärenten DAG geplant, mit Prüfpunkten versehen und aktualisiert werden kann. Siehe Daten mit Lakeflow-Pipeline-Abläufen inkrementell laden und verarbeiten.

Weitere Ressourcen

  • Last updated on