diff --git a/_posts/2016-12-08-compte-rendu-meetup-big-data-machine-learning-1.markdown b/_posts/2016-12-08-compte-rendu-meetup-big-data-machine-learning-1.markdown new file mode 100644 index 0000000..54c910c --- /dev/null +++ b/_posts/2016-12-08-compte-rendu-meetup-big-data-machine-learning-1.markdown @@ -0,0 +1,183 @@ +--- +layout: post +title: "Compte-rendu Meetup Big Data & Machine Learning #1" +date: 2016-12-08 20:30:00 +0100 +author: "Geoffrey Preud'homme" +categories: machine-learning big-data meetup cr +--- + +# Meta + +Premier meet-up d’[une +série qui devrait avoir lieu tous les deuxièmes jeudi du mois](https://www.meetup.com/fr-FR/Lille-Big-Data-and-Machine-Learning-Meetup/), +où on parlera technique et fera des retours d’expérience. Les +organisateurs (dont un est prof en GIS à Polytech) sont contents de +faire ça et heureux de nous voir si nombreux. + +# Optimisation de YARN + +Retour d’expérience de quelqu’un qui a +travaillé pour [Wajam](https://www.wajam.com/), +un service qui récupère les données des réseaux sociaux pour en +faire des recommandations personnelles pertinentes. + +Pour faire ça ils utilisent un cluster +(c’est-à-dire un groupe d’ordinateurs physiques rassemblés au +même endroit physiquement) qui tourne sur [Hadoop](https://fr.wikipedia.org/wiki/Hadoop) +(permet de faire du calcul distribué, ici toutes les machines du +cluster contribuent à analyser les données des réseaux sociaux +pour en faire des recommandations). + +Sauf qu’un beau jour, problème, au lieu d’avoir +un flux de données entrant de 150 Go/jour, ils se retrouvent à +devoir traiter 300 Go/jour, et il n’y a plus de place pour rajouter +physiquement des machines au cluster. Ils commencent donc à analyser +avec [Cloudera](https://fr.wikipedia.org/wiki/Cloudera) comment se passe le traitement de données notamment la +répartition des tâches sur les machines qui est faite par le +logiciel [YARN](https://fr.wikipedia.org/wiki/Hadoop_YARN). +Ils se rendent compte de plusieurs choses : + +* Certaines tâches [reduce](https://fr.wikipedia.org/wiki/MapReduce) + échouaient deux fois avant de réussir au troisième essai. Cela + était dû au fait que seul 1 Go de mémoire vive était alloué + pour chaque bloc (une grosse tâche est découpée en plusieurs + petits blocs répartis sur le cluster) alors qu’il avait besoin + d’un peu plus (si ça marchait à la troisième fois, c’est + probablement grâce à la [préemption](https://fr.wikipedia.org/wiki/Multit%C3%A2che_pr%C3%A9emptif) + de YARN : au bout de deux échecs il autorise le bloc à manger + de la mémoire sur les autres blocs si ils ne l’utilisent pas) + +* La répartition des tâches était trop + calculée à partir de la mémoire disponible, et ne prenait pas en + compte le CPU qui parfois était jamais utilisé, parfois beaucoup + utilisé par plusieurs blocs ce qui ralentissait le traitement des + données + +* [Sqoop](https://fr.wikipedia.org/wiki/Apache_Sqoop), + permettant de transférer des données entre les BDD relationnelles + (MySQL ici) et HDFS (HaDoop FileSystem, système de fichiers + permettant la répartition « intelligente » des données + sur les machines du cluster) avait un quota par défaut pour limiter + le nombre de requêtes par unité de temps. + +* Les données envoyées à MySQL étaient + envoyées une par une, ce qui prenait un monstre à chaque + initialisation de requête. + +* Les outils n’étaient pas à jour. Du + coup ils rataient pas mal d’optimisation sur les différents + outils qu’ils utilisaient et en plus étaient tombés sur une + version de YARN avec un bug qui réduisait sans raison la capacité + de traitement. + +* Parmi les requêtes SQL, il y avait parfois + des « ORDER BY » qui n’étaient pas nécessaires et + ralentissaient considérablement le temps d’exécution + +* Certaines données étaient traitées même + quand il était sû à l’avance qu’elles ne seraient pas + pertinentes. Les « FILTER » sur les requêtes SQL c’est + une bonne idée. + +* Le « [mode + spéculation](https://fr.wikipedia.org/wiki/Ex%C3%A9cution_sp%C3%A9culative) » était activé. Ce mode pense qu’une + tâche peut potentiellement rater donc elle est lancée sur + plusieurs machines différentes et on prend les résultats de celle + qui finit en premier. Si c’est utile pour faire du traitement de + données en temps réel, ça gâche des ressources inutilement dans + ce contexte où si une tâche échoue ça ne coûte rien de la + relancer. + +* La « collocation de données » + n’était pas activée. Cet outil permet d’informer YARN de + l’emplacement physique de chaque machine afin de mettre les + données souvent utilisées ensemble physiquement côte à côte + pour réduire les temps d’accès. + +* Parfois, sur des machines à 64 Go de + mémoire vive, seuls 16 Go étaient déclarés et donc utilisés. + + +Après avoir corrigé tout ça, ils se sont rendu +compte qu’avec le même cluster, ils pouvaient traiter non plus 150 +Go mais 700 Go de données par jour, tout en ayant réduit les +ressources utilisées et les temps de calcul. Du coup pendant 3 ans +ils utilisaient 4 × trop de serveurs, d’électricité, +de climatisation etc. pour … rien. Tout ça pour 10 lignes de +configuration et de code modifiées. + +En plus de faire des économies, ça a leur a +permis de démystifier le fonctionnement du cluster, et du coup ils +n’hésitent pas à le redémarrer de temps en temps pour faire de +l’amélioration continue. + +# Retour sur Google Cloud Plateform + +Ce monsieur a d’abord travaillé chez SFR où +ils utilisaient comme pour Wajam des clusters de machines. +Aujourd’hui, il travaille pour La Redoute, où ils utilisent [Google Cloud +Plateform](https://cloud.google.com/) (c’est du cloud de 3e génération), qui +est un autre moyen de faire du traitement de données sur des grosses +tailles. + +C’est essentiellement « serverless », +c’est-à-dire que les serveurs sont créés et détruit en fonction +des besoins. On parle d’auto-scalabilité. Ce n’est pas forcément +utile pour les petits volumes de données (pour traiter un fichier de +120 lignes il va peut-être créer 120 machines), mais ça devient +intéressant pour de gros volumes. En effet, le genre de traitement +de données qui était fait sur un cluster en 3h peut être fait en +18 secondes avec GCP. + +Google Cloud Plateform propose [d’autres services](https://cloud.google.com/products/), qui requièrent pas ou peu de configuration ou de mise +en place : + +* Storage : stockage de fichier, qui du + coup est persistent comparé aux serveurs + +* Pub / Sub : Système de publication / + souscription qui permet de connecter les services ensembles de + manière asynchrone avec des évènements + +* Dataflow : Traitement de donnée en + temps réél + +* Dataproc : Cluster de machines sur + Hadoop à la demande + +* BigQuery : Permet de faire de + l’analyse sur des grosses quantité de données + +* App Engine : Permet d’héberger des + applications (site web, serveur de jeu…) + +* Machine Learning : Service de Machine + Learning _(malheurseuement il a pas dit grand-chose là dessus)_ + +* Datalog : + Service de log (journal de tout ce qui a été effectué) amélioré, + permettant ainsi d’analyser l’utilisation même de GCM + rapidement + +* … + +Les avantages sont +multiples : tout est beaucoup plus simple et plus rapide à +mettre en place, il y a plus de services disponibles qui n’auraient +pas été possibles avec un cluster, les performances sont clairement +meilleures, plus de maintenance de machines physique à faire, la +facturation est faite en fonction de ce qui est réellement utilisé +(ça peut être pratique quand on a pas besoin de faire du traitement +24h/24 par exemple). + +Les désavantages sont présents aussi : c’est probablement plus +cher d’utiliser ce service que de faire un cluster Hadoop à la main +avec du matériel de récup, et ça peut être un problème +d’externaliser les données sur un service indépendant pour des +données sensibles. + +_Il y a certainement d’autres arguments +contre, mais le monsieur insiste sur le fait que c’est juste son +avis. Essentiellement il n’y a pas de « le cloud c’est +mieux » ou « les clusters c’est la vie », ça +dépend du cas d’utilisation._ -- libgit2 0.21.2