Die Neuerfindung des Big Data-Ansatzes von Sprout Social

Sprout Social ist im Kern ein datengesteuertes Unternehmen. Sprout verarbeitet jeden Tag Milliarden von Nachrichten aus mehreren sozialen Netzwerken. Aus diesem Grund stehen Sprout-Ingenieure vor einer einzigartigen Herausforderung – wie können mehrere Versionen derselben Nachricht (dh Retweets, Kommentare usw.) gespeichert und aktualisiert werden, die in großer Zahl auf unsere Plattform gelangen.

Da wir mehrere Versionen von Nachrichten speichern, haben Sprout-Ingenieure die Aufgabe, mehrmals täglich „die Welt neu zu erstellen“ – ein wesentlicher Prozess, der eine Iteration durch den gesamten Datensatz erfordert, um jeden Teil einer sozialen Nachricht in einer „Quelle der Wahrheit“ zu konsolidieren.

Zum Beispiel die Verfolgung von Likes, Kommentaren und Retweets eines einzelnen Twitter-Beitrags. In der Vergangenheit haben wir uns auf selbstverwaltete Hadoop-Cluster verlassen, um solch große Datenmengen zu verwalten und zu verarbeiten. Jeder Hadoop-Cluster wäre für verschiedene Teile der Sprout-Plattform verantwortlich – eine Praxis, auf die sich das gesamte Sprout-Engineering-Team verlässt, um Big-Data-Projekte in großem Maßstab zu verwalten.

Schlüssel zum Big-Data-Ansatz von Sprout

Unser Hadoop-Ökosystem stützte sich auf Apache Hbase, eine skalierbare und verteilte NoSQL-Datenbank. Was Hbase für unseren Ansatz zur Verarbeitung von Big Data entscheidend macht, ist seine Fähigkeit, nicht nur schnelle Bereichsscans über ganze Datensätze durchzuführen, sondern auch schnelle, zufällige Einzeldatensatzsuchen durchzuführen.

Hbase ermöglicht es uns auch, Daten in großen Mengen zu laden und zufällige Daten zu aktualisieren, damit wir Nachrichten, die in der falschen Reihenfolge oder mit Teilaktualisierungen ankommen, und andere Herausforderungen, die mit Social-Media-Daten einhergehen, einfacher handhaben können. Selbstverwaltete Hadoop-Cluster belasten unsere Infrastrukturtechniker jedoch mit hohen Betriebskosten, einschließlich der manuellen Verwaltung von Notfallwiederherstellung, Clustererweiterung und Knotenverwaltung.

Um den Zeitaufwand für die Verwaltung dieser Systeme mit Hunderten von Terabyte an Daten zu reduzieren, kamen die Infrastruktur- und Entwicklungsteams von Sprout zusammen, um eine bessere Lösung als die Ausführung selbstverwalteter Hadoop-Cluster zu finden. Unsere Ziele waren:

• Ermöglichen Sie Sprout-Ingenieuren, große Datensätze besser zu erstellen, zu verwalten und zu betreiben
• Minimieren Sie den Zeitaufwand für Ingenieure, um das System manuell zu besitzen und zu warten
• Reduzieren Sie unnötige Kosten durch Überbereitstellung aufgrund von Clustererweiterungen
• Bieten Sie bessere Disaster-Recovery-Methoden und mehr Zuverlässigkeit

Als wir Alternativen zu unserem aktuellen Big-Data-System evaluierten, strebten wir danach, eine Lösung zu finden, die sich leicht in unsere aktuellen Verarbeitungsprozesse und -muster integrieren lässt und die operative Mühe, die mit der manuellen Verwaltung eines Clusters einhergeht, entlastet.

Bewertung neuer Datenmusteralternativen

Eine der Lösungen, die unsere Teams in Betracht gezogen haben, waren Data Warehouses. Data Warehouses fungieren als zentraler Speicher für die Datenanalyse und -aggregation, ähneln aber im Vergleich zu Hbase eher traditionellen relationalen Datenbanken. Ihre Daten sind strukturiert, gefiltert und haben ein strenges Datenmodell (dh eine einzelne Zeile für ein einzelnes Objekt).

Für unseren Anwendungsfall, soziale Nachrichten zu speichern und zu verarbeiten, die viele Versionen einer Nachricht nebeneinander haben, hatten Data Warehouses ein ineffizientes Modell für unsere Anforderungen. Wir konnten unser vorhandenes Modell nicht effektiv an Data Warehouses anpassen, und die Leistung war viel langsamer als erwartet. Die Neuformatierung unserer Daten zur Anpassung an das Data-Warehouse-Modell würde einen erheblichen Aufwand für die Überarbeitung in der Zeitachse erfordern, die wir hatten.

