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._
|