Les informations concernant l’organisation et le déroulement de l’unité d’enseignement RCP216 « Ingénierie de la fouille et de la visualisation de données massives » au Cnam se trouvent dans ce préambule.

Cours - Introduction

Supports complémentaires :

[Diapositives du cours : 2 par page] [Diapositives du cours : 1 par page]

La fouille de données peut être définie comme le « Processus d’extraction non triviale d’informations implicites, inconnues auparavant et potentiellement utiles (sous forme de règles, contraintes, régularités) à partir de données issues de bases de données » (Gregory Piatetsky-Shapiro). Si ce domaine est loin d’être nouveau, c’est seulement depuis quelques années que les praticiens se confrontent à de nouvelles difficultés liées à une augmentation significative du volume de données. Cette augmentation a été dans certains cas bien plus rapide que la croissance continue des capacités de calcul et de stockage des serveurs individuels, les volumes résultants étant alors incompatibles avec un traitement centralisé. On parle alors en général de « données massives » (big data).

Ce cours n’est pas une introduction à la fouille de données en général : nous supposons que vous connaissez déjà les méthodes classiques (forêts aléatoires, régression logistique, réseaux de neurones, etc.) et que vous avez suivi un enseignement sur les bases de données documentaires et distribuées. Notre sujet est plutôt le passage à l’échelle de la fouille de données : comment traiter des volumes qui dépassent les capacités d’une seule machine ? Comment tirer parti efficacement d’architectures multi-cœur ou distribuées ? Comment adapter les algorithmes aux nouvelles contraintes imposées par les données massives ?

Pourquoi les données massives ?

Les défis : volume, variété, vélocité

Dans un rapport de 2001 [Lan01] le META Group (actuellement Gartner) formulait ce qui est devenu le cadre de référence pour caractériser les données massives, les 3V : volume, variété, vélocité.

  • Le volume indique l’augmentation des quantités de données stockées et traitées, augmentation qui, dans certains domaines, a été bien plus rapide que la progression des capacités des serveurs individuels. À titre indicatif, quelques ordres de grandeur actuels :

    • Un moteur d’avion de ligne génère environ 1 To de données par heure de vol (capteurs de vibration, de température, de pression, etc.) ;

    • Le télescope spatial Rubin Observatory produit environ 20 To de données astronomiques par nuit d’observation ;

    • Les grandes plateformes de streaming vidéo ingèrent plusieurs centaines de Po de contenu au total ;

    • À l’échelle mondiale, le volume de données créées et consommées a dépassé 100 Zo (zettaoctets) en 2023 selon les estimations de l’IDC.

  • La variété correspond au fait que les données massives ne se présentent plus simplement sous forme de tables relationnelles. On trouve une grande diversité de formats : semi-structurés (XML, JSON), non structurés (textes, images, vidéo, audio), ou issus de capteurs. Cette diversité exige des méthodes de prétraitement et de fouille adaptées, souvent spécifiques à chaque type de données.

  • La vélocité signifie que dans de nombreux cas les nouvelles données arrivent en flux continu et doivent être traitées en temps réel ou avec une latence très faible, comme par exemple pour la détection de fraude bancaire, le pilotage industriel ou la recommandation en ligne.

À ces 3V s’ajoutent souvent d’autres caractéristiques : la véracité (qualité et fiabilité des données, présence de bruit, d’erreurs, de données manquantes), la valeur (le retour sur investissement attendu du traitement), la visibilité (la capacité à extraire des connaissances exploitables), etc.

Une caractéristique à ne pas négliger est la faible densité en information : dans de nombreux jeux de données massives, l’information utile est « diluée » dans un très grand nombre d’observations et de variables ; un travail d’analyse et modélisation réalisé sur un échantillon trop petit ou sur une sélection trop restreinte de variables a peu de chances de donner de bons résultats.

Quelques domaines d’application

Pour mieux illustrer la diversité et la portée des problèmes que traite ce cours, voici quelques domaines d’application emblématiques.

Commerce en ligne et recommandation. Des plateformes comme Amazon ou Netflix collectent en permanence des traces d’interaction (clics, achats, évaluations) de centaines de millions d’utilisateurs sur des millions de produits ou de contenus. Le filtrage collaboratif à large échelle permettent de personnaliser les recommandations en temps quasi-réel. Nous étudierons ces méthodes dans un chapitre spécifique.

