← TravauxProjet d'ingénierie de données · scénario simulé
Un data lake open source à la manière d'AWS, de l'objet brut à la table partitionnée
MinIO compatible S3, traitement distribué PySpark, Parquet, chargement PostgreSQL partitionné et contrôles Great Expectations — dimensionné pour environ un million de transactions simulées par jour.
- Rôle
- Conception et réalisation
- Période
- 2025
- Statut
- Volumétrie simulée — pas un débit mesuré en production
- Outils
- PySparkMinIOParquetPostgreSQLGreat Expectations
01Vue d'ensemble
Construire, avec des briques open source, l'équivalent d'un data lake AWS pour des transactions bancaires : stockage objet, traitement distribué, formats colonne, chargement partitionné et contrôle qualité.
Projet d'ingénierie de données sur un scénario simulé.
Ce que j'ai fait personnellement
- 01Conçu et réalisé le pipeline de bout en bout.
02Contraintes
- Tout en local et open source, compatible avec les services managés équivalents.
03Architecture
- 01
Brut
MinIO, compatible S3.
- 02
Traitement
PySpark, sortie en Parquet.
- 03
Service
PostgreSQL partitionné.
- 04
Contrôle
Great Expectations à chaque étape.
Couches du data lake.
04Décisions d'implémentation
- 01
Séparer les couches
Brut, nettoyé et agrégé restent distincts : on peut rejouer n'importe quelle étape.
05Difficultés
Dire « simulé »
Le pipeline est dimensionné pour environ un million de transactions par jour : c'est un objectif de conception, pas un débit mesuré en production.
06Évaluation
Contrôles Great Expectations sur schémas et valeurs, sur données générées.
07Résultats
- Une architecture data lake complète et reproductible en local.
08Ce que j'en retiens
- 01Des contrats de données explicites rendent un pipeline maintenable.
09Preuves
