BigData by genAI

Big Data & 3V (+)

Volume, Vélocité, Variété — aujourd'hui on traite même l'non structuré (images, vidéo). Extension : véracité, netteté, utilité (6V). Scaling horizontal (nb machines) vs vertical (puissance).

Architecture médaillon

Lakehouse en 3 couches : Bronze (raw, landing) → Silver (propre, OLTP : nettoyage, joins, schéma en Parquet) → Gold (agrégé métier, OLAP optimisé). Possiblement plusieurs Silver/Gold.

Cloud-native & Kubernetes

L'orchestrateur connecte des conteneurs distribués : master → node → pod/conteneur. Déployable partout (gère dépendances & versions). Objets k8s : pod, deployment, service, configmap, secret.

Stockage : objet & k8s

Objet (key/URL + data + metadata, low cost, API) → pour data & IA. K8s : PV / PVC / StorageClass / CSI, modes d'accès RWO, ROX, RWX, RWOP. Récupération : réplication ou erasure-code.

ETL → ELT

ETL (transform avant load) vs ELT (load puis transform, gagne). Extraction : full / incremental / CDC (logs insert-update-delete). Load : full overwrite / append / upsert / partition replace. L'ETL perd l'historique → le lakehouse le garde.

----------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

**Quelle est la hiérarchie de déploiement en Kubernetes ?**

**master → node → pod/conteneur/app**. Le **pod est éphémère** (ne stocke rien) ; les données persistent dans le **storage node**. Le **deployment** est le "père" des pods (les maintient) ; le **service** les expose au réseau.

**Que sont les objets configmap et secret ?**

**ConfigMap** : config non sensible (yaml, params) stockée et appliquée par commande. **Secret** : contenu critique/sensible (peut être une simple variable dans un yaml). Tous deux injectés dans les pods.

**Quelle différence entre ETL et ELT, et lequel gagne ?**

**ETL** : Transform avant load dans le data warehouse. **ELT** : Load d'abord (brut), Transform ensuite — c'est le modèle qui **gagne** (GPU du DWH/SQL). L'ETL **perd l'historique** en cas de mauvais load ; l'ELT/lakehouse le conserve (lineage + time-travel).

**Quelles sont les 3 stratégies d'extraction de données ?**

**Full extract** (tout relire), **incremental extract** (seulement créé/modifié, clé auto-incrémentée), **Change Data Capture (CDC)** : lire le **log** de la DB (insert, update, delete).

**En quoi Parquet est-il "pensé requêtes" (pas juste un fichier) ?**

Stockage **colonnes** : min/max et nb de nulls par chunk pour **sauter les blocs** inutiles, **dictionnaire** (valeur → ID), compression (snappy/zstd/gzip), lecture **vectorisée par lots**, **predicate pushdown**.

**Comment fonctionne un Lakehouse (Delta Lake / Iceberg) ?**

Emplacent **Hive metastore + HDFS** : **ACID sur object storage** via atomic rename, **snapshots/commits** (WORM) → **time travel** (retour en arrière), **schema evolution sans réécrire** les fichiers. API : time travel, merges/upserts.

**Comment Spark diffère de MapReduce ?**

MapReduce re-stocke chaque état intermédiaire sur **disque** ; Spark garde les résultats intermédiaires **en mémoire (RAM)** → **10-100x plus rapide** sur les workloads itératifs. Code transformé en tâches sur les nœuds.

**C'est quoi le "lazy evaluation" de Spark et le DAG ?**

Les **transformations** (narrow/wide) ne sont **pas exécutées immédiatement** : Spark construit un **DAG** (graphe). `take()` / `show()` / `count()` sont des **actions** qui déclenchent réellement l'exécution du plan.

**Quelles sont les stratégies de jointure Spark ?**

**Broadcast Hash Join** (petite table hashée envoyée aux workers), **Sort-Merge Join** (grande × grande : tri + fusion après shuffle), **Shuffled Hash Join**, et **AQE** (Adaptative Query Execution) qui bascule dynamiquement si le petit côté suffit pour du broadcast.

**Quelles sont les 4 stratégies de load et la notion d'idempotence ?**

Load : **full overwrite** / **insert new records** / **upsert** (insert & update) / **partition replace** (réécrit une partition). **Idempotence** : si le job échoue et **retry**, on ne crée **pas de doublons** — rejouable sans effet de bord.