Principes de test – Entrepôt de données vs Data Lake vs Data Vault

Ce blog tente de faire la lumière sur les entrepôts de données terminologiques, le lac de données et le coffre-fort de données. Cela donnera un aperçu de leurs avantages, de leurs différences et des principes de test impliqués dans chacune de ces méthodologies de modélisation de données.

Commençons par l'entrepôt de données.

Qu'est-ce que l'entrepôt de données?

Un entrepôt de données est un référentiel central de données intégrées provenant d'une ou de plusieurs sources. Ils stockent les données actuelles et historiques en un seul endroit, qui sont utilisées pour créer des rapports analytiques pour les travailleurs de l'ensemble de l'entreprise.

Les données stockées dans l'entrepôt proviennent de diverses sources de données opérationnelles (ODS), ce qui signifie qu'elles peuvent être obtenues à partir de systèmes hétérogènes et nécessitent généralement le nettoyage des données pour des opérations supplémentaires afin d'assurer la qualité des données avant qu'elles ne soient utilisées dans le DW pour la génération de rapports.

Le type d'extrait, de transformation, de charge L'entrepôt de données basé sur (ETL) a la mise en scène l'intégration de données et les couches d'accès. La couche intermédiaire ou la base de données intermédiaire stocke les données brutes extraites de chacun des différents systèmes de données source. La couche d'intégration intègre les différents ensembles de données en transformant les données de la couche intermédiaire en stockant souvent ces données transformées dans une base de données ODS. Les données intégrées sont ensuite déplacées vers une autre base de données, souvent appelée base de données d'entrepôt d'entreprise, dans laquelle les données sont classées en groupes classifiés, souvent appelés dimensions, et en faits et faits agrégés. La combinaison des tables de faits et de dimensions s'appelle un schéma en étoile . La couche de génération de rapports aide les utilisateurs à récupérer des données.

Un entrepôt de données est un référentiel consolidé, organisé et structuré permettant de stocker des données. Les tests ETL impliquent essentiellement la vérification et la validation des données transitant par un canal ETL. Après tout, si les données qui aboutissent dans les systèmes cibles ne sont pas précises, les rapports et les décisions de l'entreprise peuvent s'avérer incorrects.

La complexité et la criticité des projets de test des entrepôts de données augmentent rapidement chaque jour. Les entrepôts de données doivent être validés pour la fonctionnalité, la qualité, l'intégrité, l'accessibilité, l'évolutivité et la sécurité en fonction des exigences commerciales définies par une organisation.

pratiques en matière de test ETL:

• Assurez-vous que les données ont été transformées et chargées correctement.
• Les données doivent être chargées dans l'entrepôt sans aucune troncature ni perte de données.
• Assurez-vous que l'application ETL rejette et remplace correctement avec les valeurs par défaut. et signale des données exceptionnelles qui ne sont pas valides
• Confirmez l'évolutivité et les performances en vous assurant que les données ont été chargées dans le laps de temps imparti.

Les problèmes liés aux tests ETL incluent:

• Validation des données
• Validation par contrainte : s'assurer que les limites des tables sont correctement définies
• Complétude des données: le contrôle de la vérification de la totalité des données a été effectué comme prévu
• Correction des données: vérification de la précision des données Très vérifié
• Validation des dates
• Propreté des données: suppression des colonnes inutiles

Passons maintenant au lac de données

Qu'est-ce que le lac de données?

Data Lake est généralement un emplacement unique pour toutes les données d'entreprise, y compris les copies brutes des données du système source et des données transformées utilisées pour des tâches telles que Reporting Visualisation Analytics et apprentissage machine . Un lac de données peut inclure des données structurées issues de bases de données relationnelles (lignes et colonnes), semi-structurées (CSV, journaux, XML, JSON), non structurées (emails, documents, PDF) et binaires (images, audio, vidéo).

Test du lac de données

Les quatre approches de test:

1. Test de migration: En cas de test de migration, données de la source est comparée à la cible pour garantir que toutes les données sont chargées dans Data Lake. Des tests de qualité et de conception des données sont également effectués sur la base de données cible.
2. Tests de bout en bout: Les tendances en matière de mise en œuvre de big data se concentrent sur la création de nouveaux lacs de données / concentrateurs de données, le big data remplaçant la base de données existante. systèmes d'entrepôt de données pour stocker des données dans différentes régions pour une récupération facile. Ces exécutions nécessitent différentes méthodes de test.

En fait, la mise en œuvre complète du lac de données nécessite les quatre méthodes de test suivantes:

• Test d'ingestion de données : données provenant de diverses sources Les sources telles que les médias sociaux, les journaux Web (non structurés) et les systèmes de sourcing tels que les SGBDR (structurés) sont validées pour la transformation, les modifications de format, le masquage, etc. En conséquence, les données seront validées à chaque étape de l'ingestion de données
• Tests de traitement des données: L'analyse de la qualité des données est la deuxième étape de test à suivre pour garantir l'intégrité des données et valider la transformation de l'entreprise. règles. Ceci doit être effectué dans les mégadonnées, une fois que les données sont déplacées des systèmes sources
• Tests d'exploration de données: Les données disponibles dans les lacs de données seront extraites en fonction d'une logique métier spécifique afin de garantir que les bonnes données sont filtrées et rendues accessibles pour d’autres magasins de données ou bases de données relationnelles. Ceci prend en charge la validation de la logique de requête de transformation
• Test de visualisation des données: Les rapports et les tests de visualisation concernent les utilisateurs finaux, pour lesquels la sortie est validée par rapport aux récits et à la conception d'utilisateurs. Les rapports constituent la base de nombreuses décisions, mais sont également les composants critiques du cadre de contrôle de l'organisation. En conséquence, les rapports, les tableaux de bord et les sorties mobiles sont vérifiés et validés

