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, 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, 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 (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 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. Ils se rendent compte de plusieurs choses :
Certaines tâches reduce é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 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, 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 » é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 (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, 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.