Eine weitere Lösung, die wir uns angeschaut haben, waren Data Lakehouses. Data Lakehouses erweitern Data-Warehouse-Konzepte, um weniger strukturierte Daten, billigere Speicherung und eine zusätzliche Sicherheitsebene für sensible Daten zu ermöglichen. Obwohl Data Lakehouses mehr boten als Data Warehouses, waren sie nicht so effizient wie unsere aktuelle Hbase-Lösung. Beim Testen unseres Zusammenführungsdatensatzes und unserer Einfüge- und Löschverarbeitungsmuster konnten wir keine akzeptablen Schreiblatenzen für unsere Batch-Jobs generieren.

Reduzierung von Overhead und Wartung mit AWS EMR

Angesichts dessen, was wir über Data Warehousing und Lakehouse-Lösungen gelernt haben, begannen wir, nach alternativen Tools zu suchen, auf denen Managed Hbase ausgeführt wird. Während wir entschieden, dass unsere derzeitige Nutzung von Hbase für das, was wir bei Sprout tun, effektiv ist, haben wir uns gefragt: „Wie können wir Hbase besser betreiben, um unsere Betriebslast zu verringern und gleichzeitig unsere wichtigsten Nutzungsmuster beizubehalten?“

Zu diesem Zeitpunkt begannen wir damit, den Managed Service Elastic Map Reduce (EMR) von Amazon für Hbase zu evaluieren. Die Bewertung von EMR erforderte eine Bewertung seiner Leistung auf die gleiche Weise, wie wir Data Warehouses und Lakehouses getestet haben, z. B. das Testen der Datenaufnahme, um festzustellen, ob es unsere Leistungsanforderungen erfüllen kann. Wir mussten auch die Datenspeicherung, Hochverfügbarkeit und Notfallwiederherstellung testen, um sicherzustellen, dass EMR unseren Anforderungen aus infrastruktureller/administrativer Sicht entspricht.

Die Funktionen von EMR verbesserten unsere aktuelle selbstverwaltete Lösung und ermöglichten es uns, unsere aktuellen Muster zum Lesen, Schreiben und Ausführen von Jobs auf die gleiche Weise wie bei Hbase wiederzuverwenden. Einer der größten Vorteile von EMR ist die Verwendung des EMR-Dateisystems (EMRFS), das Daten in S3 und nicht auf den Knoten selbst speichert.

Eine Herausforderung, die wir fanden, war, dass EMR über begrenzte Hochverfügbarkeitsoptionen verfügte, was uns darauf beschränkte, mehrere Hauptknoten in einer einzigen Verfügbarkeitszone oder einen Hauptknoten in mehreren Verfügbarkeitszonen auszuführen. Dieses Risiko wurde durch die Nutzung von EMRFS gemildert, da es zusätzliche Fehlertoleranz für die Notfallwiederherstellung und die Entkopplung der Datenspeicherung von Rechenfunktionen bot. Durch die Verwendung von EMR als unsere Lösung für Hbase sind wir in der Lage, unsere Skalierbarkeit und Fehlerbehebung zu verbessern und die manuellen Eingriffe zu minimieren, die zur Wartung der Cluster erforderlich sind. Letztendlich haben wir entschieden, dass EMR am besten zu unseren Anforderungen passt.

Der Migrationsprozess wurde im Vorfeld problemlos getestet und ausgeführt, um Milliarden von Datensätzen ohne Ausfallzeiten für den Kunden auf die neuen EMR-Cluster zu migrieren. Die neuen Cluster zeigten eine verbesserte Leistung und reduzierten die Kosten um fast 40 %. Um mehr darüber zu erfahren, wie der Wechsel zu EMR dazu beigetragen hat, die Infrastrukturkosten zu senken und unsere Leistung zu verbessern, sehen Sie sich die Fallstudie von Sprout Social mit AWS an.

Was wir gelernt haben

Die Größe und der Umfang dieses Projekts gaben uns, dem Infrastructure Database Reliability Engineering-Team, die Möglichkeit, funktionsübergreifend mit mehreren Engineering-Teams zusammenzuarbeiten. Obwohl es eine Herausforderung war, erwies es sich als ein unglaubliches Beispiel für die großen Projekte, die wir bei Sprout als kollaboratives Engineering-Unternehmen angehen können. Durch dieses Projekt hat unser Infrastrukturteam ein tieferes Verständnis dafür gewonnen, wie die Daten von Sprout verwendet, gespeichert und verarbeitet werden, und wir sind besser gerüstet, um bei der Behebung zukünftiger Probleme zu helfen. Wir haben eine gemeinsame Wissensbasis für mehrere Teams geschaffen, die uns dabei helfen kann, die nächste Generation von Kundenfunktionen zu entwickeln.

Wenn Sie daran interessiert sind, was wir bauen, treten Sie unserem Team bei und bewerben Sie sich noch heute für eine unserer offenen Ingenieurstellen.