Le document analyse l'évolution des architectures Big Data influencées par le data mining, soulignant l'importance des paradigmes de traitement des données, notamment MapReduce et Hadoop, pour gérer la montée en volume, variété et vitesse des données. Il évoque également l'émergence de nouvelles solutions comme Apache Spark, qui répondent mieux aux besoins des algorithmes de datamining. Enfin, le texte questionne les implications de ces évolutions sur les pratiques des statisticiens et les performances des modèles analytiques.

1. COMMENT LE DATA MINING A
INFLUENCÉ L’ÉVOLUTION DES
ARCHITECTURES BIG DATA ?
JULIEN BLAIZE
Product Manager SPAD
07/04/2016

2. COHERIS - EDITEUR DE SOLUTIONS
CRM & BUSINESS ANALYTICS
CA 2014
14.6 M€
147
collaborateurs
86 PAYS
+1000 CLIENTS LEADERS SUR LEUR MARCHÉ
22 %
investi en R&D
Cotée sur Euronext
25 %
à l’international
Label Entreprise Innovante
Lauréat Trophée de l’innovation Big Data 2015
2

3. 1 PARLONS INFORMATIQUE
2 PARLONS STATISTIQUE
3 ET ÇA CHANGE QUOI POUR MOI ?
3

4. PARLONS INFORMATIQUE
1
4

5. PARADIGMES D’ACCÈS AUX DONNÉES
 Données partagées
 Les données sont stockées dans un endroit unique
 Plusieurs processeurs accèdent à la même RAM/au même disque en parallèle
 Les processeurs échangent des données dans la RAM/le disque
 Exemple : fonctionnement de votre ordinateur personnel multi-cœurs
 Données distribuées
 Un réseau d’ordinateurs qui travaillent ensemble
 Les données sont réparties entre les machines
 Les machines échangent des messages par le réseau
 Exemple : le projet SETI qui recherche les extras-terrestre en utilisant les
ordinateurs personnels (SETI@home).
5

6. CONSTAT BIG DATA
 Les 3 V
 Volume : de plus en plus de données
 Vitesse : les données changent de plus en plus rapidement
 Variété : de multiples formes nouvelles de données apparaissent
 Explosion du volume des données, elles ne peuvent plus être stockées sur
une seule machine.
 On ne peut plus utiliser le paradigme des données partagées
 Si on utilise le paradigme des données distribuées on fait voyager de plus en
plus de données sur le réseau jusqu’à saturation.
 Il faut trouver une alternative
6

7. 2 IDÉES NOVATRICES ET COMPLÉMENTAIRES
 Jeffrey Dean et Sanjay Ghemahat (2004, Google)
 Plutôt que de déplacer les données par le réseau, déplaçons le code
 Création du framework Map/Reduce (Inspiré de LISP)
 Simplifie le développement d’applications massivement parallèles.
 Doug Cutting et Michael J. Cafarella (2006, Apache)
 Travaillent sur Nutch et créent un système de fichiers distribués (NDFS).
 Après la publication de Dean et Ghemahat, ils créent Hadoop qui permet de faire
fonctionner des applications Map/Reduce sur leur système de fichiers distribués.
 NDFS devient HDFS (Hadoop Distributed File System)
 Hadoop : une solution accessible à tous pour traiter le V de Volume.
7

8. FONCTIONNEMENT DE MAP/REDUCE
M1
M2
M3
Code
R1
R2
i1
i2
i3
o1
o2
a
b
c
d
Données
en entrée Mappers Reducers
Copie du code
Données
en sortie
HDFS Cluster de machines
rd1
rd2
Shuffle
8

9. EXEMPLE SIMPLISTE (1/2)
 Calcul de la moyenne en Map/Reduce
 On veut calculer la moyenne du salaire des hommes et celui des femmes
 C’est simple à paralléliser car on peut faire une moyenne de moyennes
 Les statistiques nécessaires sont la moyenne et le poids des individus
M1
M2
R1
R2
♂[µ;30]
♀[µ;42]
♂[µ;22]
♀[µ;18]
♂[µ;52]
♀[µ;60]
30 ♂
42 ♀
♂[µ;30]
♂[µ;22]
♀[µ;42]
♀[µ;18]
22 ♂
18 ♀
9

10. EXEMPLE SIMPLISTE (2/2)
 Calcul de la médiane en Map/Reduce
 Traditionnellement on a besoin d’avoir tous les individus triés
 On ne peut pas agréger facilement des médianes
 Quelle sont les statistiques nécessaires ?
 Conclusion
 Certains algorithmes sont évidents à programmer en mémoire distribuée
 D’autres algorithmes demandent beaucoup plus de travail.
10

11. PARLONS STATISTIQUES
2
11

12. APACHE MAHOUT
 Une librairie dédiée à l’écriture d’algorithmes pour Hadoop. ( depuis 2008)
 Bénéficient de Map/Reduce:
 Filtrage collaboratif
 Bayésien naïf
 Forêt aléatoire
 ACP (fait avec une SVD stochastique)
 Streaming K-means (Shingler et al)
 Latent Dirichlet Allocation
 …
 Fonctionnent dans l’architecture mais sur une seule machine (échec ?)
 Régression logistique (par SGD)
 Perceptron multicouches
 …
12

13. NAISSANCE D’UNE ALTERNATIVE
“RDDs are motivated by two types of applications that current
computing frameworks handle inefficiently: iterative algorithms and
interactive data mining tools.” (M. Zaharia et al, Berkeley)
 RDD : Resilient Distributed Datasets
 Des données distribuées que l’on peut accéder « presque » comme des données
partagées.
 On ne doit plus adapter les algorithmes de datamining à Map/Reduce mais
