Revision data Data engineering Architecture

Guide de revision
Objectif Data Engineer
Synthese structurée de ton document sur le monde de la donnée, enrichie avec
les connaissances indispensables pour concevoir, industrialiser et maintenir des
pipelines de données fiables.

Comprendre Construire Industrialiser

données, formats, bases, architectures ingestion, transformation, stockage, qualité, monitoring, sécurité, CI/CD
orchestration

Document de revision - version synthétique et opérationnelle

Objectif Data Engineer Page 1 / 26

 MODE D'EMPLOI

Ce que ce guide doit t'apporter

Un data engineer ne se limite pas à “faire de l'ETL”. Il conçoit une chaîne complète qui transforme des données
brutes en données fiables, disponibles et utiles pour l'analyse, le reporting, le machine learning ou les produits
logiciels.

Objectif de revision : comprendre les concepts, savoir les relier entre eux, être capable de justifier des choix techniques et
repérer les points critiques en production.

1. Fondamentaux 2. Persistance
Donnée, information, métadonnées, qualité, granularité, Fichiers, bases relationnelles, NoSQL, index, transactions.
formats.

3. Big Data 4. Architecture data

Hadoop, Spark, systèmes distribués, CAP, cache, DBaaS. Data warehouse, data lake, lakehouse, Modern Data Stack.

5. Intégration 6. Production
ETL, ELT, connecteurs, gateways, virtualisation, batch, Orchestration, qualité, sécurité, observabilité, CI/CD,
streaming. roadmap.

Objectif Data Engineer Page 2 / 26

 CHAPITRE 1

Fondamentaux de la donnée
Avant de parler de pipelines et d'outils, il faut maîtriser le vocabulaire qui décrit la donnée elle-même.

Donnée vs information Métadonnées

Donnée : élément brut, non interprété. Données qui décrivent d'autres données : auteur, date,
Information : donnée contextualisée, organisée et taille, format, source, schéma, sens métier, droits d'accès.
exploitable.
Elles sont essentielles pour la gouvernance, la recherche, le
Exemple 38,5 est une donnée ; température du patient = lineage et la qualité.

38,5 °C devient une information.

Les propriétés utiles d'une donnée

Type de Question Exemples Pourquoi c'est important
propriété

Présentation A quoi cela ressemble ? Couleur, police, mise en page, contraste Utile pour les documents, interfaces, rendus
visuels.

Physique Comment c'est stocké ? Type, taille, encodage, format, résolution Impacte le stockage, la performance, la
compatibilité.

Structurelle Comment c'est Colonnes, tables, balises, objets, relations Permet le parsing, la validation et la modélisation.
organisé ?

Fonctionnelle Que peut-on faire avec ? Rechercher, filtrer, agréger, modifier, Relie la donnée à son usage métier.
partager

Encodage, internationalisation et granularité

Encodage Internationalisation Granularité

Une donnée numérique est stockée Un système doit gérer les formats Niveau de détail d'une donnée. Une
en bits. ASCII code les caractères de selon les pays : dates, nombres, vente au ticket est fine ; un total
base ; Unicode couvre presque toutes monnaies, langues, adresses, mensuel est agrégé. La granularité
les langues et symboles. UTF-8 est fuseaux horaires. Stocker au format conditionne les analyses possibles.
très courant et compatible ASCII. standard, afficher selon le contexte.

Réflexe de data engineer : pour chaque donnée, demander : source ? format ? type ? grain ? fraîcheur ? qualité ?
propriétaire ? droit d'accès ? usage final ?

Objectif Data Engineer Page 3 / 26

 CHAPITRE 2

Formats de fichiers et persistance

Les fichiers sont souvent la première forme de persistance. Un data engineer doit savoir choisir un format selon le
volume, la structure, la lisibilité et la performance attendue.

Format Type de données Avantages Limites Usage typique

CSV Tabulaire, texte Simple, lisible, compatible Excel et Pas de types robustes, ambiguïtés de Echange simple, export,
Python séparateur/encodage, lourd petit dataset

JSON Semi-structuré, objets Souple, proche des API web, imbriqué Verbeux, moins efficace en gros API, événements,
clé-valeur volumes configuration

XML Hiérarchique avec Schéma explicite, très structuré Verbeux, parsing parfois lourd Systèmes anciens,
balises échanges normés

Parquet Tabulaire colonnaire, Compression, types conservés, Non lisible directement, besoin d'outils Data lake, Spark, analytics,
binaire lecture partielle de colonnes gros volumes

Avro Row-based binaire Adapté aux messages et à l'évolution Moins performant pour requêtes Kafka, streaming,
avec schéma de schéma analytiques colonnaires sérialisation

ORC Colonnaire optimisé Très efficace dans l'écosystème Hive/ Moins universel que Parquet selon les Hadoop, Hive, analytique
Hadoop stacks

DOM vs SAX CSV vs Parquet

DOM charge le document entier en mémoire et crée un CSV est idéal pour lire ou échanger simplement.
arbre : pratique pour naviguer et modifier, mais gourmand.
Parquet est meilleur pour l'analytique : il stocke par
SAX lit le document progressivement par événements : colonnes, compresse mieux et permet de lire seulement les
adapté aux gros fichiers, mais moins flexible. colonnes utiles.

Règles de choix d'un format

• Petit fichier à transmettre à un humain : CSV ou Excel. • Besoin de schéma strict : Avro, Protobuf, XML Schema,
• Données issues d'API : JSON. tables SQL.

