PROJET DE FIN DE MODULE

Big Data & Data Engineering

DATA LAKE
d’Entreprise

Stack Technique :
HDFS | Apache Hive |
Apache Spark | Apache Airflow

Responsable du Module :
M. GOUSKIR

Équipe du Projet :

Rayhana Laznasni
Aitchettou Fatimezzahra
Jaber Yassir

Année Universitaire 2025–2026

Document Confidentiel — Version 1.0
Table des matières

1 Résumé Exécutif 3
1.1 Axes Principaux du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Contexte & Objectifs 4

2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Objectifs Principaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Périmètre Fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Architecture Technique 6
3.1 Stack Technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Architecture des Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Flux de Données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Exigences Fonctionnelles 8
4.1 Ingestion — Zone Raw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Traitements ETL — Apache Spark . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Orchestration — Apache Airflow . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Qualité des Données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Exigences Non Fonctionnelles 10

6 Répartition des Tâches 11

6.1 Matrice Globale des Responsabilités . . . . . . . . . . . . . . . . . . . . . . 11
6.2 Fatimezzahra Aitchettou — Ingénieur Data (Ingestion & HDFS/Hive) . . . 11
6.2.1 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.2 Infrastructure Déployée . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.3 Scripts Développés . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.4 Livrables Réalisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 Yassir Jaber — Data Engineer (ETL Spark & Zone Curated) . . . . . . . . 12
6.3.1 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3.2 Configuration Spark Commune . . . . . . . . . . . . . . . . . . . . 13
6.3.3 Script 1 : etl_ventes.py — Pipeline ETL Ventes . . . . . . . . . . . 13
6.3.4 Script 2 : etl_clients.py — Pipeline ETL Clients . . . . . . . . . . . 13
6.3.5 Script 3 : compact_curated.py — Maintenance Hebdomadaire . . . 13
6.3.6 Livrables Réalisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4 Rayhana Laznasni — DataOps / QA (Orchestration & Qualité) . . . . . . 14
6.4.1 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4.2 Tâches Précises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1
Projet Data Lake — Module Big Data 2

6.4.3 Livrables Attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7 Exemple de DAG Airflow 15

8 Planning Prévisionnel 17

9 Livrables & Critères d’Acceptation 18

9.1 Livrables du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2 Critères d’Acceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

10 Glossaire 19

Document confidentiel — Équipe Data Lake

 1

Résumé Exécutif

Contexte du Projet
Ce rapport présente la conception et la mise en œuvre d’un Data Lake d’Entreprise
reposant sur une stack Big Data open-source éprouvée : HDFS, Apache Hive,
Apache Spark et Apache Airflow.

L’objectif central est de centraliser l’ensemble des données de l’entreprise (ERP, CRM,
logs applicatifs, fichiers plats, APIs) dans une plateforme unique, scalable et fiable, afin
de faciliter :
• L’analytique avancée
• La Business Intelligence
• Le Machine Learning

1.1 Axes Principaux du Projet

Le projet s’articule autour de quatre axes stratégiques :
1. Ingestion automatisée des données brutes dans une zone Raw sécurisée (HDFS).
2. Transformation ETL vers un format Parquet optimisé via Apache Spark.
3. Orchestration complète des pipelines avec monitoring via Apache Airflow.
4. Contrôle qualité continu des données à chaque étape du pipeline.
Informations Clés
▷ Durée du projet : 7 semaines
▷ Équipe : 3 profils spécialisés
▷ Technologies : HDFS, Hive, Spark, Airflow

3
 2

Contexte & Objectifs

2.1 Contexte
L’entreprise génère quotidiennement un volume croissant de données hétérogènes pro-
venant de sources diverses :

Source Type de Données

Systèmes ERP Données transactionnelles
CRM Données clients et prospects
Logs applicatifs Traces et événements système
Fichiers plats CSV, JSON, XML
APIs tierces Données externes et enrichissements

Table 2.1 – Sources de données de l’entreprise

2.1.1 Problématique
Point Critique
Les données sont éparpillées dans des systèmes cloisonnés, sans gouvernance centra-
lisée, rendant difficile toute initiative d’analytique avancée ou de Machine Learning
à l’échelle de l’entreprise.

2.2 Objectifs Principaux

Mettre en place un Data Lake scalable et hautement disponible
Assurer l’ingestion automatisée des données brutes depuis toutes les sources
Transformer les données vers un format optimisé (Parquet/Snappy)
Garantir la qualité des données tout au long du pipeline
Orchestrer l’ensemble des processus avec un monitoring centralisé

