Conseil 30: Mettez vos tables de faits au régime

Au milieu des années 1990, avant internet, il semblait que l'explosion des données pourrait finalement décroître  A cette époque, nous étions en train d'apprendre à capturer chaque appel téléphonique, chaque article vendu à une caisse enregistreuse, chaque transaction d'actions à Wall Street, et toutes les transactions de polices par d'énormes compagnies d'assurance. Il est vrai que nous n'avons pas souvent conservé une très longue période de certaines de ces sources de données dans nos entrepôts de données, mais il y avait un sentiment que peut-être nous avions atteint une sorte de limite physique à la granularité des données. Peut-être que nous avions enfin rencontré les vrais "atomes" des données.

Eh bien, ce point de vue était évidemment faux. Nous savons maintenant qu'il n'y a pas de limite à la quantité de données que nous pouvons recueillir. Chaque mesure peut être remplacée par toute une série de sous-mesures plus fines. Sur le web, dans les Weblogs nous voyons chaque geste effectué par un visiteur avant qu'il regarde et achète un produit. Nous avons remplacé l'enregistrement unique d'achat de produit par une douzaine ou une centaine d'enregistrements de suivi du comportement. Le pire, c'est que les gens du marketing adorent ces enregistrements de suivi du comportement, et ils veulent en faire toutes sortes d'analyses.



Attendez que les systèmes de capture de données GPS soient incorporées dans nos voitures et nos cartes de crédit et nos téléphones. Chaque être humain pourrait éventuellement générer un ou plusieurs enregistrements, chaque seconde, 24 heures par jour!

Bien que nous ne pouvons pas arrêter cette avalanche de données, nous devons essayer de la contrôler, ou nous allons dépenser trop d'argent dans ​​le stockage sur disque. Beaucoup de nos plans de dimensionnement de données actuels sont basés sur des estimations rapides. Dans de nombreux cas, ces estimations exagèrent sérieusement nos besoins de stockage. Le résultat peut être une décision d'acheter beaucoup trop d'unités de stockage, ou bien d'annuler nos plans pour analyser les données disponibles.

Dans la modélisation dimensionnelle, il est facile de voir que le coupable est toujours la table de faits. La fréquence élevée, des mesures répétées de nos activités sont stockées dans la table de faits. La table de faits est entouré par des tables de dimensions plus petites. Même une énorme table de dimension Client avec des millions d'enregistrements sera beaucoup plus petite que la plus grande table de faits.

En prêtant une attention soutenue à la conception de nos tables de faits, nous pouvons souvent les réduire de manière significative. Voici les possibilités:

1. Remplacer toutes les clés étrangères naturelles par des clés de substitution constituées d'entiers les plus petits possibles.
2. Remplacer toutes les dates et timestamps par des clés de substitutions de type entier.
3. Fusionner les dimensions corrélées dans des dimensions individuelles, si c'est possible.
4. Grouper les petites dimensions de faible cardinalité ensemble, même si elles n'ont pas de lien.
5. Sortir tous les champs texte de la table de faits. Faites-en des dimensions. Surtout si ce sont des champs de commentaires.
6. Remplacer tous les faits de type entier long et float par des entiers adaptés à la bonne échelle, si c'est possible.

À titre d'exemple, supposons que nous sommes une grande compagnie de téléphonie traitant 300 millions d'appels par jour. Nous pourrions facilement faire un plan de dimensionnement des données pour le suivi de tous ces appels sur une période de 3 ans en se basant sur les hypothèses suivantes:

     Date/Heure = 8 octets, timestamp
     Numéro de téléphone appelant = 10 octets, chaîne
     Numéro de téléphone appelé = 15 octets, chaîne (pour les indicatifs internationaux)
     Fournisseur local = 10 octets, chaîne
     Fournisseur long distance = 10 octets, chaîne
     Fournisseur de service à valeur ajouté = 10 octets, chaîne
     Statut de l'appel = 5 octets, chaîne (100 valeurs possibles)
     Statut de fin = 5  octets, chaîne, (100 valeurs possibles)
     Durée = 4 octets, entier
     Taux de charge = 8 octets, float

Chaque appel représente un enregistrement de 85 octets. Conserver ces données sur trois années, sans index, demanderait 27,9 téraoctets  Si le volume est constant, alors il nous faudrait 776 gigaoctets d'espace de stockage supplémentaire par mois.

Évidemment, il y a du gaspillage dans l'enregistrement ci-dessus. Nous allons donc le reprendre en suivant les conseils énoncés plus haut. Ainsi, on peut coder les mêmes informations comme suit:


     Date = 2 octets, petit entier
     Heure = 2 octets, petit entier
     Numéro de téléphone appelant = 4 octets, entier - clé de substitution
     Numéro de téléphone appelé = 4 octets, entier - clé de substitution
     Fournisseur local = 2 octets, petit entier - clé de substitution
     Fournisseur long distance = 2 octets, petit entier - clé de substitution
     Fournisseur de service à valeur ajouté = 2 octets, petit entier - clé de substitution
     Statut = 2 octets, petit entier - clé de substitution (combinant le statut de l'appel et de fin)
     Durée = 4 octets, entier
     Taux de charge = 4 octets, entier

Nous avons fait quelques hypothèses sur les types de données pris en charge par notre base de données. Nous avons supposé que les 65 536 valeurs possibles qu'offrent un petit entier de 2 octets sont suffisants pour soutenir chaque dimension figurant ci-dessus.

Avec cette conception, l'espace nécessaire pour notre table de faits est de 9,2 téraoctets, soit une économie de 67%! Notre croissance mensuelle a chuté à 256 gigaoctets.

Bien que ces chiffres soient encore grands, ils nous laissent une certaine marge de manœuvre.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #30: Put your fact table on a diet", publié le 3 novembre 2001.