Sprout Social és, en el seu nucli, una empresa basada en dades. Sprout processa milers de milions de missatges de diverses xarxes socials cada dia. Per això, els enginyers de Sprout s'enfronten a un repte únic: com emmagatzemar i actualitzar diverses versions del mateix missatge (és a dir, retuits, comentaris, etc.) que arriben a la nostra plataforma a un volum molt elevat.





Com que emmagatzemem diverses versions de missatges, els enginyers de Sprout tenen l'encàrrec de 'recrear el món' diverses vegades al dia, un procés essencial que requereix iterar tot el conjunt de dades per consolidar cada part d'un missatge social en una 'font de veritat'.



Per exemple, fer un seguiment dels m'agrada, comentaris i retuits d'una sola publicació de Twitter. Històricament, hem confiat en clústers Hadoop autogestionats per mantenir i treballar amb quantitats tan grans de dades. Cada clúster de Hadoop seria responsable de diferents parts de la plataforma Sprout, una pràctica que es basa en tot l'equip d'enginyeria de Sprout per gestionar projectes de grans dades a escala.



Claus de l'enfocament de big data de Sprout

El nostre ecosistema Hadoop depenia d'Apache Hbase, una base de dades NoSQL escalable i distribuïda. El que fa que Hbase sigui crucial per al nostre enfocament sobre el processament de grans dades és la seva capacitat no només de fer escanejos de rang ràpid sobre conjunts de dades sencers, sinó també de fer cerques ràpides, aleatòries i d'un sol registre.

Hbase també ens permet carregar dades massivament i actualitzar dades aleatòries perquè puguem gestionar més fàcilment els missatges que arriben fora d'ordre o amb actualitzacions parcials i altres reptes que comporten les dades de les xarxes socials. Tanmateix, els clústers Hadoop autogestionats carreguen els nostres enginyers d'infraestructura amb costos operatius elevats, inclosa la gestió manual de la recuperació de desastres, l'expansió del clúster i la gestió de nodes.

Per ajudar a reduir la quantitat de temps que prové de la gestió d'aquests sistemes amb centenars de terabytes de dades, els equips d'Infraestructura i Desenvolupament de Sprout es van unir per trobar una solució millor que executar clústers Hadoop autogestionats. Els nostres objectius eren:



  • Permet als enginyers de Sprout crear, gestionar i operar millor conjunts de dades grans
  • Minimitzeu la inversió de temps dels enginyers per posseir i mantenir manualment el sistema
  • Reduïu els costos innecessaris del sobreprovisionament a causa de l'expansió del clúster
  • Proporcioneu millors mètodes de recuperació de desastres i fiabilitat

A mesura que avaluàvem alternatives al nostre sistema actual de big data, ens vam esforçar per trobar una solució que s'integrara fàcilment amb el nostre processament i patrons actuals i alleugeriés la feina operativa que comporta la gestió manual d'un clúster.



Avaluació de noves alternatives de patrons de dades

Una de les solucions que els nostres equips van considerar van ser els magatzems de dades. Els magatzems de dades actuen com a magatzem centralitzat per a l'anàlisi i l'agregació de dades, però s'assemblen més a les bases de dades relacionals tradicionals en comparació amb Hbase. Les seves dades s'estructuren, es filtren i tenen un model de dades estricte (és a dir, tenir una sola fila per a un sol objecte).

Per al nostre cas d'ús d'emmagatzemar i processar missatges socials que tenen moltes versions d'un missatge que viuen una al costat de l'altra, els magatzems de dades tenien un model ineficient per a les nostres necessitats. No vam poder adaptar el nostre model existent amb eficàcia als magatzems de dades i el rendiment va ser molt més lent del que preveiem. Reformatar les nostres dades per adaptar-les al model de magatzem de dades requeriria una sobrecàrrega important per tornar a treballar en la línia de temps que teníem.



