Sprout Social je ve svém jádru společnost založená na datech. Sprout zpracovává miliardy zpráv z různých sociálních sítí každý den. Z tohoto důvodu čelí inženýři Sprout jedinečné výzvě – jak uložit a aktualizovat více verzí stejné zprávy (tj. retweety, komentáře atd.), které přicházejí na naši platformu ve velmi velkém objemu.



Vzhledem k tomu, že ukládáme více verzí zpráv, mají inženýři Sprout za úkol několikrát denně „obnovit svět“ – což je základní proces, který vyžaduje iteraci celého souboru dat, aby se každá část sociální zprávy sjednotila do jednoho „zdroje pravdy“.



Například sledování lajků, komentářů a retweetů jednoho příspěvku na Twitteru. Historicky jsme se při údržbě a práci s tak velkým množstvím dat spoléhali na samostatně spravované clustery Hadoop. Každý cluster Hadoop by byl zodpovědný za různé části platformy Sprout – postup, na který se spoléhá celý inženýrský tým Sprout při řízení velkých datových projektů ve velkém měřítku.

Klíče k přístupu Sprout k velkým datům

Náš ekosystém Hadoop závisel na Apache Hbase, škálovatelné a distribuované databázi NoSQL. To, co dělá Hbase zásadní pro náš přístup ke zpracování velkých dat, je jeho schopnost nejen provádět rychlé skenování celých datových sad, ale také provádět rychlé, náhodné vyhledávání jednotlivých záznamů.

Hbase nám také umožňuje hromadně načítat data a aktualizovat náhodná data, abychom mohli snadněji zpracovávat zprávy přicházející mimo provoz nebo s částečnými aktualizacemi a další výzvy, které s sebou přináší data ze sociálních sítí. Samospravované clustery Hadoop však zatěžují naše inženýry infrastruktury vysokými provozními náklady, včetně ruční správy obnovy po havárii, rozšíření clusteru a správy uzlů.

Aby pomohly zkrátit množství času, který pochází ze správy těchto systémů se stovkami terabajtů dat, spojily se týmy pro infrastrukturu a vývoj společnosti Sprout, aby našly lepší řešení, než je provozování samostatně spravovaných clusterů Hadoop. Naše cíle byly:

  • Umožněte inženýrům Sproutu lépe sestavovat, spravovat a provozovat velké soubory dat
  • Minimalizujte časovou investici inženýrů do manuálního vlastnictví a údržby systému
  • Snižte zbytečné náklady na nadměrné poskytování služeb v důsledku expanze clusteru
  • Poskytujte lepší metody obnovy po havárii a spolehlivost

Když jsme vyhodnocovali alternativy k našemu současnému systému velkých dat, snažili jsme se najít řešení, které se snadno integruje s naším současným zpracováním a vzory a ulehčí nám provozní dřinu spojenou s ruční správou clusteru.



Vyhodnocování nových alternativ datových vzorů

Jedním z řešení, které naše týmy zvažovaly, byly datové sklady. Datové sklady fungují jako centralizované úložiště pro analýzu a agregaci dat, ale ve srovnání s Hbase se více podobají tradičním relačním databázím. Jejich data jsou strukturovaná, filtrovaná a mají striktní datový model (tj. mají jeden řádek pro jeden objekt).

význam 455

Pro náš případ použití ukládání a zpracování sociálních zpráv, které mají mnoho verzí zpráv žijících vedle sebe, měly datové sklady pro naše potřeby neefektivní model. Náš stávající model jsme nebyli schopni efektivně přizpůsobit datovým skladům a výkon byl mnohem pomalejší, než jsme očekávali. Přeformátování našich dat, aby se přizpůsobila modelu datového skladu, by vyžadovalo velkou režii na přepracování v časové ose, kterou jsme měli.