3. Tests de rapports: Lors de ce type de test, les rapports qui extraient des données d’entrepôts de données sont modifiés pour obtenir des données de grands magasins centraux. Deux validations sont effectuées: Comparaison des données affichées dans les rapports par rapport aux données disponibles dans le Big Data. Les rapports sont comparés visuellement ou validés par rapport à un format ou à un modèle prédéfini conçu par les utilisateurs ou les architectes
4. Tests d'archivage des données: Ce type de test est utilisé dans des magasins de données rares et principalement volumineux utilisés pour stocker des données à des fins d'audit et de vérification. fins de conformité. Les données ne sont pas traitées et sont stockées «en l’état» pour pouvoir les récupérer facilement. L'approche de validation implique une réconciliation source-cible, dans laquelle les données sont validées à partir de bases de données source avec des magasins de données volumineux cibles.

Définition du dépôt de données

Définition du dépôt de données

Un coffre de données est un système constitué d'un modèle, d'une méthodologie et d'une architecture qui est explicitement conçu pour résoudre un problème commercial complet à mesure que les exigences changent.

Les données du coffre de données sont généralement des ensembles de données RAW. Ainsi, dans le cas du Data Vault, la réconciliation avec le système source est recommandée pour les tests. Cela peut être une réconciliation avec les fichiers plats qui arrivent ou une comparaison avec les bases de données source. Parfois, il n’existe pas de «système» à réconcilier, car les données arrivent sur un service Web. Dans ce cas, suggérerions de stocker les données dans une couche intermédiaire.

Ce sont des caractéristiques de la modélisation de DATA Vault qui la sépare des autres approches

Elle sert structurer les données de l'entrepôt de données sous forme de systèmes d'enregistrements permanents et absorber les modifications structurelles sans aucune modification

Data Vault requiert le chargement des données exactement telles qu'elles existent dans le système source. Aucune modification, aucune modification, aucune application des règles commerciales (y compris le nettoyage des données). Cela garantit que le coffre de données est auditable à 100%.

Si les données sont modifiées à l’arrivée dans le coffre de données, cela empêche le suivi des données jusqu’à la source en cas d’audit, car nous ne pouvons pas faire correspondre les données de l’entrepôt de données. aux données source. EDW (Enterprise Data Warehouse) est également le magasin de l'entreprise pour les données historiques. Une fois les données supprimées des systèmes sources, le fichier EDW peut également être la source d'enregistrement. Il est donc essentiel que les données restent propres.

Le processus de création d'un coffre de données se fait en 5 étapes simples.

Étape 1: Établissez les clés de gestion / clés de hachage, hubs
Étape 2: établissez les relations entre les clés commerciales / clés de hachage, liens
Étape 3: Définissez une description autour des clés commerciales / clés de hachage, satellites
Étape 4: ajoutez des objets autonomes tels que des calendriers et des codes / descriptions pour le décodage dans les magasins de données
Étape 5 : Optimisation de la requête et ajout de tables de performances telles que des structures ponctuelles

Il est indispensable d'effectuer un test avec un coffre de données vide, suivi d'un chargement initial simple, suivi d'un chargement le deuxième jour. Une charge de jour 2 vous permettra de tester les données delta / incrémentielles et de supprimer les doublons de la zone de stockage intermédiaire. La stratégie de test générale convient le mieux aux projets adoptés par Data Vault. Cependant, en utilisant des charges brutes Data Vault, nous pouvons limiter les transformations à un niveau minimum dans l'ensemble du processus ETL grâce à « Erreurs de charge admissibles ».

Les tests ETL / Data Warehouse Testing doivent mettre en évidence:

• Données quality of Source Systems
• Rapprochement des données entre la source et la cible
• Problèmes de performance, d'évolutivité et de mise à niveau de BI Reports

Voici cinq propositions importantes visant à exécuter des tests pour un projet Data Vault – ETL / DWH conforme à ce qui précède pointage de base:

1. Concevez une petite base de données de tests statiques dérivée des données réelles pour exécuter les tests rapidement et les résultats attendus peuvent être identifiés à l'étape précédente.
2. Exécution rapide des tests du système pour garantir les boîtes de connexion dans l'interface ETL .
3. Engagez les utilisateurs professionnels lors de la génération et de la dérivation des données réelles dans une petite base de données de tests afin d’assurer le profilage et la qualité des données.
4. Simulez l’environnement de test tel quel de la production à c.
5. Exécutez les ETL, capturez les journaux et validez tous les flux de données (Mauvais / Rejeté / Valide / Négatif)

Nous pouvons résumer les différences comme indiqué