• Gros volume analytique : Parquet. • Besoin de performance Spark : Parquet/Delta avec

partitionnement adapté.
• Flux d'événements : JSON, Avro ou Protobuf selon les
contraintes.

Objectif Data Engineer Page 4 / 26

 CHAPITRE 3

Bases de données : familles, modélisation et accès

Le choix d'une base dépend du modèle de données, des requêtes, de la cohérence attendue, du volume et de la
distribution.

Grandes familles de bases

Famille Organisation Exemples Points forts Limites

Relationnelle Tables, lignes, PostgreSQL, MySQL, SQL, cohérence, transactions, Schéma plus rigide, scaling distribué
colonnes, clés Oracle, SQL Server jointures plus délicat

Clé-valeur clé -> valeur Redis, DynamoDB Très rapide, cache, sessions Requêtes complexes limitées

Documents JSON/BSON MongoDB, Firestore Souple, proche API, données Cohérence et jointures moins
imbriquées naturelles

Colonnes Colonnes/familles de Cassandra, HBase, Très gros volumes, scalabilité Modélisation orientée requêtes
distribuées colonnes Bigtable horizontale

Graphes Noeuds et relations Neo4j, Neptune Relations complexes, Moins adapté aux données tabulaires
recommandations, fraude simples

Temporelles Données horodatées InfluxDB, TimescaleDB, Mesures, séries temporelles, Usage spécialisé
Prometheus monitoring

Entrepôts Analytique, colonnes, BigQuery, Snowflake, OLAP, BI, agrégations massives Pas fait pour les transactions
SQL Redshift, Synapse quotidiennes

Vectorielles Embeddings FAISS, Milvus, Pinecone, Similarité, RAG, recherche Complément d'une architecture, pas
numériques Weaviate sémantique remplacement global

Relationnel vs NoSQL : le relationnel impose une structure stricte et garantit fortement la cohérence. Le NoSQL offre une
modélisation plus flexible pour les volumes, la variété et la distribution, mais certaines garanties doivent être gérées par
l'application ou par la conception.

Modélisation : les trois niveaux

Conceptuel Logique Physique

-> ->
entités et liens métier tables, documents, graphes types, index, partitions

Notion Définition A retenir

Clé primaire Identifiant unique d'une ligne. Exemple : id_client.

Clé étrangère Référence à une clé primaire d'une autre table. Crée un lien entre deux tables.

Intégrité référentielle Une clé étrangère doit pointer vers une donnée existante. Evite les commandes sans client existant.

Normalisation Réduire doublons et anomalies par découpage en tables. Utile en OLTP.

Dénormalisation Regrouper des données pour accélérer la lecture. Fréquent en OLAP, NoSQL, data marts.

Index : accélérer sans tout casser

Type Principe Bon pour Attention
d'index

B-Tree Arbre équilibré trié =, >, BETWEEN, ORDER BY Index généraliste le plus courant

Bitmap Vecteurs de 0/1 par valeur Colonnes à faible cardinalité : statut, sexe, Mauvais pour valeurs très
catégorie distinctes

Hachage Fonction de hachage vers un Recherche exacte : id, email Pas adapté aux intervalles ou tris
emplacement

Compromis : un index accélère les lectures mais ralentit les écritures, car l'index doit être maintenu à chaque insertion, mise
à jour ou suppression.

Objectif Data Engineer Page 5 / 26

 CHAPITRE 4

SQL, OLTP, OLAP et entrepôts de données

Le SQL est une compétence centrale. Un data engineer doit savoir modéliser, interroger, optimiser et préparer des
données analytiques.

OLTP OLAP
Online Transaction Processing. Système qui enregistre Online Analytical Processing. Système qui analyse des
les opérations du quotidien : commande, paiement, volumes importants : ventes mensuelles, reporting,
inscription, réservation. indicateurs, BI.

Priorités : transactions, cohérence, faible latence, Priorités : lectures massives, agrégations, historique,
écritures fréquentes. requêtes analytiques.

Critère OLTP OLAP

But Faire tourner l'activité Comprendre et piloter l'activité

Données Détaillées, actuelles Historiques, agrégées ou préparées

Requêtes Courtes, fréquentes Longues, analytiques

Schéma fréquent Normalisé Etoile, flocon, tables de faits/dimensions

Exemple Enregistrer une commande Calculer le CA par mois et région

Modélisation analytique : fait et dimensions

Fact Ventes
Dim Client -> <- Dim Produit <- Dim Date
montant, quantité

Une table de faits contient les mesures analysables : montant, quantité, durée. Les dimensions décrivent les axes d'analyse :
client, produit, date, magasin, région.

SELECT [Link], [Link], SUM([Link]) AS ca

FROM fact_ventes f
JOIN dim_date d ON f.date_id = d.date_id
JOIN dim_produit p ON f.produit_id = p.produit_id
GROUP BY [Link], [Link];

Pour devenir data engineer : entraîne-toi à écrire des requêtes avec jointures, agrégations, fenêtres SQL, CTE,
dédoublonnage et contrôles de qualité.

Objectif Data Engineer Page 6 / 26

 CHAPITRE 5

Big Data et systèmes distribués

Le Big Data naît quand le volume, la vitesse ou la variété dépassent ce qu'une architecture classique gère
confortablement.

Volume Vélocité Variété

Très grandes quantités de données à Données produites ou consommées Formats multiples : CSV, JSON, logs,
stocker et traiter. rapidement, parfois en temps réel. images, capteurs, API.

