Aller au contenu principal
Dernière mise à jour le

Modélisation dimensionnelle dans les LakeFlow Pipelines

La modélisation dimensionnelle est une technique permettant d'organiser vos données de la couche Gold en tables de faits et tables de dimension afin que les analystes et les outils de Business Intelligence (BI) puissent les query efficacement. Cette page explique comment créer ce modèle avec les LakeFlow Pipelines.

Présentation​

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 Ventes. Chaque ligne est une occurrence de cet événement, décrite principalement par des clés et des mesures numériques.
  • Les tables de dimension contiennent le contexte descriptif autour de ces événements, tels que les clients, les produits ou les dates. Chaque ligne correspond à une entité métier.

Un schéma d’étoile est la forme que l’on obtient lorsque l’on place une table de faits au centre et que l’on la relie à plusieurs tables de dimensions grâce à leurs clés. Layout est facile à query 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 Lakeflow pipelines, le schéma en étoile s'intègre naturellement à la couche Gold de l'architecture en médaillon. Les datasets Bronze et Silver gèrent l'ingestion et le nettoyage, et la couche Gold matérialise vos tables de faits et de dimension afin que les consommateurs en aval puissent les interroger directement. Comme le pipeline maintient ces tables à jour de manière incrémentielle, vous bénéficiez de la simplicité de requête d'un schéma en étoile sans étape distincte d'extraction, transformation et chargement (ETL) au niveau de la couche BI.

Comment ça marche​

Vous créez 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 de la couche Gold :

  • Créez des tables de dimension sous forme de vues matérialisées (ou sous forme de tables de streaming avec des dimensions à évolution lente (SCD) de type 2 lorsque vous avez besoin d'un historique). Une vue matérialisée se recalcule efficacement à partir de vos données « silver » nettoyées au fur et à mesure que les entrées changent, vous donnant une ligne par entité métier.
  • Créez des tables de faits en tant que tables de streaming alimentées de manière incrémentielle à partir de la couche Silver, afin que les agrégats de la couche Gold restent proches du temps réel. Les faits référencent leurs dimensions par clé plutôt que de dupliquer les attributs descriptifs.

Pour plus d'informations sur les deux types de dataset, consultez les vues matérialisées et les tables de streaming. Pour suivre l'historique dans une dimension, consultez les AUTO CDC APIs : simplifiez la capture des modifications de données avec les 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 clusters et se joint bien. Ne cherchez une clé de substitution (un identifiant de remplacement généré par le pipeline) que lorsqu’une source réutilise ou modifie d’ID.

Lorsque vous avez besoin d’une clé de substitution, évitez une clé de substitution de hachage comme sha2(natural_key). Un hachage est volontairement aléatoire, ce qui est mauvais pour le clustering liquide et la performance en Z-order 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. Une clé déterministe survit à un refresh complet ou à une reconstruction de la dimension, ce qui maintient intactes les jointures fait-dimension existantes.

Alternativement, vous pouvez utiliser une colonne IDENTITY lorsque la table en amont est en ajout seul et n'est jamais réactualisée intégralement. Comme les valeurs IDENTITY sont attribuées lors de l'insertion des lignes, une reconstruction peut réattribuer des ID différents à la même entité et rompre silencieusement les jointures faits-dimensions qui portaient les anciennes valeurs.

Dimensions de date​

Créez un dim_date sous forme de vue matérialisée simple générée avec sequence() et explode() sur une plage de dates, plutôt que de l'ingérer à partir d'une source. Il s'agit de données de référence statiques, peu coûteuses à compute, et cela simplifie les jointures basées sur les dates et le fenêtrage partout ailleurs dans le modèle.

Exemples​

Les exemples suivants permettent de créer un petit schéma en étoile avec une dimension clients et une table de faits des commandes.

Table de dimension​

Une table de dimension est généralement une vue matérialisée construite à partir de données silver 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")
    )

Table de faits​

Une table de faits contient les événements mesurables, en référençant les dimensions par leurs clés plutôt qu’en dupliquant les attributs descriptifs. Gardez les faits restreints (principalement des clés et des mesures numériques) et utilisez des jointures pour récupérer les détails descriptifs au moment de la query, 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",
        )
    )

Bonnes pratiques​

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

Ressources supplémentaires​

Sur cette page