Dalším řešením, které jsme zkoumali, byly datové jezerní domy. Data lakehouses rozšiřují koncepty datových skladů, aby umožnily méně strukturovaná data, levnější úložiště a další vrstvu zabezpečení kolem citlivých dat. Data lakehouse sice nabízely více, než mohly datové sklady, nebyly však tak efektivní jako naše současné řešení Hbase. Prostřednictvím testování našeho slučovacího záznamu a našich vzorů zpracování vkládání a mazání jsme nebyli schopni vygenerovat přijatelné latence zápisu pro naše dávkové úlohy.



Snížení režie a údržby s AWS EMR

Vzhledem k tomu, co jsme se dozvěděli o řešeních datových skladů a lakehouse, jsme se začali zabývat alternativními nástroji provozujícími spravovaný Hbase. I když jsme se rozhodli, že naše současné použití Hbase je efektivní pro to, co děláme ve Sprout, zeptali jsme se sami sebe: „Jak můžeme provozovat Hbase lépe, abychom snížili naši provozní zátěž a zároveň zachovali naše hlavní vzorce používání?

Tehdy jsme začali vyhodnocovat spravovanou službu Amazon Elastic Map Reduce (EMR) pro Hbase. Hodnocení EMR vyžadovalo posouzení jeho výkonu stejným způsobem, jakým jsme testovali datové sklady a jezerní domy, jako je testování příjmu dat, abychom zjistili, zda může splňovat naše požadavky na výkon. Museli jsme také otestovat ukládání dat, vysokou dostupnost a obnovu po havárii, abychom zajistili, že EMR vyhovuje našim potřebám z hlediska infrastruktury/administrativy.

Funkce EMR vylepšily naše současné samospravované řešení a umožnily nám znovu použít naše aktuální vzory pro čtení, zápis a spouštění úloh stejným způsobem, jako jsme to udělali s Hbase. Jednou z největších výhod EMR je použití systému souborů EMR (EMRFS), který ukládá data spíše do S3 než do samotných uzlů.

Problém, který jsme zjistili, spočíval v tom, že EMR mělo omezené možnosti vysoké dostupnosti, což nás omezovalo na provozování více hlavních uzlů v jedné zóně dostupnosti nebo jednoho hlavního uzlu ve více zónách dostupnosti. Toto riziko bylo zmírněno využitím EMRFS, protože poskytoval další odolnost proti chybám pro obnovu po havárii a oddělení datového úložiště od výpočetních funkcí. Použitím EMR jako našeho řešení pro Hbase jsme schopni zlepšit naši škálovatelnost a zotavení po selhání a minimalizovat ruční zásahy potřebné k údržbě clusterů. Nakonec jsme se rozhodli, že EMR je pro naše potřeby nejvhodnější.

Proces migrace byl předem snadno otestován a proveden za účelem migrace miliard záznamů do nových clusterů EMR bez jakéhokoli výpadku zákazníků. Nové clustery vykázaly lepší výkon a snížení nákladů o téměř 40 %. Chcete-li si přečíst více o tom, jak přechod na EMR pomohl snížit náklady na infrastrukturu a zlepšit náš výkon, podívejte se Případová studie společnosti Sprout Social s AWS.

Co jsme se naučili

Velikost a rozsah tohoto projektu nám, týmu Infrastructure Database Reliability Engineering, poskytl příležitost pracovat napříč funkcemi s více inženýrskými týmy. I když to bylo náročné, ukázalo se, že je to neuvěřitelný příklad velkých projektů, které můžeme ve společnosti Sprout jako kolaborativní inženýrská organizace řešit. Prostřednictvím tohoto projektu náš tým pro infrastrukturu hlouběji porozuměl tomu, jak jsou data společnosti Sprout používána, ukládána a zpracovávána, a my jsme lépe vybaveni k tomu, abychom pomohli odstraňovat budoucí problémy. Vytvořili jsme společnou znalostní základnu napříč několika týmy, která nám může pomoci vytvořit novou generaci zákaznických funkcí.

Pokud vás zajímá, co stavíme, připojte se k našemu týmu a přihlaste se pro jednu z našich dnešních otevřených inženýrských rolí.

Sdílej Se Svými Přáteli: