Dans les coulisses informatiques de Facebook Comment Facebook a migré 30 pétaoctets de données à chaud grâce à Hadoop

Facebook utilise plusieurs solutions Open Source dans ses entrepôts de données : Apache Hadoop, Apache Hive, Apache HBase, Apache Thrift ou l'outil maison Facebook Scribe, dont le code source est désormais ouvert.

Chez Facebook, Hadoop est utilisé de trois manières différentes : comme un entrepôt de données pour du web analytics, pour stocker une base de données distribuée, et enfin pour les sauvegardes de ces serveurs de données MySQL (car Facebook utilise en effet MySQL, et dispose probablement de l'une des meilleures équipes dédiée à ce système. Elle encaisse chez Facebook au bas mot 60 millions de requêtes par seconde)

En 2010, Facebook avait sans doute le plus grand cluster Hadoop au monde, avec plus de 21 pétaoctets stockés. Moins d'un an après, le cluster Big Data st passé à 30 pétaoctets. "A ce stade, nous avons été à court d'énergie et d'espace pour ajouter d'autres nœuds, ce qui a nécessité de migrer vers un datacenter plus grand", explique Paul Yang, ingénieur employé dans l'équipe dédiée à l'infrastructure de Facebook, dans un billet relatant la délicate opération, et titré "Faire bouger un éléphant " (en référence au logo d'Hadoop mais aussi à la taille du cluster).

Délicate réplication

Une telle migration n'est évidemment pas une mince affaire. Facebook avait deux choix : déménager les machines vers le nouveau datacenter, ou adopter un système de réplication en miroir. Les analystes et utilisateurs ayant constamment besoin des données, le temps d'indisponibilité causé par la première idée a été jugé bien trop long. C'est la deuxième possibilité qui a finalement été retenue.

Problème : des fichiers, créés et supprimés en permanence, sont nécessaires au bon fonctionnement du réseau social. En outre, en raison de la taille du cluster, sans précédent, un nouveau système de réplication capable de gérer la charge a dû être développé.

Facebook a démontré qu'il était possible de garder actif un cluster de plusieurs pétaoctets en cours de réplication

Plugin sur mesure pour Hadoop Hive

"Une copie a d'abord permis de transférer l'essentiel des données de la source à la destination. La plupart des annuaires ont été copiés par le biais DistCp, une application livrée avec Hadoop qui utilise MapReduce pour copier des fichiers en parallèle", explique Paul Yang sur Facebook. "Nos ingénieurs Hadoop ont également dû changer certains code et configuration pour gérer les cas particuliers des données de Facebook".

Ensuite, les modifications apportées aux fichiers dans le cluster d'origine ont été détectées grâce à un plugin pour Hadoop Hive, développé en interne. Ces modifications étaient enregistrées en détails dans un journal. Le système de réplication a continuellement scruté ce journal pour pouvoir ensuite intégré ces modifications, avec, au maximum, quelques heures de retard. Pour l'ultime basculement, une "cellule de guerre" a même été montée pour surveiller de près l'opération, qui s'est finalement bien terminée.

Une solution qui pourrait servir à d'autres

Avantage supplémentaire, souligné par Paul Yang : ce système de réplication a également montré une solution potentielle de reprise après sinistre pour des entrepôts de données utilisant Hadoop Hive.

"Nous avons démontré qu'il était possible de garder actif un cluster de plusieurs pétaoctets en train d'être répliqué, avec seulement un léger décalage. Avec la réplication déployée, les opérations pourraient être basculées vers la réplique avec relativement peu de travail en cas de catastrophe. Le système de réplication pourrait ainsi augmenter l'attrait d'Hadoop pour des applications critiques", estime l'ingénieur, qui explique également que le prochain défi, pour Facebook, sera de répartir l'entrepôt de données entre plusieurs datacenters.