Hadoop : stockage et traitement distribués

Composant Rôle Ce qu'il faut retenir

HDFS Système de fichiers distribué Découpe les fichiers en blocs, les répartit et les réplique.

MapReduce Modèle historique de traitement Map traite localement, Reduce agrège les résultats.

YARN Gestionnaire de ressources Alloue CPU/mémoire et planifie les jobs sur le cluster.

Hive SQL-like sur Hadoop Permet d'interroger de grands volumes avec HiveQL.

Pig Scripts de transformation Pig Latin décrit des traitements étape par étape.

Spark : moteur de traitement distribué moderne

Spark est un moteur de traitement distribué utilisé pour le Composants : Spark Core, Spark SQL, Structured
batch, le SQL, le streaming, le machine learning et les Streaming, MLlib, GraphX.
graphes.
Objets clés : DataFrame, Dataset, RDD, driver, executors,
Il est souvent plus flexible que MapReduce, notamment cluster manager.
grâce au traitement en mémoire.

from [Link] import functions as F

ventes = [Link]("s3://lake/bronze/ventes/")
ca = [Link]("mois", "categorie").agg([Link]("montant").alias("ca"))
[Link]("overwrite").parquet("s3://lake/gold/ca_mensuel/")

CAP : compromis des systèmes distribués

Lettre Signification Idée

C Consistency Tous les noeuds voient la même donnée.

A Availability Le système répond toujours aux requêtes.

P Partition tolerance Le système continue malgré une coupure réseau.

A retenir : en cas de partition réseau, il faut souvent arbitrer entre cohérence forte et disponibilité. Les systèmes distribués
sont toujours des compromis.

Objectif Data Engineer Page 7 / 26

 CHAPITRE 6

Architecture data moderne : warehouse, lake,

lakehouse, MDS
Une plateforme data organise la circulation entre sources, stockage, transformations, contrôle et usages finaux.

Les grands espaces de stockage

Architecture Principe Avantages Limites

Data Données structurées, préparées pour SQL, BI, performance, gouvernance Moins flexible pour données brutes variées
Warehouse analyse

Data Lake Stockage brut de données variées Flexible, économique, conserve le Risque de “data swamp” si mal gouverné
brut

Lakehouse Combine lake et warehouse Formats ouverts, tables fiables, BI Demande une architecture et une gouvernance
+ ML solides

Architecture Medallion

Bronze Silver Gold

-> ->
brut nettoyé, normalisé métier, BI, ML

• Bronze : données brutes, historisées, peu transformées.

• Silver : données nettoyées, typées, dédupliquées, conformes.
• Gold : données métier prêtes à l'usage : indicateurs, marts, features.

Modern Data Stack (MDS)

Sources -> Ingestion -> Warehouse/Lakehouse -> Transformation -> BI/ML

Couche Rôle Exemples d'outils

Sources Produisent les données CRM, ERP, bases SQL, logs, API, fichiers

Ingestion Récupère et charge les données Airbyte, Fivetran, Kafka Connect, scripts Python

Stockage Centralise et historise BigQuery, Snowflake, Databricks, S3, ADLS, GCS

Transformation Nettoie, modélise, agrège SQL, dbt, Spark, Python

Orchestration Planifie et surveille Airflow, Dagster, Prefect, Cloud Composer

Exposition Rend les données utilisables Power BI, Tableau, Looker, API, notebooks

Databricks
Databricks est une plateforme cloud de données et d'IA, très liée à Spark, qui permet de construire des pipelines, requêtes SQL,
notebooks, workflows, modèles ML et architectures lakehouse. Les notions à connaître : Spark, Delta Lake, notebooks, jobs/
workflows, Unity Catalog, lakehouse.

Objectif Data Engineer Page 8 / 26

 CHAPITRE 7

Intégration de données : architectures et modèles

L'intégration de données consiste à faire circuler, combiner ou synchroniser des données entre plusieurs systèmes.

Deux typologies d'architecture

Point à point Centralisée

Chaque application se connecte directement aux autres. Les systèmes passent par une plateforme commune : ETL,
ESB, data hub, warehouse.
Avantage : simple au départ.
Avantage : plus maintenable et contrôlable.
Limite : effet spaghetti quand le nombre de systèmes
augmente. Limite : point central critique et coût initial.

Modèles d'intégration
Modèle Définition Exemple

Diffusion Envoyer une donnée vers plusieurs systèmes Une commande vers CRM, facturation, livraison

Migration Déplacer durablement vers un nouveau système Ancien CRM -> nouveau CRM

Synchronisation Maintenir plusieurs systèmes cohérents Adresse client identique dans CRM et facturation

Agrégation Regrouper plusieurs sources pour une vue globale CA total web + magasins + marketplace

Corrélation Mettre en relation pour détecter un lien Météo + ventes pour analyser une tendance

Connecteurs, ODBC/JDBC et Data Gateways

Notion Rôle Exemple

Connecteur Permet à un outil de parler à une source/destination Connecteur Salesforce, PostgreSQL, S3, API REST

ODBC Interface standard générale pour se connecter à des bases Excel -> ODBC -> Oracle

JDBC Interface Java pour bases de données Application Java -> JDBC -> PostgreSQL

Data Gateway Pont sécurisé entre cloud et source locale/protégée Power BI Cloud -> Gateway -> base SQL interne

Données virtuelles
Le modèle de données virtuelles crée une couche logique permettant d'interroger plusieurs sources sans recopier physiquement
toutes les données. C'est utile pour une vue unifiée rapide, mais les performances dépendent des systèmes sources.

