C'est une compilation de 20 articles qui racontent comment une solution a été trouvée face à des données complexes que ce soit dans leur nature ou volumétrie. Le chapitre qui a retenu toute mon attention est le chapitre 5 - Il y est raconté par Jeff Hammerbacher comment Facebook a géré ses données.
Thefacebook
C'est en 2005 - ca s'appelle encore thefacebook et il vient de prendre un virage important avec l'ouverture des comptes à tout le monde et non plus uniquement aux étudiants des universités. Jeff Hammerbacher est alors embauché comme "research scientist" auprès du directeur du reporting & analytics.
MySQL... et quelques scripts ^^
Leur premier reflexe est de choisir MySQL comme base de données. Ils vont alors développer en Python des scripts d'alimentation, quelques scripts SQL pour retraiter l'information et au bout du bout du PHP pour envoyer à l'ensemble des utilisateurs du reporting sur l'activité Facebook. L'auteur reconnaîtra que sans le savoir, ils venaient tout simplement d'écrire un système BI... Enfin, d'un genre un peu particulier puisqu'il est totalement basé sur de l'open source !
Le double crash...
Quelques centaines de gigaoctet plus tard... les scripts durent maintenant des jours. L'auteur reconnait alors qu'il se disait que c'était normal vu la volumétrie des données et la complexité des requêtes. Et puis un jour le traitement s'arrête en plein milieu...la base de données vient de jeter l'éponge !
C'est là que cela devient intéressant... Conseillé par des vétérans de la BI (les conseilleurs ne sont pas les payeurs), ils décident de passer sur du Oracle : une vrai base de données professionnelle avec un serveur Sun et des disques optimisés (chers bien sûr). En prime, ils gagnent un projet de migration parce que la grammaire SQL d'Oracle n'est pas tout à fait la même que MySQL - qu'il faut aussi s'appuyer sur les fonctionnalités standards de la base notamment en matière d'alimentation. Le projet est douloureux mais voilà ils ont un datawarehouse digne de ce nom.
Le premier jour de ce nouveau datawarehouse commence avec l'alimentation de 400 go de données pour une journée (c'est très très respectable !) et là mauvaise surprise... l'alimentation dure très au delà de 24h. Bref, c'est déjà mort alors que cela venait de commencer... C'est un deuxième crash.
Sauvé par un... éléphant
Le premier réflexe de l'équipe sera de traiter une partie des informations en dehors de la base de données et d'écrire une "synthèse" uniquement dans la base de données. Ainsi ils ramèneront à 2h le traitement mais avec plein de problèmes qui est de ne pas pouvoir requêter dans les données de détail. La suite est dans mon article sur le datawarehousing façon Facebook où avec Hadoop ils vont résoudre l'ensemble de leurs problèmes ! En moins d'un 1 an, ils vont tout migrer sur cette solution. L'auteur donne quelques chiffres : 2.5 petabytes de données, 15 To de données quotidienne - 3000 jobs quotidiens qui "bougent" 55 to de données ^^
Certains sont sceptiques du phénomène "big data"... Je m'imagine juste à la place des personnes chez Facebook et je me dis que les lignes sont en train de changer fortement quand je vois la solution à laquelle ils sont arrivés - relisez chaque étape de leur développement, c'est riche d'enseignement et pas simplement parce que Facebook gère beaucoup de données !
Aucun commentaire:
Enregistrer un commentaire