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).
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.
Un repère historique souvent cité est la formalisation des « 3V » (Volume, Velocity, Variety), renvoyant à une note de recherche publiée en février 2001 : “3-D Data Management: Controlling Data Volume, Velocity and Variety”. Source
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.
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
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
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
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
Le « disque dur » de l’entreprise devient un service. On peut enfin imaginer stocker beaucoup de données brutes (sans tout modéliser à l’avance), puis décider plus tard comment les exploiter.
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
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
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
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.
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
L’histoire récente montre plutôt une convergence : on garde la flexibilité du lake (formats variés, stockage objet) tout en récupérant des garanties de type warehouse (SQL performant, transactions, gouvernance).
| Année | Événement | Pourquoi c’est important |
|---|---|---|
| 2001 | Note « 3V » (Volume, Velocity, Variety) popularisée par Doug Laney | Cadre simple pour expliquer l’émergence Big Data |
| 2003 | Publication GFS (SOSP’03) | Stockage distribué tolérant aux pannes |
| 2004 | Publication MapReduce (OSDI 2004) | Calcul parallèle « industrialisé » |
| 2006 | Annonce Amazon S3 (13 mars 2006) | Stockage objet cloud à l’échelle du web |
| 2008 | Hadoop devient top-level project Apache (janvier 2008) | Standardisation open source et adoption massive |
| 2010 | Terme « data lake » (octobre 2010) | Stocker brut + usages futurs inconnus |
| 2011 | Kafka incubator Apache (juillet 2011) + premières releases Apache | Streaming / pipelines temps réel |
| 2013 | Annonce Parquet 1.0 | Optimisation analytique (format colonne) |
| 2019 | Open source de Delta Lake | ACID + versioning : pas vers le « lakehouse » |
Sources : 3V Source, GFS Source, MapReduce Source, S3 Source, Hadoop Source, Data lake Source, Parquet Source, Delta Lake Source, Kafka Source
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
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
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
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
