2. Qui suis-je ?Qui suis-je ?
Dev chez Booking.com de 02/2007 à 11/2015
Frontend, Email marketing, Infra, Visitor personalization,
puis Big Data (2011)
Il n'y a pas de problème, il n'y a que des
solutions
(beaucoup de solutions)
2 / 22
6. Le prototypeLe prototype
Vite fait, machines hétéroclites, jobs en
HadoopStreaming. Mariage peu orthodoxe
(Hadoop+Perl), mais des résultats encourageants, voire
magiques
6 / 22
7. Le premierLe premier vraivrai clustercluster
Import de tables de BDD (Sqoop) pour quelques
analystes : permettre enfin les requêtes cross-DB
Manque de docs à l'époque. Plus le cas aujourd'hui :
nombreux livres très utiles, voire obligatoires
Tout est à (ré)apprendre
7 / 22
8. Mise en productionMise en production
Passage rapide à deux clusters pour les tests de
configuration, les upgrades et la redondance
Consultants Cloudera pour le bootstrap, utilisation de
CM au début puis Puppet
8 / 22
9. Le dédale des optionsLe dédale des options
C'est un cauchemar !
Aucune config standard adaptée
Théorie : les gros utilisateurs (early adopters) n'ont pas
de temps pour la doc
Différent aujourd'hui ?
9 / 22
10. Nos premiers utilisateursNos premiers utilisateurs
Venant de MySQL, Hive était un choix évident
TRANSFORM est une killer feature
10 / 22
11. Ce qu'ils nous apprennentCe qu'ils nous apprennent
Une vélocité jamais atteinte, très favorable aux
processus de développement itératifs
Un effort de formation très important :
mapreduce demande un paradigm shift
les utilisateurs voient une chose qui just works et
cassent tout très facilement
11 / 22
12. La montée en chargeLa montée en charge
Ingestion des events du site : millions, puis milliards de
JSON par jour
Demande endémiquement sous-évaluée : croissance du
volume dans toutes les directions
Reprocess, big jointures : quelques indigestions
Prévisions d'espace disque et CPU : encore plus
difficiles sur un petit cluster
Les clusters sont de petits gros êtres fragiles
12 / 22
13. La minute de la haineLa minute de la haine
Le jour où on a effacé toutes les partitions
Le jour où le FairScheduler est devenu fou
Le jour où le HistoryServer a fait tomber le cluster
Et les 1458 autres jours
De grands moments de solitude (surtout la nuit)
Chasser les bugs est so fun
13 / 22
14. Pourquoi tant dePourquoi tant de hainehaine bugsbugs
fun ?fun ?
Parce que ce sont des systèmes jeunes !
Parce que ce sont des systèmes complexes (pas un
système, mais un écosystème)
Parce que le développement est rapide, et la
concurrence féroce
Encore très loin de la stabilité et de la prévisibilité des
SGBDR (même si c'est très différent)
14 / 22
15. Le cloud, pourquoi pas ?Le cloud, pourquoi pas ?
Obstacles culturels et confidentialité
Le faire si l'on peut, surtout pour le démarrage : se
concentrer sur la valeur, pas sur la plomberie
Virtualisation in-house ? Now you have 2 problems
15 / 22
16. La division du tempsLa division du temps
40 % troubleshoot infra, maintenance, évolution
40 % troubleshoot users, formation, assistance
40 % codage de scripts de monitoring, et facilitation
d'accès pour les users
Demande un peu d'organisation :-)
16 / 22
17. Des solutions ?Des solutions ?
Briques de bases (automatisation, profiling, grosses
config comme Kerberos) à implémenter toujours très
tôt ; les systèmes distribués ne rendent pas les choses
plus simples
Peut-être une 2ème équipe déchargée du support
utilisateurs ?
Favoriser la diffusion de la connaissance, utiliser des
outils adaptés, type StackOverflow. Former des
utilisateurs experts qui forment les autres
Classique, non ? Presque...
17 / 22
19. Recette : réussir ses lasagnesRecette : réussir ses lasagnes
à la big dataà la big data
Un investissement humain et matériel important, un
R.O.I incertain
Le data-centrisme et la transdiciplinarité en préalable
Pourquoi ai-je besoin d'Hadoop ? Quelles alternatives ?
Comme toujours, la clé est dans la qualité de l'exécution
Workhorses, not show ponies ; faire bien une chose,
plutôt que dix mal
19 / 22