Santé et bioinformatique. Le séquençage génomique produit des données de très haute dimension (des millions de positions sur le génome) pour chaque individu. L’analyse de cohortes de patients nécessite de fouiller des millions de dossiers médicaux dont les contenus mélangent données textuelles et structurées. Les méthodes de réduction de dimension, d’encodage de texte et d’apprentissage à grande échelle sont indispensables.

Réseaux sociaux et graphes du web. Facebook, X (ex-Twitter) ou LinkedIn gèrent des graphes de plusieurs milliards de nœuds (utilisateurs) et de dizaines de milliards d’arêtes (liens). L’analyse de ces graphes — détection de communautés, calcul de centralités, propagation d’influence — requiert des algorithmes distribués spécifiques étudiés dans un chapitre de ce cours.

Villes intelligentes et IoT. Des réseaux de capteurs urbains (trafic, qualité de l’air, consommation énergétique) génèrent des flux continus de données qui doivent être traités en temps réel pour piloter des systèmes de régulation. Ces problèmes relèvent à la fois des approches de traitement de flux et de la visualisation, qui seront abordés dans un chapitre du cours.

Traitement automatique des langues à grande échelle. L’entraînement de grands modèles de langue (LLM) mobilise des corpus de plusieurs centaines de milliards de tokens et des milliers de GPU pendant des semaines. Même leur utilisation en inférence à grande échelle soulève des défis de passage à l’échelle. Nous examinerons les méthodes de fouille de textes et les LLM dans un chapitre spécifique.

Pour aller plus loin :

La note Analyse des big data. Quels usages, quels défis ? du Commissariat général à la stratégie et à la prospective, mise à jour en 2025, offre un panorama des enjeux économiques et sociaux des données massives avec de nombreux exemples concrets.

Sujet du cours

Nous nous intéressons dans ce cours aux trois défis mentionnés — volume, variété et vélocité — en insistant toutefois sur le premier. Nous verrons quelles sont les approches actuelles pour faire passer à l’échelle la fouille de données et étudierons plus longuement les opérations de fouille en environnement distribué. Nous aborderons dans ce contexte certains problèmes fréquents dans la fouille de données massives. Enfin, nous examinerons le rôle de la visualisation et de l’interaction, non seulement dans la présentation des résultats mais aussi lors des opérations de fouille de données.

Dans le cadre de ce cours, par capacité à « passer à l’échelle » (scalability) nous entendons la capacité à faire face à une augmentation forte du volume de données à traiter. Il faut remarquer que la notion de « passage à l’échelle » est plus large et, même dans un contexte de données massives, peut concerner d’autres aspects : capacité d’une méthode à traiter des données décrites par un très grand nombre de variables, capacité d’un outil à gérer des données malgré leur hétérogénéité, etc.

Approches pour passer à l’échelle

Face à un volume de données qui dépasse les capacités d’une architecture centralisée classique, deux grandes familles d’approches sont possibles : réduire le travail à faire (sans distribuer les calculs), ou distribuer les données et les calculs sur plusieurs unités de traitement. Ces deux familles ne sont pas exclusives et peuvent être combinées.

Approches sans distribution

Lorsque les données tiennent — après un traitement préliminaire — sur une seule machine, il peut être suffisant (et plus simple) de rester dans un cadre non distribué tout en cherchant à réduire le volume de travail ou à utiliser plus efficacement les ressources disponibles (mémoire, cœurs de processeur). Trois familles de méthodes sont envisageables.

1. Réduction du volume de données. Une première approche consiste à travailler sur un sous-ensemble représentatif des données. L”échantillonnage (tirage aléatoire simple, stratifié, en grappes) réduit le nombre d’observations traitées. La réduction de dimension (analyse en composantes principales, analyse factorielle discriminante, etc.) réduit le nombre de variables. Ces méthodes produisent en général des approximations des résultats que l’on obtiendrait sur les données complètes. Leur principal risque est la perte d’information lorsque les données présentent une faible densité en information : un échantillon trop petit ou un espace de représentation trop restreint peuvent rendre les régularités indétectables ou les performances prédictives insuffisantes. Nous étudierons ces méthodes en détail dans le chapitre suivant.

2. Réduction de l’ordre de complexité. Une seconde famille de méthodes travaille sur toutes les données mais exploite leurs caractéristiques de similarité pour diminuer le nombre d’opérations à réaliser. Par exemple, grâce à des structures d’index, on peut parfois passer de \(O(N^2)\) à \(O(N \log N)\) pour une recherche des plus proches voisins, \(N\) étant le nombre total de données. Le hachage sensible à la similarité (Locality Sensitive Hashing, LSH) et les bases de données vectorielles (vector databases) sont mises en œuvre dans ce type d’approche. Ces méthodes sont toutefois moins efficaces lorsque le nombre de dimensions est très élevé (malédiction de la dimension). Nous les étudierons dans le troisième chapitre.

3. Calcul plus efficace sur une seule machine. Même sans réduire la taille des données, il est possible d’accélérer significativement les traitements en utilisant des bibliothèques optimisées par rapport à Pandas et NumPy, capables d’exploiter le parallélisme multi-cœur et de minimiser les copies mémoire inutiles. Deux bibliothèques Python se distinguent actuellement :

  • Polars est une bibliothèque DataFrame écrite en Rust, qui utilise des représentations en colonnes (columnar format, Apache Arrow) et parallélise automatiquement les opérations sur tous les cœurs disponibles. Sur de nombreux jeux de données, Polars est 5 à 10 fois plus rapide que Pandas pour des opérations classiques de filtrage, d’agrégation ou de jointure.

  • Dask est une solution Python native qui étend les API NumPy et Pandas à des données qui ne tiennent pas entièrement en mémoire, en découpant les calculs en tâches exécutées en parallèle sur les cœurs disponibles ou, le cas échéant, sur un cluster. Dask permet ainsi de traiter des données dont la taille dépasse la mémoire vive d’une seule machine, tout en restant dans un cadre de programmation familier.

Ces outils seront présentés dans le troisième chapitre et utilisés dans des travaux pratiques.

Approches distribuées

Lorsque le volume de données est tel qu’une seule machine — même après optimisations — ne suffit plus, la solution préférée à partir des années 2010 consiste à distribuer données et calculs sur un nombre élevé d’ordinateurs standardisés, plutôt bon marché, chacun avec son propre stockage de masse, reliés par un réseau local haut débit standard pour former un cluster.

Principe général

La distribution des données et des calculs repose sur deux mécanismes fondamentaux, la réplication et le partitionnement des calculs.

Par la réplication, chaque fragment de données est stocké sur plusieurs nœuds du cluster afin de garantir la disponibilité des données en cas de panne d’un nœud de calcul. Sans réplication, la panne d’un seul nœud entraînerait une perte définitive des données qu’il hébergeait. Or, dans un cluster composé d’un grand nombre de nœuds, la probabilité de panne n’est plus négligeable [1].

Le partitionnement des calculs signifie que l’ensemble du travail est découpé en tâches élémentaires suffisamment fines pour pouvoir être réparties dynamiquement entre les nœuds disponibles. En cas de panne d’un nœud, les tâches qu’il devait réaliser sont simplement réaffectées aux autres nœuds actifs, sans qu’il soit nécessaire de reprendre l’ensemble du calcul depuis le début.

MapReduce : le modèle fondateur

Le modèle MapReduce, popularisé par Google puis implémenté dans le framework open source Hadoop, a été le premier mécanisme d’exécution distribuée à grande échelle. Il propose de décomposer tout traitement en deux types de tâches élémentaires et uniformes :

  • une tâche Map qui reçoit un fragment de données et produit une séquence de paires [clé, valeur] ;

  • une tâche Reduce qui reçoit, pour une clé donnée, l’ensemble des valeurs associées à cette clé par les différentes tâches Map, et les combine pour produire un résultat.

MapReduce : exécution d'un programme

Fig. 1 MapReduce : exécution d’un programme

Le programmeur n’écrit que les fonctions Map et Reduce ; le framework se charge de distribuer les données, d’affecter les tâches aux nœuds, de gérer les pannes et de collecter les résultats.

La hiérarchie de stockage joue un rôle important dans l’efficacité des traitements distribués. La figure suivante rappelle les ordres de grandeur des débits aux différents niveaux :

Hiérarchie de stockage

Fig. 2 Hiérarchie de stockage (issue de Communications of the ACM 2009 (8): 36-44)

