Retour à Big Data
Big Data

QCM

Consultez les contenus publiés dans cette ressource.

Ressources en accès libre

QCM de « Big Data »

40 contenus
11
Question à choix multiples

Sélectionnez les propositions correctes. Conception d'une couche d'ingestion et de stockage pour un système à très fort volume et pics de vélocité, flux hétérogènes et données douteuses mais besoin de valeur métier rapide : quelles décisions techniques prioriser ?

  • Imposer schéma strict et validation complète à l'entrée, rejeter/retourner les événements non conformes.
  • Utiliser un log distribué (p. ex. Kafka) comme buffer partitionné + stockage objet partitionné pour longs termes (schema‑on‑read) et autoscaling des consommateurs. Bonne réponse
  • Construire index synchrones et stockage OLTP pour fournir réponses analytiques instantanées même sous pics.
  • Appliquer algorithmes approximatifs (sketches), échantillonnage pour premiers insights et capturer métriques de qualité/metadata dans un catalogue. Bonne réponse
Explication

Buffering (log) + schema‑on‑read gèrent volume/vélocité/variété; approximations et métadonnées adressent besoin rapide et véracité.

12
Question à choix multiples

Quelle est la meilleure décision ? Vous devez déployer une base clé‑valeur globale : la disponibilité pendant partitions est prioritaire mais certaines opérations financières exigent forte cohérence. Quelle architecture choisir ?

  • Choisir un système CP (consensus synchronisé) pour tout le cluster afin de garantir cohérence stricte même pendant partitions.
  • Mener une architecture hybride : routage des opérations critiques vers le sous‑ensemble CP (leader synchronisé ou single‑region transactions) et permettre lectures/écritures moins critiques en mode AP via réplicas locales. Bonne réponse
  • Concevoir tout en mode AP pour maximiser disponibilité, puis exécuter vérification batch pour corriger conflits financiers.
  • Utiliser quorum de lecture/écriture universels synchrones entre toutes les régions pour chaque opération afin d'équilibrer cohérence et disponibilité.
Explication

Séparer chemins critiques/non critiques (hybrid) permet compromis CAP pragmatique : disponibilité globale et cohérence locale pour transactions.

13
Question à choix multiples

Sélectionnez les propositions correctes. Pour minimiser latence utilisateur et équilibrer charge dans une base distribuée multi‑régions, quelles stratégies de partitionnement et de réplication appliquer ?

  • Partitionnement par hash sur la clé primaire + réplication synchronisée vers N réplicas avec leader dans région principale.
  • Partitionnement par plages temporelles avec bucketing temporel et réplication asynchrone pour atténuer hotspots.
  • Consistent hashing avec virtual nodes, placement géo‑aware des réplicas et quorums tunables pour reads/writes. Bonne réponse
  • Maître global unique avec réplication synchrone multi‑région pour garantir latence prévisible et cohérence.
Explication

Consistent hashing + nœuds virtuels et placement géographique réduisent latence et hotspots; solutions synchrones globales dégradent disponibilité.

14
Question à choix multiples

Sélectionnez les propositions correctes. Votre cluster HDFS a un NameNode unique et vous craignez une interruption du namespace : quelles mesures techniques réduisent le risque d'indisponibilité ?

  • Déployer HDFS High Availability (Active/Standby NameNode) avec ZooKeeper et stockage partagé (edit logs) pour bascule automatisée. Bonne réponse
  • Se reposer sur réplication élevée des blocs et les enregistrements des DataNodes sans HA NameNode.
  • Activer HDFS Federation pour répartir le namespace sur plusieurs NameNodes indépendants et réduire point unique de contention. Bonne réponse
  • Augmenter le facteur de réplication à 5 et compter uniquement sur checkpoints périodiques pour restaurer le namespace en cas de panne.
Explication

HA (Active/Standby) avec ZooKeeper et Federation pour scalabilité/robustesse sont complémentaires pour réduire le SPOF du NameNode.

15
Question à choix multiples

Sélectionnez les propositions correctes. Vous optimisez jobs MapReduce confrontés à nombreux petits fichiers, joins volumineux et algorithmes itératifs : quelles optimisations MapReduce ont le plus d'impact ?

  • Utiliser CombineFileInputFormat ou fusionner petits fichiers en gros blocs avant exécution pour réduire overhead map. Bonne réponse
  • Utiliser Distributed Cache (broadcast) pour petites tables et transformer certains joins en map‑side joins. Bonne réponse
  • Pour rester MapReduce pur, enchaîner jobs pour itérations sans autres changements (chaîne simple de MapReduce).
  • Compresser données intermédiaires et fixer le nombre de reduce à égal au nombre logique total de cœurs sur tous les nœuds.
Explication

Réduire overhead I/O (fusion petits fichiers) et map‑side joins via cache améliorent fortement perf; MapReduce reste mauvais pour itératif.

16
Question à choix multiples

