Réinventer l'approche de Sprout Social en matière de big data

Sprout Social est, à la base, une entreprise axée sur les données. Sprout traite chaque jour des milliards de messages provenant de plusieurs réseaux sociaux. Pour cette raison, les ingénieurs de Sprout sont confrontés à un défi unique : comment stocker et mettre à jour plusieurs versions du même message (c'est-à-dire les retweets, les commentaires, etc.) qui arrivent sur notre plate-forme à un volume très élevé.

Étant donné que nous stockons plusieurs versions de messages, les ingénieurs de Sprout sont chargés de « recréer le monde » plusieurs fois par jour, un processus essentiel qui nécessite de parcourir l'intégralité de l'ensemble de données pour consolider chaque partie d'un message social en une seule « source de vérité ».

Par exemple, garder une trace des likes, des commentaires et des retweets d'un seul post Twitter. Historiquement, nous nous sommes appuyés sur des clusters Hadoop autogérés pour gérer et traiter de si grandes quantités de données. Chaque cluster Hadoop serait responsable de différentes parties de la plate-forme Sprout, une pratique sur laquelle s'appuie l'ensemble de l'équipe d'ingénierie Sprout pour gérer les projets Big Data, à grande échelle.

Clés de l'approche Big Data de Sprout

Notre écosystème Hadoop dépendait d'Apache Hbase, une base de données NoSQL évolutive et distribuée. Ce qui rend Hbase crucial pour notre approche du traitement du Big Data, c'est sa capacité non seulement à effectuer des analyses rapides sur des ensembles de données entiers, mais également à effectuer des recherches rapides, aléatoires et d'enregistrement unique.

Hbase nous permet également de charger en bloc des données et de mettre à jour des données aléatoires afin que nous puissions plus facilement gérer les messages arrivant dans le désordre ou avec des mises à jour partielles, et d'autres défis liés aux données des médias sociaux. Cependant, les clusters Hadoop autogérés imposent à nos ingénieurs d'infrastructure des coûts opérationnels élevés, notamment la gestion manuelle de la reprise après sinistre, l'expansion des clusters et la gestion des nœuds.

Pour aider à réduire le temps nécessaire à la gestion de ces systèmes avec des centaines de téraoctets de données, les équipes d'infrastructure et de développement de Sprout se sont réunies pour trouver une meilleure solution que l'exécution de clusters Hadoop autogérés. Nos objectifs étaient de :

• Permettre aux ingénieurs de Sprout de mieux créer, gérer et exploiter de grands ensembles de données
• Minimiser l'investissement en temps des ingénieurs pour posséder et entretenir manuellement le système
• Réduisez les coûts inutiles de sur-provisionnement dus à l'expansion du cluster
• Fournir de meilleures méthodes de reprise après sinistre et une meilleure fiabilité

Alors que nous évaluions des alternatives à notre système de Big Data actuel, nous nous sommes efforcés de trouver une solution qui s'intégrerait facilement à notre traitement et à nos modèles actuels, et qui soulagerait le labeur opérationnel lié à la gestion manuelle d'un cluster.

Évaluation de nouvelles alternatives de modèles de données

L'une des solutions envisagées par nos équipes était les entrepôts de données. Les entrepôts de données agissent comme un magasin centralisé pour l'analyse et l'agrégation des données, mais ressemblent davantage aux bases de données relationnelles traditionnelles par rapport à Hbase. Leurs données sont structurées, filtrées et ont un modèle de données strict (c'est-à-dire avoir une seule ligne pour un seul objet).

Pour notre cas d'utilisation du stockage et du traitement des messages sociaux qui ont plusieurs versions d'un message vivant côte à côte, les entrepôts de données avaient un modèle inefficace pour nos besoins. Nous n'avons pas été en mesure d'adapter efficacement notre modèle existant aux entrepôts de données, et les performances ont été beaucoup plus lentes que prévu. Le reformatage de nos données pour s'adapter au modèle d'entrepôt de données nécessiterait des frais généraux importants à retravailler dans le délai dont nous disposions.

