Modèle de stockage de données pour Data Workbench

Ce document vise à aider les nouveaux administrateurs et analystes qui viennent de terminer la formation Adobe Analytics Data Workbench. La lecture de cette article facilitera la visualisation du fonctionnement de ce logiciel tout en proposant des solutions aux problèmes et l’exécution d’une analyse approfondie.

Les architectures conventionnelles telles qu’une base de données relationnelle organisent les données en tableaux interconnectés par des clés. A l’inverse, le composant Data Workbench d’Adobe Analytics recourt à un procédé fondamentalement différent appelé architecture « roue ». Cet article décrit le fonctionnement de l’architecture roue par rapport aux éléments classiques et identifie ses atouts et ses faiblesses.  

Qu’est-ce qu’une architecture de roue ?

Considérez les données des visiteurs sur votre site Web comme des sacs circulant sur le tapis roulant à l’arrivée d’un aéroport. Dans cet exemple, votre objectif est de compter les sacs d’une couleur similaire au fur et à mesure de leur apparition.   

Pour interroger les sacs en circulation, vous pouvez identifier le premier sac, puis comptabiliser les sacs suivants passent devant vous.

À chaque fois qu’un sac correspondant défile, vous l’identifiez et comptabiliser les différents types. Cela vous permet de compter les sacs et de les regroupe en fonction du type.

Lorsque le premier sac passe à nouveau devant vous, vous savez alors qu’il a terminé l’ensemble du circuit. À ce stade, vous pouvez arrêter la comptabilisation et rapporter les résultats.

Si d’autres personnes doivent également interroger les résultats, ils peuvent aller à la roue et regarder les sacs pour une seule révolution, en commençant à la même révolution ou d’autres révolutions de la roue. Le tapis roulant, ou la roue de données, tourne toujours et une requête peut être entamée à tout moment et continuera jusqu’à ce qu’une seule révolution soit terminée.

En outre, Data Workbench garantit l’ordre totalement aléatoire des sacs sur le tapis. (Les compagnies aériennes font également un bon travail.) Cela permet d’afficher une requête de données circulaires comme un instantané aléatoire du total des données, permettant ainsi aux requêtes de calculer très rapidement les réponses approximatives en extrapolant les résultats de la population entière.

Avec 50 éléments de données, ceci risque de ne pas très bien fonctionner. Mais avec des millions ou des milliards de données, une estimation très précise du décompte des réponses final peut être extraite presque immédiatement.

Exécution de requêtes détaillées

Développons un peu plus cette analogie. Pour des requêtes analytiques plus détaillées, nous sortons tous les éléments du sac (tout en les gardant regroupés par voyageur). Le contenu est composé d’un petit sac, d’un sac de rangement encore plus petit et des objets individuels.

Maintenant que l’agent de requête a un accès direct au contenu, une requête plus détaillée comme « le nombre de voyageur avec une bouteille bleu » peut être réalisée.   

Structure hiérarchique dans un sac.

À partir de cette analogie, retournons aux données de visiteur : un sac pour chaque voyageur représente toutes les données pour un Visitor, l’étiquette le Visitor ID, les petits sacs une Visit, les sacs de rangement les Hits et les objets individuels les Events.

Sur le client Data Workbench, cette structure peut être décrite comme un schéma. Une description du schéma est présentée ici.

L’opération de mise en forme des données en fonction de cette architecture est appelée Log Processing. Il doit se produire dès que la structure hiérarchique change de manière significative.  Bien que ce procédé prenne du temps, vous obtiendrez des données optimisées pour des requêtes analytiques très rapides.

Les tableaux relationnels et l’analogie des sacs

Avant de décrire la manière dont la roue de données diffère des tableaux, réfléchissons à cette analogie de sacs par rapport à une approche traditionnelle. Dans une base de données relationnelle, les données seraient comparables à un grand nombre d’étagères avec des sacs. Cette architecture conventionnelle vous permet d’insérer rapidement un sac ou d’en extraire un spécifique.

Pour une analyse plus détaillée, les données de chaque sac devront être extraites et réduites dans des étagères distinctes.

Dans cette configuration, l’agent de requête doit résoudre les clés externes pour lier chacun des éléments sur les quatre étagères.  

Prise en compte de la surcharge pour la requête analytique