On voit que l’accès à la mémoire vive est plusieurs ordres de grandeur plus rapide que l’accès au disque. Cette observation est au cœur des choix architecturaux de Spark par rapport à MapReduce, comme nous allons le voir.

Cette approche présente cependant une limite importante pour les algorithmes itératifs courants en fouille de données : le mécanisme de reprise sur panne impose que les résultats intermédiaires de chaque étape Reduce soient écrits sur disque avant de pouvoir être utilisés par l’étape suivante. Pour un algorithme comportant \(k\) itérations, cela engendre \(k\) aller-retours disque, avec un ralentissement considérable (voir la hiérarchie de stockage ci-dessus). Une séance entière de cours sera consacrée à MapReduce et à ses évolutions.

Spark : conserver les données en mémoire

Apache Spark a été conçu pour lever la limitation principale de MapReduce. Sa solution est de conserver les résultats intermédiaires en mémoire vive des nœuds de calcul, et de garder l’historique des opérations ayant permis de les produire. En cas de panne, l’historique permet de recalculer les données perdues à partir des dernières données encore disponibles, sans reprise depuis le début.

Cette approche procure une accélération de 10 à 100 fois par rapport à MapReduce classique sur les algorithmes itératifs. Elle repose sur les Resilient Distributed Datasets (RDD), des collections de données partitionnées et distribuées sur les nœuds, conservées autant que possible en mémoire. L’API plus récente de Spark s’appuie sur les Dataset/DataFrame, qui ajoutent un typage fort et un optimiseur de plans d’exécution (Catalyst).

Spark propose également des bibliothèques couvrant l’ensemble des besoins de la fouille de données massives : MLlib (apprentissage statistique), Spark Streaming / Structured Streaming (traitement de flux), GraphX / GraphFrames (calcul sur les graphes) et SparkNLP (traitement de la langue).

Ray et Dask en mode distribué

En dehors de Spark, deux autres plateformes méritent d’être mentionnées pour leurs capacités distribuées.

Dask, mentionné ci-dessus en mode mono-machine, peut également être déployé sur un cluster pour traiter des données qui dépassent la capacité d’une seule machine tout en conservant les API familières de Pandas et NumPy. Dask est généralement considéré comme plus facile à prendre en main que Spark pour les utilisateurs Python, mais moins adapté aux très grandes échelles.

Ray est développé en C++ depuis 2017, avec pour objectif la parallélisation d’algorithmes Python, et est utilisé entre autres par OpenAI. Ray propose un modèle de parallélisme plus général que Spark, fondé sur trois primitives : Task (fonction sans état), Actor (instance avec état) et Object (donnée). Il est particulièrement adapté à l’entraînement distribué de modèles prédictifs (y compris par apprentissage par renforcement) et au service de modèles en production. En revanche, le support des opérations relationnelles est plus limité dans Ray que dans Spark.

Le choix entre ces plateformes dépend de plusieurs facteurs : la taille des données, la nature des calculs (batch, streaming, itératif, apprentissage), la familiarité avec les API et la disponibilité d’un support commercial ou communautaire. Le tableau suivant donne un premier aperçu des principales bibliothèques/plateformes abordées dans ce cours. Un tableau comparatif plus complet, avec des critères supplémentaires, sera présenté à la fin du troisième chapitre. Nous remarquerons que ce domaine est en évolution rapide.

Tableau 1 Vue d’ensemble des principales bibliothèques/plateformes abordées dans ce cours

Pandas

Polars

Dask

Spark

Ray

Hadoop / MapReduce

Bases vectorielles

Distribution

Non

Non

Optionnelle

Oui

Oui

Oui

Variable

Multi-cœur

Non

Oui

Oui

Oui

Oui

Oui

Variable

API Python

Oui

Oui

Oui

Oui (PySpark)

Oui

Non natif

Oui

Données > RAM

Non

Partiel

Oui

Oui

Oui

Oui

Oui

Algorithmes itératifs

Oui

Oui

Oui

Très efficace

Très efficace

Lent (disque)

—

ML [2] intégré

Non

Non

Partiel

MLlib

Ray Train

Non

—

Facilité de prise en main

★★★★★

★★★★

★★★★

★★★

★★★

★★

★★★★