on adapte la lecture des données aux besoins des algorithmes.
13

14. QUELLE DIFFÉRENCE AVEC HADOOP ?
P1 tmp1input P2 tmp1 P2 output
P1input P2 P2 output
 Les algorithmes se compose de tâches qui s’enchainent et réutilisent les
résultats intermédiaires précédents
 Hadoop stocke les résultats intermédiaires sur disque
 Spark utilise un cache pour accélérer les traitements= In Memory
14

15. SPARK
 Promesse d’un gain de performance jusqu’à X100
 Librairie Mlib dédié au machine learning.
 Librairie GraphX pour l’analyse de Graph.
 Plus d’algorithmes déjà disponible dans Mlib que dans Mahout qui a
commencé avant.
 Aujourd’hui un des projets open-source les plus actifs dans le monde du Big
Data.
15

16. SYNTHÈSE
 Les avancées portées par les informaticiens dans le monde du Big Data ont
apporté un premier lot d’outils aux statisticiens avec Map/Reduce et
Hadoop. Mais tous les algorithmes ne pouvaient pas être adaptés.
 Spark qui s’adapte mieux aux besoins des algorithmes de datamining
marque une nouvelle avancée importante.
 Comment ces outils modifient ils notre façon de travailler ?
16

17. ET ÇA CHANGE QUOI POUR MOI ?
3
17

18. QUELS GAINS POUR LES STATISTICIENS ?
 Quelques gains évidents de la parallélisation et de Map/Reduce.
 Nous pouvons facilement paralléliser l’application d’un modèle déjà construit sur un
échantillon.
 Si on peut construire un modèle sur 1 seule machine on peut faire la validation
croisée en parallèle sur d’autres machines.
 Recherche plus rapide des paramètres optimaux d’une méthode.
18

19. ÉVOLUTION DES OUTILS (1/2)
 J’ai un outil habituel pour mes besoins de datamining
 J’ai accès à un entrepôt Big Data Hadoop sur lequel j’ai installé Spark.
 Comment faire tourner mes algorithmes R sur les données Big Data ?
 Il y a des solutions payantes (vous les trouverez facilement)
 Il existe R Map/Reduce ou SparkR (R on Spark).
 Il est possible de programmer en Scala, Java, Python,… directement dans Spark.
 Par exemple SPAD Par exemple SPAD R (je suis pas là pour faire de la pub)
19

20. ÉVOLUTION DES OUTILS (2/2)
 On a alors le choix des algorithmes
 1 - Ceux inclus dans l’architecture Big Data installée (par ex :Mahout ou Spark).
 2 - Ceux de l’outil (ici R) qui tourneront probablement sur un seul nœud du cluster et
sur un échantillon.
 3 - Développer nous-mêmes nos fonctions Map/Reduce … ?
 Le commun des mortels ira vers le choix 1.
20

21. EXEMPLE : UNE TYPOLOGIE
 Mise en classes des continues
 Analyse des Correspondances
Multiples
 Kmeans sur les individus pour
obtenir une sous population pour
ma CAH (par ex : 200 points)
 Classification Ascendante
Hiérarchique
 Description des classes de la
CAH
 Mise en classes des continues
Outil classique Spark
 Ah non, finalement une ACP
stochastique et abandon des
nominales
 Kmeans sur les individus pour
obtenir une sous population pour ma
CAH (par ex : 200 points)
 Pas de CAH du coup seulement
Kmeans
 Description des classes des Kmeans
(inutile)
(inutile)
21

22. SYNDROME DE L’AUTOROUTE
 Le volume des données et l’architecture utilisée pour le gérer doivent ils
restreindre nos possibilités ?
 On va vite vers un endroit habituel et connu de tous.
 On prend le temps de chercher et on peut trouver des choses intéressantes.
22

23. PROBLÈME DE LA BOITE NOIRE
 Une grande partie des algorithmes implémentés dans ce type de Framework
sont beaucoup plus complexes à interpréter.
 Méthodes stochastiques
 Méthodes ensemblistes (Forêts aléatoires plutôt qu’Arbre de décision)
 Doit-on faire le choix de la qualité d’un modèle au détriment de son
interprétation ?
 Comment critiquer ou comparer la pertinence de résultats dont on ne pourra
pas expliquer le calcul ?
23

24. EN CONCLUSION
 Les besoins spécifiques du datamining prennent de l’importance dans les
architectures Big Data et deviennent un moteur d’innovation.
 Il est déjà possible d’analyser des données Big Data et les ajouts de
méthodes connues dans ces architectures est rapide.
 Il ne tient qu’à nous éditeurs ou chercheurs de contribuer plus.
 Il faut garder un œil critique sur le véritable besoin d’utiliser l’ensemble des
données.
 Un échantillon peut-il donner d’aussi bons résultats ?
 Le 2éme V (Vitesse) du Big Data nous laisse penser que les données analysées sont
de toute façon un échantillon de ce que l’on aura dans 1 mois, 1 semaine.
24

25. BIBLIOGRAPHIE
 Map-Reduce for Machine Learning on Multicore (C. T. Chu et al)
 Fast and Accurate k-Means For Large Datasets (Shindler et al)
 Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory
Cluster Computing (M. Zaharia et al)
 https://en.wikipedia.org/wiki/Apache_Hadoop
 https://blogs.msdn.microsoft.com/big_data_france/2013/03/25/vous-avez-
dit-hadoop-1re-partie/
25

26. VOTRE CONTACT : JULIEN BLAIZE
E-MAIL : JBLAIZE@COHERIS.COM
WWW.COHERIS.COM
COHERIS, 4, RUE DU PORT AUX VINS- 92 150 SURESNES
26