Lorsqu’une requête est ciblée pour une entité, la base de données relationnelle peut effectuer la requête très rapidement. Par exemple, une requête sur le « nombre d’événements lancés par M. Taro Adobe » : Pour ce genre de requête, l’agent de requête devrait rechercher une donnée sur le tableau Visitor, plusieurs données sur le tableau Visit et plus encore sur les tableaux Hit et Event. Il devrait également compter le nombre d’événements. Ce sont des étapes coûteuses pour la base de données que d’utiliser ces clés externes, mais c’est quand même une démarche pratique pour une seule personne.

Toutefois, une requête analytique est plus ouverte et requiert une réponse à la question : « Combien d’utilisateurs déclenchent combien d’événements par session ? » Cela nécessite une requête sur de nombreux enregistrements avec l’agent de requête qui répète les étapes onéreuses pour tous les utilisateurs. Par conséquent, lorsque vous avez des millions ou des milliards de visiteurs, cela devient rapidement impossible.

Grâce aux roues de données, les données de chaque visiteur sont organisées en un seul sac. Ainsi, l’agent de requête peut évaluer immédiatement chaque sac et passer au suivant, ce qui permet à la roue de terminer la requête en une seule recherche.  Donc, l’architecture de roue convient mieux aux requêtes analytiques.

Le cube OLAP

Pour augmenter la vitesse de requête analytique, le logiciel Business Intelligence (BI) typique repose sur une structure multidimensionnelle contenant des données de résumé pré-calculées, connues sous le nom de cube OLAP. En lançant une requête sur ces résumés, le temps de réponse est nettement plus court pour certaines applications, mais rencontre des problèmes avec les requêtes avancées.

Par exemple, une entreprise a des clients dans 50 pays différents, 1000 lignes de produits et 10 milliards de transactions par an. Les données sont stockées à l’aide des cubes tridimensionnels basés sur l’heure, le produit et le pays. Cela nécessite des pré-calculs de 1,2 milliards de cubes.

Dans cette architecture, la requête analytique pour « Combien de produits avons-nous vendus par heure dans chaque pays ? » peut être résolue rapidement par l’examen d’un résumé des cubes. C’est une grande amélioration des requêtes de tableau standard avec des références externes.

Augmentation du niveau de détails de la série de données et de l’échelle

Toutefois, une requête plus détaillée concernant « combien de produits ont été vendus par minute dans chaque pays ? » nécessitera des pré-calculs multipliées par 60 pour le cube OLAP. L’ajout de nouveaux produits, le développement du compte à différents pays ou l’introduction de nouvelles dimensions (comme la taille, le sexe, le matériau, etc.) entraînera la multiplication de la pile à un taux exponentiel par le cube OLAP.  

Au fur et à mesure que la pile du cube augmente, les pré-calculs et la mise à jour des données augmentent le temps de surcharge et forcent l’analyste à exécuter une requête sur un jeu de données qui est généralement en retard. Cette surcharge transactionnelle et la croissance exponentielle des données entre les tableaux augmentent le temps d’attente et limitent grandement les requêtes analytiques utilisant l’architecture de cube OLAP.

En revanche, une augmentation équivalente du niveau de détails de la série de données donnera une croissance différentielle plus petite.

En outre, sans surcharge de pré-calculs, les données récemment ajoutées sont disponibles peu de temps après leur addition. Cela permet aux analystes de lancer des requêtes pratiquement en temps réel. Le fonctionnement du traitement en temps réel sera discuté dans le prochain article.

Requête sur les données réelles par opposition au résumé des données réelles

Même lorsqu’une organisation a la capacité énorme de mettre à jour le résumé en temps quasiment réel, un autre facteur devrait également être pris en compte : une requête sur un cube OLAP est une requête sur le résumé des données, ce qui baisse le niveau de détail d’une série de données et entraîne par conséquent des pertes.  Inversement, les résultats de la requête sur la roue sont calculés à partir des données traitées directement.

Conclusion:

Comme indiqué dans ce document, l’opération d’Adobe Analytics Data Workbench peut être décrite comme des données de visiteur placées sur une roue au lieu de tableaux linéaires ou des étagères. Elle convient mieux à l’exécution de requêtes analytiques pour analyser de grandes quantités de données.

La compréhension des fonctionnements intérieurs de ce modèle de base de données vous aidera à tirer parti de ses avantages.