Point fort principal

Référence universelle

Rapidité mono-machine

Transition Pandas → distribué

Batch et ML distribués

ML distribué et RL [3]

Robustesse, maturité

Recherche par similarité

Contenu et objectifs de l’enseignement

Les objectifs de cet enseignement sont les suivants :

  • comprendre les approches de passage à l’échelle de la fouille de données ;

  • découvrir des outils permettant un traitement efficace sans distribution (Polars, Dask) ;

  • se familiariser avec Spark comme plateforme de référence pour l’exécution distribuée ;

  • mettre en œuvre des méthodes de fouille sur des données textuelles, des graphes et des flux ;

  • comprendre les principes et techniques de la visualisation de données et de graphes ;

  • prendre conscience des enjeux éthiques liés à la fouille de données massives.

Les travaux pratiques sont une mise en œuvre directe des notions vues en cours. Ils utilisent principalement Python, Spark (via PySpark), Polars, Dask, SparkNLP et GraphFrames. Ils peuvent être réalisés sur une plateforme JupyterLab de taille modeste, sans accès GPU. Les données manipulées en TP restent volontairement peu volumineuses : l’objectif est de comprendre les mécanismes plutôt que de les mettre en œuvre sur une infrastructure industrielle.

Le tableau suivant présente une vue synthétique de la progression du cours, séance après séance. Chaque séance de cours (2 heures) est suivie d’une séance de travaux pratiques (2 heures).

Tableau 2 Contenu du cours RCP216

Séance

Thème du cours

Travaux pratiques

1

Introduction : données massives, approches de passage à l’échelle, vue d’ensemble

Introduction à Python, NumPy, Matplotlib

2

Approches sans distribution : réduction de volume (échantillonnage, méthodes factorielles), calcul efficace avec Polars et Dask

Pandas et Polars ; visualisation pour données volumineuses

3

Calcul distribué : MapReduce, Spark (RDD, DataFrame, MLlib), Ray

Introduction à Spark, DataFrames Spark

4

Réduction de l’ordre de complexité : LSH, bases de données vectorielles

Comparaison Spark / Dask sur un problème de passage à l’échelle

5

Apprentissage statistique à large échelle : SVM linéaires, gradient stochastique distribué

Comparaison SVM, régression logistique, forêt aléatoire et réseau de neurones dans Spark

6

Données textuelles 1 : traitements classiques, TF-IDF, LSA, ESA, plongements lexicaux (Word2Vec, GloVe, FastText)

Introduction à SparkNLP ; utilisation de GloVe

7

Données textuelles 2 : Transformers, BERT, LLM

Comparaison GloVe vs BERT avec SparkNLP

8

Graphes 1 : définitions, propriétés, algorithmes fondamentaux

Chemins et centralités avec GraphFrames

9

Graphes 2 : détection de communautés

Fouille du graphe Medline

10

Visualisation de données : principes, perception, techniques de représentation et d’interaction

Visualisation de données volumineuses avec Plotly Dash / Dask

11

Visualisation de graphes : critères, algorithmes de spatialisation

Gephi et NetworkX sur Medline

12

Systèmes de recommandation : filtrage collaboratif, factorisation matricielle, graphes

Filtrage collaboratif par factorisation matricielle avec Spark

13

Flux de données : traitement de flux, Spark Streaming, Kafka

Traitement de flux avec Spark Streaming

14

Éthique 1 : équité, critères observationnels

Évaluation de modèle employant ou non des variables protégées

15

Éthique 2 : biais, détection et correction de l’iniquité

Estimation des variables protégées ; correction a posteriori d’un modèle

Références bibliographiques

De nombreuses références traitent les différents sujets abordés dans cet enseignement. Des références spécifiques sont données dans chaque séance de cours ou de TP. Nous listons ci-dessous quelques références couvrant des parties plus larges du contenu.

Sur la fouille de données massives :

Sur la visualisation de données et l’interaction :

  • Fry, B. Visualizing Data. O’Reilly. 2008.

  • Spence, R. Information Visualization: Design for Interaction. Prentice Hall. 2007.

  • Munzner, T. Visualization Analysis and Design. A K Peters / CRC Press, 2014.

[Lan01]

Laney, D. (2001). 3D Data Management: Controlling Data Volume, Velocity and Variety. META Group.