Une autre solution que nous avons étudiée était les data lakehouses. Les data lakehouses élargissent les concepts d'entrepôt de données pour permettre des données moins structurées, un stockage moins cher et une couche de sécurité supplémentaire autour des données sensibles. Bien que les data lakehouses offraient plus que ce que les entrepôts de données pouvaient offrir, ils n'étaient pas aussi efficaces que notre solution Hbase actuelle. En testant notre enregistrement de fusion et nos modèles de traitement d'insertion et de suppression, nous n'avons pas été en mesure de générer des latences d'écriture acceptables pour nos travaux par lots.

Réduction des frais généraux et de la maintenance avec AWS EMR

Compte tenu de ce que nous avons appris sur l'entreposage de données et les solutions Lakehouse, nous avons commencé à rechercher des outils alternatifs exécutant Hbase géré. Bien que nous ayons décidé que notre utilisation actuelle de Hbase était efficace pour ce que nous faisons chez Sprout, nous nous sommes demandé : "Comment pouvons-nous mieux exécuter Hbase pour réduire notre charge opérationnelle tout en conservant nos principaux modèles d'utilisation ?"

C'est à ce moment-là que nous avons commencé à évaluer le service géré Elastic Map Reduce (EMR) d'Amazon pour Hbase. L'évaluation d'EMR nécessitait d'évaluer ses performances de la même manière que nous avons testé des entrepôts de données et des maisons de lac, comme tester l'ingestion de données pour voir s'il pouvait répondre à nos exigences de performance. Nous avons également dû tester le stockage des données, la haute disponibilité et la reprise après sinistre pour nous assurer que l'EMR répondait à nos besoins d'un point de vue infrastructurel/administratif.

Les fonctionnalités d'EMR ont amélioré notre solution autogérée actuelle et nous ont permis de réutiliser nos modèles actuels pour lire, écrire et exécuter des tâches de la même manière que nous le faisions avec Hbase. L'un des principaux avantages d'EMR est l'utilisation du système de fichiers EMR (EMRFS), qui stocke les données dans S3 plutôt que sur les nœuds eux-mêmes.

Un défi que nous avons constaté était qu'EMR avait des options de haute disponibilité limitées, ce qui nous limitait à exécuter plusieurs nœuds principaux dans une seule zone de disponibilité, ou un nœud principal dans plusieurs zones de disponibilité. Ce risque a été atténué en tirant parti d'EMRFS car il offrait une tolérance aux pannes supplémentaire pour la reprise après sinistre et le découplage du stockage des données des fonctions de calcul. En utilisant EMR comme solution pour Hbase, nous sommes en mesure d'améliorer notre évolutivité et notre récupération après panne, et de minimiser l'intervention manuelle nécessaire pour maintenir les clusters. En fin de compte, nous avons décidé que le DME était le mieux adapté à nos besoins.

Le processus de migration a été facilement testé au préalable et exécuté pour migrer des milliards d'enregistrements vers les nouveaux clusters EMR sans aucun temps d'arrêt pour le client. Les nouveaux clusters ont montré des performances améliorées et des coûts réduits de près de 40 %. Pour en savoir plus sur la façon dont le passage à l'EMR a permis de réduire les coûts d'infrastructure et d'améliorer nos performances, consultez l'étude de cas de Sprout Social avec AWS.

Ce que nous avons appris

La taille et la portée de ce projet nous ont donné, à l'équipe d'ingénierie de la fiabilité de la base de données d'infrastructure, l'opportunité de travailler de manière interfonctionnelle avec plusieurs équipes d'ingénierie. Bien que ce soit un défi, cela s'est avéré être un exemple incroyable des projets à grande échelle auxquels nous pouvons nous attaquer chez Sprout en tant qu'organisation d'ingénierie collaborative. Grâce à ce projet, notre équipe d'infrastructure a acquis une meilleure compréhension de la façon dont les données de Sprout sont utilisées, stockées et traitées, et nous sommes mieux équipés pour aider à résoudre les problèmes futurs. Nous avons créé une base de connaissances commune à plusieurs équipes qui peut nous aider à créer la prochaine génération de fonctionnalités client.

Si vous êtes intéressé par ce que nous construisons, rejoignez notre équipe et postulez dès aujourd'hui pour l'un de nos postes d'ingénierie ouverts.