Blame view

_posts/2016-12-08-compte-rendu-meetup-big-data-machine-learning-1.markdown 7.84 KB
55b7d826   Geoffrey PREUD'HOMME   Ajout du Meetup B...
1
2
3
4
5
  ---
  layout: post
  title:  "Compte-rendu Meetup Big Data & Machine Learning #1"
  date:   2016-12-08 20:30:00 +0100
  author: "Geoffrey Preud'homme"
d4b5ecd0   Geoffrey PREUD'HOMME   categories → tags
6
  tags: machine-learning big-data meetup cr
55b7d826   Geoffrey PREUD'HOMME   Ajout du Meetup B...
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
  ---
  
  # 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._