Una altra solució que vam investigar van ser els data Lakehouses. Els data lakehouses amplien els conceptes de magatzem de dades per permetre dades menys estructurades, emmagatzematge més barat i una capa addicional de seguretat al voltant de les dades sensibles. Tot i que els data Lakehouses oferien més del que podrien els magatzems de dades, no eren tan eficients com la nostra solució Hbase actual. Mitjançant la prova del nostre registre de combinació i els nostres patrons de processament d'inserció i supressió, no vam poder generar latències d'escriptura acceptables per als nostres treballs per lots.



Reduint les despeses generals i el manteniment amb AWS EMR

Tenint en compte el que vam aprendre sobre les solucions d'emmagatzematge de dades i lakehouse, vam començar a buscar eines alternatives amb Hbase gestionada. Tot i que vam decidir que el nostre ús actual d'Hbase era efectiu per al que fem a Sprout, ens vam preguntar: 'Com podem executar Hbase millor per reduir la nostra càrrega operativa tot mantenint els nostres patrons d'ús principals?'



Va ser llavors quan vam començar a avaluar el servei gestionat d'Amazon Elastic Map Reduce (EMR) per a Hbase. Per avaluar l'EMR, calia avaluar el seu rendiment de la mateixa manera que vam provar els magatzems de dades i els llacs, com ara provar la ingestió de dades per veure si podia complir els nostres requisits de rendiment. També vam haver de provar l'emmagatzematge de dades, l'alta disponibilitat i la recuperació de desastres per assegurar-nos que EMR s'adaptava a les nostres necessitats des d'una perspectiva d'infraestructura/administrativa.

Les funcions d'EMR van millorar la nostra solució autogestionada actual i ens van permetre reutilitzar els nostres patrons actuals per llegir, escriure i executar treballs de la mateixa manera que ho vam fer amb Hbase. Un dels majors avantatges de l'EMR és l'ús del sistema de fitxers EMR (EMRFS), que emmagatzema dades a S3 en lloc dels mateixos nodes.

Un repte que vam trobar va ser que EMR tenia opcions d'alta disponibilitat limitades, cosa que ens limitava a executar diversos nodes principals en una sola zona de disponibilitat o un node principal en diverses zones de disponibilitat. Aquest risc es va mitigar aprofitant EMRFS, ja que proporcionava una tolerància a errors addicional per a la recuperació de desastres i la desacoblament de l'emmagatzematge de dades de les funcions de càlcul. En utilitzar EMR com a solució per a Hbase, podem millorar la nostra escalabilitat i la recuperació d'errors, i minimitzar la intervenció manual necessària per mantenir els clústers. Finalment, vam decidir que EMR era el millor per a les nostres necessitats.

El procés de migració es va provar i executar fàcilment per endavant per migrar milers de milions de registres als nous clústers EMR sense cap temps d'inactivitat del client. Els nous clústers van mostrar un rendiment millorat i una reducció de costos gairebé un 40%. Per obtenir més informació sobre com passar a EMR va ajudar a reduir els costos d'infraestructura i millorar el nostre rendiment, fes una ullada Cas pràctic de Sprout Social amb AWS.

El que hem après

La mida i l'abast d'aquest projecte ens va donar a nosaltres, l'equip d'enginyeria de fiabilitat de la base de dades d'infraestructura, l'oportunitat de treballar de manera transversal amb diversos equips d'enginyeria. Tot i que va ser un repte, va resultar ser un exemple increïble dels projectes a gran escala que podem abordar a Sprout com a organització d'enginyeria col·laborativa. Amb aquest projecte, el nostre equip d'Infraestructura va obtenir una comprensió més profunda de com s'utilitzen, s'emmagatzemen i es processen les dades de Sprout, i estem més equipats per ajudar a resoldre problemes futurs. Hem creat una base de coneixement comú entre diversos equips que ens pot ajudar a crear la propera generació de funcions per als clients.

Si estàs interessat en el que estem construint, uneix-te al nostre equip i sol·licita per a una de les nostres funcions d'enginyeria oberta avui.

Comparteix Amb Els Teus Amics: