Architecture data • Culture tech • Big Data

Histoire et évolution de la Big Data : des bases de données aux data lakes

La Big Data n’est pas née d’un coup : c’est une succession de ruptures techniques et d’usages. On passe du SGBDR (transactions) au data warehouse (analytique), puis aux architectures « web-scale » (stockage distribué, calcul parallèle), jusqu’au data lake (stockage massif, multi-formats) et au lakehouse (fiabilité + SQL).

Public : data analysts, data engineers, décideurs Lecture : 10–15 min Objectif : comprendre « pourquoi » les data lakes ont émergé

1) Avant la Big Data : l’âge d’or des bases de données (SGBDR)

Pendant des décennies, le modèle dominant pour stocker et interroger des données a été la base de données relationnelle : des tables, des schémas stricts, des transactions ACID, et des requêtes SQL. C’est excellent pour la gestion opérationnelle (paiements, commandes, CRM), où la cohérence est cruciale.

Le problème ? À mesure que les organisations deviennent numériques, les volumes explosent, les formats se diversifient (logs, clics, fichiers, texte, images), et les données arrivent plus vite que la capacité des architectures classiques à absorber et transformer.

2) Data warehouse : la réponse « analytique » des années 1990–2000

Avant l’arrivée des data lakes, la stratégie la plus courante consistait à extraire les données des systèmes métiers, à les transformer (ETL), puis à les charger dans un data warehouse optimisé pour l’analyse. Cette approche structure la donnée en amont pour simplifier l’exploration (BI, reporting).

Mais l’industrialisation du web et des services à grande échelle a changé l’équation : on veut conserver plus de données brutes, itérer plus vite, répondre à des questions non prévues à l’avance, et supporter des workloads massifs.

3) Rupture « web-scale » : stockage distribué et calcul parallèle

Google File System : stocker « énorme » sur des machines ordinaires

Au début des années 2000, les entreprises web doivent stocker et traiter des quantités de données inédites. Google publie en 2003 un papier fondateur sur le Google File System (GFS), présenté à SOSP’03 (octobre 2003). L’idée : un système de fichiers distribué, pensé pour la tolérance aux pannes et la scalabilité sur du matériel standard. Source

MapReduce : traiter en parallèle sur des clusters

En 2004, le modèle de programmation MapReduce est présenté (OSDI 2004) pour simplifier le traitement distribué : on « mappe » (transforme) puis on « réduit » (agrège) sur des milliers de machines, tout en masquant la complexité (pannes, partitionnement, ordonnancement). Source

4) L’open source industrialise : Apache Hadoop

Hadoop popularise dans l’écosystème open source des idées proches de GFS/MapReduce, rendant le « big data processing » accessible à un grand nombre d’entreprises, sans être Google.

Le projet prend une ampleur institutionnelle quand Hadoop devient un top-level project Apache en janvier 2008 (sortie de Lucene, création du PMC), ce qui stabilise sa gouvernance et accélère son adoption. Source

5) Le cloud change la donne : Amazon S3 et le stockage objet

Si Hadoop a longtemps été associé à HDFS on-premise, la montée du cloud rend le stockage massif plus simple : on loue une capacité quasi infinie, sans gérer de disques ni de serveurs.

Un jalon clé est l’annonce d’Amazon S3 (Simple Storage Service), publiée le 13 mars 2006. S3 formalise le stockage objet « à l’échelle du web » : déposer, récupérer, et conserver des volumes massifs, à la demande. Source

6) Naissance du concept : Data Lake

En octobre 2010, James Dixon (Pentaho) introduit l’expression « data lake » pour décrire une solution où les données arrivent « dans un état plus naturel » (moins emballé et agrégé qu’un datamart), afin de servir des usages multiples, dont certains inconnus à l’avance. Il oppose l’image du datamart (« eau en bouteille ») au data lake (« grand plan d’eau »). Source

Ce que le data lake promet

• Stocker beaucoup (souvent sur stockage objet)
• Accepter plusieurs formats (CSV, JSON, Parquet, logs, images…)
• Servir plusieurs équipes (BI, data science, produit, conformité)

Ce qu’il risque (si mal conçu)

• Un « data swamp » (données ingérables, qualité faible)
• Des coûts de requête/scan élevés
• Une gouvernance difficile (catalogue, traçabilité, accès)

7) L’optimisation analytique : formats colonnes et métadonnées

Parquet 1.0 : le format colonne devient un standard de fait

Pour analyser de gros volumes, lire « colonne par colonne » est souvent plus efficace que « ligne par ligne ». Parquet devient un format pivot : il améliore la compression, limite les lectures inutiles, et accélère les moteurs analytiques. L’annonce de Parquet 1.0 (Twitter Engineering) marque un jalon en 2013. Source

8) Le temps réel : streaming et files de messages

Les architectures « batch only » (MapReduce) ne suffisent plus quand les entreprises veulent réagir vite : fraude, recommandation, monitoring, alerting… Les pipelines deviennent hybrides (batch + streaming).

Côté streaming, Kafka s’impose comme une brique majeure. LinkedIn annonce notamment une « first Apache release » de Kafka (0.7.0) et rappelle que Kafka est entré dans l’Apache incubator en juillet 2011. Source

9) Vers le « lakehouse » : fiabiliser le data lake (ACID, versioning)

Le data lake a un défaut historique : il est facile d’y déposer des fichiers, mais difficile d’y garantir la qualité, la cohérence, les mises à jour, et une gouvernance robuste. Résultat : on réintroduit des mécanismes « type base de données » au-dessus du stockage objet.

Delta Lake : quand le lac gagne des garanties

En avril 2019, Databricks annonce l’open source de Delta Lake : une couche de stockage qui vise à rendre les data lakes plus fiables (transactions ACID, contrôle de concurrence, versioning / time travel, gestion de schéma…). C’est l’une des briques emblématiques du mouvement « lakehouse ». Source

10) Timeline express (repères historiques)

Sources : 3V Source, GFS Source, MapReduce Source, S3 Source, Hadoop Source, Data lake Source, Parquet Source, Delta Lake Source, Kafka Source

FAQ

Pourquoi dit-on que la Big Data est une « rupture » et pas juste « plus de données » ?

Parce qu’elle impose de nouveaux compromis : tolérance aux pannes, calcul distribué, stockage objet, formats colonnes, gouvernance et contrôle des coûts à grande échelle. Les 3V (volume, vélocité, variété) sont un bon résumé historique. Source

Data lake : faut-il stocker « tout » en brut ?

Stocker brut est utile pour ne pas « tuer » des cas d’usage futurs, mais il faut une gouvernance (catalogue, qualité, droits). L’idée du data lake est justement d’accueillir des usages inconnus à l’avance, sans se limiter à un datamart pré-agrégé. Source

Pourquoi Parquet est-il si important ?

Parce qu’il rend les requêtes analytiques plus efficaces (lecture colonne, compression, skipping), ce qui réduit coûts et latence sur de grands volumes. Source

Qu’est-ce qui a « cassé » les premiers data lakes ?

L’absence de garanties (écritures concurrentes, qualité, schéma, mises à jour, traçabilité) et la multiplication des fichiers. Des projets comme Delta Lake ont explicitement ciblé ces limites (ACID, versioning, schéma, etc.). Source

Sources

• 3V / définition Big Data — Doug Laney : Source
• Google File System (SOSP’03) : Source
• MapReduce (OSDI 2004) : Source
• Annonce Amazon S3 : Source
• Apache Hadoop (top-level project 2008) : Source
• Origine du terme « Data Lake » : Source
• Annonce Parquet 1.0 : Source
• Open source de Delta Lake : Source
• Kafka : première release Apache & incubator (LinkedIn) : Source