Commit 55b7d8263ced0204ed9333cd0b141ab268889a43

Authored by Geoffrey PREUD'HOMME
1 parent 27d3677c

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.
_posts/2016-12-08-compte-rendu-meetup-big-data-machine-learning-1.markdown 0 → 100644
... ... @@ -0,0 +1,183 @@
  1 +---
  2 +layout: post
  3 +title: "Compte-rendu Meetup Big Data & Machine Learning #1"
  4 +date: 2016-12-08 20:30:00 +0100
  5 +author: "Geoffrey Preud'homme"
  6 +categories: machine-learning big-data meetup cr
  7 +---
  8 +
  9 +# Meta
  10 +
  11 +Premier meet-up d’[une
  12 +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/),
  13 +où on parlera technique et fera des retours d’expérience. Les
  14 +organisateurs (dont un est prof en GIS à Polytech) sont contents de
  15 +faire ça et heureux de nous voir si nombreux.
  16 +
  17 +# Optimisation de YARN
  18 +
  19 +Retour d’expérience de quelqu’un qui a
  20 +travaillé pour [Wajam](https://www.wajam.com/),
  21 +un service qui récupère les données des réseaux sociaux pour en
  22 +faire des recommandations personnelles pertinentes.
  23 +
  24 +Pour faire ça ils utilisent un cluster
  25 +(c’est-à-dire un groupe d’ordinateurs physiques rassemblés au
  26 +même endroit physiquement) qui tourne sur [Hadoop](https://fr.wikipedia.org/wiki/Hadoop)
  27 +(permet de faire du calcul distribué, ici toutes les machines du
  28 +cluster contribuent à analyser les données des réseaux sociaux
  29 +pour en faire des recommandations).
  30 +
  31 +Sauf qu’un beau jour, problème, au lieu d’avoir
  32 +un flux de données entrant de 150 Go/jour, ils se retrouvent à
  33 +devoir traiter 300 Go/jour, et il n’y a plus de place pour rajouter
  34 +physiquement des machines au cluster. Ils commencent donc à analyser
  35 +avec [Cloudera](https://fr.wikipedia.org/wiki/Cloudera) comment se passe le traitement de données notamment la
  36 +répartition des tâches sur les machines qui est faite par le
  37 +logiciel [YARN](https://fr.wikipedia.org/wiki/Hadoop_YARN).
  38 +Ils se rendent compte de plusieurs choses :
  39 +
  40 +* Certaines tâches [reduce](https://fr.wikipedia.org/wiki/MapReduce)
  41 + échouaient deux fois avant de réussir au troisième essai. Cela
  42 + était dû au fait que seul 1 Go de mémoire vive était alloué
  43 + pour chaque bloc (une grosse tâche est découpée en plusieurs
  44 + petits blocs répartis sur le cluster) alors qu’il avait besoin
  45 + d’un peu plus (si ça marchait à la troisième fois, c’est
  46 + probablement grâce à la [préemption](https://fr.wikipedia.org/wiki/Multit%C3%A2che_pr%C3%A9emptif)
  47 + de YARN : au bout de deux échecs il autorise le bloc à manger
  48 + de la mémoire sur les autres blocs si ils ne l’utilisent pas)
  49 +
  50 +* La répartition des tâches était trop
  51 + calculée à partir de la mémoire disponible, et ne prenait pas en
  52 + compte le CPU qui parfois était jamais utilisé, parfois beaucoup
  53 + utilisé par plusieurs blocs ce qui ralentissait le traitement des
  54 + données
  55 +
  56 +* [Sqoop](https://fr.wikipedia.org/wiki/Apache_Sqoop),
  57 + permettant de transférer des données entre les BDD relationnelles
  58 + (MySQL ici) et HDFS (HaDoop FileSystem, système de fichiers
  59 + permettant la répartition « intelligente » des données
  60 + sur les machines du cluster) avait un quota par défaut pour limiter
  61 + le nombre de requêtes par unité de temps.
  62 +
  63 +* Les données envoyées à MySQL étaient
  64 + envoyées une par une, ce qui prenait un monstre à chaque
  65 + initialisation de requête.
  66 +
  67 +* Les outils n’étaient pas à jour. Du
  68 + coup ils rataient pas mal d’optimisation sur les différents
  69 + outils qu’ils utilisaient et en plus étaient tombés sur une
  70 + version de YARN avec un bug qui réduisait sans raison la capacité
  71 + de traitement.
  72 +
  73 +* Parmi les requêtes SQL, il y avait parfois
  74 + des « ORDER BY » qui n’étaient pas nécessaires et
  75 + ralentissaient considérablement le temps d’exécution
  76 +
  77 +* Certaines données étaient traitées même
  78 + quand il était sû à l’avance qu’elles ne seraient pas
  79 + pertinentes. Les « FILTER » sur les requêtes SQL c’est
  80 + une bonne idée.
  81 +
  82 +* Le « [mode
  83 + spéculation](https://fr.wikipedia.org/wiki/Ex%C3%A9cution_sp%C3%A9culative) » était activé. Ce mode pense qu’une
  84 + tâche peut potentiellement rater donc elle est lancée sur
  85 + plusieurs machines différentes et on prend les résultats de celle
  86 + qui finit en premier. Si c’est utile pour faire du traitement de
  87 + données en temps réel, ça gâche des ressources inutilement dans
  88 + ce contexte où si une tâche échoue ça ne coûte rien de la
  89 + relancer.
  90 +
  91 +* La « collocation de données »
  92 + n’était pas activée. Cet outil permet d’informer YARN de
  93 + l’emplacement physique de chaque machine afin de mettre les
  94 + données souvent utilisées ensemble physiquement côte à côte
  95 + pour réduire les temps d’accès.
  96 +
  97 +* Parfois, sur des machines à 64 Go de
  98 + mémoire vive, seuls 16 Go étaient déclarés et donc utilisés.
  99 +
  100 +
  101 +Après avoir corrigé tout ça, ils se sont rendu
  102 +compte qu’avec le même cluster, ils pouvaient traiter non plus 150
  103 +Go mais 700 Go de données par jour, tout en ayant réduit les
  104 +ressources utilisées et les temps de calcul. Du coup pendant 3 ans
  105 +ils utilisaient 4 × trop de serveurs, d’électricité,
  106 +de climatisation etc. pour … rien. Tout ça pour 10 lignes de
  107 +configuration et de code modifiées.
  108 +
  109 +En plus de faire des économies, ça a leur a
  110 +permis de démystifier le fonctionnement du cluster, et du coup ils
  111 +n’hésitent pas à le redémarrer de temps en temps pour faire de
  112 +l’amélioration continue.
  113 +
  114 +# Retour sur Google Cloud Plateform
  115 +
  116 +Ce monsieur a d’abord travaillé chez SFR où
  117 +ils utilisaient comme pour Wajam des clusters de machines.
  118 +Aujourd’hui, il travaille pour La Redoute, où ils utilisent [Google Cloud
  119 +Plateform](https://cloud.google.com/) (c’est du cloud de 3<sup>e</sup> génération), qui
  120 +est un autre moyen de faire du traitement de données sur des grosses
  121 +tailles.
  122 +
  123 +C’est essentiellement « serverless »,
  124 +c’est-à-dire que les serveurs sont créés et détruit en fonction
  125 +des besoins. On parle d’auto-scalabilité. Ce n’est pas forcément
  126 +utile pour les petits volumes de données (pour traiter un fichier de
  127 +120 lignes il va peut-être créer 120 machines), mais ça devient
  128 +intéressant pour de gros volumes. En effet, le genre de traitement
  129 +de données qui était fait sur un cluster en 3h peut être fait en
  130 +18 secondes avec GCP.
  131 +
  132 +Google Cloud Plateform propose [d’autres services](https://cloud.google.com/products/), qui requièrent pas ou peu de configuration ou de mise
  133 +en place :
  134 +
  135 +* Storage : stockage de fichier, qui du
  136 + coup est persistent comparé aux serveurs
  137 +
  138 +* Pub / Sub : Système de publication /
  139 + souscription qui permet de connecter les services ensembles de
  140 + manière asynchrone avec des évènements
  141 +
  142 +* Dataflow : Traitement de donnée en
  143 + temps réél
  144 +
  145 +* Dataproc : Cluster de machines sur
  146 + Hadoop à la demande
  147 +
  148 +* BigQuery : Permet de faire de
  149 + l’analyse sur des grosses quantité de données
  150 +
  151 +* App Engine : Permet d’héberger des
  152 + applications (site web, serveur de jeu…)
  153 +
  154 +* Machine Learning : Service de Machine
  155 + Learning _(malheurseuement il a pas dit grand-chose là dessus)_
  156 +
  157 +* Datalog :
  158 + Service de log (journal de tout ce qui a été effectué) amélioré,
  159 + permettant ainsi d’analyser l’utilisation même de GCM
  160 + rapidement
  161 +
  162 +* …
  163 +
  164 +Les avantages sont
  165 +multiples : tout est beaucoup plus simple et plus rapide à
  166 +mettre en place, il y a plus de services disponibles qui n’auraient
  167 +pas été possibles avec un cluster, les performances sont clairement
  168 +meilleures, plus de maintenance de machines physique à faire, la
  169 +facturation est faite en fonction de ce qui est réellement utilisé
  170 +(ça peut être pratique quand on a pas besoin de faire du traitement
  171 +24h/24 par exemple).
  172 +
  173 +Les désavantages sont présents aussi : c’est probablement plus
  174 +cher d’utiliser ce service que de faire un cluster Hadoop à la main
  175 +avec du matériel de récup, et ça peut être un problème
  176 +d’externaliser les données sur un service indépendant pour des
  177 +données sensibles.
  178 +
  179 +_Il y a certainement d’autres arguments
  180 +contre, mais le monsieur insiste sur le fait que c’est juste son
  181 +avis. Essentiellement il n’y a pas de « le cloud c’est
  182 +mieux » ou « les clusters c’est la vie », ça
  183 +dépend du cas d’utilisation._
... ...