Reinventare l'approccio di Sprout Social ai big data

Sprout Social è, in sostanza, un'azienda basata sui dati. Sprout elabora miliardi di messaggi da più social network ogni giorno. Per questo motivo, gli ingegneri di Sprout devono affrontare una sfida unica: come archiviare e aggiornare più versioni dello stesso messaggio (ad esempio retweet, commenti e così via) che arrivano sulla nostra piattaforma a un volume molto elevato.

Poiché memorizziamo più versioni dei messaggi, gli ingegneri di Sprout hanno il compito di "ricreare il mondo" più volte al giorno, un processo essenziale che richiede l'iterazione dell'intero set di dati per consolidare ogni parte di un messaggio social in una "fonte di verità".

Ad esempio, tenere traccia dei Mi piace, dei commenti e dei retweet di un singolo post su Twitter. Storicamente, ci siamo affidati a cluster Hadoop autogestiti per gestire e gestire quantità così grandi di dati. Ogni cluster Hadoop sarebbe responsabile di diverse parti della piattaforma Sprout, una pratica su cui fa affidamento tutto il team di ingegneri di Sprout per gestire i progetti di big data su larga scala.

Le chiavi dell'approccio ai big data di Sprout

Il nostro ecosistema Hadoop dipendeva da Apache Hbase, un database NoSQL scalabile e distribuito. Ciò che rende Hbase cruciale per il nostro approccio all'elaborazione dei big data è la sua capacità non solo di eseguire scansioni rapide su interi set di dati, ma anche di eseguire ricerche rapide, casuali e di singoli record.

Hbase ci consente inoltre di caricare in blocco dati e aggiornare dati casuali in modo da poter gestire più facilmente i messaggi che arrivano fuori servizio o con aggiornamenti parziali e altre sfide che derivano dai dati dei social media. Tuttavia, i cluster Hadoop autogestiti gravano sui nostri ingegneri dell'infrastruttura con costi operativi elevati, inclusa la gestione manuale del ripristino di emergenza, l'espansione del cluster e la gestione dei nodi.

Per contribuire a ridurre la quantità di tempo che deriva dalla gestione di questi sistemi con centinaia di terabyte di dati, i team di infrastruttura e sviluppo di Sprout si sono riuniti per trovare una soluzione migliore rispetto all'esecuzione di cluster Hadoop autogestiti. I nostri obiettivi erano:

• Consenti agli ingegneri di Sprout di creare, gestire e utilizzare in modo migliore set di dati di grandi dimensioni
• Riduci al minimo l'investimento di tempo da parte degli ingegneri per possedere e mantenere manualmente il sistema
• Taglia i costi inutili di overprovisioning dovuti all'espansione del cluster
• Fornire migliori metodi di ripristino di emergenza e affidabilità

Mentre valutavamo le alternative al nostro attuale sistema di big data, ci siamo sforzati di trovare una soluzione che si integrasse facilmente con la nostra elaborazione e i nostri modelli attuali e che alleviasse la fatica operativa che deriva dalla gestione manuale di un cluster.

Valutazione di nuove alternative di modelli di dati

Una delle soluzioni prese in considerazione dai nostri team erano i data warehouse. I data warehouse fungono da archivio centralizzato per l'analisi e l'aggregazione dei dati, ma assomigliano più da vicino ai database relazionali tradizionali rispetto a Hbase. I loro dati sono strutturati, filtrati e hanno un modello di dati rigoroso (cioè con una singola riga per un singolo oggetto).

Per il nostro caso d'uso di archiviazione ed elaborazione di messaggi social che hanno molte versioni di un messaggio che vivono fianco a fianco, i data warehouse avevano un modello inefficiente per le nostre esigenze. Non siamo stati in grado di adattare efficacemente il nostro modello esistente ai data warehouse e le prestazioni sono state molto più lente di quanto previsto. La riformattazione dei nostri dati per adattarli al modello di data warehouse richiederebbe un notevole sovraccarico per la rielaborazione nella sequenza temporale che avevamo.

