Reinventând abordarea Sprout Social față de big data

Sprout Social este, în esență, o companie bazată pe date. Sprout procesează miliarde de mesaje de pe mai multe rețele sociale în fiecare zi. Din această cauză, inginerii Sprout se confruntă cu o provocare unică – cum să stocheze și să actualizeze mai multe versiuni ale aceluiași mesaj (adică retweeturi, comentarii etc.) care vin pe platforma noastră la un volum foarte mare.

Deoarece stocăm mai multe versiuni de mesaje, inginerii Sprout au sarcina de a „recrea lumea” de mai multe ori pe zi – un proces esențial care necesită iterarea întregului set de date pentru a consolida fiecare parte a unui mesaj social într-o singură „sursă de adevăr”.

De exemplu, urmărirea aprecierilor, comentariilor și retweeturilor unei singure postări Twitter. Din punct de vedere istoric, ne-am bazat pe clustere Hadoop autogestionate pentru a menține și a lucra cu cantități atât de mari de date. Fiecare cluster Hadoop ar fi responsabil pentru diferite părți ale platformei Sprout - o practică pe care se bazează echipa de inginerie Sprout pentru a gestiona proiectele de date mari, la scară.

Cheile abordării Big Data a lui Sprout

Ecosistemul nostru Hadoop depindea de Apache Hbase, o bază de date NoSQL scalabilă și distribuită. Ceea ce face ca Hbase să fie crucial pentru abordarea noastră cu privire la procesarea datelor mari este capacitatea sa de a nu numai să efectueze scanări rapide ale întregii seturi de date, ci și de a face căutări rapide, aleatorii, pentru o singură înregistrare.

Hbase ne permite, de asemenea, să încărcăm în bloc datele și să actualizăm datele aleatoare, astfel încât să putem gestiona mai ușor mesajele care sosesc în neregulă sau cu actualizări parțiale și alte provocări care vin cu datele din rețelele sociale. Cu toate acestea, clusterele Hadoop autogestionate îi împovărează pe inginerii noștri de infrastructură cu costuri operaționale ridicate, inclusiv gestionarea manuală a recuperării în caz de dezastru, extinderea clusterului și gestionarea nodurilor.

Pentru a ajuta la reducerea timpului care provine din gestionarea acestor sisteme cu sute de terabytes de date, echipele de infrastructură și dezvoltare ale Sprout s-au unit pentru a găsi o soluție mai bună decât rularea clusterelor Hadoop autogestionate. Obiectivele noastre au fost:

• Permiteți inginerilor Sprout să construiască, să gestioneze și să opereze mai bine seturi mari de date
• Reduceți la minimum investiția de timp din partea inginerilor pentru a deține și întreține manual sistemul
• Reduceți costurile inutile ale supraprovizionarii datorită extinderii clusterului
• Oferiți metode și fiabilitate mai bune de recuperare în caz de dezastru

Pe măsură ce am evaluat alternative la sistemul nostru actual de date mari, ne-am străduit să găsim o soluție care să se integreze cu ușurință cu procesarea și tiparele noastre actuale și să ușureze efortul operațional care vine cu gestionarea manuală a unui cluster.

Evaluarea noilor alternative de model de date

Una dintre soluțiile pe care echipele noastre le-au luat în considerare au fost depozitele de date. Depozitele de date acționează ca un depozit centralizat pentru analiza și agregarea datelor, dar seamănă mai mult cu bazele de date relaționale tradiționale în comparație cu Hbase. Datele lor sunt structurate, filtrate și au un model de date strict (adică având un singur rând pentru un singur obiect).

Pentru cazul nostru de utilizare de stocare și procesare a mesajelor sociale care au multe versiuni ale unui mesaj care trăiesc unul lângă altul, depozitele de date au avut un model ineficient pentru nevoile noastre. Nu am reușit să adaptăm modelul existent în mod eficient la depozitele de date, iar performanța a fost mult mai lentă decât ne-am anticipat. Reformatarea datelor noastre pentru a ne adapta la modelul de depozit de date ar necesita o suprafață majoră pentru a reelabora în cronologia pe care o aveam.

