Choisir une granularité sur une colonne ou une table en fonction des exigences

La granularité est l’une des décisions de conception les plus critiques que vous prenez lors de la création d’un modèle de données. Il définit le niveau de détail capturé dans vos tables et affecte directement les coûts de stockage, les performances des requêtes et les questions analytiques auxquelles vous pouvez répondre. En tant qu’ingénieur données, la compréhension de la granularité vous aide à concevoir des tables qui répondent aux exigences métier tout en conservant des opérations efficaces.

Cette unité explique quelle granularité signifie dans le contexte de la modélisation dimensionnelle et comment évaluer différentes options de granularité en fonction des exigences de votre organisation.

Comprendre ce que représente la granularité

La granularité, parfois appelée « grain », décrit le niveau de détail que chaque ligne d’une table représente. Dans une table de faits, le grain détermine l’événement métier ou la mesure que chaque ligne capture. Dans une table de dimensions, le grain détermine la façon dont les entités sont représentées et mises en version.

Envisagez un scénario de données de capteur IoT. Vous pouvez concevoir votre table de faits à différents niveaux de granularité :

• Granularité au niveau de la milliseconde : chaque ligne représente une seule lecture de capteur capturée au niveau de la milliseconde. Cela capture les informations les plus détaillées, notamment des horodatages précis, des valeurs de capteur et des identificateurs d’appareil pour chaque mesure.

• Deuxième granularité agrégée : chaque ligne représente la valeur moyenne, minimale ou maximale d’un capteur pour un appareil par seconde. Les lectures individuelles sont résumées en statistiques par seconde.

• Granularité agrégée de minute : chaque ligne représente des statistiques de capteur agrégées pour un appareil pendant une minute entière. Cela fournit le moins de détails, mais nécessite le moins de stockage.

Le grain que vous choisissez affecte tout en aval. Une fois que vous perdez des détails par le biais de l’agrégation, vous ne pouvez pas le récupérer. Si votre table agrégée minute indique que le capteur X avait une température moyenne de 75 °C pendant une minute spécifique, vous ne pouvez pas déterminer quelles millisecondes avaient des pics de température ou identifier le moment exact où une anomalie s’est produite.

Évaluer les facteurs qui influencent les décisions de granularité

Le choix de la granularité appropriée nécessite l’équilibrage de plusieurs préoccupations concurrentes. Le bon choix dépend de votre contexte métier et de vos contraintes techniques spécifiques.

Les exigences métier déterminent la granularité

Les questions analytiques auxquelles votre organisation doit répondre doivent être le facteur principal pour déterminer la granularité. Demandez-vous : quel est le niveau d’analyse le plus détaillé requis ?

Si les ingénieurs des opérations doivent détecter les anomalies d’équipement au niveau de la milliseconde, les agrégats par minute ne suffiront pas. Si la direction ne nécessite que des résumés horaires d'utilisation par ligne de production, stocker toutes les lectures de capteur gaspille des ressources.

Considérez les scénarios suivants :

Les schémas de requête influencent la performance

La façon dont les utilisateurs interrogent vos données influence la granularité optimale. Lorsque les requêtes filtrent et s’agrègent généralement à des niveaux plus élevés, le stockage de données trop affinées crée une surcharge de traitement inutile. Chaque requête doit analyser et agréger plus de lignes que nécessaire.

En même temps, le stockage de données trop grossières empêche les utilisateurs d’explorer pour répondre à des questions détaillées. La recherche de l’équilibre nécessite de comprendre les modèles de requête actuels et prévus.

Les coûts de stockage et de calcul s’accumulent

Une granularité plus fine signifie plus de lignes, ce qui augmente les coûts de stockage. Elle augmente également les coûts de calcul , car les requêtes doivent traiter davantage de données. Dans Azure Databricks, ces coûts se composent au fil du temps à mesure que les données historiques s’accumulent.

Une usine de fabrication avec des milliers de capteurs capturant des lectures à intervalles de millisecondes peut générer des milliards de lignes quotidiennement à la plus fine granularité. L’agrégation à des statistiques par seconde ou par minute peut réduire le nombre de lignes de 99 % ou plus, se traduisant directement par des coûts de stockage et de requête plus bas.

Questions relatives à la conformité et à l’audit

Les exigences réglementaires imposent parfois des niveaux de granularité spécifiques. Les organisations de services financiers doivent souvent conserver les détails au niveau des transactions à des fins d’audit, quels que soient les coûts de stockage. Les organisations de santé peuvent avoir besoin de suivre les interactions individuelles des patients pour des raisons de conformité.

Lorsque la conformité détermine votre décision de granularité, documentez clairement les exigences. Cette justification aide quand les parties prenantes interrogent pourquoi vous stockez plus de détails que les besoins analytiques seuls nécessiteraient.

Appliquer la granularité aux tables de faits

Les tables de faits bénéficient le plus de décisions de granularité minutieuses, car elles contiennent généralement les volumes de données les plus importants. Le grain d’une table de faits est déterminé par la combinaison de ses clés de dimension.

Une table de faits de vente avec des clés de dimension pour la date, le produit, le client et le magasin a un grain de « une ligne par produit par client par magasin par jour ». Chaque combinaison unique de ces valeurs de dimension crée une ligne distincte. L’ajout d’une clé de dimension de temps au niveau de l’heure modifierait le grain en « une ligne par produit par client par magasin par heure », ce qui augmente considérablement le nombre de lignes.

Lorsque vous concevez des tables de faits, déterminez si vous avez besoin des éléments suivants :

• Grain atomique : niveau le plus détaillé capturé dans le système source. Choisir une granularité atomique offre une flexibilité analytique maximale car vous pouvez toujours agréger, mais jamais désagréger.

• Niveau agrégé: données résumées à un niveau supérieur à celui de la source. Les tables de faits agrégées améliorent les performances des requêtes pour les modèles analytiques courants, mais limitent les questions auxquelles les utilisateurs peuvent répondre.

De nombreuses organisations gèrent des tables de faits atomiques et agrégées, en utilisant des tables d’agrégation comme optimisation des performances tout en préservant les détails atomiques pour l’analyse ad hoc. Dans Azure Databricks, les vues matérialisées peuvent gérer automatiquement ces tables d’agrégation, et les actualiser au fur et à mesure que les données atomiques sous-jacentes évoluent.

Appliquer la granularité aux tables de dimension

Les tables de dimension ont également une granularité, mais elle fonctionne différemment de la granularité des tables de faits. Le grain de dimension détermine la façon dont vous représentez et versionez vos entités métier.

Pour une dimension client, vous pouvez choisir :

• Une ligne par client : état actuel de chaque client, mis à jour en place lorsque les attributs changent (SCD Type 1).
• Une ligne par client par version : nouvelle ligne pour chaque modification significative, préservant les états historiques (SCD Type 2).
• Une ligne par client par période : captures instantanées périodiques capturant les attributs du client à intervalles réguliers.

Le grain de dimension que vous choisissez doit s’aligner sur le grain de votre table de faits. Si votre table de faits suit des transactions individuelles avec des clés de substitution vers la dimension client, la granularité de votre dimension client doit prendre en charge cette relation. Une transaction faisant référence à la version 5 du client doit être en mesure de trouver cette version spécifique dans la table de dimension.

Équilibrer les compromis lors de la sélection de la granularité

Aucun choix de granularité unique n’est universel. Chaque décision implique des compromis que vous devez évaluer par rapport à vos exigences spécifiques.

Lorsque vous êtes incertain, commencer par une granularité plus fine est souvent plus sûr. Vous pouvez toujours créer des tables d’agrégation ultérieurement pour l’optimisation des performances, mais vous ne pouvez pas récupérer les détails qui n’ont jamais été capturés. Toutefois, ces conseils supposent que vous disposez du budget et de l’infrastructure pour prendre en charge le stockage plus précis initialement.

Comprendre comment choisir une granularité appropriée vous permet de concevoir des modèles de données qui prennent en charge les besoins analytiques de votre organisation tout en gérant efficacement les coûts. Les détails de l’implémentation pour la création et le chargement de tables à la granularité choisie dans Azure Databricks sont abordés dans les unités ultérieures.