4
Projet Data Lake — Module Big Data 5

2.3 Périmètre Fonctionnel

Domaine Description
Ingestion Batch quotidien depuis ERP, CRM, logs, fichiers plats,
APIs
Stockage HDFS avec zones Raw et Curated
Catalogage Hive Metastore pour la gestion des métadonnées
Transformation Apache Spark (PySpark) pour les traitements ETL
Orchestration Apache Airflow pour la planification et le monitoring
Qualité Contrôles automatisés avec rapports JSON

Table 2.2 – Périmètre fonctionnel du projet

Document confidentiel — Équipe Data Lake

 3

Architecture Technique

3.1 Stack Technologique

Composant Technologie Rôle

Stockage HDFS (Hadoop) Stockage distribué des données brutes
et traitées
Catalogage Apache Hive Métastore, tables externes, requêtes
SQL analytiques
Traitement Apache Spark (PySpark) ETL, nettoyage, enrichissement, écri-
ture Parquet
Orchestration Apache Airflow Planification, dépendances, retry, aler-
ting
Qualité Spark + JSON Vérifications intégrées, rapports de
qualité

Table 3.1 – Stack technologique du Data Lake

3.2 Architecture des Zones

Zone Format Objectif

Raw JSON, CSV, XML Données brutes, version originale, colonnes
techniques
Curated Parquet (Snappy) Données nettoyées, typées, partitionnées, op-
timisées

Table 3.2 – Architecture des zones de données

3.3 Flux de Données

Le flux de données suit trois étapes séquentielles bien définies :
Étape 1. Sources → Ingestion → Zone Raw (HDFS)
Les données brutes sont extraites des systèmes sources et déposées dans la zone

6
Projet Data Lake — Module Big Data 7

Raw sous la structure /data/raw/{source}/{date}/ avec l’ajout de colonnes

techniques (source_system, ingestion_timestamp, file_name).
Étape 2. Raw → Spark ETL → Zone Curated (Parquet)
Les pipelines PySpark lisent les données brutes, appliquent les transformations
(nettoyage, enrichissement, conversion de types) et écrivent en format Parquet
compressé Snappy, partitionné par year/month/day.
Étape 3. Curated → Hive → Analytics / BI
Les tables externes Hive pointent vers la zone Curated, permettant aux ana-
lystes d’exécuter des requêtes SQL analytiques et d’alimenter les outils de
BI/ML.

Document confidentiel — Équipe Data Lake

 4

Exigences Fonctionnelles

4.1 Ingestion — Zone Raw

La zone Raw est le point d’entrée unique de toutes les données dans le Data Lake :
• Chargement des fichiers sources dans HDFS
• Arborescence standardisée : /data/raw/{source}/{date}/
• Conservation intégrale de la version originale (immuabilité)
• Ajout automatique des colonnes techniques : source_system, ingestion_timestamp,
file_name

4.2 Traitements ETL — Apache Spark

Pipeline ETL Spark
▷ Nettoyage : suppression des valeurs nulles, déduplication, normalisation des for-
mats de dates et types de données
▷ Enrichissement : jointures entre entités métier, calcul de colonnes dérivées
▷ Conversion : écriture en Parquet avec compression Snappy
▷ Partitionnement dynamique : year / month / day
▷ Écriture : /data/curated/{entity}/

4.3 Orchestration — Apache Airflow

• DAGs dédiés pour chaque pipeline (ingestion + transformation)
• Gestion des dépendances inter-tâches (opérateurs »)
• Politique de retry : 3 tentatives, délai de 5 minutes
• Alerting : email et/ou Slack en cas d’échec de tâche
• Planification : exécution quotidienne (@daily)

8
Projet Data Lake — Module Big Data 9

4.4 Qualité des Données

Contrôle Description Seuil

Schéma Vérification du nombre et des Strict
types de colonnes
Valeurs nulles Taux de nulls par colonne critique < 5%
Unicité Contrôle de l’unicité des clés mé- 0 doublon
tier
Plages de valeurs Contrôle min/max des colonnes Configurable
numériques
Comptage Comparaison des volumes Raw vs Écart < 1%
Curated
Rapport Génération de Obligatoire
dq_report_{date}.json

Table 4.1 – Contrôles qualité des données

Document confidentiel — Équipe Data Lake

5

Exigences Non Fonctionnelles

Exigence Description
Sécurité ACL HDFS : zone Raw en lecture seule pour les ana-
lystes ; zone Curated en lecture/écriture pour l’équipe
data
Performance Partitionnement et bucketing Parquet ; compaction des
petits fichiers pour optimiser les lectures
Maintenabilité Code versionné sur Git ; documentation des pipelines ;
conventions de nommage strictes
Monitoring Logs Airflow centralisés ; métriques Spark (UI) ; rap-
ports de qualité après chaque exécution
Reprise sur échec Idempotence de tous les traitements ; reprise à partir du
dernier état connu (checkpointing)

Table 5.1 – Exigences non fonctionnelles

Règle Critique — Idempotence

Tous les pipelines doivent être idempotents : une ré-exécution du même traite-
ment pour la même date ne doit pas créer de doublons ni corrompre les données
existantes. Implémenté par la Personne B via partitionOverwriteMode=dynamic +
mode(’overwrite’) : seule la partition year/month/day du jour traité est réécrite
lors de chaque exécution ou retry Airflow.

Conformité RGPD — Données Clients

Les colonnes PII (nom, prénom, email, téléphone, date_naissance) sont hachées en
SHA-256 via F.sha2(..., 256) avant toute écriture en zone Curated. Les analystes
n’ont jamais accès aux données personnelles brutes.

10
 6

Répartition des Tâches

L’équipe est composée de 3 personnes aux profils complémentaires, chacune respon-

sable d’un domaine fonctionnel bien délimité.

6.1 Matrice Globale des Responsabilités

Tâche Personne A Personne B Personne C

Configuration HDFS & répertoires R
Ingestion Raw R
Tables Hive externes R
Sécurité HDFS (ACL) R
Transformation Spark → Parquet R
Optimisation & partitionnement R
Compaction & maintenance R
Orchestration Airflow (DAGs) R
Data Quality checks R
Alerting & monitoring R

Table 6.1 – Matrice RACI des responsabilités — R = Responsable

6.2 Fatimezzahra Aitchettou — Ingénieur Data (Inges-

tion & HDFS/Hive)
6.2.1 Focus
Mise en place de la zone Raw, du pipeline d’ingestion et du catalogue Hive, dans une
infrastructure entièrement conteneurisée avec Docker.

11
Projet Data Lake — Module Big Data 12

6.2.2 Infrastructure Déployée

Service Image Rôle

Namenode Hadoop Gestionnaire du système de fichiers
HDFS
Datanode Hadoop Nœud de stockage distribué
Spark Master Apache Spark Coordination des traitements distri-
bués
Spark Worker Apache Spark Exécution des jobs Spark
Hive Server Apache Hive Exposition SQL des données Curated
Airflow Apache Airflow Orchestration des DAGs
PostgreSQL PostgreSQL Metastore Airflow

Table 6.2 – Services Docker déployés

6.2.3 Scripts Développés

1. Script d’ingestion — scripts/ingest_to_raw.py
Cœur de la zone Raw. Lecture des fichiers CSV, enrichissement avec colonnes tech-
niques, chargement dans HDFS sous /data/raw/<source>/<date>/.
2. Script de maintenance — scripts/nettoyage_raw.py
Nettoyage périodique de la zone Raw. Suppression automatique des données brutes
datant de plus de 30 jours.
3. DAG d’ingestion — dags/dag_ingestion.py
Coordination des étapes du pipeline d’ingestion : création des répertoires HDFS, exé-
cution du script d’ingestion, vérification de la présence des données.
4. DDL Hive — hive/create_tables.sql
Création des tables externes Hive pointant vers la zone Curated.

6.2.4 Livrables Réalisés

[Link] — Infrastructure complète conteneurisée
scripts/ingest_to_raw.py — Script d’ingestion avec enrichissement
scripts/nettoyage_raw.py — Script de maintenance (purge 30 jours)
dags/dag_ingestion.py — DAG Airflow d’orchestration de l’ingestion
hive/create_tables.sql — DDL des tables externes Hive
[Link] — Documentation de déploiement

6.3 Yassir Jaber — Data Engineer (ETL Spark & Zone

Curated)
6.3.1 Focus
Développement des trois pipelines PySpark de transformation : etl_ventes.py, etl_clients.py
et compact_curated.py.

Document confidentiel — Équipe Data Lake

 Projet Data Lake — Module Big Data 13

6.3.2 Configuration Spark Commune

Paramètre Valeur / Justification

[Link] snappy — Compression rapide, gain 60–70%
[Link] 200 (ETL) / 50 (compaction)
partitionOverwriteMode dynamic — Idempotence : seule la partition
du jour est réécrite
[Link] true — Active les bucket joins sans shuffle
autoBroadcastJoinThreshold -1 — Force le bucket join entre ventes et
clients

Table 6.3 – Configuration Spark

6.3.3 Script 1 : etl_ventes.py — Pipeline ETL Ventes

Exécution : spark-submit etl_ventes.py –date YYYY-MM-DD
Pipeline en 5 étapes :
1. Lecture (read_raw) : Lecture CSV depuis /data/raw/ventes/{date}/
2. Nettoyage (clean) : dropDuplicates sur id_vente, filtre NULL, cast montant en
Double
3. Enrichissement (enrich) : Jointure LEFT avec clients, calcul montant_ttc (×1.20)
4. Métadonnées (add_metadata) : Ajout de _last_transformed, _etl_version
5. Écriture Curated (write_curated) : Écriture partitionnée et bucketisée

6.3.4 Script 2 : etl_clients.py — Pipeline ETL Clients

Points clés :
• dropDuplicates sur id_client ; calcul et filtre de l’âge (18 ≤ âge ≤ 120)
• Normalisation : nom UPPERCASE, prénom INITCAP, email lowercase
• Validation email par regex ; nettoyage téléphone
• Calcul tranche_age, anciennete_jours, statut_fidelite
1 # Colonnes PII hachees en SHA -256 avant ecriture
2 pii_cols = [ ’ email ’ , ’ telephone ’ , ’ nom ’ , ’ prenom ’ , ’ date_naissance ’
]
3 for col_name in pii_cols :
4 df = df . withColumn ( col_name , F . sha2 ( F . col ( col_name ) . cast ( ’
string ’) , 256) )
Listing 6.1 – Hachage RGPD des colonnes PII

6.3.5 Script 3 : compact_curated.py — Maintenance Hebdoma-

daire
Résolution du small files problem : compaction des fichiers Parquet pour optimiser
HDFS et Spark.

Document confidentiel — Équipe Data Lake

Projet Data Lake — Module Big Data 14

Entité Partition Fichiers cible Taille cible Colonnes tri

ventes year / month / day 20 256 MB date_vente
clients region_client / segment 10 128 MB date_inscription

Table 6.4 – Paramètres de compaction

6.3.6 Livrables Réalisés

etl_ventes.py — Pipeline ETL complet
etl_clients.py — Pipeline ETL clients avec conformité RGPD (SHA-256)
compact_curated.py — Script de maintenance hebdomadaire
Documentation technique des transformations

6.4 Rayhana Laznasni — DataOps / QA (Orchestra-

tion & Qualité)
6.4.1 Focus
Orchestration des pipelines, monitoring et contrôle qualité des données.

6.4.2 Tâches Précises

1. Création du DAG Airflow principal : ingestion, contrôle qualité Raw, transformation,
contrôle qualité Curated
2. Gestion des dépendances, retries (3), timeouts
3. Implémentation des Data Quality checks dans Spark
4. Génération du rapport JSON de qualité (dq_report_{date}.json)
5. Configuration des alertes Slack/Email
6. DAG de nettoyage (suppression des données Raw > 30 jours)

6.4.3 Livrables Attendus

data_lake_dag.py — DAG principal
data_quality_checks.py — Contrôles qualité
[Link] — Callbacks Airflow
Dashboard de monitoring (logs ou Grafana)

Document confidentiel — Équipe Data Lake

 7

Exemple de DAG Airflow

Le DAG principal, implémenté par la Personne C, orchestre l’intégralité du pipeline

de données.
1 from airflow import DAG
2 from airflow . operators . bash import BashOperator
3 from airflow . operators . python import PythonOperator
4 from datetime import datetime , timedelta
5

6 default_args = {
7 ’ owner ’: ’ data_lake ’ ,
8 ’ retries ’: 3 ,
9 ’ retry_delay ’: timedelta ( minutes =5) ,
10 ’ email_on_failure ’: True ,
11 ’ email ’: [ ’ alertes@entreprise . com ’]
12 }
13

14 with DAG (
15 dag_id = ’ data_lake_pipeline ’ ,
16 start_date = datetime (2025 , 1 , 1) ,
17 schedule = ’ @daily ’ ,
18 catchup = False ,
19 default_args = default_args
20 ) as dag :
21

