Comment architecturer le parfait entrepôt de données

Techniques d'entreposage clés simplifiées

Entreposage de données: simplifié

En surface, il peut sembler que beaucoup de choses ont changé ces dernières années en ce qui concerne la collecte, le stockage et l’entreposage des données. L’introduction et le rachat de NoSQL, des technologies «Big Data», Graphing et Streaming peuvent sembler avoir changé le paysage, mais il reste certains principes fondamentaux.

Dans mon rôle actuel, nous utilisons Amazon Redshift pour notre entreposage de données. Toutefois, que nous construisions un entrepôt de données traditionnel avec Oracle ou un lac de données dans Hadoop, l’architecture de base resterait la même.

L’architecture de base se résume à un prétraitement et à trois zones distinctes (schémas si vous utilisez redshift) appelées Staging, Master et Reporting. Dans cet article, je vais parler de chacun en détail.

Prétraitement

Malheureusement, toutes les données ne sont pas créées de manière égale, mais ce sont néanmoins des données qui ont donc une valeur.

Afin de faire face à la complexité des données externes, certains pré-traitements sont presque inévitables, en particulier lors de la collecte à partir de différentes sources. L'objectif principal de l'étape de prétraitement est d'obtenir les données dans un format cohérent pouvant être chargé par l'entrepôt de données.

Ceci inclut, mais n’est pas limité à:

  • Conversion de feuilles de calcul Excel au format CSV
  • Analyse des données JSON (nous avons tendance à traiter chaque objet sur une ligne dans une colonne et à laisser Redshift l’analyser, mais vous pouvez aussi l’analyser d’emblée)
  • Nettoyage des fichiers de données défectueux ou erronés

Une fois prêt, vous aurez besoin d’un emplacement central pour mettre ces fichiers prêts à être chargés dans l’entrepôt de données.

Un exemple pourrait être de placer tous les fichiers dans un compartiment Amazon S3. Il est polyvalent, bon marché et s’intègre à de nombreuses technologies. Si vous utilisez Redshift pour votre entrepôt de données, il offre également une excellente intégration.

Mise en scène

La zone de transit constitue le pain quotidien de tout entrepôt de données.

Un bon entrepôt de données prend des données provenant de nombreuses sources différentes. Chaque source de données possède ses propres nuances, styles et conventions de dénomination.

La zone intermédiaire est l'endroit idéal pour importer tout cela - probablement depuis l'endroit où vous l'avez placé après le pré-traitement (mais pas toujours) - et pour le stocker de manière transitoire jusqu'à ce qu'il soit traité plus loin dans la ligne.

Comme la zone de chargement dans un entrepôt réel. L’endroit où les marchandises sont déchargées n’est pas la destination finale ni la forme finale des matériaux ou des produits. C'est juste une zone d'attente.
Photo de Hannes Egler sur Unsplash

Il vous permet simplement, pour la première fois, de disposer de toutes les données dans les limites de l’entrepôt, prêtes pour un traitement et une modélisation ultérieurs.

Mon opinion personnelle est que les données dans la zone de transfert doivent être aussi proches que possible des données brutes (encore une fois, vous devez apporter des modifications lors du prétraitement, mais cela ne devrait pas changer ce que les données brutes vous indiquent). Vous voudrez peut-être même conserver les mêmes noms de colonne et de table. Cela facilite la recherche lors de la recherche ou du signalement de problèmes dans la source.

La zone de transit doit également être considérée comme transitoire.

Vous devez conserver les données pendant une période donnée dans la zone de transfert, après quoi elles doivent être purgées. Par exemple, vous pouvez conserver une fenêtre glissante de données d'un mois en cas d'échec des chargements ou de toute autre enquête.

C’est le dernier point où les données doivent être considérées comme brutes. À partir de ce moment, les données doivent être conformes aux normes de l'entrepôt de données.

Maître

La zone principale est l'endroit où les données entrantes prennent une forme réelle.

Le schéma principal doit contenir des tables correctement modélisées et nommées en conséquence. Les noms de colonnes doivent également être corrigés avec leurs types de données.

Cela facilite la compréhension de ce que sont les tables et de ce qu’elles contiennent, améliorant ainsi la convivialité. Tout comme le classement des documents à l’ancienne école.

Photo par Drew Beamer sur Unsplash

Lorsque vous déplacez des données de Staging dans Master, vous devez penser à les nettoyer, par exemple:

  • Normaliser tous les formats de date et les fuseaux horaires pour qu'ils soient identiques (le cas échéant)
  • Arrondir les nombres, le cas échéant, à moins de décimales
  • Nettoyage des chaînes pour éventuellement réparer la capitalisation ou supprimer les espaces blancs de début et de fin
  • Normaliser les adresses pour qu'elles soient du même format
  • Séparer les données en plusieurs colonnes ou les extraire de JSON
Je donnerais aussi un peu de temps pour faire en sorte que les noms des colonnes qui se joignent se rejoignent

Par exemple, si vous avez des données utilisateur issues de certains journaux Web, de votre magasin de données utilisateur dans MongoDB et éventuellement de certaines données publicitaires relatives aux utilisateurs. Espérons que ces sources contiendront un identifiant d'utilisateur unique. Cependant, ils pourraient ne pas l'appeler tous la même chose.

En normalisant les noms de colonnes, il devient alors si facile pour vous, ou pour tout autre utilisateur de vos données, de comprendre intuitivement quelles données peuvent être jointes.

En tant qu’ingénieur de données, c’est l’objectif ultime.

Vous disposez de données propres et nommées de manière appropriée pour correspondre au langage métier, modélisées correctement et prêtes pour toute exploration ou tout calcul en aval.

Rapport

Le travail de base est terminé. Nous avons préparé et ingéré, modélisé et nettoyé. Nous voulons maintenant exposer nos nouvelles données brillantes au monde. C'est ici que la couche de rapport entre en jeu.

À ce stade, si vous utilisez un entrepôt de données basé sur des lignes dans Oracle, vous pouvez créer des tables de faits et des dépôts de données. C’est un cas d’utilisation tout à fait raisonnable pour la couche de création de rapports, car vous pouvez y coller tout outil de création de rapports décent et vous êtes prêt à partir.

Cependant, certaines de ces techniques d’entreposage de données traditionnelles sont basées sur l’efficacité des solutions de stockage basées sur des rangées telles que Oracle. Ces systèmes sont efficaces pour joindre des données, mais les lignes comportant de nombreuses colonnes sont inefficaces, principalement en raison du fait que l'approche basée sur les lignes doit traiter la totalité de la ligne, même si la requête ne nécessite que quelques colonnes.

Si vous utilisez un entrepôt de données basé sur des colonnes comme Amazon Redshift, votre approche devrait être différente. Redshift ne s'inquiète pas des tables larges et dénormaliser les dimensions et les faits sur une seule table est préférable à plusieurs dimensions.

Les avantages de la modélisation de vos données de cette manière lors de l’utilisation de Redshift sont les suivants:

  • Efficacité améliorée, car Redshift gère plus facilement les tables larges que les nombreuses jointures.
  • Facilité d’utilisation pour les utilisateurs finaux ou les analystes qui ne connaissent pas les modèles de données car ils n’ont pas à se battre avec des jointures.
  • Il est plus facile d'interroger car toutes les données requises pour l'entité déclarée sont réunies au même endroit.
Photo de Micheile Henderson sur Unsplash

Par exemple, supposons que vous souhaitiez créer des rapports sur vos clients. Vous avez une table de clients, une table de commandes, une table de journaux marketing et des données d'analyse Web dans votre couche principale épurée.

Dans Redshift, dans la couche de génération de rapports, vous construisez une table de clients. Cela conserverait toutes les données client standard (moins leurs données personnelles, car elles ne devraient pas être requises pour les rapports), telles que leur date d’enregistrement, peut-être un code postal, etc.

Vous pouvez indiquer s'ils sont enregistrés sur un appareil mobile ou s'ils ont installé votre application smartphone ou votre application de bureau.

Vous pouvez joindre les données de commande et créer des colonnes de faits telles que le total dépensé à ce jour, la date de la première commande, la date de la dernière commande, le nombre de commandes.

La table marketing vous permet de faire la même chose et de créer des faits pertinents tels que le nombre d’e-mails envoyés, ouverts et cliqués, etc.

À partir des analyses Web, vous pouvez extraire la date de leur dernière visite sur le site Web, leur appareil préféré, le type d’appareil le plus courant (ordinateur de bureau, téléphone portable, etc.), etc.

Vous obtenez la photo.

“Graphiques avec des statistiques sur l'écran d'un ordinateur portable sur une surface brillante” par Carlos Muza sur Unsplash

Tout cela aboutit à un tableau client très large avec toutes les dimensions et faits pertinents. Vos analystes peuvent l’utiliser pour tout calculer: taux d’acquisition, modification de l’utilisation des appareils dans votre base de clients, clients importants (et leurs points communs), déviation et engagement des clients, et bien plus encore.

Tout cela à partir d'un seul endroit, sans jointure et avec la majeure partie du travail lourd effectué comme il se doit, en utilisant la puissance de l'entrepôt de données.

Les entrepôts de données n’ont pas tendance à être bon marché et sont littéralement conçus pour traiter des données. Profitez-en au maximum, faites tout ce que vous pouvez ici. Libérez vos analystes pour qu'ils exploitent les connaissances au lieu d'attendre que le serveur de rapports moins costaud fasse le gros du travail.

Vous constaterez peut-être que plus que les analystes ne souhaitent l’utiliser, si vous le rendez facile et rapide.

En résumé

En suivant cette approche simple, je pense que vous pouvez construire un entrepôt de données entièrement opérationnel, ce qui est non seulement facile à développer, mais également à comprendre.

Vous voudrez peut-être considérer vos couches de stockage intermédiaire, principal et de rapport comme des éléments logiques. Cela peut fonctionner pour vous. Je préfère les séparer physiquement car non seulement cela vous semble plus propre, mais vous permet également de limiter ce que les utilisateurs finaux peuvent utiliser et voir à partir des états précédents.