L'automatisé, Pas de code Pile de données
Apprener comment Astera Data Stack peut simplifier et rationaliser la gestion des données de votre entreprise.
Charger des données dans des faits et des dimensions - Un jeu d'enfant ?
KimballLa modélisation dimensionnelle de style a été l'architecture de choix pour la plupart des développeurs d'entrepôts de données au cours des deux dernières décennies. La nature dénormalisée de ces schémas, associée à l'optimisation de la maintenance de l'historique, fait du modèle dimensionnel un outil idéal pour l'arsenal d'entreposage de données, en particulier pour le reporting via l'intelligence d'entreprise (BI) outils.
À première vue, l'idée est simple : les tables de faits contiennent des informations transactionnelles et les dimensions fournissent un contexte à ces faits via des relations de clé étrangère. Cependant, les questions qui se posent sont les suivantes : Est-il facile de charger et de gérer des données dans des tables de faits et de dimension ? Et est-ce que ça vaut le coup ?
Prenons un scénario où vous avez mis en place une architecture pour votre entrepôt de données - un simple schéma en étoile composé d'informations sur les ventes dans la table de faits, entouré de quelques dimensions, telles que les clients, les fournisseurs, etc. Les données sources provenant initialement de systèmes disparates ont été chargées dans une couche intermédiaire unifiée.
L'objectif est de mettre en place un processus de chargement et de maintenance pour vos tables de dimensions et de faits. Le chargement de données dans des tables de dimension peut être simple, étant donné que vous ne cherchez pas à conserver l'historique. Dans ce cas, vous ne souhaitez mettre à jour que les enregistrements de destination, ce qui peut être effectué via Dimensions qui changent lentement Type 1 (SCD1). Voici un extrait de ce à quoi ressemblerait cette requête :
Cependant, il est peu probable que cela soit suffisant dans un scénario commercial pratique. Il est important de conserver au moins un historique dans un entrepôt de données pour identifier les tendances et les modèles. C'est là que d'autres types de SCD, plus compliqués, entrent en jeu, tels que les SCD 2, 3 et 6.
Si vous avez l'intention d'utiliser SCD 2 ou 6 sur certains champs, la table doit également contenir des identifiants d'enregistrement pour reconnaître la ligne active pour chaque enregistrement. Il peut s'agir d'un indicateur vrai/faux, d'une plage de dates d'expiration effectives ou simplement d'un numéro de version pour chaque enregistrement, pour ne citer que quelques exemples.
Si vous souhaitez utiliser SCD 3 ou 6, vous aurez besoin d'un champ supplémentaire pour stocker la valeur précédente du champ en question.
Voici à quoi pourrait ressembler une partie de la requête si vous deviez utiliser SCD 2 ou 6 pour conserver l'historique :
Cela commence-t-il à paraître un peu compliqué ? Nous n'avons touché que la pointe de l'iceberg.
Vous auriez probablement besoin de différents niveaux d'historique pour différents domaines. Supposons, par exemple, que vous disposiez d'une dimension d'employé contenant des informations sur le salaire et le numéro de téléphone des employés. Ici, vous voudrez peut-être suivre l'évolution du salaire d'un employé, mais mettez simplement à jour le numéro de téléphone.
Pour des cas comme celui-ci, vous utiliserez plusieurs types de SCD ; SCD 1 pour les champs qui nécessitent simplement des mises à jour et SCD 2, 3 ou 6 pour les champs qui nécessitent un certain niveau d'historique pour être conservés. Avec tant de choses à prendre en compte, vous pouvez imaginer la complexité de la requête !
Jusqu'à présent, nous nous sommes concentrés sur la population et la maintenance des tables de dimension. Ces dimensions fournissent un contexte aux informations stockées dans les tables de faits. Par conséquent, chaque modification apportée à une table de dimensions est également propagée dans la table de faits ; s'assurer que cette propagation est effectuée avec précision peut être difficile.
Certaines des informations que vous devez charger dans la table de faits ne sont pas disponibles dans la source. Les clés de substitution utilisées pour établir des relations entre les dimensions et les tables de faits sont inexistantes dans la couche intermédiaire — elles ont été créées en tant que clés générées par le système dans chaque dimension.
Par conséquent, vous devez concevoir un mécanisme qui utilise des recherches de dimension pour prendre chaque clé métier (naturelle) entrante de la couche intermédiaire vers la dimension appropriée et récupérer la clé de substitution active pour cet enregistrement. De plus, les complexités de la récupération de ces clés de substitution varient en fonction du type SCD utilisé pour chaque champ et de l'identifiant de ligne présent dans la table de dimension.
Comme si ce processus n'était pas assez complexe, voici une autre courbe pour vous : que se passe-t-il si vous avez des entrées manquantes dans la table de faits qui ne nécessitent pas la clé de substitution la plus à jour ? Vous pouvez utiliser une clé de date de transaction pour déterminer la clé de substitution active, étant donné que vous avez utilisé un identifiant de ligne active spécifique à l'horodatage, tel que la plage de dates d'expiration effective.
La situation pourrait également être l'inverse : vous pouvez avoir des entrées dans la table de faits qui font référence à un enregistrement de dimension qui n'a pas encore été ajouté à la table de dimension. Il s'agit d'un casse-tête courant en matière d'entreposage de données : dimensions tardives et faits précoces. Pour répondre à ce problème, vous pouvez créer un enregistrement factice dans la table de dimension lors de l'exécution.
Cet enregistrement serait éventuellement remplacé par l'enregistrement de dimension approprié (différé) provenant de la source. Mais cela permettrait au moins à la recherche de dimension de se produire au bon moment sans aucun problème inutile.
Dans l'ensemble, le chargement de données dans la table de faits peut être un processus fastidieux et sujet aux erreurs. Si les problèmes soulignés ci-dessus ne sont pas résolus. Par exemple, vos pipelines pourraient tomber en panne ou votre entrepôt pourrait finir par contenir des données inexactes.
Voici un exemple de requête qui pourrait charger des données dans une table de faits :
Disons que vous faites tout. Vous avez tapé avec succès toutes les requêtes nécessaires, et elles sont parfaites. Votre travail n'est pas encore tout à fait terminé. Un processus d'entreposage de données n'est jamais complètement terminé car la maintenance de l'écosystème est aussi importante que sa conception en premier lieu. Pour optimiser les performances, vous devez vous assurer que les données sont chargées de manière incrémentielle, ce qui nécessite la mise en œuvre du mécanisme Change Data Capture (CDC).
De plus, ces requêtes complexes nécessiteraient des mises à jour fréquentes, en fonction des besoins de l'entreprise. Vous devrez peut-être ajouter ou supprimer des champs, modifier certains types de données, modifier le type SCD appliqué à un champ, etc. Apporter ces modifications aux requêtes est non seulement chronophage, mais également extrêmement sujet aux erreurs. Avant de vous en rendre compte, vous avez peut-être gâché un pipeline existant lors de la mise en œuvre d'un changement mineur dans le mécanisme de chargement.
Malgré ces problèmes de maintenance potentiels, vous auriez toujours l'impression que la plupart du travail acharné est fait. Cependant, les entreprises cherchent constamment à moderniser et à améliorer leurs processus de données. Un jour viendra peut-être où votre entreprise décidera de changer de plate-forme d'entrepôt de données. Disons qu'ils ont décidé de passer de SQL Server sur site à une plate-forme cloud comme Flocon or Redshift d'Amazon.
Vous rendez-vous compte de ce que cela nécessiterait ? Tout d'abord, vous devez créer une nouvelle architecture sur la nouvelle plate-forme. Ensuite, réécrivez toutes les requêtes pour configurer des pipelines natifs vers les nouvelles tables de destination. Vous auriez essentiellement à refaire tout le processus - à partir de zéro ! Ainsi, sur la base de tout ce que nous avons dévoilé, il est prudent de conclure que le chargement de données dans des tables de faits et de dimensions est ne pas une part de gateau. Le niveau de complexité impliqué peut devenir trop élevé, même pour les utilisateurs techniques.
Et si je vous disais qu'il existe un moyen beaucoup plus simple d'obtenir le même résultat ?
Avec Astera Constructeur d'entrepôt de données, vous pouvez construire une architecture pour votre modèle dimensionnel à l'aide du concepteur de modèle de données intuitif. De plus, l'interface click-and-point vous permet d'attribuer des rôles, tels que des types de SCD, des identifiants de lignes actives, des clés de date de transaction, etc., aux champs dans les tables de faits et de dimensions.
Plus important encore, vous pouvez exploiter les informations contenues dans vos modèles dans le composant ETL/ELT basé sur le glisser-déposer de l'outil pour automatiser les tâches fastidieuses et chronophages impliquées dans le chargement des tables de faits et de dimensions - allant de la maintenance des SCD dans les dimensions à l'exécution recherches de dimension dans les tables de faits. Le code compliqué que nous avons vu précédemment est généré automatiquement par l'outil.
Pourquoi perdre autant de temps et d'efforts à écrire d'énormes requêtes alors que vous pouvez obtenir le même résultat en utilisant une interface visuelle simple ? Même si le chargement de données dans des faits et des dimensions n'est généralement pas un jeu d'enfant, avec Astera Data Warehouse Builder, c'est possible !
Si vous souhaitez explorer la manière agile de créer votre entrepôt de données, contactez-nous à [email protected] aujourd'hui ou téléchargez un Essai gratuit 14-day.