Sélectionnez les propositions correctes. Vous optimisez un pipeline Spark avec UDFs coûteux, besoin d'évolution de schéma et partition pruning pour requêtes analytiques : quelles pratiques adopter ?

  • Préférer l'API DataFrame/Dataset, remplacer UDFs par fonctions natives Spark pour profiter de Catalyst/Tungsten. Bonne réponse
  • Utiliser Avro pour zones brutes (schema évolutif) et Parquet pour stockage analytique ; partitionner sur colonnes d'usage et tirer parti du predicate pushdown. Bonne réponse
  • Écrire les transformations en RDD et mapPartitions personnalisées pour mieux contrôler sérialisation et forcer pruning.
  • Partitionner systématiquement sur colonnes très cardinales (ID utilisateur) pour maximiser pruning.
Explication

DataFrame + formats adaptés (Avro pour landing, Parquet pour analytics) + partitionnement raisonné permettent pruning et optimisations Catalyst.

17
Question à choix multiples

Quelle est la meilleure décision ? L'application doit produire rapports journaliers tout en fournissant mises à jour incrémentales en quasi‑temps réel et gérer événements hors d'ordre : quelle architecture privilégier ?

  • Lambda architecture (batch + speed layer séparés) pour assurer exactitude batch et rapidité en speed layer.
  • Une architecture unifiée de streaming (ex. Structured Streaming) en event‑time avec watermarks et backfill batch pour le rattrapage. Bonne réponse
  • Utiliser fenêtres tumbling fixes sans watermark ; accepter écarts temporaires et corriger manuellement.
  • Exécuter uniquement batch quotidien et augmenter fréquence à toutes les minutes pour simuler streaming.
Explication

Approche unifiée stream‑first avec event‑time, watermarks et capacité de backfill simplifie maintenance et gère out‑of‑order.

18
Question à choix multiples

Sélectionnez les propositions correctes. Vous devez garantir livraison 'exactly‑once' depuis Kafka vers une base cible avec redémarrages et retries : quelles stratégies combinées assurent la robustesse la plus élevée ?

  • Activer l'API transactionnelle Kafka (producers idempotents, transactions) et utiliser sinks qui supportent commit atomique des transactions Kafka. Bonne réponse
  • S'appuyer exclusivement sur at‑least‑once consumer puis stocker offsets dans la base cible en même transaction (écrire données + offsets atomiquement).
  • Rendre les opérations de sink idempotentes (clef logique/UPSERT) et concevoir du dédoublonnage côté cible sans dépendre uniquement des transactions Kafka. Bonne réponse
  • S'appuyer sur log compaction seule pour supprimer doublons ultérieurement, sans mécanisme d'idempotence côté sink.
Explication

Combinaison d'EOS Kafka et idempotence côté sink est pragmatique ; stockage d'offsets atomique est une alternative mais dépend du support transactionnel DB.

19
Question à choix multiples

Sélectionnez les propositions correctes. Un JOIN distribué provoque skew important et vous devez aussi assurer traçabilité et contrôles d'accès sur données jointes : quelles mesures techniques et de gouvernance implémenter ?

  • Appliquer salting/repartitioning pour clés chaudes et, si possible, broadcaster la table la plus petite. Bonne réponse
  • Forcer uniquement des map‑side joins évitant les shuffle quel que soit le volume des partitions.
  • Capturer lineage déterministe (IDs d'événement, versions de dataset) et intégrer contrôle d'accès colonne‑par‑colonne et masquage PII dans le pipeline. Bonne réponse
  • Augmenter simplement le nombre de reducers et activer l'exécution spéculative pour réduire l'impact des tâches lentes du join.
Explication

Salting/broadcast atténuent skew ; lineage + contrôle d'accès/masquage assurent traçabilité et conformité; augmenter reducers n'adresse pas skew clés chaudes.

20
Question à choix multiples

Sélectionnez les propositions correctes. Vous concevez une plateforme analytique supportant BI, évolutions de schéma, qualité, catalogage et confidentialité : quelles décisions globaux adopter ?

  • Utiliser seulement un bucket S3 brut (data lake) et appliquer sécurité basique au niveau du storage sans catalogue centralisé.
  • Adopter un lakehouse (Delta/Iceberg) avec métastore transactionnel, politiques de qualité (tests, règles), catalogage central, lineage et contrôles d'accès fins (masquage/chiffrement). Bonne réponse
  • Remplacer lake par entrepôt classique unique ETL strict pour tout pour simplifier gouvernance et éviter zones brutes.
  • Mettre en place découverte automatique de PII, contrôles d'accès basés sur rôles et attributs, tests de qualité automatisés et catalogue unifié intégrant politiques. Bonne réponse
Explication

Lakehouse + catalogue/lineage/contrôles fins offrent ACID, évolutivité et gouvernance ; détection PII et tests automatisés complètent la sécurité et qualité.

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