22 ingest = BashOperator (
23 task_id = ’ ingest_to_raw ’ ,
24 bash_command = ’ python / scripts / ingest_to_raw . py {{ ds }} ’
25 )
26

27 quality_raw = PythonOperator (
28 task_id = ’ quality_check_raw ’ ,
29 python_callable = run_quality_checks ,
30 op_args =[ ’ raw ’ , ’ {{ ds }} ’]
31 )
32

33 transform = BashOperator (
34 task_id = ’ spark_etl ’ ,
35 bash_command = ’ spark - submit / scripts / etl_main . py -- date {{

15
 Projet Data Lake — Module Big Data 16

ds }} ’
36 )
37

38 quality_curated = PythonOperator (
39 task_id = ’ quality_check_curated ’ ,
40 python_callable = run_quality_checks ,
41 op_args =[ ’ curated ’ , ’ {{ ds }} ’]
42 )
43

44 ingest >> quality_raw >> transform >> quality_curated

Listing 7.1 – DAG principal Airflow — data_lake_pipeline.py

Document confidentiel — Équipe Data Lake

8

Planning Prévisionnel

Sprint Objectifs
Sprint 1 (sem. 1–2) Mise en place de la zone Raw, configuration HDFS, déve-
loppement de l’ingestion de base, DAG Airflow minimal
Sprint 2 (sem. 3–4) Développement des pipelines ETL Spark, écriture en
Parquet partitionné, optimisation des performances
Sprint 3 (sem. 5–6) Implémentation des Data Quality checks, configuration
de l’alerting, documentation technique complète
Sprint 4 (sem. 7) Tests d’intégration de bout en bout, optimisation finale,
déploiement en production

Table 8.1 – Planning prévisionnel sur 7 semaines

17
 9

Livrables & Critères d’Acceptation

9.1 Livrables du Projet

Livrable Responsable Description

[Link] Personne A Infrastructure Docker complète
scripts/ingest_to_raw.py Personne A Ingestion CSV → HDFS avec métadon-
nées
scripts/nettoyage_raw.py Personne A Purge automatique Raw (> 30 jours)
dags/dag_ingestion.py Personne A DAG Airflow d’orchestration
hive/create_tables.sql Personne A DDL tables externes Hive
scripts/etl_ventes.py Personne B Pipeline ETL ventes (TVA, bucketing)
scripts/etl_clients.py Personne B Pipeline ETL clients (RGPD SHA-256)
scripts/compact_curated.py Personne B Compaction hebdomadaire
data_lake_dag.py Personne C DAG principal Airflow
data_quality_checks.py Personne C Contrôles qualité des données
[Link] Personne C Callbacks d’alerting
[Link] Équipe Documentation de déploiement

Table 9.1 – Liste complète des livrables

9.2 Critères d’Acceptation

Tous les fichiers ingérés sont présents dans HDFS (zone Raw)
Les tables Hive externes pointent correctement vers les données Curated
Les pipelines Spark s’exécutent en moins de 2 heures pour 1 To de données
Airflow déclenche correctement les DAGs et gère les reprises automatiquement
Les rapports de qualité (dq_report_{date}.json) sont générés après chaque exécu-
tion
Les alertes fonctionnent en cas d’échec ou de dépassement de seuils de qualité

18
10

Glossaire

Terme Définition
HDFS Hadoop Distributed File System — système de fichiers
distribué, résilient et scalable
Hive Outil d’entreposage de données pour Hadoop permet-
tant d’exécuter des requêtes SQL
Spark Moteur de traitement distribué open-source (PySpark =
API Python)
Airflow Plateforme d’orchestration de workflows pour pipelines
de données
Parquet Format de stockage columnar optimisé pour les requêtes
analytiques
Raw Zone de données brutes non transformées, version origi-
nale
Curated Zone de données nettoyées, typées et partitionnées,
prêtes pour l’analyse
DAG Directed Acyclic Graph — graphe orienté sans cycle re-
présentant les dépendances
ETL Extract, Transform, Load — processus d’extraction,
transformation et chargement
Data Quality Ensemble des contrôles et métriques garantissant la qua-
lité des données
Snappy Algorithme de compression rapide pour fichiers Parquet
ACL Access Control List — listes de contrôle d’accès HDFS

Table 10.1 – Glossaire des termes techniques

19