COMMENT LE DATA MINING A INFLUENCÉ L’ÉVOLUTION DES ARCHITECTURES BIG DATA ?

JULIEN BLAIZEProduct Manager SPAD07/04/2016

2

COHERIS - EDITEUR DE SOLUTIONS CRM & BUSINESS ANALYTICS

CA 201414.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

3

1 PARLONS INFORMATIQUE

2 PARLONS STATISTIQUE

3 ET ÇA CHANGE QUOI POUR MOI ?

4

PARLONS INFORMATIQUE1

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).

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

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.

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éesen sortie

HDFS Cluster de machines

rd1

rd2

Shuffl

e

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 ♀

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.

11

PARLONS STATISTIQUES2

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 …

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.

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

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.

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 ?

17

ET ÇA CHANGE QUOI POUR MOI ?3

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.

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)

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.

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)

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.

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 ?

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.

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/

26

VOTRE CONTACT : JULIEN BLAIZE

E-MAIL : JBLAIZE@COHERIS.COM

WWW.COHERIS.COMCOHERIS, 4, RUE DU PORT AUX VINS- 92 150 SURESNES