CRM ERP CSV -> Couche virtuelle -> Vue unifiée

Objectif Data Engineer Page 9 / 26

 CHAPITRE 8

ETL, ELT et pipelines de données

Un pipeline est une chaîne d'étapes qui transforme des données source en données exploitables, de manière
automatisée, contrôlée et répétable.

ETL ELT
Extract -> Transform -> Load Extract -> Load -> Transform

On transforme avant de charger dans la cible. On charge d'abord les données brutes, puis on transforme
Historiquement fréquent dans les architectures data dans le warehouse/lakehouse. Très fréquent dans les
warehouse classiques. architectures cloud modernes.

Aspect ETL ELT

Moment de transformation Avant chargement Après chargement

Conservation du brut Pas toujours Oui, souvent en zone bronze/raw

Adapté à Systèmes traditionnels, contraintes fortes avant stockage Cloud, data warehouse moderne, lakehouse

Risque Pipeline rigide, transformations difficiles à rejouer Accumulation de données brutes si mal gouverné

Étapes d'une bonne intégration

1. Identifier le besoin : BI, synchronisation, migration, IA, API, conformité.
2. Identifier les sources : schéma, volumes, fréquence, propriétaire, accès.
3. Modéliser et mapper : correspondance entre champs, types, clés, grain.
4. Extraire : fichiers, API, SQL, CDC, événements.
5. Nettoyer : doublons, valeurs manquantes, formats, incohérences.
6. Transformer : typage, jointures, calculs, agrégations, dimensions.
7. Charger : base cible, data lake, warehouse, table Gold, API.
8. Contrôler : tests, volumes, règles métier, intégrité, fraîcheur.
9. Sécuriser : droits, chiffrement, RGPD, secrets, audit.
10. Surveiller : logs, alertes, SLA, coûts, performances.

Ce qui rend un pipeline professionnel

• Idempotent : relancé deux fois, il ne crée pas de doublons. • Observé : logs, métriques, alertes.
• Rejouable : permet un backfill sur une période passée. • Documenté : schéma, définitions métier, owner.
• Traçable : on sait d'où vient chaque donnée. • Sécurisé : accès minimum nécessaire.
• Testé : règles de qualité automatiques. • Optimisé : partitions, formats, requêtes, coût cloud.

Objectif Data Engineer Page 10 / 26

 CHAPITRE 9

Modes de transit : batch, temps réel, streaming

La fréquence de circulation des données influence toute l'architecture : outils, latence, coût, complexité et garanties.

Mode Principe Latence Exemples Outils possibles

Batch Traitement par lots à intervalles Minutes, heures, Rapport quotidien, sauvegarde, Airflow, dbt, Spark batch, SQL
réguliers jours calcul mensuel

Temps Réagir presque immédiatement à un Très faible Paiement, alerte fraude, réservation API, Kafka, bases rapides,
réel événement fonctions cloud

Streaming Traiter un flux continu d'événements Faible à très faible Logs, capteurs IoT, clickstream, Kafka, Flink, Spark Structured
monitoring Streaming

Kafka et event streaming

Event streaming consiste à capturer des événements en continu, les stocker durablement et les router vers des consommateurs.
Kafka organise les événements dans des topics, produits par des producers et lus par des consumers. Les topics sont
partitionnés pour scaler.

Topic Kafka
Producer -> -> Consumers
partitions

CDC - Change Data Capture

Le CDC capture les changements d'une base opérationnelle : insertions, mises à jour, suppressions. C'est utile pour alimenter un
data lake/warehouse sans relire toute la base à chaque fois.

Question clé : as-tu besoin de fraîcheur à la seconde, à la minute, à l'heure ou au jour ? Plus la latence visée est faible, plus
l'architecture est complexe et coûteuse.

Objectif Data Engineer Page 11 / 26

 CHAPITRE 10

Orchestration, workflow et fiabilité

L'orchestration organise l'exécution automatique des tâches : ordre, planning, dépendances, retries, erreurs, alertes
et backfills.

Vocabulaire
Notion Définition

Workflow Suite organisée d'étapes pour réaliser un traitement.

Task Une étape précise : extraire, transformer, tester, charger.

DAG Graphe orienté acyclique représentant l'ordre des tâches.

Schedule Planification : toutes les heures, tous les jours, à la demande.

Retry Nouvelle tentative automatique en cas d'échec.

Backfill Rejouer un pipeline sur une période passée.

Extract -> Clean -> Transform -> Tests -> Publish

Exemple Airflow simplifié

from airflow import DAG

from [Link] import BashOperator
from datetime import datetime

with DAG("sales_daily", start_date=datetime(2026,1,1), schedule="@daily", catchup=True) as dag:

extract = BashOperator(task_id="extract", bash_command="python [Link]")
transform = BashOperator(task_id="transform", bash_command="python [Link]")
test = BashOperator(task_id="test", bash_command="dbt test")
publish = BashOperator(task_id="publish", bash_command="dbt run --select marts")

extract >> transform >> test >> publish

Logs et failover

Log Failover
Trace enregistrée par un système : démarrage, erreur, Basculement vers un système de secours quand le système
durée, volume traité, requête API, statut de job. principal tombe en panne.

Un pipeline sans logs est difficile à diagnostiquer. Essentiel pour haute disponibilité et continuité de service.

