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

Présentation au sujet: "COMMENT LE DATA MINING A INFLUENCÉ L’ÉVOLUTION DES ARCHITECTURES BIG DATA ? JULIEN BLAIZE Product Manager SPAD 07/04/2016."— Transcription de la présentation:

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 1PARLONS INFORMATIQUE 2PARLONS STATISTIQUE 3ET Ç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 LL es 3 V VV olume : de plus en plus de données VV itesse : les données changent de plus en plus rapidement VV ariété : de multiples formes nouvelles de données apparaissent EE xplosion du volume des données, elles ne peuvent plus être stockées sur une seule machine. OO n ne peut plus utiliser le paradigme des données partagées SS i 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. II l 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 M1M1 M2M2 M3M3 Code R1R1 R2R2 i1 i2 i3 o1 o2 a b c d Données en entrée MappersReducers 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 M1M1 M2M2 R1R1 R2R2 ♂ [µ;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 ? P1P1 tmp1input P2P2 tmp1 P2P2 output P1P1 input P2P2 P2P2 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 classiqueSpark  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) 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://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 SURESNESJBLAIZE@COHERIS.COM WWW.COHERIS.COM 26