Ajout du Meetup Big Data & Machine Learning #1

Bon cette fois c'est un peu plus sale, mais je vais pas m'amuser à corriger toutes les saletés que me fait LibreOffice en export HTML.

Ajout du Meetup Big Data & Machine Learning #1
Bon cette fois c'est un peu plus sale, mais je vais pas m'amuser à corriger toutes les saletés que me fait LibreOffice en export HTML.
Geoffrey PREUD'HOMME
1 parent 27d3677c
Showing 1 changed file with 183 additions and 0 deletions Show diff stats
_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 3<sup>e</sup> 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._