Règle de production : un pipeline doit dire ce qu'il fait, quand il échoue, pourquoi il échoue et comment le relancer sans
créer d'effets de bord.

Objectif Data Engineer Page 12 / 26

 CHAPITRE 11

Qualité, gouvernance, sécurité et conformité

Une donnée n'est utile que si elle est fiable, comprise, protégée et utilisable par les bonnes personnes.

Dimensions de qualité
Dimension Question Test possible

Complétude Les valeurs obligatoires sont-elles présentes ? Non-null sur id_client, date, montant

Unicité Y a-t-il des doublons interdits ? id_commande unique

Validité Les valeurs respectent-elles un domaine ? statut dans une liste autorisée

Cohérence Les relations sont-elles correctes ? customer_id existe dans la table clients

Fraîcheur La donnée est-elle assez récente ? Dernier chargement < 24h

Exactitude La valeur reflète-t-elle la réalité ? Réconciliation avec système source

dbt : transformation et tests

dbt permet de créer des modèles analytiques sous forme de requêtes SQL versionnées. Les tests vérifient automatiquement des
assertions comme unique, not_null, accepted_values et relationships.

models:
- name: dim_customers
columns:
- name: customer_id
data_tests:
- unique
- not_null
- name: country
data_tests:
- accepted_values:
values: ['FR', 'ES', 'DE']

Gouvernance
• Catalogue : inventaire des tables, colonnes, owners, • Data owner/steward : responsable métier ou technique de
définitions. la donnée.
• Lineage : suivi des transformations de la source jusqu'au • Classification : publique, interne, confidentielle, sensible.
dashboard. • RGPD : minimisation, finalité, droit d'accès, anonymisation/
• Data contracts : accord explicite sur schéma, qualité et pseudonymisation.
fréquence.

Sécurité
Point Bonne pratique

Accès Principe du moindre privilège, RBAC, groupes, revues régulières.

Secrets Ne jamais stocker mots de passe dans le code ; utiliser un gestionnaire de secrets.

Chiffrement Chiffrement au repos et en transit.

Données sensibles Masquage, anonymisation, tokenisation selon les usages.

Audit Tracer les accès, modifications et exports critiques.

Objectif Data Engineer Page 13 / 26

 CHAPITRE 12

Observabilité, performance et coûts

En production, un pipeline doit être surveillé, optimisé et économiquement maîtrisé.

Ce qu'il faut monitorer

Dimension Exemples de métriques Questions

Fiabilité Taux d'échec, retries, durées, tâches bloquées Le pipeline fonctionne-t-il tous les jours ?

Fraîcheur Age de la dernière donnée, retard de flux Les utilisateurs voient-ils des données récentes ?

Qualité Tests échoués, valeurs nulles, doublons Peut-on faire confiance aux résultats ?

Volume Lignes traitées, taille fichiers, événements/sec Y a-t-il une rupture ou un pic anormal ?

Coût CPU, RAM, stockage, requêtes, egress Le traitement coûte-t-il trop cher ?

Performance : réflexes
• SQL : filtrer tôt, éviter SELECT *, vérifier les plans, indexer les • Spark : limiter les shuffles, gérer le skew, ajuster les
clés utiles. partitions.
• Partitionnement : partitionner par date ou clé fréquemment • Warehouse : matérialiser les tables très utilisées, surveiller
filtrée. les scans.
• Formats : utiliser Parquet/Delta pour l'analytique. • Cloud : éteindre les clusters inutilisés, choisir la bonne taille
• Fichiers : éviter trop de petits fichiers dans un data lake. de ressources.
• Cache : l'utiliser pour données/résultats réutilisés, mais gérer
l'expiration.

Cache

But : garder temporairement des données ou résultats Risque : donnée périmée si le cache n'est pas invalidé.
fréquents dans un stockage rapide.
Concepts : cache hit, cache miss, TTL, invalidation.
Avantage : moins de latence et moins de charge sur la
source.

Objectif Data Engineer Page 14 / 26

 CHAPITRE 13

DevOps pour data engineers : Git, Docker, CI/CD, IaC

Un data engineer travaille avec du code. Les pipelines doivent être versionnés, testés, déployés et reproductibles.

Compétence Ce qu'il faut savoir faire Pourquoi

Git Branches, commits propres, pull requests, résolution de conflits Travailler en équipe et historiser les changements.

Python Scripts propres, fonctions, environnements, packages, tests Ingestion, automatisation, APIs, Spark/Pandas.

SQL Jointures, agrégations, CTE, fenêtres, optimisation Langage central de transformation analytique.

Linux Shell, fichiers, permissions, cron, logs Comprendre l'exécution serveur.

Docker Images, conteneurs, Dockerfile, Compose Reproduire un environnement d'exécution.

CI/CD Tests automatiques, lint, déploiement Réduire les erreurs et industrialiser.

IaC Terraform ou équivalent Décrire l'infrastructure en code.

Cloud Stockage objet, IAM, compute, réseau, coûts La majorité des stacks data modernes sont cloud ou hybrides.

Ce qu'une CI peut vérifier dans un projet data

• Syntaxe SQL et Python. • Formatage du code.
• Tests unitaires des fonctions de transformation. • Build d'image Docker.
• Tests dbt : unique, not_null, relationships. • Déploiement en dev/staging puis prod.
• Validation du schéma attendu.

Objectif Data Engineer Page 15 / 26

 CHAPITRE 14

Architecture cible d'un pipeline data complet

Voici une architecture de référence que tu dois être capable d'expliquer en entretien ou dans un projet.