O altă soluție pe care am căutat-o ​​au fost data lakehouses. Data Lakehouse-urile extind conceptele de depozit de date pentru a permite date mai puțin structurate, stocare mai ieftină și un strat suplimentar de securitate în jurul datelor sensibile. În timp ce data lakehouse-urile au oferit mai mult decât ar putea depozitele de date, acestea nu au fost la fel de eficiente ca soluția noastră actuală Hbase. Prin testarea înregistrării noastre de îmbinare și a modelelor noastre de procesare a inserării și ștergerii, nu am reușit să generăm latențe de scriere acceptabile pentru joburile noastre batch.

Reducerea cheltuielilor generale și a întreținerii cu AWS EMR

Având în vedere ceea ce am învățat despre soluțiile de depozitare de date și lakehouse, am început să analizăm instrumente alternative care rulează Hbase gestionat. Deși am decis că utilizarea actuală a Hbase este eficientă pentru ceea ce facem la Sprout, ne-am întrebat: „Cum putem rula Hbase mai bine pentru a reduce sarcina operațională, menținând în același timp tiparele noastre majore de utilizare?”

Acesta este momentul în care am început să evaluăm serviciul gestionat Elastic Map Reduce (EMR) de la Amazon pentru Hbase. Evaluarea EMR a necesitat evaluarea performanței sale în același mod în care am testat depozitele de date și lakehouse-urile, cum ar fi testarea ingerării de date pentru a vedea dacă ar putea îndeplini cerințele noastre de performanță. De asemenea, a trebuit să testăm stocarea datelor, disponibilitatea ridicată și recuperarea în caz de dezastru pentru a ne asigura că EMR se potrivește nevoilor noastre din perspectiva infrastructurii/administrativă.

Caracteristicile EMR ne-au îmbunătățit soluția actuală autogestionată și ne-au permis să reutilizam tiparele noastre actuale pentru citirea, scrierea și executarea lucrărilor în același mod în care am făcut-o cu Hbase. Unul dintre cele mai mari beneficii ale EMR este utilizarea sistemului de fișiere EMR (EMRFS), care stochează datele în S3, mai degrabă decât pe nodurile în sine.

O provocare pe care am constatat-o ​​a fost că EMR avea opțiuni de înaltă disponibilitate limitate, ceea ce ne-a limitat să rulăm mai multe noduri principale într-o singură zonă de disponibilitate sau un nod principal în mai multe zone de disponibilitate. Acest risc a fost atenuat prin utilizarea EMRFS, deoarece a oferit toleranță suplimentară la erori pentru recuperarea în caz de dezastru și decuplarea stocării datelor de funcțiile de calcul. Folosind EMR ca soluție pentru Hbase, suntem capabili să îmbunătățim scalabilitatea și recuperarea erorilor și să minimizăm intervenția manuală necesară pentru menținerea clusterelor. În cele din urmă, am decis că EMR este cel mai potrivit pentru nevoile noastre.

Procesul de migrare a fost testat cu ușurință în prealabil și executat pentru a migra miliarde de înregistrări către noile clustere EMR fără niciun timp de nefuncționare a clienților. Noile clustere au prezentat performanțe îmbunătățite și costuri reduse cu aproape 40%. Pentru a citi mai multe despre modul în care trecerea la EMR a ajutat la reducerea costurilor de infrastructură și la îmbunătățirea performanței noastre, consultați studiul de caz al Sprout Social cu AWS.

Ce am învățat

Dimensiunea și amploarea acestui proiect ne-au oferit nouă, echipei Infrastructure Database Reliability Engineering, oportunitatea de a lucra interfuncțional cu mai multe echipe de inginerie. Deși a fost o provocare, s-a dovedit a fi un exemplu incredibil al proiectelor la scară largă pe care le putem aborda la Sprout ca organizație de inginerie colaborativă. Prin acest proiect, echipa noastră de infrastructură a dobândit o înțelegere mai profundă a modului în care sunt utilizate, stocate și procesate datele lui Sprout și suntem mai echipați pentru a ajuta la depanarea problemelor viitoare. Am creat o bază comună de cunoștințe pentru mai multe echipe care ne pot ajuta să construim următoarea generație de caracteristici pentru clienți.

Dacă sunteți interesat de ceea ce construim, alăturați-vă echipei noastre și aplicați astăzi pentru unul dintre rolurile noastre deschise de inginerie.