Q / R: Travailler avec l'entrepôt de données à haut volume Centerprise

Le premier dans notre Centerprise Série de webinaires sur les meilleures pratiques discute des caractéristiques de Centerprise qui en font la solution d'intégration idéale pour l'entrepôt de données à volume élevé. Les sujets incluent qualité des données (profilage, mesures de qualité et validation), la traduction des données en schéma en étoile (maintien des relations de clé étrangère et de la cardinalité avec des dimensions à évolution lente) et les performances, y compris l'interrogation des données avec des jointures de base de données et la mise en cache. Nous avons publié les questions-réponses ci-dessous, qui abordent des sujets intéressants.

Q: Le profilage de données peut-il être autonome?

A: Oui, absolument. C'est exactement ce qui est fait dans l'exemple d'analyse de commande présenté ci-dessous. Si vous regardez les cibles, je n'écris pas dans un entrepôt de données ni ne déplace aucune donnée, je ne fais que créer des rapports pour cela. Alors oui, vous pouvez utiliser cette information séparément, ce que je fais dans ce cas-ci, c'est rassembler des informations sur ce schéma particulier

Q: Pouvons-nous regrouper un ensemble de règles de qualité des données et les utiliser dans plusieurs flux?

A: oui Comme indiqué ci-dessous, vous pouvez créer plusieurs règles et en faire un composant raisonnable en les faisant simplement glisser dans le projet. Vous pouvez voir que ce composant de contrôle de données devient alors une case grisée et qu’il s’agit maintenant d’une référence. Maintenant, si j’ai un autre flux, je peux utiliser cette vérification de données car c’est par référence. C'est une très bonne pratique de le faire à tout moment. Vous vous remercierez à l'avenir.

Q: Expliquez comment le cache de recherche persistant améliore les performances

R: Dans l'exemple ci-dessous utilisant la recherche de produit de dimension, il s'agit d'un outil qui sera utilisé à maintes reprises. Vous ne souhaitez donc pas avoir à charger cette table de dimension à chaque fois. Vous pouvez voir où cette table de dimension peut contenir des centaines de milliers de lignes. Ainsi, si vous chargez chaque table de faits, vous devez charger toutes les données pour une recherche, clairement le traitement, tous les données traversant lors de la migration. va être consommé en seulement des consultations. Alors au lieu maintenant dans Centerprise vous pouvez utiliser le cache de recherche persistant. Centerprise dispose d'une base de données intégrée dans laquelle il stocke ces informations, qui sont stockées sur disque, de sorte que vous n'avez pas à vous soucier de l'utilisation de la mémoire. Chaque fois qu'une recherche utilise cette étiquette, elle consultera alors ce cache plutôt que de se rendre dans la base de données. Quoi qu'il en soit, consulter la base de données coûte cher par nature. Effectuer de manière répétitive une visite dans une très grande table et récupérer tous les enregistrements sont extrêmement coûteux et peuvent en réalité mettre un terme à votre processus. Je recommande d'utiliser le cache persistant chaque fois que vous en avez la possibilité.

Q: Quelles sont les causes les plus fréquentes de problèmes de performances liés au chargement d’entrepôts de données rencontrées par les utilisateurs? Centerprise?

A: La première cause de problèmes de performances avec Centerprise, comme avec tout intégration de données programme, est le volume de données - avoir trop de recherches, en particulier trop de recherches dans une colonne. Dans l'exemple ci-dessous, vous pouvez voir que dans la table de faits, toutes les clés ont besoin d'une sorte de recherche et si vous avez, par exemple, 10 recherches juste avant la table de dimension, chacune de ces recherches doit être terminée avant que l'enregistrement puisse être inséré. dans une table de faits. Ainsi, avoir beaucoup de recherches inefficaces ralentira considérablement le flux de données.

La requête initiale est un autre problème susceptible de nuire aux performances. Pour résoudre ce problème, vous devez paramétrer ces requêtes, ce qui peut être effectué de différentes manières. Tout d'abord, vous pouvez utiliser des variables contrôlées de l'extérieur. Par exemple, si vous avez un flux de travail qui déclenche tous vos flux de données, vous pouvez définir ce flux de travail pour les enregistrements sur une durée limitée, par exemple une semaine. Cela réduira considérablement le volume de données entre la base de données source et Centerprise.

Une troisième option est très similaire à l'utilisation de variables, mais utilise à la place une charge incrémentielle basée sur les champs d'audit. Si vous avez un champ dont vous savez qu'il est garanti d'être modifié à chaque fois qu'un changement lui arrive, vous pouvez utiliser l'en-tête de date de modification dans le champ d'audit comme indiqué dans l'exemple ci-dessous et il stockera ces informations dans un fichier.

Ensuite, à des moments ultérieurs, le flux de données va s'exécuter, il consultera ce fichier et fera essentiellement la même chose que vous avez définie dans votre clause «where», mais le fera automatiquement dans ce fichier «where». Donc, l’avantage, c’est que vous n’avez pas à suivre les variables, l’inconvénient est que vous avez maintenant un fichier incrémentiel par objet à partir duquel vous chargez. Cela fait apparaître le fait que vous pouvez même souhaiter que les sources soient des actions partagées, de cette façon vous n'avez pas à continuer à les définir et à définir leurs champs d'audit.

Q: L’utilisation de l’écriture par contrainte détermine-t-elle automatiquement la séquence d’écriture?

A: Oui c'est le cas. Le nombre de tables sur lesquelles vous écrivez importe peu, tant qu'elles se trouvent dans la même base de données. Vous choisissez l'option Utiliser l'écriture basée sur les contraintes et il sait dans quel ordre écrire. Il sait qu'il doit d'abord écrire le client, puis la commande client. Il s'occupe de l'ordre des opérations qu'il écrit pour vous.

Q: Comment le processeur Diff se compare-t-il aux performances upsert?

A: Diff Processor est beaucoup plus rapide que l'Upsert. Upsert va lancer une autre requête pour voir si les informations existent ou non, tandis que le processeur de différences fonctionne en envoyant tous les enregistrements par lots au système cible. Ils sont ensuite écrits dans une table temporaire et joints. Cette comparaison se produit du côté de la base de données plutôt que du Centerprise côté, donc de gros morceaux sont préparés du côté de la base de données plutôt que d'utiliser une requête séparée pour savoir si une insertion ou une mise à jour doit avoir lieu. Fondamentalement, upsert effectue un enregistrement à la fois et Diff Processor compare par lots. Nous avons constaté que c'était des ordres de grandeur plus rapides.

Q: Soutenez-vous la charge rapide pour Teradata?

R : Oui, le chargement rapide et le chargement multiple sont pris en charge pour Teradata. Le chargement rapide est automatiquement utilisé lorsque vous écrivez dans une table vide.