Modélisation dimensionnelle dans les pipelines Lakeflow

La modélisation dimensionnelle est une technique permettant d’organiser vos données de la couche or en tables de faits et de tables dimensionnelles afin que les analystes et les outils d’intelligence économique (BI) puissent les interroger efficacement. Cette page explique comment construire ce modèle avec des pipelines Lakeflow.

Overview

La modélisation dimensionnelle sépare les données en deux types de tables :

  • Les tables de faits contiennent les événements ou mesures qui vous intéressent, comme les commandes, les clics ou les soldes. Chaque ligne est une occurrence de cet événement, décrite principalement par des clés et des mesures numériques.
  • Les tables de dimensions contiennent le contexte descriptif autour de ces événements, tels que les clients, les produits ou les dates. Chaque ligne représente une entité commerciale.

Un schéma en étoile désigne la structure obtenue lorsque l’on place une table de faits au centre et qu’on la relie à plusieurs tables de dimensions via leurs clés. La mise en page est facile à interroger pour les analystes et les outils BI et facile à raisonner pour les ingénieurs, car chaque table a une responsabilité unique et claire.

Dans les pipelines Lakeflow, le schéma en étoile s’ajuste naturellement à la couche Or de l’architecture médaillon. Les jeux de données Bronze et Argent gèrent l’ingestion et le nettoyage, tandis que l’Or matérialise vos tables de faits et de dimensions afin que les consommateurs en aval les interrogent directement. Parce que le pipeline maintient ces tables à jour de manière incrémentale, vous obtenez la simplicité de requête d’un schéma en étoile sans étape séparée d’extraction, transformation, chargement (ETL) à la couche BI.

Fonctionnement

Vous construisez des dimensions et des faits sous forme de jeux de données dans votre pipeline, en choisissant le type de jeu de données qui correspond à la façon dont chacun évolue. Pour la plupart des modèles à couche d’or :

  • Construis des tables de dimensions sous forme de vues matérialisées (ou comme tables de streaming avec dimension à changement lent (SCD) Type 2 quand tu as besoin d’historique). La vue matérialisée se recalcule efficacement à partir de vos données Argent nettoyées, à mesure que les données d’entrée sont modifiées, afin de fournir une ligne par entité métier.
  • Construisez des tables de faits comme des tables en flux alimentées progressivement à partir de l’argent, afin que les agrégats de la couche or restent proches du temps réel. Les faits référencent leurs dimensions par clé au lieu de dupliquer des attributs descriptifs.

Pour plus d’informations sur les deux types de jeux de données, voir Vues matérialisées et Tables de streaming. Pour suivre l’historique dans une dimension, voir Les API AUTO CDC : Simplifiez la capture des données de modifications avec des pipelines.

Clés et clés de substitution

Privilégiez les clés naturelles (un identifiant déjà présent dans les données sources, comme un numéro d’ordre) où la clé naturelle de la source est stable et utilisable, car elle se regroupe et se joint bien. N’utilisez une clé de substitution (un identifiant de remplacement généré par le pipeline) que lorsqu’une source réutilise des ID ou les modifie.

Lorsque vous devez effectivement utiliser une clé de substitution, évitez une clé de substitution de type hachage, telle que sha2(natural_key). Un hachage est volontairement aléatoire, ce qui est mauvais pour le clustering liquide et la performance en ordre Z car les lignes physiquement adjacentes finissent dispersées entre les fichiers. Au lieu de cela, on dérive un substitut préservant l’ordre de manière déterministe à partir de la clé naturelle stable, de sorte que la même entité commerciale corresponde toujours au même substitut. La clé déterministe survit à une actualisation complète ou à une reconstruction de la dimension, ce qui maintient intactes les jointures de type « fait vers dimension » existantes.

Vous pouvez également utiliser une colonne IDENTITY lorsque la table en amont est en ajout uniquement et n’est jamais complètement actualisée. Parce que les valeurs IDENTITY sont attribuées à mesure que les lignes sont insérées, une reconstruction peut réattribuer des identifiants différents à la même entité et rompre silencieusement les jointures entre les faits et les dimensions qui utilisaient les anciennes valeurs.

Dimensions temporelles

Créez une vue matérialisée simple dim_date générée avec sequence() et explode() sur une plage de dates, plutôt que de la charger depuis une source. Ce sont des données de référence statiques, peu coûteuses à calculer, et cela simplifie les jointures et fenêtres basées sur la date partout ailleurs dans le modèle.

Examples

Les exemples suivants présentent un petit schéma en étoile avec une dimension client et une table des faits commandes.

Table de dimension

Une table de dimensions est généralement une vue matérialisée créée à partir des données Argent nettoyées, avec une ligne par entité métier, comme dans le code suivant :

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;

Table de faits

Une table de faits contient les événements mesurables, en référant les dimensions par leurs clés plutôt que par la duplication des attributs descriptifs. Gardez les faits précis (principalement des clés et des mesures numériques) et utilisez les jointures pour intégrer des détails descriptifs au moment de la requête, comme dans le code suivant :

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

Bonnes pratiques

Quelques pratiques permettent de maintenir un schéma d’étoile en bonne santé au fur et à mesure de sa croissance :

Ressources additionnelles

  • Last updated on