Peux-tu devenir Data Engineer en 12 mois, en autodidacte, à côté de ton travail ?
La réponse est oui — à condition de suivre un parcours progressif, structuré et surtout orienté pratique.
Le Data Engineer est l’architecte invisible des entreprises modernes : il construit les pipelines qui transportent les données, les nettoie, les transforme, les stocke et les rend disponibles pour les analystes, les Data Scientists et les applications d’IA. Sans lui, aucune entreprise ne peut vraiment exploiter son capital data.
Ce guide n’est pas une formation académique ni un cursus universitaire. C’est un parcours autodidacte de 12 mois, pensé pour être suivi en parallèle de ton travail, avec quelques heures régulières chaque semaine. L’objectif n’est pas d’empiler des cours théoriques, mais de développer une culture pratique de l’ingénierie data : comprendre, tester, construire, documenter.
Tu vas avancer étape par étape, mois après mois, dans un cadre volontairement resserré pour éviter les digressions inutiles. Le principe est simple : tu apprends, tu comprends, tu fais.
Le programme suit une logique claire :
- Les fondations (Janvier à Mars) : Python, SQL, Linux, Git, APIs.
- La montée en puissance (Avril à Juin) : Cloud, Spark, Hadoop.
- L’ouverture vers le temps réel (Juillet à Septembre) : Data Warehousing, Kafka, Spark Streaming.
- L’industrialisation (Octobre à Décembre) : bonnes pratiques de code, NoSQL, orchestration avec Airflow.
Chaque étape est illustrée par des exercices concrets et mini-projets que tu pourras décliner, enrichir et publier dans ton portfolio. Et si tu prends ce parcours au sérieux, en fin d’année tu ne seras pas seulement initié : tu auras acquis une culture technique solide et une pratique démontrable du métier de Data Engineer.
En d’autres termes : 12 mois pour devenir Data Engineer en autodidacte — en apprenant, en comprenant, et surtout en faisant.
- Peux-tu devenir Data Engineer en 12 mois, en autodidacte, à côté de ton travail ?
- Objectifs pédagogiques
- Tableau de synthèse — 12 mois pour devenir Data Engineer en autodidacte
- Janvier — Python et bases du code
- Février — SQL et bases relationnelles
- Mars — Linux, Git & APIs
- Avril — Cloud Fundamentals (AWS/GCP)
- Mai — Big Data batch avec Apache Spark
- Bilan de Mai
- Juin — Hadoop et frameworks distribués
- Juillet — Data Warehousing
- Août — Ingestion temps réel avec Apache Kafka
- Septembre — Spark Streaming
- Octobre — Programmation avancée pour Data Engineers
- Novembre — Bases NoSQL
- Décembre — Orchestration & Workflow avec Apache Airflow
- Et maintenant ?
- Le futur
- FAQ — Data Engineer & Formation Autodidacte
Objectifs pédagogiques
- Comprendre le rôle exact du Data Engineer : construire des architectures robustes, fiables et scalables.
- Maîtriser les langages et outils clés : Python, SQL, Spark, Hadoop, Kafka, Airflow, bases relationnelles et NoSQL.
- Monter en compétence sur les clouds (AWS, GCP, Azure), incontournables en production.
- Savoir gérer aussi bien les pipelines batch que streaming, les entrepôts de données et l’orchestration.
- Construire un portfolio crédible avec des projets pratiques, pour passer d’apprenant à professionnel employable.
Tableau de synthèse — 12 mois pour devenir Data Engineer en autodidacte
Mois / Semaine | Objectif principal | Notions clés | Outils / Pratique |
---|---|---|---|
Janvier – Python & bases de la programmation | |||
S1 | Installer environnement, découvrir Python | Variables, types, opérateurs | Python, VS Code, Jupyter |
S2 | Logique de contrôle | Boucles, conditions, fonctions | Python |
S3 | Structures de données | Listes, dict, sets, tuples | Python |
S4 | Librairies data | Pandas (import/export, nettoyage) | Pandas, CSV/JSON |
Février – Linux, Git & APIs | |||
S5 | Linux & Shell | Commandes, scripts bash, cron | Ubuntu, WSL |
S6 | Git & GitHub | Versionning, branches, merge | Git, GitHub |
S7 | APIs REST | GET/POST, JSON, authentification | Python requests |
S8 | Web scraping | BeautifulSoup, Selenium | Python |
Mars – SQL & bases relationnelles | |||
S9 | SQL de base | SELECT, WHERE, ORDER BY | PostgreSQL/MySQL |
S10 | Jointures | INNER/LEFT JOIN | PostgreSQL |
S11 | Requêtes avancées | Window functions, CTE | PostgreSQL |
S12 | Normalisation & projet | Schéma en étoile simple | PostgreSQL + projet API→SQL |
Avril – Cloud & stockage | |||
S13 | Découverte Cloud | Concepts IaaS/PaaS/SaaS | AWS/GCP console |
S14 | Stockage objet | S3, GCS | AWS S3, GCS |
S15 | Compute | EC2/VM, Lambda | AWS EC2, Lambda |
S16 | Bases managées | RDS, CloudSQL | PostgreSQL managé |
Mai – Spark & Big Data batch | |||
S17 | Spark basics | RDD, DataFrames | PySpark |
S18 | Transformations | groupBy, filter, agg | PySpark |
S19 | Formats optimisés | Parquet, ORC, partitionnement | PySpark |
S20 | Projet batch | Analyse dataset volumineux | Kaggle + Spark |
Juin – Hadoop & écosystème distribué | |||
S21 | HDFS | Stockage distribué | Hadoop local |
S22 | MapReduce | Mapper, Reducer | Hadoop streaming |
S23 | YARN & cluster | Gestion ressources | AWS EMR |
S24 | Projet Hadoop | Logs → HDFS → MapReduce | Hadoop |
Juillet – Data Warehousing | |||
S25 | Concepts OLAP | OLTP vs OLAP | Théorie |
S26 | Modélisation | Schéma étoile, flocon | dbdiagram.io |
S27 | Hive basics | HQL, tables externes | Hive |
S28 | Warehouse cloud | BigQuery, Redshift | GCP BigQuery |
Août – Kafka & ingestion temps réel | |||
S29 | Kafka basics | Producers, Consumers, Topics | Kafka local |
S30 | Partitions & offsets | Scalabilité, fiabilité | Kafka |
S31 | Intégration cloud | AWS Kinesis, GCP Pub/Sub | Kinesis/PubSub |
S32 | Projet Kafka | Flux commandes e-commerce | Kafka + Python |
Septembre – Spark Streaming | |||
S33 | Structured Streaming | Micro-batchs | PySpark |
S34 | Fenêtres temporelles | window, watermarks | PySpark |
S35 | Connecteurs | Kafka → Spark → DB | Kafka + Spark |
S36 | Projet streaming | Analytics en temps réel | Kafka + Spark + PostgreSQL |
Octobre – Programmation avancée & CI/CD | |||
S37 | OOP | Classes, héritage | Python |
S38 | Design patterns | Singleton, pipeline | Python |
S39 | Tests unitaires | pytest | Python + pytest |
S40 | CI/CD | GitHub Actions | GitHub Actions |
Novembre – NoSQL | |||
S41 | MongoDB | CRUD, agrégations | MongoDB |
S42 | Redis | Key-value, cache | Redis |
S43 | Cassandra | Wide-column, CQL | Cassandra |
S44 | Projet polyglot | Logs → Mongo + Redis + Cassandra | Projet multi-bases |
Décembre – Orchestration & Airflow | |||
S45 | Concepts Airflow | DAGs, tasks, operators | Airflow |
S46 | Scheduling | Dépendances, sensors | Airflow |
S47 | Branching & XComs | Pipelines complexes | Airflow |
S48 | Projet final | Capstone project orchestré (API → Spark → Warehouse → Airflow) | Airflow + Cloud |
Janvier — Python et bases du code
Pourquoi commencer par Python ?
- C’est le langage roi des données. Lisible, simple, documenté partout.
- Toutes les briques de la data (ETL, Spark, Airflow, APIs, IA) savent dialoguer en Python.
- Un Data Engineer n’est pas un chercheur en algorithmie : ton but est d’assembler, nettoyer et transporter la donnée. Python est parfait pour ça.
Étape 1 : Installer ton environnement
- Choix rapide : Anaconda (pack complet) ou Miniconda si tu veux léger.
- Éditeur : VS Code + extensions Python.
- Notebook : JupyterLab pour tester et documenter en même temps.
Astuce : crée toujours un environnement virtuel (conda create -n dataeng python=3.11
) pour éviter le bazar de dépendances.
Étape 2 : Les bases indispensables
Tu n’as pas besoin de tout savoir, mais tu dois être rapide sur les fondamentaux :
- Variables & types :
int
,float
,str
,list
,dict
. - Conditions & boucles :
if
,for
,while
, compréhension de listes. - Fonctions : écrire une fonction claire, utiliser
lambda
,map
,filter
. - Fichiers :
open()
, lire/écrire un CSV ou JSON. - Libs standard :
os
,datetime
,json
,re
(regex simples).
Étape 3 : Pandas, ton outil principal
Tu dois vite devenir à l’aise avec pandas, car 80 % du job Data Engineer = transformer des données.
Quelques opérations vitales :
🚀 Devenez un expert en Data Marketing avec nos formations !
Maîtrisez les outils essentiels pour analyser, automatiser et visualiser vos données comme un pro. De BigQuery SQL à Google Apps Script, en passant par Google Sheets et Looker Studio, nos formations couvrent tous les niveaux pour vous permettre d’optimiser vos flux de données, structurer vos bases SQL, automatiser vos tâches et créer des dashboards percutants. Que vous soyez débutant ou avancé, chaque formation est conçue pour une mise en pratique immédiate et un impact direct sur vos projets. Ne subissez plus vos données, prenez le contrôle dès aujourd’hui ! 📊🔥
import pandas as pd
# Charger un CSV
df = pd.read_csv("ventes.csv")
# Aperçu
print(df.head())
# Nettoyer colonnes
df.rename(columns={"Nom Client": "client"}, inplace=True)
df.dropna(inplace=True) # supprimer valeurs manquantes
# Créer une colonne calculée
df["revenu_total"] = df["quantité"] * df["prix_unitaire"]
# Grouper et agréger
ventes_par_client = df.groupby("client")["revenu_total"].sum()
⚡ Dès que tu maîtrises ça, tu peux déjà bosser comme assistant Data.
Étape 4 : Ton premier mini-projet (1 semaine)
Objectif : extraire, transformer, charger (ETL) un petit dataset.
- Récupère un dataset public (ex. data.gouv.fr, Kaggle).
- Nettoie les données avec pandas (colonnes, doublons, valeurs manquantes).
- Transforme : calcule des agrégations simples (totaux, moyennes).
- Stocke le résultat dans un fichier CSV propre.
→ En 7 jours, tu passes de “je code un peu” à “je sais construire un mini pipeline de données”.
Étape 5 : Automatiser une petite tâche
Teste un script simple lancé automatiquement :
import pandas as pd
from datetime import datetime
df = pd.read_csv("ventes.csv")
df["revenu_total"] = df["quantité"] * df["prix_unitaire"]
df.to_csv(f"rapport_{datetime.today().date()}.csv", index=False)
Ensuite, programme-le avec cron (Linux/Mac) ou Task Scheduler (Windows) → tu touches déjà à l’automatisation.
Étape 6 : Aller plus loin si tu as du temps
- Katas Python sur Hackerrank ou LeetCode Easy.
- Nettoyage de vrais CSV pourris : accents, dates mal formées, colonnes mélangées.
- Regex simples pour extraire un email ou un code postal dans un texte.
Bilan de Janvier
✅ Tu sais coder en Python basique.
✅ Tu es autonome avec pandas pour manipuler des datasets.
✅ Tu as déjà ton premier “pipeline maison” (mini ETL).
✅ Tu commences à automatiser.
En un mois, tu n’es pas programmeur, tu es déjà Data Engineer en herbe : tu as mis les mains dans le cambouis de la donnée.
Février — SQL et bases relationnelles
Pourquoi SQL est incontournable ?
- Langage universel : toutes les bases (MySQL, PostgreSQL, BigQuery, Snowflake…) comprennent SQL.
- Efficacité : 3 lignes SQL remplacent souvent 30 lignes Python.
- Indispensable : chaque entretien de Data Engineer contient un test SQL.
Ton objectif ce mois-ci : écrire, optimiser et comprendre des requêtes qui tournent sur des millions de lignes.
Étape 1 : Installer une base relationnelle
- Choix simple : PostgreSQL (open source, utilisé partout).
- Interface : pgAdmin ou DBeaver pour requêter facilement.
- Dataset de test : Chinook DB (base factice de musique) ou un dataset Kaggle.
Étape 2 : Les bases du SQL
Tu dois être à l’aise avec les opérations suivantes :
-- Sélection simple
SELECT nom, age FROM clients;
-- Filtrer
SELECT * FROM commandes WHERE montant > 100;
-- Trier
SELECT * FROM produits ORDER BY prix DESC;
-- Agréger
SELECT categorie, AVG(prix) as prix_moyen
FROM produits
GROUP BY categorie;
-- Joindre des tables
SELECT c.nom, o.montant
FROM clients c
JOIN commandes o ON c.id = o.client_id;
⚡ Les JOINS sont la clé. Apprends à jongler entre INNER
, LEFT
, RIGHT
, FULL
.
Étape 3 : Concepts fondamentaux
- Clés primaires / étrangères : relations entre tables.
- Contraintes :
NOT NULL
,UNIQUE
,CHECK
. - Index : accélèrent les requêtes (mais coûtent en écriture).
- Transactions :
BEGIN
,COMMIT
,ROLLBACK
pour garder la cohérence.
Étape 4 : Aller plus loin — SQL avancé
- Subqueries (requêtes dans la requête).
- Window functions (indispensables en analytics) :
SELECT client_id,
montant,
SUM(montant) OVER (PARTITION BY client_id ORDER BY date) as cumul_client
FROM commandes;
- CTE (Common Table Expressions) : écrire des requêtes lisibles :
WITH ventes_mensuelles AS (
SELECT client_id, DATE_TRUNC('month', date) as mois, SUM(montant) as total
FROM commandes
GROUP BY client_id, mois
)
SELECT * FROM ventes_mensuelles WHERE total > 1000;
Étape 5 : Mini-projet SQL (fin de mois)
Construis un mini data mart e-commerce :
- Télécharge un dataset de commandes (Kaggle → “E-commerce orders” ou data.gouv.fr).
- Charge-le dans PostgreSQL (
COPY
ou via DBeaver). - Crée des tables propres (
clients
,produits
,commandes
). - Ecris 5 à 10 requêtes analytiques :
- Top 10 clients par chiffre d’affaires.
- Panier moyen par mois.
- Catégorie produit la plus rentable.
- Évolution du revenu mensuel.
Étape 6 : Connecter Python + SQL
Ne reste pas cloisonné : combine ce que tu as appris en janvier.
import psycopg2
import pandas as pd
conn = psycopg2.connect(
dbname="ecommerce", user="postgres", password="1234", host="localhost"
)
query = "SELECT categorie, AVG(prix) as prix_moyen FROM produits GROUP BY categorie;"
df = pd.read_sql(query, conn)
print(df)
👉 Tu commences à bâtir de vrais pipelines ETL Python → SQL → Python.
Bilan de Février
✅ Tu sais créer et interroger une base relationnelle.
✅ Tu maîtrises les JOINS, agrégations et window functions.
✅ Tu as construit ton premier mini entrepôt de données.
✅ Tu sais relier Python ↔ SQL.
En deux mois, tu es déjà capable de :
- Collecter et nettoyer des données (Janvier).
- Les stocker et les interroger efficacement (Février).
C’est la fondation de tout Data Engineer.
Mars — Linux, Git & APIs
Pourquoi ces 3 briques sont vitales ?
- Linux : 90 % des serveurs de données tournent dessus. Si tu ne sais pas naviguer en ligne de commande, tu es bloqué.
- Git : sans versionning, impossible de collaborer. Tu dois maîtriser Git comme tu sais respirer.
- APIs : énormément de données passent par des APIs (Twitter, Stripe, CRM, Google Analytics…). Impossible d’être Data Engineer sans savoir en consommer.
1. Linux & Shell scripting
Commandes de base
# Navigation
pwd # où suis-je
ls -lh # lister les fichiers
cd dossier/ # changer de répertoire
# Fichiers
touch fichier.txt
nano fichier.txt # éditer
cat fichier.txt # afficher
rm fichier.txt # supprimer
# Processus
ps aux | grep python
kill -9 12345 # tuer un process
# Réseau
curl https://api.github.com
Automatiser avec un script simple
Exemple : un script Bash qui sauvegarde une base chaque nuit.
#!/bin/bash
DATE=$(date +%F)
pg_dump ecommerce > backup_$DATE.sql
Puis planifie-le avec cron
:
crontab -e
0 2 * * * /home/user/backup.sh
👉 Tu viens de mettre en place ta première automatisation système.
2. Git & GitHub
Commandes essentielles
git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/ton_repo.git
git push -u origin main
Workflow basique en équipe
- Créer une branche :
git checkout -b feature-pipeline
- Coder → commit → push.
- Pull request sur GitHub.
- Merge après review.
Astuce : utilise .gitignore
pour éviter de versionner tes données brutes.
3. APIs et intégration
Comprendre REST
GET
→ récupérer des données.POST
→ envoyer des données.PUT
→ mettre à jour.DELETE
→ supprimer.
Exemple avec Python (requests
)
import requests
import pandas as pd
url = "https://jsonplaceholder.typicode.com/posts"
r = requests.get(url)
data = r.json()
df = pd.DataFrame(data)
print(df.head())
⚡ En 10 lignes, tu as transformé une API en DataFrame exploitable.
API + SQL
Combine avec PostgreSQL pour construire un mini-pipeline ETL temps réel :
- Extraire depuis une API (
requests
). - Transformer avec Pandas.
- Charger dans PostgreSQL (
psycopg2
).
Mini-projet de Mars : API → SQL → Automation
- Choisis une API ouverte (ex : OpenWeatherMap, PokéAPI, data.gouv.fr).
- Ecris un script Python qui appelle l’API chaque jour, nettoie les données et les charge dans PostgreSQL.
- Automatisation : programme ton script avec
cron
(Linux) ouTask Scheduler
(Windows). - Versionne ton code sur GitHub.
→ À la fin du mois, tu as ton premier vrai pipeline de prod : data ingestion automatisée, versionnée, stockée.
Bilan de Mars
✅ Tu sais naviguer et automatiser sous Linux.
✅ Tu maîtrises Git pour collaborer.
✅ Tu sais exploiter une API et l’intégrer dans un pipeline.
✅ Tu as un mini ETL automatisé et versionné.
En 3 mois, tu as posé toutes les bases techniques : code (Python), stockage (SQL), système & APIs (Mars). Tu commences à ressembler à un vrai Data Engineer.
Avril — Cloud Fundamentals (AWS/GCP)
Pourquoi le cloud est incontournable ?
- Les données grossissent trop vite pour un laptop.
- Les entreprises veulent scalabilité, sécurité, disponibilité 24/7.
- Les clouds (AWS, GCP, Azure) offrent des services prêts à l’emploi (databases, stockage, serverless, orchestration) → tu ne réinventes pas la roue.
👉 Pour démarrer, concentre-toi sur AWS (leader du marché) et/ou GCP (très orienté data & IA).
1. Stockage : ton premier réflexe
- AWS S3 ou Google Cloud Storage (GCS) = tes disques durs du cloud.
- Formats : CSV, JSON, Parquet (très utilisé car compressé + lisible par Spark/BigQuery).
# Exemple AWS CLI
aws s3 mb s3://mon-premier-bucket
aws s3 cp data.csv s3://mon-premier-bucket/
2. Compute : faire tourner tes jobs
- AWS EC2 ou Google Compute Engine → machines virtuelles à la demande.
- Choisis une petite instance (t2.micro / e2-small) pour expérimenter gratuitement.
👉 Installe Python, PostgreSQL, Spark… exactement comme sur ton PC, mais sur un serveur distant.
3. Bases managées
- AWS RDS ou Cloud SQL (GCP) → PostgreSQL/MySQL prêts à l’emploi, sans gérer l’install ni la sauvegarde.
- BigQuery (GCP) → data warehouse serverless ultra puissant.
Exemple de requête BigQuery (SQL standard) :
SELECT country, COUNT(*) as nb_users
FROM `bigquery-public-data.github_repos.users`
GROUP BY country
ORDER BY nb_users DESC
LIMIT 10;
⚡ Pas besoin de serveur : tu payes juste à la requête.
4. Serverless & automatisation
- AWS Lambda ou Google Cloud Functions → exécuter du code sans serveur.
- Idéal pour déclencher un traitement dès qu’un fichier arrive dans S3/GCS.
Exemple (AWS Lambda en Python) :
import boto3
def handler(event, context):
s3 = boto3.client("s3")
bucket = event["Records"][0]["s3"]["bucket"]["name"]
key = event["Records"][0]["s3"]["object"]["key"]
print(f"Fichier reçu : {bucket}/{key}")
5. Réseau & API Gateway
- AWS API Gateway ou Google Endpoints → exposer ton script Python comme API REST.
- Tu peux transformer un pipeline Python en service accessible publiquement (ex. : API de nettoyage de CSV).
Mini-projet d’Avril : pipeline cloud de bout en bout
- Ingestion : récupère des données via API (exemple : météo) → stocke-les dans S3/GCS.
- Transformation : déclenche une Lambda/Cloud Function qui nettoie les données et les convertit en Parquet.
- Stockage final : charge les données dans RDS/Postgres ou BigQuery.
- Automatisation : planifie le tout (Cloud Scheduler / EventBridge).
👉 En 1 mois, tu passes de “scripts locaux” à pipeline 100 % cloud, scalable, automatisé.
6. Ressources gratuites pour pratiquer
- AWS Free Tier : S3, EC2, Lambda gratuits pendant 12 mois.
- Google Cloud Free Tier : 300 $ de crédits + BigQuery gratuit 1 To/mois.
- Qwiklabs / Google Cloud Skills Boost : labs guidés.
Bilan d’Avril
✅ Tu sais créer un bucket cloud, y stocker des fichiers.
✅ Tu sais lancer une VM pour exécuter tes jobs.
✅ Tu comprends bases managées (RDS/BigQuery).
✅ Tu as déclenché une fonction serverless automatiquement.
✅ Tu as construit ton premier pipeline end-to-end dans le cloud.
En 4 mois, tu as posé les fondations solides :
- Python + Pandas (manipuler).
- SQL (stocker & interroger).
- Linux + Git + APIs (industrialiser).
- Cloud (scaler).
Mai — Big Data batch avec Apache Spark
Pourquoi Spark est indispensable ?
- Scalable : tourne aussi bien en local que sur un cluster de 100 machines.
- Rapide : moteur distribué en mémoire → bien plus performant que Hadoop MapReduce classique.
- Polyvalent : SQL, machine learning, ETL, streaming… tout est intégré.
- Standard du marché : utilisé chez Netflix, Uber, Airbnb, Amazon…
👉 Maîtriser Spark, c’est montrer que tu peux gérer de la donnée en mode industriel.
1. Installer Spark pour pratiquer
Trois options :
- Local : pyspark (installable via pip).
- Databricks Community Edition (gratuit, interface notebook, cluster managé).
- Cloud : AWS EMR, GCP Dataproc (payants mais réalistes).
Pour commencer :
pip install pyspark
Puis dans Python :
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("Test").getOrCreate()
df = spark.read.csv("ventes.csv", header=True, inferSchema=True)
df.show(5)
2. Concepts fondamentaux
- RDD (Resilient Distributed Dataset) : la brique de base, bas niveau.
- DataFrames : API haut niveau (comme Pandas, mais distribué).
- Transformations :
filter
,select
,groupBy
… - Actions :
show
,count
,collect
. - SparkSQL : interroger tes DataFrames en SQL.
Exemple :
# Transformation
ventes_par_client = df.groupBy("client").sum("montant")
# SQL
df.createOrReplaceTempView("ventes")
spark.sql("""
SELECT client, SUM(montant) as total
FROM ventes
GROUP BY client
ORDER BY total DESC
""").show()
3. Formats et performances
- Parquet et ORC : formats compressés optimisés → beaucoup plus rapides que CSV.
- Partitions : découpent les données pour paralléliser.
- Broadcast variables : éviter de dupliquer une petite table dans chaque worker.
👉 Exemple :
df.write.parquet("s3://mon-bucket/ventes_parquet/")
4. ETL avec Spark
Spark est une machine à ETL :
- Extract : lire des fichiers (CSV, JSON, Parquet) ou une base SQL.
- Transform : nettoyer, agréger, enrichir.
- Load : stocker en Parquet, dans PostgreSQL, ou dans un Data Warehouse.
5. Mini-projet de Mai : traitement batch avec Spark
- Télécharge un dataset volumineux (Kaggle : “New York Taxi trips” → plusieurs Go).
- Charge-le dans Spark.
- Nettoie les données (valeurs manquantes, types de colonnes).
- Crée des agrégations : revenu moyen par quartier, pics horaires de trajets, top chauffeurs.
- Stocke les résultats en Parquet sur ton cloud (S3 ou GCS).
👉 Résultat : tu passes de “j’analyse des petits CSV en Pandas” à “je traite des datasets massifs comme une entreprise réelle”.
6. Où pratiquer gratuitement ?
- Databricks Community → cluster Spark gratuit avec notebooks collaboratifs.
- Google Colab + PySpark → pratique rapide sans installer Spark localement.
Bilan de Mai
✅ Tu sais lancer un job Spark et comprendre son architecture.
✅ Tu manipules des DataFrames distribués.
✅ Tu as écrit ton premier pipeline ETL Spark.
✅ Tu as stocké des données propres et optimisées (Parquet).
En 5 mois, tu es déjà capable de traiter de la donnée à l’échelle industrielle, ce qui te rapproche beaucoup du rôle attendu en entreprise.
Juin — Hadoop et frameworks distribués
Pourquoi apprendre Hadoop en 2025 ?
- Parce qu’il est partout dans les vieux SI (banques, assurances, télécoms).
- Parce qu’il t’aide à comprendre le principe : découper un gros job en petites tâches distribuées sur plusieurs machines.
- Parce que Spark lui-même s’exécute souvent au-dessus de YARN (le gestionnaire de ressources d’Hadoop).
👉 Hadoop = fondations. Spark = moteur moderne. Tu dois connaître les deux.
1. L’écosystème Hadoop
- HDFS (Hadoop Distributed File System) : stockage distribué. Les fichiers sont découpés en blocs, répliqués sur plusieurs machines.
- MapReduce : modèle de calcul. Map (découpe), Reduce (agrège). Aujourd’hui dépassé par Spark, mais à connaître.
- YARN (Yet Another Resource Negotiator) : gère les ressources du cluster et planifie les jobs.
- Hadoop Common : les libs de base qui connectent tout ça.
2. Exemple simple de MapReduce (Python)
Comptage de mots (le “Hello World” du Big Data) :
Mapper (map.py)
import sys
for line in sys.stdin:
for word in line.strip().split():
print(f"{word}\t1")
Reducer (reduce.py)
import sys
from collections import defaultdict
counts = defaultdict(int)
for line in sys.stdin:
word, val = line.strip().split("\t")
counts[word] += int(val)
for word, total in counts.items():
print(f"{word}\t{total}")
Puis tu lances sur Hadoop :
hadoop jar hadoop-streaming.jar \
-input data.txt \
-output output_dir \
-mapper map.py \
-reducer reduce.py
3. Hadoop vs Spark
Critère | Hadoop MapReduce | Spark |
---|---|---|
Mode de calcul | Disque (lent) | Mémoire (rapide) |
Facilité de dev | Complexe (Java) | Facile (Python, Scala, SQL) |
Cas d’usage actuel | Jobs batch historiques | ETL modernes, streaming, ML |
Statut en 2025 | Héritage encore présent | Standard actuel du marché |
👉 Moralité : Hadoop = comprendre, Spark = pratiquer en prod.
4. Où pratiquer Hadoop ?
- Local (pseudo-distributed) : installe Hadoop avec Docker → bon pour tester.
- AWS EMR (Elastic MapReduce) : cluster Hadoop/Spark prêt en 10 minutes.
- GCP Dataproc : équivalent Google.
5. Mini-projet de Juin : batch distribué avec Hadoop
- Télécharge un dataset massif (logs web, ventes e-commerce).
- Stocke-le dans HDFS.
- Écris un MapReduce simple pour :
- compter les visites par page,
- identifier les utilisateurs actifs,
- calculer le top produits.
- Compare performances Hadoop vs Spark (temps d’exécution).
👉 Résultat : tu comprends pourquoi Spark a gagné, mais tu sais aussi lire/maintenir un job Hadoop si on t’en met un entre les mains.
6. Bilan de Juin
✅ Tu comprends les bases des systèmes distribués.
✅ Tu sais lancer un job MapReduce.
✅ Tu sais manipuler HDFS et YARN.
✅ Tu sais comparer Hadoop vs Spark.
En 6 mois, tu maîtrises Python + SQL + Linux + Git + APIs + Cloud + Big Data (Spark/Hadoop). Tu es déjà au-dessus de la moyenne des juniors Data Engineers.
Juillet — Data Warehousing
Pourquoi un Data Warehouse est indispensable ?
- Centralisation : toutes les données (CRM, e-commerce, web analytics, logs) dans un seul endroit.
- Historisation : garder la trace (pas juste le snapshot du jour).
- Optimisation analytique : conçu pour les requêtes rapides, pas pour gérer des transactions comme un SQL classique.
- Confiance : une “vérité unique” évite d’avoir 10 chiffres différents selon les services.
👉 Sans data warehouse, une boîte finit toujours par se noyer dans la data.
1. Les concepts clés à maîtriser
- OLTP vs OLAP :
- OLTP (MySQL/Postgres) → rapide en écriture, gère les transactions.
- OLAP (Redshift, BigQuery, Snowflake, Hive) → optimisé pour les requêtes de synthèse.
- Modélisation :
- Schéma en étoile (Star schema) : une table “fact” (transactions, événements) reliée à des tables “dimensions” (produits, clients, temps).
- Schéma flocon (Snowflake) : variante plus normalisée.
Exemple simple :
Fact_Sales
| sale_id | date_id | client_id | product_id | revenue |
Dim_Client
| client_id | nom | pays |
Dim_Product
| product_id | catégorie | prix |
👉 Tu crées une base pensée pour les requêtes analytiques.
2. Les outils incontournables
- Apache Hive : couche SQL au-dessus d’Hadoop. Très utilisé dans les architectures Big Data historiques.
- BigQuery (GCP) : warehouse cloud serverless. Paye à la requête, ultra-scalable.
- Redshift (AWS) : warehouse managé, proche de PostgreSQL.
- Snowflake (bonus) : très populaire en 2025, cloud-agnostic, simple à scaler.
3. Exemple avec Hive
CREATE EXTERNAL TABLE ventes (
id INT,
produit STRING,
client STRING,
montant DOUBLE,
date STRING
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
STORED AS TEXTFILE
LOCATION '/user/hive/warehouse/ventes/';
SELECT client, SUM(montant) as total
FROM ventes
GROUP BY client
ORDER BY total DESC;
👉 Tu interroges des fichiers stockés sur HDFS comme une base SQL.
4. Exemple avec BigQuery
SELECT country, COUNT(DISTINCT user_id) as nb_users
FROM `bigquery-public-data.github_repos.users`
GROUP BY country
ORDER BY nb_users DESC
LIMIT 10;
⚡ BigQuery te permet d’interroger des milliards de lignes en quelques secondes.
5. Mini-projet de Juillet : ton premier Data Mart
- Choisis un dataset multi-sources : par exemple, ventes e-commerce + logs web (Google Analytics export).
- Modélise un schéma en étoile :
Fact_Sales
,Dim_Client
,Dim_Product
,Dim_Date
. - Charge les données dans :
- Hive (si tu bosses Hadoop).
- BigQuery ou Redshift (plus moderne).
- Crée 5 requêtes analytiques clés :
- CA par mois.
- Top 10 produits.
- Clients les plus fidèles.
- Taux de churn (clients non revenus).
- Comparaison nouveaux vs anciens clients.
👉 Tu viens de créer un mini data warehouse.
6. Astuce pro : documenter ton DWH
Un bon Data Engineer ne livre jamais un entrepôt sans doc.
- Schéma (diagramme entités-relations).
- Dictionnaire des colonnes (qu’est-ce que “revenue”, comment est calculé ?).
- Table de suivi (date de dernière update, source).
Outils pratiques : dbdiagram.io, Metabase, DataHub.
Bilan de Juillet
✅ Tu comprends la différence OLTP/OLAP.
✅ Tu sais modéliser un schéma en étoile.
✅ Tu as touché à Hive, BigQuery ou Redshift.
✅ Tu as construit ton premier data mart analytique.
En 7 mois, tu es capable non seulement de collecter et transformer des données, mais aussi de les centraliser et les rendre exploitables par toute une entreprise.
Août — Ingestion temps réel avec Apache Kafka
Pourquoi Kafka ?
- Scalabilité extrême : utilisé chez LinkedIn, Uber, Netflix pour gérer des millions d’événements par seconde.
- Fiabilité : garantit que les messages ne se perdent pas, même en cas de crash.
- Flexibilité : Kafka sert de “tuyauterie centrale” pour distribuer les données vers plusieurs systèmes (bases SQL, warehouses, Spark, monitoring).
👉 Kafka = le “système sanguin” de la donnée en temps réel.
1. Architecture de Kafka en bref
- Producer : l’app qui envoie des événements (ex. site e-commerce qui envoie chaque commande).
- Broker : le serveur Kafka qui reçoit, stocke et distribue les messages.
- Topic : la file d’attente logique où arrivent les messages (ex.
commandes
,paiements
). - Consumer : l’app qui lit les messages (ex. un pipeline qui stocke les commandes dans PostgreSQL).
- Partition : permet de paralléliser un topic en plusieurs morceaux.
👉 Un topic commandes
peut avoir 3 partitions → 3 consumers peuvent lire en parallèle → ingestion massive.
2. Exemple simple en Python
Producer (écrit des messages dans Kafka)
from kafka import KafkaProducer
import json
producer = KafkaProducer(bootstrap_servers="localhost:9092",
value_serializer=lambda v: json.dumps(v).encode("utf-8"))
commande = {"id": 1, "client": "Alice", "montant": 120}
producer.send("commandes", commande)
producer.flush()
Consumer (lit les messages)
from kafka import KafkaConsumer
import json
consumer = KafkaConsumer("commandes",
bootstrap_servers="localhost:9092",
value_deserializer=lambda v: json.loads(v.decode("utf-8")))
for message in consumer:
print("Commande reçue :", message.value)
👉 Tu viens de construire un flux temps réel : chaque commande envoyée est reçue immédiatement par ton consumer.
3. Cas d’usage typiques
- Détection fraude bancaire → flagger une transaction suspecte en temps réel.
- Logs serveurs → monitoring de production.
- Analytics live → dashboards qui se mettent à jour sans attendre la fin du jour.
- Recommandations e-commerce → proposer un produit dès que l’utilisateur clique.
4. Kafka vs AWS Kinesis vs GCP Pub/Sub
Critère | Kafka (open-source) | Kinesis (AWS) | Pub/Sub (GCP) |
---|---|---|---|
Déploiement | Auto-hébergé ou Confluent | Managé AWS | Managé GCP |
Scalabilité | Très élevée | Très élevée | Très élevée |
Complexité | Haute (cluster à gérer) | Moyenne | Moyenne |
Cas d’usage | Entreprises data-heavy | AWS users | GCP users |
👉 En pratique : Kafka si tu veux maîtriser, Kinesis/PubSub si tu veux aller vite.
5. Mini-projet d’Août : streaming e-commerce
- Installe Kafka en local (ou utilise Confluent Cloud Free).
- Crée un topic
commandes
. - Producer Python → envoie chaque commande simulée (client, produit, montant).
- Consumer Python → lit et stocke en PostgreSQL.
- Bonus : connecte Spark Streaming pour analyser les commandes en flux (voir Septembre).
👉 Tu passes officiellement du batch au streaming.
6. Astuce pro : éviter la noyade
- Kafka est puissant mais complexe (clusters, partitions, offsets). Pour apprendre, reste simple : un seul broker, un seul topic.
- Documente ton pipeline dès le début (quels events, quel schéma JSON, quelle retention).
- Si ton objectif est l’employabilité rapide → maîtrise Kafka conceptuellement et pratique un mini-projet. En entreprise, tu utiliseras souvent un Kafka déjà configuré.
Bilan d’Août
✅ Tu comprends le modèle publish/subscribe.
✅ Tu sais créer un producer et un consumer.
✅ Tu as construit un pipeline streaming simple.
✅ Tu as vu comment Kafka s’intègre dans l’écosystème (Spark, warehouses, monitoring).
En 8 mois, tu sais déjà faire du batch et du streaming → deux mondes complémentaires que tout Data Engineer doit connaître.
Septembre — Spark Streaming
Pourquoi Spark Streaming ?
- Kafka capte les événements → Spark les transforme en données exploitables.
- Tu peux faire les mêmes transformations qu’en batch, mais en flux continu.
- Idéal pour : détection de fraude, alertes temps réel, dashboards interactifs, analyse de logs.
👉 Spark Streaming = ton couteau suisse temps réel.
1. Deux approches dans Spark Streaming
- DStreams (historique) : flux découpés en micro-batchs. Ancienne API.
- Structured Streaming (moderne) : même syntaxe que Spark SQL/DataFrames, mais en temps réel. → c’est celle à utiliser en 2025.
2. Exemple simple avec Structured Streaming
On suppose que Kafka reçoit des commandes e-commerce (topic: commandes
).
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("StreamCommandes").getOrCreate()
# Lire en continu depuis Kafka
df = spark.readStream.format("kafka") \
.option("kafka.bootstrap.servers", "localhost:9092") \
.option("subscribe", "commandes") \
.load()
# Kafka fournit key et value en binaire → cast en string
df_str = df.selectExpr("CAST(value AS STRING) as commande")
# Exemple : compter le nombre de messages reçus par minute
agg = df_str.groupBy().count()
# Ecrire la sortie en console
query = agg.writeStream.outputMode("update").format("console").start()
query.awaitTermination()
👉 Chaque fois qu’une commande arrive dans Kafka, Spark la lit et l’analyse immédiatement.
3. Cas pratiques
- Détection d’anomalies : flagger une commande > 10 000 € en direct.
- Analytics en temps réel : calcul du chiffre d’affaires minute par minute.
- Monitoring : alerter si trop d’erreurs apparaissent dans des logs.
Exemple de transformation avec fenêtre temporelle :
from pyspark.sql.functions import window, col
agg = df_str.groupBy(window(col("timestamp"), "5 minutes")) \
.count()
4. Stockage des flux traités
Une fois transformées, les données doivent être stockées ou envoyées ailleurs :
- Systèmes temps réel : Elasticsearch, Redis, Cassandra.
- Data Warehouse : BigQuery, Redshift (via connecteurs).
- Dashboards live : Grafana, Kibana.
👉 En pratique : Kafka → Spark Streaming → stockage/dashboards.
5. Mini-projet de Septembre : analyse en direct des commandes
- Kafka reçoit un flux de commandes (id, client, montant).
- Spark Streaming lit en continu le topic.
- Transformation : calcul du CA cumulé par client en temps réel.
- Stockage : envoie les résultats vers PostgreSQL (ou Redis pour un cache rapide).
- Visualisation : dashboard Grafana ou Metabase connecté à PostgreSQL.
👉 Tu construis ton premier pipeline temps réel complet.
6. Limites et bonnes pratiques
- Spark Streaming ≠ “milliseconde” → c’est du near real-time (latence de 1 à 5 sec).
- Bien choisir la granularité des micro-batchs (trop court → surcharge, trop long → perte de réactivité).
- Toujours penser à la tolérance aux pannes → checkpoints obligatoires (sauvegarder l’état du flux).
Bilan de Septembre
✅ Tu comprends Structured Streaming.
✅ Tu as relié Kafka → Spark Streaming.
✅ Tu sais transformer et stocker des données en temps réel.
✅ Tu as réalisé un pipeline complet de la capture à l’analyse live.
En 9 mois, tu sais maintenant gérer à la fois du batch massif (Spark/Hadoop) et du streaming temps réel (Kafka + Spark). Tu entres dans le cœur du métier d’un Data Engineer moderne.
Octobre — Programmation avancée pour Data Engineers
Pourquoi passer au niveau supérieur ?
- Les pipelines deviennent complexes → il faut du code organisé.
- Tu travailleras en équipe → ton code doit être lisible et testé.
- En prod, un bug peut coûter très cher → tests et CI/CD sont obligatoires.
👉 Tu ne deviens pas “ingénieur logiciel complet”, mais tu adoptes les bonnes pratiques.
1. Programmation orientée objet (OOP)
Concepts de base :
- Classe : plan de construction.
- Objet : instance de la classe.
- Héritage : réutiliser/étendre du code.
- Encapsulation : cacher la complexité derrière des méthodes.
Exemple simple :
class ETLPipeline:
def __init__(self, source):
self.source = source
def extract(self):
print(f"Extraction depuis {self.source}")
def transform(self, data):
return [d.upper() for d in data]
def load(self, data):
print("Chargement des données :", data)
pipeline = ETLPipeline("API ventes")
pipeline.extract()
pipeline.load(pipeline.transform(["alice", "bob"]))
👉 Au lieu de 3 scripts dispersés, tu as une classe ETL réutilisable.
2. Recursion & patterns utiles
- Recursion : une fonction qui s’appelle elle-même. Peu utilisé en ETL, mais bon à savoir.
- Design patterns fréquents :
- Factory (créer des objets différents avec la même interface).
- Singleton (une seule connexion DB partagée).
- Pipeline pattern (chaîne de transformations).
3. Tests unitaires & d’intégration
Tests unitaires → valider une fonction isolée.
Tests d’intégration → vérifier qu’un pipeline complet marche.
Exemple avec pytest
:
# etl.py
def transform(data):
return [d.upper() for d in data]
# test_etl.py
from etl import transform
def test_transform():
assert transform(["a", "b"]) == ["A", "B"]
👉 Avec pytest
, tu exécutes pytest -v
et tu sais tout de suite si ton code casse.
4. CI/CD pour tes pipelines
CI/CD = Intégration Continue / Déploiement Continu.
- CI : chaque push déclenche les tests automatiquement (GitHub Actions, GitLab CI).
- CD : déploiement automatique si tout est vert.
Exemple GitHub Actions (fichier .github/workflows/test.yml
) :
name: Tests ETL
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup Python
uses: actions/setup-python@v2
with:
python-version: "3.11"
- run: pip install -r requirements.txt
- run: pytest
👉 Chaque fois que tu pousses ton code → tests auto → pipeline validé ou rejeté.
5. Mini-projet d’Octobre : refactorer ton ETL en code pro
- Reprends ton projet d’API → SQL du mois de mars.
- Refactorise en classe Python (
ETLPipeline
). - Ajoute des tests unitaires pour
extract
,transform
,load
. - Mets le tout sur GitHub.
- Ajoute un workflow GitHub Actions qui lance les tests à chaque push.
👉 Tu passes officiellement de “script rapide” à pipeline industrialisé.
6. Astuce pro : le code n’est pas que du code
- Style : utilise
black
ouflake8
pour formater automatiquement. - Logs : ajoute
logging
pour tracer tes pipelines → indispensable en prod. - Config : sépare tes paramètres (
.env
ou YAML), ne jamais hardcoder mots de passe/URL.
Bilan d’Octobre
✅ Tu comprends OOP et design patterns simples.
✅ Tu écris et exécutes des tests unitaires.
✅ Tu as mis en place une CI/CD basique.
✅ Tu as transformé un vieux script en pipeline pro.
En 10 mois, tu n’es plus juste un Data Engineer “bricoleur” : tu commences à écrire du code propre, testé et déployable comme un vrai pro.
Novembre — Bases NoSQL
Pourquoi le NoSQL est crucial ?
- Flexibilité : tu peux stocker du JSON sans schéma rigide.
- Scalabilité horizontale : facile à répartir sur plusieurs serveurs.
- Performance : super rapide pour certaines requêtes (lookup clé-valeur, temps réel).
👉 En 2025, beaucoup d’architectures combinent SQL et NoSQL → ce qu’on appelle polyglot persistence.
1. Les 4 grandes familles NoSQL
- Document stores → JSON (MongoDB, Couchbase).
- Key-Value stores → paires simples (Redis, DynamoDB).
- Wide-column stores → gros volumes distribués (Cassandra, HBase).
- Graph databases → relations complexes (Neo4j).
En pratique, maîtrise au moins MongoDB (document), Redis (temps réel) et Cassandra (scalable).
2. MongoDB (Document store)
Stocke tes données comme du JSON → parfait pour logs, profils clients, APIs.
Exemple :
from pymongo import MongoClient
client = MongoClient("mongodb://localhost:27017/")
db = client["ecommerce"]
collection = db["commandes"]
# Insérer un document JSON
collection.insert_one({"client": "Alice", "produit": "Laptop", "prix": 1200})
# Requête simple
for doc in collection.find({"prix": {"$gt": 1000}}):
print(doc)
👉 Avantage : pas besoin de définir un schéma en avance.
3. Redis (Key-Value store)
Ultra rapide, utilisé comme cache ou pour du temps réel.
Exemple :
import redis
r = redis.Redis(host="localhost", port=6379, db=0)
# Set/Get
r.set("user:1", "Alice")
print(r.get("user:1").decode("utf-8")) # → Alice
# Incrément (compteur temps réel)
r.incr("visites_page")
👉 Utilisé pour des compteurs live (ex. nombre de visiteurs connectés).
4. Cassandra (Wide-column)
Conçu pour la scalabilité massive (Netflix l’utilise pour ses logs utilisateurs).
Exemple en CQL (Cassandra Query Language)
CREATE KEYSPACE ecommerce WITH replication =
{'class': 'SimpleStrategy', 'replication_factor': 2};
USE ecommerce;
CREATE TABLE commandes (
id UUID PRIMARY KEY,
client TEXT,
produit TEXT,
prix DECIMAL
);
INSERT INTO commandes (id, client, produit, prix)
VALUES (uuid(), 'Alice', 'Laptop', 1200);
👉 Cassandra est pensé pour écrire/ingérer des millions d’événements par seconde.
5. Mini-projet de Novembre : polyglot persistence
- Récupère des logs d’un site (par ex. logs Nginx ou Apache).
- Stocke-les :
- MongoDB → garder le JSON brut.
- Redis → créer un compteur temps réel (visites par minute).
- Cassandra → archiver l’historique des logs.
- Fais une analyse croisée (Python) :
- Logs live dans Redis.
- Requêtes flexibles dans Mongo.
- Historique massif dans Cassandra.
👉 Tu montres que tu sais utiliser chaque base pour ce qu’elle fait le mieux.
6. Bonnes pratiques NoSQL
- Toujours documenter le schéma implicite (même si NoSQL ne l’impose pas).
- Attention à la consistance : beaucoup de NoSQL privilégient la disponibilité (CAP theorem).
- Ne tombe pas dans le piège “NoSQL > SQL” : choisis l’outil adapté, pas le plus hype.
Bilan de Novembre
✅ Tu connais les grandes familles NoSQL.
✅ Tu as pratiqué MongoDB, Redis et Cassandra.
✅ Tu as construit un projet multi-bases.
✅ Tu sais quand utiliser NoSQL vs SQL.
En 11 mois, tu deviens un ingénieur data complet : SQL, NoSQL, batch, streaming, cloud.
Décembre — Orchestration & Workflow avec Apache Airflow
Pourquoi l’orchestration est vitale ?
- Un projet Data = plusieurs étapes : extraire → transformer → charger.
- Chaque étape dépend d’une autre → il faut gérer les dépendances.
- Les jobs doivent tourner automatiquement (chaque nuit, ou à chaque nouvel événement).
- En cas d’erreur, tu dois avoir des logs clairs et des alertes.
👉 C’est exactement ce que fait Apache Airflow.
1. Les concepts clés d’Airflow
- DAG (Directed Acyclic Graph) : un pipeline de tâches, reliées par des dépendances.
- Task : une étape (ex. extraire API, charger SQL).
- Operator : type de tâche (PythonOperator, BashOperator, PostgresOperator…).
- Scheduler : qui planifie quand lancer le DAG.
- Web UI : visualiser tes workflows, voir les erreurs, relancer un job.
2. Exemple de DAG simple
Un pipeline ETL basique en Airflow :
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
def extract():
print("Extraction API")
def transform():
print("Nettoyage données")
def load():
print("Chargement PostgreSQL")
with DAG(
"etl_simple",
start_date=datetime(2025, 1, 1),
schedule_interval="@daily",
catchup=False,
) as dag:
t1 = PythonOperator(task_id="extract", python_callable=extract)
t2 = PythonOperator(task_id="transform", python_callable=transform)
t3 = PythonOperator(task_id="load", python_callable=load)
t1 >> t2 >> t3 # dépendances
👉 Résultat : chaque jour, Airflow exécute les 3 tâches dans l’ordre.
3. Cas d’usage réels
- Pipeline batch : tous les jours à 2h, récupérer les ventes → nettoyer → charger dans Redshift.
- Streaming + batch mix : monitorer Kafka en temps réel, puis agréger toutes les heures.
- Data Warehouse : orchestrer la mise à jour d’un DWH complet.
4. Aller plus loin avec Airflow
- XComs : échanger des données entre tâches.
- Sensors : attendre un fichier/événement avant de lancer une tâche.
- Branching : exécuter un chemin A ou B selon une condition.
- Plugins : connecter Airflow à presque tout (GCP, AWS, Spark, Slack, etc.).
5. Alternatives modernes
- Dagster : plus “dev-friendly”, type checking, observabilité native.
- Prefect : syntaxe Python simple, cloud pour monitoring.
- Mage.ai : open-source, orienté notebooks + orchestration.
👉 En 2025, Airflow reste le standard, mais Dagster et Prefect gagnent du terrain.
6. Mini-projet de Décembre : Capstone project
Construis ton pipeline final pour boucler l’année :
- Source : extrais des données (API météo, e-commerce, logs Kafka).
- Transform : nettoie avec Spark (batch) ou Spark Streaming (live).
- Stockage : envoie dans ton Data Warehouse (BigQuery/Redshift/Hive).
- Orchestration : écris un DAG Airflow qui pilote l’ensemble.
- Monitoring : ajoute logs + alertes Slack si une tâche échoue.
👉 C’est ton projet vitrine GitHub/portfolio pour candidater à un poste de Data Engineer en 2025.
Bilan de Décembre
✅ Tu comprends DAGs, Operators, dépendances.
✅ Tu sais planifier et surveiller tes pipelines.
✅ Tu as comparé Airflow à ses alternatives (Dagster, Prefect).
✅ Tu as construit un pipeline complet orchestré → ton capstone project.
Douze mois plus tôt, tu avais peut-être à peine ouvert un notebook Python ou tapé ta première requête SQL. Aujourd’hui, après un an de travail régulier, de mini-projets, d’exercices poussés et d’expérimentations cadrées, tu as franchi toutes les étapes pour devenir Data Engineer opérationnel.
Tu sais :
- Coder en Python, organiser ton code et l’automatiser.
- Stocker et interroger des données efficacement avec SQL.
- Travailler comme un pro avec Linux, Git et les APIs.
- Déployer dans le cloud (AWS, GCP), et scaler quand ton laptop ne suffit plus.
- Traiter du Big Data avec Spark et comprendre les bases d’Hadoop.
- Construire un Data Warehouse robuste (Hive, BigQuery, Redshift).
- Ingest et traiter en temps réel des flux de données avec Kafka et Spark Streaming.
- Écrire du code propre, testé et versionné, prêt pour la production.
- Manipuler NoSQL (MongoDB, Cassandra, Redis) pour les données non structurées.
- Orchestrer tes pipelines avec Airflow et gérer des workflows complets comme un chef d’orchestre.
Bref, tu n’es plus spectateur, tu es acteur du monde data.
Et maintenant ?
Un Data Engineer ne cesse jamais d’apprendre. La donnée évolue, les outils changent, de nouvelles architectures apparaissent (Data Mesh, Lakehouse, temps réel + IA…). Mais désormais, tu as le socle solide pour explorer sans te perdre.
👉 Le secret : continuer à décliner tes exercices.
- Quand tu construis un pipeline ETL avec Airflow, ajoute une étape de qualité des données (tests automatiques avec Great Expectations).
- Quand tu fais du streaming avec Kafka, entraîne-toi à gérer des erreurs réseau ou des volumes massifs.
- Quand tu bosses sur un Data Warehouse, ajoute une couche BI (Metabase, Looker Studio) pour voir tes données prendre vie.
Tu ne pars pas dans tous les sens, tu élargis à partir de ce que tu sais déjà.
Le futur
Ton parcours ne s’arrête pas là. Tu peux maintenant te spécialiser selon tes envies :
- Data Engineer Cloud (AWS/GCP/Azure, BigQuery, Snowflake).
- Streaming Specialist (Kafka, Flink, Spark Streaming).
- Machine Learning Engineer (si tu veux aller vers l’IA).
- Data Architect (si tu veux concevoir les grandes infrastructures).
Mais quelle que soit ta route, rappelle-toi : c’est ton cadre et ta discipline qui font la différence. Tu as appris à monter chaque marche, dans le bon ordre, sans digressions inutiles.
🎯 En résumé : tu as désormais les clés pour transformer la donnée brute en valeur, et c’est exactement ce qui fait de toi un Data Engineer.