Sources Ingestion Bronze Silver Gold

-> -> -> ->
API, SQL, fichiers, logs batch/CDC/stream brut historisé clean marts

Tests qualité + Orchestration + Monitoring + Sécurité

Exemple : pipeline de ventes e-commerce

Étape Choix possible Justification

Sources PostgreSQL commandes, Stripe paiements, API livraison, logs web Sources métier hétérogènes.

Ingestion Airbyte/Fivetran pour SaaS, CDC pour base, Kafka pour événements Automatiser et limiter le code maison.

Stockage brut Data lake en Parquet partitionné par date Historisation, coût, reprocessing.

Transformation dbt pour SQL analytique, Spark pour gros volumes Modèles versionnés et scalabilité.

Qualité Tests not_null, unique, relationships, contrôles de volume Empêcher des dashboards faux.

Orchestration Airflow DAG quotidien + alertes Ordre, planning, retries, monitoring.

Exposition Power BI/Tableau + tables Gold Usage métier direct.

Questions de conception à poser

• Quelle est la fréquence attendue ? • Qui consomme la donnée ?
• Quel est le volume actuel et futur ? • Quelles données sont sensibles ?
• Quelle est la source de vérité ? • Comment relancer en cas d'échec ?
• Quel niveau de qualité est acceptable ? • Comment mesurer la fraîcheur ?
• Faut-il conserver l'historique complet ? • Quel budget cloud est acceptable ?

Objectif Data Engineer Page 16 / 26

 CHAPITRE 15

Roadmap pour devenir data engineer

Voici une progression réaliste pour passer des notions de cours à une compétence projet.

Étape Objectif Livrable concret

1. SQL solide Jointures, agrégations, fenêtres, optimisation 20 requêtes sur un dataset e-commerce

2. Python data Scripts, Pandas, API, fichiers, tests Extracteur API -> CSV/Parquet

3. Modélisation OLTP vs OLAP, étoile, dimensions, qualité Schéma en étoile ventes

4. ETL/ELT Pipeline complet, idempotence, logs Pipeline quotidien automatisé

5. Orchestration Airflow/Dagster, DAG, retries, backfill DAG avec tests et alertes

6. Big Data Spark, Parquet, partitionnement Traitement PySpark sur gros CSV

7. Cloud/Lakehouse Stockage objet, warehouse, droits Bronze/Silver/Gold sur cloud ou local simulé

8. Production Docker, CI/CD, monitoring, documentation Projet GitHub reproductible

Trois projets portfolio recommandés

Projet 1 - Batch BI Projet 2 - Streaming Projet 3 - Lakehouse

API publique -> Parquet -> dbt/SQL Générer des événements -> Kafka -> Bronze/Silver/Gold avec
-> dashboard. Ajouter tests qualité et Spark/Flink -> table agrégée temps partitionnement, historisation, CI/CD
documentation. réel. et orchestration.

Compétences prioritaires à travailler

SQL avancé Python Modélisation ETL/ELT Spark Airflow dbt Cloud Docker Qualité Sécurité

Monitoring

Objectif Data Engineer Page 17 / 26

 CHAPITRE 16

SQL et modélisation : niveau data engineer

Le SQL est le socle du métier. Il faut savoir l'utiliser pour comprendre, transformer, contrôler et optimiser les
données.

Objets SQL à connaître

Notion Usage Exemple d'application

JOIN Relier plusieurs tables Commandes + clients + produits

GROUP BY Agréger CA par mois, nombre de commandes

CTE Découper une requête en étapes lisibles Nettoyage puis agrégation

Window functions Calculer sans perdre le détail ligne rang, moyenne mobile, détection de doublons

MERGE / UPSERT Insérer ou mettre à jour Chargement incrémental idempotent

EXPLAIN Comprendre le plan d'exécution Identifier scan complet, mauvais join, index non utilisé

Patrons SQL fréquents

-- Dédoublonner en gardant la ligne la plus récente

WITH ranked AS (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY business_key ORDER BY updated_at DESC) AS rn
FROM source_table
)
SELECT *
FROM ranked
WHERE rn = 1;

-- Chargement incrémental conceptuel

MERGE INTO dim_customer AS target
USING staging_customer AS source
ON target.customer_id = source.customer_id
WHEN MATCHED THEN UPDATE SET [Link] = [Link], target.updated_at = source.updated_at
WHEN NOT MATCHED THEN INSERT (customer_id, email, updated_at) VALUES (source.customer_id, [Link], source.updated_at);

Slowly Changing Dimensions (SCD)

Type Principe Quand l'utiliser

SCD Type 1 On écrase l'ancienne valeur Correction d'erreur ou historique inutile

SCD Type 2 On conserve l'historique avec dates de validité Suivre l'évolution d'un client, segment, adresse, statut

SCD Type 3 On garde une valeur courante et une ancienne valeur Historique très limité

Réflexe entretien : préciser le grain d'une table de faits avant de parler de mesures. Exemple : une ligne = une ligne de
commande, et non une commande complète.

Objectif Data Engineer Page 18 / 26

 CHAPITRE 17

Python pour data engineering

Python sert à automatiser les extractions, manipuler les fichiers, appeler des API, lancer des jobs, écrire des tests et
créer des traitements reproductibles.

Bibliothèques utiles
Besoin Outils Python Exemple

Fichiers et chemins pathlib, os, glob Lister des fichiers à traiter

API HTTP requests, httpx Récupérer des données JSON

Données tabulaires pandas, polars Nettoyage local et exploration

Parquet pyarrow, fastparquet Lire/écrire des tables efficaces

Bases de données sqlalchemy, psycopg, pymysql Extraire depuis PostgreSQL/MySQL

Qualité/tests pytest, great_expectations Tester fonctions et règles data

Configuration dotenv, pydantic-settings Variables d'environnement, paramètres

Structure d'un script d'ingestion propre

import logging
from pathlib import Path
import requests
import pandas as pd

[Link](level=[Link])

def extract(url: str) -> list[dict]:

r = [Link](url, timeout=30)
r.raise_for_status()
return [Link]()

def transform(rows: list[dict]) -> [Link]:

df = [Link](rows)
df["loaded_at"] = [Link]()
return df

def load(df: [Link], path: str) -> None:

Path(path).[Link](parents=True, exist_ok=True)
df.to_parquet(path, index=False)

def main():
rows = extract("[Link]
df = transform(rows)
load(df, "data/bronze/[Link]")
[Link]("loaded %s rows", len(df))

if __name__ == "__main__":
main()

Production : ne jamais mettre de secret dans le code. Utiliser des variables d'environnement ou un secret manager.

Objectif Data Engineer Page 19 / 26

 CHAPITRE 18

Spark : concepts à maîtriser vraiment

Spark est incontournable pour traiter de gros volumes. Il faut connaître son modèle mental pour éviter les
traitements très lents ou coûteux.

Concepts fondamentaux
Concept Définition Impact pratique

Driver Processus qui pilote l'application Spark Ne doit pas collecter trop de données localement

Executors Processus qui exécutent les tâches sur le cluster Consomment CPU/RAM, lisent et écrivent les données

DataFrame Table distribuée avec colonnes nommées API principale pour PySpark moderne

Lazy evaluation Spark construit un plan sans exécuter immédiatement Une action déclenche le calcul

Transformation Opération qui produit un nouveau DataFrame filter, select, join, groupBy

Action Opération qui déclenche l'exécution count, show, write, collect

Shuffle Redistribution réseau des données Coûteux : groupBy, join, distinct

Partition Morceau de données traité en parallèle Trop peu = peu de parallélisme ; trop = overhead

Bonnes pratiques Spark

• Préférer les DataFrames aux boucles Python ligne par ligne. • Utiliser cache() uniquement si le DataFrame est réutilisé.
• Filtrer et sélectionner les colonnes tôt. • Partitionner les sorties par colonnes fréquemment filtrées.
• Eviter collect() sur de gros volumes. • Surveiller le skew : une clé trop fréquente ralentit tout le job.
• Comprendre les shuffles et les joints coûteux. • Contrôler le nombre et la taille des fichiers écrits.

Anti-pattern Spark
Anti-pattern Pourquoi c'est mauvais Alternative

[Link]() puis traitement Python Ramène tout sur le driver Utiliser fonctions Spark distribuées

UDF Python partout Moins optimisable par Spark Fonctions natives Spark SQL

Ecrire des milliers de petits fichiers Lenteur de lecture et metadata overhead Compaction/coalesce/repartition

Joindre deux grosses tables sans stratégie Shuffle massif Broadcast petite table, partitionnement, filtrage

Objectif Data Engineer Page 20 / 26

 CHAPITRE 19

Streaming et Kafka : notions de production

Le streaming permet de traiter des événements au fil de l'eau, mais il impose de réfléchir aux garanties, aux retards,
à la reprise et à l'ordre des messages.

Vocabulaire Kafka
Notion Définition A retenir

Event/message Fait métier : commande créée, paiement validé Contient clé, valeur, timestamp, headers

Producer Application qui écrit des événements Publie dans un topic

Consumer Application qui lit des événements Traite et commit sa position

Topic Canal logique d'événements Exemple : orders, payments

Partition Sous-division d'un topic Permet parallélisme et ordre par clé

Offset Position d'un message dans une partition Permet la reprise après panne

Consumer group Groupe de consumers partageant les partitions Permet de scaler la lecture

Schema Registry Gestion des schémas d'événements Evite de casser les consommateurs

Garanties de livraison
Garantie Définition Risque

At most once Au plus une fois Perte possible

At least once Au moins une fois Doublons possibles

Exactly once Une fois exactement, selon conditions techniques strictes Plus complexe à garantir de bout en bout

Important : même avec Kafka, il faut concevoir les consommateurs pour gérer les doublons. L'idempotence reste
indispensable.

Objectif Data Engineer Page 21 / 26

 CHAPITRE 20

Cloud data : services et équivalences

Les noms varient selon les fournisseurs, mais les besoins restent similaires : stocker, calculer, orchestrer, sécuriser,
observer.

Besoin AWS Google Cloud Azure Notion à retenir

Stockage objet S3 Cloud Storage ADLS / Blob Storage Base d'un data lake

Data warehouse Redshift BigQuery Synapse SQL analytique scalable

Traitement Spark EMR / Glue Dataproc Synapse Spark / HDInsight Calcul distribué

Orchestration MWAA / Step Functions Cloud Composer Data Factory Planifier et surveiller

Streaming Kinesis / MSK Pub/Sub Event Hubs Evénements en continu

Secrets Secrets Manager Secret Manager Key Vault Protéger credentials

Identité IAM IAM Entra ID / RBAC Droits et sécurité

Coûts cloud : points de vigilance

• Stockage : volume, classes de stockage, rétention. • Réseau : egress entre régions ou vers Internet.
• Compute : temps de cluster, taille des machines, autoscaling. • Logs : volume de logs conservés.
• Requêtes : bytes scannés dans certains warehouses. • Environnements oubliés : dev/staging non arrêtés.

Objectif Data Engineer Page 22 / 26

 CHAPITRE 21

Data contracts, schémas et évolution

Un pipeline casse souvent parce qu'une source change : colonne renommée, type modifié, valeur inattendue. Les
data contracts permettent d'anticiper cela.

Ce qu'un data contract doit préciser

Élément Exemple

Owner Equipe CRM responsable de la table clients

Schéma customer_id string non null, email string, created_at timestamp

Grain Une ligne = un client unique

Fréquence Mise à jour toutes les 15 minutes

Qualité minimale customer_id unique, email valide si présent

SLA Donnée disponible avant 8h chaque matin

Politique de changement Prévenir 2 semaines avant suppression/renommage

Schema evolution

Changements souvent compatibles Changements cassants

• Ajouter une colonne optionnelle • Renommer ou supprimer une colonne utilisée
• Ajouter une nouvelle valeur de catégorie acceptée • Changer un type sans migration
• Ajouter un topic ou une table nouvelle • Changer le grain d'une table
• Modifier la signification métier d'un champ

Data engineer mature : il ne subit pas les changements de sources. Il met en place contrats, tests, alertes et
communication avec les producteurs de données.

Objectif Data Engineer Page 23 / 26

 CHAPITRE 22

Préparation entretien et questions classiques

Savoir réciter une définition ne suffit pas. Il faut expliquer des compromis techniques.

Questions fréquentes
Question Attendu dans une bonne réponse

ETL ou ELT ? Parler du lieu de transformation, du cloud, du brut conservé, du coût, de la gouvernance.

CSV ou Parquet ? Comparer lisibilité, types, compression, lecture colonnaire, volume, compatibilité.

Batch ou streaming ? Justifier par latence, coût, complexité, garanties, besoin métier.

Comment rendre un pipeline fiable ? Idempotence, tests, logs, retries, alertes, backfill, monitoring, documentation.

Pourquoi un job Spark est lent ? Shuffles, skew, petits fichiers, mauvaise partition, collect, ressources insuffisantes.

Comment garantir la qualité ? Tests automatiques, contrats, contrôles de volumes, réconciliation, lineage.

Qu'est-ce qu'une architecture lakehouse ? Combinaison lake + warehouse, données ouvertes, couches bronze/silver/gold, BI + ML.

Mini-cas à savoir résoudre

Cas : un dashboard de ventes est faux depuis deux jours.

Réponse structurée : vérifier fraîcheur, logs d'orchestration, volumes ingérés, tests qualité, changement de schéma source,
requêtes de transformation, comparaison avec source, puis corriger et rejouer les partitions impactées.

Cas : le pipeline quotidien prend 3h au lieu de 30 min.

Réponse structurée : regarder évolution du volume, plan SQL/Spark, partitions, shuffles, petits fichiers, index, ressources
cluster, transformations récemment changées, puis optimiser et mesurer.

Objectif Data Engineer Page 24 / 26

 ANNEXE

Fiches express à mémoriser

Les phrases à retenir

• Donnée : élément brut ; information : donnée contextualisée.
• Granularité : niveau de détail d'une donnée.
• Parquet : format colonnaire optimisé pour l'analytique.
• Relationnel : structure stricte, SQL, cohérence forte.
• NoSQL : flexibilité, scalabilité, données variées, cohérence parfois moins automatique.
• OLTP : transactions du quotidien ; OLAP : analyse et décision.
• Hadoop : stockage + traitement distribués ; Spark : traitement distribué rapide et polyvalent.
• ETL : transformer avant de charger ; ELT : charger brut puis transformer.
• Batch : lots ; streaming : flux continu ; real time : réaction immédiate.
• Orchestration : planifier, coordonner et surveiller les tâches d'un pipeline.
• Data quality : tester que les données sont complètes, uniques, valides, cohérentes et fraîches.

Anti-erreurs fréquentes
Erreur Conséquence Correction

Ne pas garder les données brutes Impossible de rejouer proprement Zone Bronze/raw historisée

Pipeline non idempotent Doublons après relance Clés naturelles, upsert, partitions écrasées proprement

Aucun test qualité Dashboards faux Tests automatiques et seuils d'alerte

Trop de petits fichiers Lenteur dans Spark/lake Compaction et tailles de fichiers adaptées

Droits trop larges Risque sécurité/RGPD RBAC et moindre privilège

Pas de monitoring Erreurs invisibles Logs, métriques, alertes

Objectif Data Engineer Page 25 / 26

 SOURCES

Sources et références utilisées

Ce guide synthétise ton document de cours Guide de survie dans le monde de la donnée et l'enrichit avec des références
techniques officielles utiles pour approfondir.

• Apache Parquet Documentation - Overview : [Link]

• Apache Kafka Documentation - Introduction : [Link]
• Apache Airflow Documentation - DAGs : [Link]
• Apache Spark Documentation - SQL/DataFrames et Structured Streaming : [Link]
• dbt Documentation - Models et Data tests : [Link] ; [Link]
data-tests
• Databricks Documentation - Data Lakehouse : [Link]
• Docker Documentation - Overview : [Link]
• Kubernetes Documentation - Overview : [Link]
• GitHub Docs - Understanding GitHub Actions : [Link]

Objectif Data Engineer Page 26 / 26