Présentation sur le Big data écrite pour la session Méthodes et Logiciels de la SFDS.

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