Un'altra soluzione che abbiamo esaminato sono state le case sul lago di dati. I data lakehouse espandono i concetti di data warehouse per consentire dati meno strutturati, storage più economico e un ulteriore livello di sicurezza intorno ai dati sensibili. Anche se i data lakehouse offrivano più di quello che potevano fare i data warehouse, non erano efficienti quanto la nostra attuale soluzione Hbase. Attraverso il test del nostro record di unione e dei nostri modelli di elaborazione di inserimento ed eliminazione, non siamo stati in grado di generare latenze di scrittura accettabili per i nostri processi batch.

Riduzione dei costi generali e della manutenzione con AWS EMR

Alla luce di ciò che abbiamo appreso sulle soluzioni di data warehousing e lakehouse, abbiamo iniziato a esaminare strumenti alternativi che eseguono Hbase gestito. Mentre decidevamo che il nostro attuale utilizzo di Hbase fosse efficace per ciò che facciamo in Sprout, ci siamo chiesti: "Come possiamo eseguire meglio Hbase per ridurre il nostro carico operativo pur mantenendo i nostri principali modelli di utilizzo?"

Questo è il momento in cui abbiamo iniziato a valutare il servizio gestito Elastic Map Reduce (EMR) di Amazon per Hbase. La valutazione di EMR ha richiesto di valutarne le prestazioni nello stesso modo in cui abbiamo testato data warehouse e lakehouse, ad esempio testando l'inserimento di dati per vedere se poteva soddisfare i nostri requisiti di prestazioni. Abbiamo anche dovuto testare l'archiviazione dei dati, l'alta disponibilità e il ripristino di emergenza per garantire che EMR soddisfacesse le nostre esigenze dal punto di vista infrastrutturale/amministrativo.

Le funzionalità di EMR hanno migliorato la nostra attuale soluzione autogestita e ci hanno permesso di riutilizzare i nostri modelli attuali per la lettura, la scrittura e l'esecuzione di lavori nello stesso modo in cui abbiamo fatto con Hbase. Uno dei maggiori vantaggi di EMR è l'uso del file system EMR (EMRFS), che archivia i dati in S3 anziché sui nodi stessi.

Una sfida che abbiamo riscontrato è stata che EMR aveva opzioni di disponibilità elevata limitate, che ci limitavano a eseguire più nodi principali in una singola zona di disponibilità o un nodo principale in più zone di disponibilità. Questo rischio è stato mitigato sfruttando EMRFS in quanto ha fornito ulteriore tolleranza ai guasti per il ripristino di emergenza e il disaccoppiamento dello storage dei dati dalle funzioni di calcolo. Utilizzando EMR come nostra soluzione per Hbase, siamo in grado di migliorare la nostra scalabilità e il ripristino dagli errori e ridurre al minimo l'intervento manuale necessario per mantenere i cluster. Alla fine, abbiamo deciso che EMR era la soluzione migliore per le nostre esigenze.

Il processo di migrazione è stato facilmente testato in anticipo ed eseguito per migrare miliardi di record ai nuovi cluster EMR senza tempi di inattività del cliente. I nuovi cluster hanno mostrato prestazioni migliorate e costi ridotti di quasi il 40%. Per saperne di più su come il passaggio a EMR ha contribuito a ridurre i costi dell'infrastruttura e migliorare le nostre prestazioni, consulta il case study di Sprout Social con AWS.

Cosa abbiamo imparato

Le dimensioni e la portata di questo progetto hanno dato a noi, il team di Infrastructure Database Reliability Engineering, l'opportunità di lavorare in modo interfunzionale con più team di ingegneri. Sebbene sia stato impegnativo, si è rivelato un incredibile esempio dei progetti su larga scala che possiamo affrontare in Sprout come organizzazione di ingegneria collaborativa. Attraverso questo progetto, il nostro team Infrastructure ha acquisito una comprensione più approfondita del modo in cui i dati di Sprout vengono utilizzati, archiviati ed elaborati e siamo più attrezzati per aiutare a risolvere i problemi futuri. Abbiamo creato una base di conoscenza comune tra più team che può aiutarci a creare la prossima generazione di funzionalità per i clienti.

Se sei interessato a ciò che stiamo costruendo, unisciti al nostro team e fai domanda per uno dei nostri ruoli di ingegneria aperti oggi.