QCM

Notion : Déséquilibre de distribution, ou skew, dans un moteur distribué.
Explication : Une clé peu variée peut concentrer une quantité disproportionnée de données dans certaines partitions. Ces partitions traitent alors davantage de travail et peuvent devenir des goulots d’étranglement. Le temps total d’exécution peut dépendre de la partition la plus lente, même si les autres terminent rapidement. Il faut donc analyser la cardinalité, la répartition des valeurs et les jointures fréquentes avant de choisir une clé de distribution.
À retenir : Un bon parallélisme exige une répartition adaptée des données et du travail.
Piège fréquent : Croire qu’une faible cardinalité garantit une distribution efficace ; elle peut au contraire limiter l’utilisation équilibrée des ressources.

Notion : Optimisation d’une jointure distribuée entre faits et dimension.
Explication : Lorsqu’une dimension est petite, son broadcast ou sa réplication peut, selon le moteur, éviter de redistribuer massivement la grande table de faits. Réduire les lignes et les colonnes avant la jointure, lorsque cela est possible, limite le volume traité et déplacé. Vérifier les types et les clés de jointure assure une comparaison compatible. Ces précautions se complètent : stratégie de distribution, réduction du volume et compatibilité des clés agissent sur des aspects différents.
À retenir : Choisir une stratégie de jointure en fonction du moteur et des données réellement manipulées.
Piège fréquent : Diffuser systématiquement toute table sans examiner sa taille.

Notion : Fonction de fenêtre pour un cumul chronologique.
Explication : Une fonction de fenêtre calcule une valeur à partir de lignes liées à la ligne courante tout en conservant le détail du résultat. Pour un chiffre d’affaires cumulé par client, la partition sépare les clients et l’ordre par date organise la progression temporelle. Le cadre de fenêtre précise quelles lignes participent au calcul à chaque étape ; il doit donc être défini soigneusement. Ces paramètres se complètent pour produire le cumul attendu.
À retenir : Partition, ordre et cadre déterminent ensemble le calcul, sans supprimer les lignes détaillées.
Piège fréquent : Utiliser un GROUP BY en supposant qu’il préserve le détail : il regroupe les lignes en résultats agrégés.

Notion : Sélection déterministe du dernier état avec ROW_NUMBER.
Explication : ROW_NUMBER attribue un rang aux lignes selon un ordre défini. Pour retrouver le dernier état de chaque entité, il faut partitionner par sa clé métier, puis ordonner par une date ou une version fiable, du plus récent au plus ancien. La ligne de rang un représente alors l’état recherché. Si plusieurs lignes ont la même date ou version, un critère de départage déterministe complète l’ordre et rend la sélection reproductible.
À retenir : Identifier l’entité, définir la récence et départager les égalités sont trois exigences complémentaires.
Piège fréquent : Choisir arbitrairement parmi des dates identiques, ce qui peut produire un résultat instable.

Notion : Granularité des faits et double comptage.
Explication : La granularité décrit ce que représente une ligne d'une table de faits. Lorsque deux tables ne décrivent pas le même niveau de détail, une jointure peut associer une ligne à plusieurs autres. La mesure de cette ligne est alors répétée, ce qui peut gonfler le chiffre d'affaires. Les bonnes réponses relient ainsi la cause, le mécanisme et la prévention : agréger au niveau commun ou s'appuyer sur des dimensions conformes avec une combinaison adaptée des résultats.
À retenir : Vérifier la granularité et les correspondances avant de sommer les mesures.
Piège fréquent : Des colonnes portant le même nom ne garantissent ni une correspondance unique ni une jointure sûre.

Notion : Gestion des erreurs et reprise par partition.
Explication : Lorsqu'une partition échoue, il faut distinguer son état de celui des partitions valides. Conserver le détail de l'erreur permet de diagnostiquer le problème ; enregistrer l'état permet de savoir ce qui reste à traiter. Une reprise ciblée, lorsqu'elle est sûre, évite de relancer inutilement tout le pipeline. L'alerte complète ces mécanismes en informant les responsables selon la criticité et l'impact de l'incident.
À retenir : Isoler, tracer, alerter et reprendre constituent des pratiques complémentaires.
Piège fréquent : Ignorer une partition puis déclarer le pipeline réussi masque un résultat incomplet et empêche une appréciation fiable de son état.

Notion : Tests de schéma et contrôles de qualité métier.
Explication : Un test de schéma vérifie que les données présentent la structure attendue, notamment la présence des colonnes et leurs types. Un test métier examine leur validité au regard des règles attendues : unicité, non-nullité conditionnelle, plages de valeurs, relations ou rapprochement de totaux. Ces contrôles se complètent : une structure correcte rend les données techniquement exploitables, sans garantir qu'elles respectent les attentes métier.
À retenir : Le schéma contrôle la forme ; la qualité métier contrôle les règles et la cohérence des données.
Piège fréquent : Une exécution SQL sans erreur prouve seulement que le traitement s'est exécuté, pas que son résultat est conforme au métier.

Notion : Maintenance rigoureuse des tests de volume.
Explication : Un test de volume signale un écart par rapport à une attente. Son échec ne prouve pas automatiquement une anomalie : une évolution légitime de la source peut modifier les volumes. Il faut analyser la cause, confirmer que le changement est attendu, puis réviser explicitement le seuil ou le contrat de données si nécessaire. Tracer la décision et son impact rend cette évolution compréhensible et vérifiable.
À retenir : Analyser, valider et documenter permettent d'adapter le contrôle sans perdre sa valeur.
Piège fréquent : Désactiver définitivement le test pour supprimer les alertes élimine aussi sa capacité à détecter de futurs écarts.

Notion : Optimisation maîtrisée des coûts d'un Data Warehouse cloud.
Explication : Plusieurs leviers se complètent. Le partitionnement et les filtres adaptés réduisent les données scannées lorsque le moteur peut écarter les portions inutiles. Le dimensionnement et l'autoscaling ajustent les ressources aux profils de charge. Une politique de rétention et d'archivage maîtrise les données conservées selon leur utilité et les exigences de conformité. Ces décisions doivent s'appuyer sur l'usage réel plutôt que sur des suppressions aveugles.
À retenir : Optimiser les lectures, les ressources et la conservation permet d'agir sur différents postes de coût.
Piège fréquent : Supprimer les tests et la journalisation réduit la visibilité et les garanties de qualité, au lieu d'optimiser proprement le fonctionnement.

Notion : Sécurisation de la bascule lors d'une migration.
Explication : L'inventaire des flux, dépendances, rapports et consommateurs permet d'identifier le périmètre à migrer et les impacts possibles. Le mapping, les tests et la comparaison des résultats entre plateformes vérifient que les traitements conservent le sens attendu, notamment par réconciliation ou exécution parallèle. Une stratégie de bascule accompagnée d'un plan de retour arrière encadre ensuite le passage en production. Ces étapes couvrent respectivement la connaissance du périmètre, la validation et la maîtrise du risque.
À retenir : Une migration se prépare, se compare et prévoit une possibilité de retour.
Piège fréquent : Des schémas similaires ne suffisent pas à démontrer l'équivalence des résultats.