Retour à Data Warehouse
Data Warehouse

QCM

Consultez les contenus publiés dans cette ressource.

Ressources en accès libre

QCM de « Data Warehouse »

44 contenus
41
Question à choix multiples

Lors d'une migration, les totaux correspondent mais les résultats par segment diffèrent. Quelles investigations sont nécessaires ?

  • Comparer les règles de segmentation et les mappings de dimensions Bonne réponse
  • Vérifier les fuseaux horaires, fenêtres temporelles et filtres Bonne réponse
  • Examiner les jointures et la granularité à un niveau détaillé Bonne réponse
  • Conclure que la migration est correcte puisque le total général correspond
Explication

Notion : Réconciliation détaillée des résultats de migration.
Explication : Un total général identique peut masquer des écarts entre segments qui se compensent. Il faut comparer les règles de segmentation et les mappings de dimensions pour vérifier l'attribution des données. Les fuseaux horaires, fenêtres temporelles et filtres déterminent ensuite quels événements entrent dans chaque périmètre. Enfin, examiner les jointures et la granularité permet de repérer des duplications ou des associations incorrectes. Ces investigations se complètent pour localiser l'origine des différences.
À retenir : Valider les résultats à des niveaux de détail utiles, pas seulement au total général.
Piège fréquent : Confondre égalité globale et exactitude de chaque segment conduit à valider une migration potentiellement incorrecte.

42
Question à choix multiples

Une analyse compare des événements en heure locale alors que les données sont stockées en UTC. Quels risques faut-il traiter ?

  • Des événements proches de minuit peuvent changer de jour analytique Bonne réponse
  • Les fenêtres journalières et mensuelles peuvent différer selon le fuseau Bonne réponse
  • Le fuseau de référence doit être documenté et cohérent dans les transformations Bonne réponse
  • UTC et heure locale produisent toujours les mêmes agrégations
Explication

Notion : Fuseau de référence et périodes analytiques.
Explication : Un même événement stocké en UTC peut appartenir à une autre date lorsqu'il est exprimé en heure locale, notamment près de minuit. Les bornes des journées et des mois ne correspondent donc pas nécessairement aux mêmes instants selon le fuseau utilisé. Cela peut modifier les agrégations et l'attribution des événements aux périodes. Documenter le fuseau de référence et l'appliquer de façon cohérente dans les transformations permet de rendre les comparaisons interprétables.
À retenir : Une période analytique dépend de la convention temporelle retenue.
Piège fréquent : Supposer que le stockage en UTC produit automatiquement les mêmes regroupements qu'une analyse en heure locale.

43
Question à choix multiples

Quelles précautions sont nécessaires pour calculer une fenêtre glissante de 30 jours ?

  • Utiliser une dimension ou un calendrier permettant de représenter les jours sans événements Bonne réponse
  • Définir précisément si les bornes sont inclusives ou exclusives Bonne réponse
  • Distinguer une fenêtre de 30 jours d'une fenêtre de 30 lignes Bonne réponse
  • Utiliser toujours les 30 lignes précédentes comme équivalent exact de 30 jours
Explication

Notion : Fenêtre temporelle glissante et fenêtre de lignes.
Explication : Calculer une fenêtre glissante de 30 jours exige de raisonner sur les dates, pas seulement sur la position des lignes. Un calendrier ou une dimension date permet de représenter aussi les journées sans événements. Les bornes inclusives ou exclusives doivent être précisées pour déterminer exactement quelles dates participent au calcul. Ces précautions se complètent : continuité du calendrier et définition des bornes rendent le périmètre temporel explicite.
À retenir : Trente jours décrivent une durée ; trente lignes décrivent un nombre d'enregistrements.
Piège fréquent : Assimiler systématiquement les 30 lignes précédentes à 30 jours, alors que certains jours peuvent être absents ou comporter plusieurs lignes.

44
Question à choix multiples

Quels éléments doivent être surveillés après la mise en production d'un pipeline Data Warehouse ?

  • La fraîcheur et le retard des données Bonne réponse
  • Les volumes, durées et erreurs d'exécution Bonne réponse
  • Les coûts de stockage et de calcul Bonne réponse
  • Les tests de qualité et les changements de schéma Bonne réponse
  • Uniquement le statut vert ou rouge du dernier job
Explication

Notion : Observabilité d'un pipeline en production.
Explication : La fraîcheur et le retard indiquent si les données sont disponibles à temps. Les volumes, durées et erreurs renseignent sur le comportement des traitements. Les coûts de stockage et de calcul suivent leur consommation de ressources. Les tests de qualité et la surveillance des changements de schéma vérifient que les données restent exploitables. Ces dimensions se complètent et doivent alimenter des alertes actionnables, avec des responsables identifiés.
À retenir : Surveiller un pipeline signifie observer ses données, son exécution et ses coûts.
Piège fréquent : Le seul statut vert ou rouge du dernier job ne révèle pas nécessairement des données anciennes, des volumes inhabituels ou une qualité dégradée.

Passez de la consultation à l’entraînement

Avec un compte Quizos, entraînez-vous sur ces ressources et retrouvez votre progression.

Paramètres

Définissez votre propre style personnalisé

Schéma de couleurs

Choisissez le mode de couleur parfait pour vous.


Style de barre de navigation verticale

Basculer entre les styles de votre barre de navigation verticale

customize