Sprout Social je v svojem bistvu podjetje, ki temelji na podatkih. Sprout vsak dan obdela milijarde sporočil iz več družbenih omrežij. Zaradi tega se inženirji Sprout soočajo z edinstvenim izzivom – kako shraniti in posodobiti več različic istega sporočila (tj. ponovnih tvitov, komentarjev itd.), ki pridejo na našo platformo v zelo veliki količini.



Ker shranjujemo več različic sporočil, so inženirji Sprouta zadolženi za »ponovno ustvarjanje sveta« večkrat na dan – bistven proces, ki zahteva ponavljanje celotnega nabora podatkov za združitev vsakega dela družbenega sporočila v en »vir resnice«.



Na primer spremljanje všečkov, komentarjev in ponovnih tvitov posamezne objave na Twitterju. Zgodovinsko gledano smo se za vzdrževanje in delo s tako velikimi količinami podatkov zanašali na samoupravljane gruče Hadoop. Vsaka gruča Hadoop bi bila odgovorna za različne dele platforme Sprout – praksa, na katero se zanaša celotna inženirska ekipa Sprout za upravljanje velikih podatkovnih projektov v velikem obsegu.

Ključ do velikega podatkovnega pristopa podjetja Sprout

Naš ekosistem Hadoop je bil odvisen od Apache Hbase, razširljive in porazdeljene baze podatkov NoSQL. Zaradi česar je Hbase ključnega pomena za naš pristop k obdelavi velikih podatkov, je njegova zmožnost ne samo hitrega skeniranja celotnega niza podatkov, ampak tudi hitrega, naključnega iskanja posameznih zapisov.

Hbase nam omogoča tudi množično nalaganje podatkov in posodabljanje naključnih podatkov, tako da lahko lažje obravnavamo sporočila, ki prihajajo po napačnem vrstnem redu ali z delnimi posodobitvami, in druge izzive, ki jih prinašajo podatki družbenih medijev. Vendar pa samoupravljane gruče Hadoop obremenjujejo naše infrastrukturne inženirje z visokimi operativnimi stroški, vključno z ročnim upravljanjem obnovitve po katastrofi, širitvijo gruče in upravljanjem vozlišč.

Da bi pomagali zmanjšati količino časa, ki izhaja iz upravljanja teh sistemov s stotinami terabajtov podatkov, so se Sproutove ekipe za infrastrukturo in razvoj združile, da bi poiskale boljšo rešitev od izvajanja samoupravljanih gruč Hadoop. Naši cilji so bili:

  • Inženirjem Sprout omogočite boljšo gradnjo, upravljanje in upravljanje velikih podatkovnih nizov
  • Zmanjšajte časovne naložbe inženirjev za ročno lastništvo in vzdrževanje sistema
  • Zmanjšajte nepotrebne stroške prekomernega zagotavljanja zaradi širitve gruče
  • Zagotovite boljše metode za obnovitev po katastrofi in zanesljivost

Ko smo ocenjevali alternative našemu trenutnemu sistemu velikih podatkov, smo si prizadevali najti rešitev, ki bi se zlahka integrirala z našo trenutno obdelavo in vzorci ter bi razbremenila operativno napor, ki ga prinaša ročno upravljanje gruče.



Ocenjevanje novih alternativ podatkovnih vzorcev

Ena od rešitev, o kateri so razmišljale naše ekipe, so bila podatkovna skladišča. Podatkovna skladišča delujejo kot centralizirana shramba za analizo in združevanje podatkov, vendar so bolj podobna tradicionalnim relacijskim bazam podatkov v primerjavi s Hbase. Njihovi podatki so strukturirani, filtrirani in imajo strog podatkovni model (tj. imajo eno vrstico za en predmet).

angel številka 311

Za naš primer uporabe shranjevanja in obdelave družabnih sporočil, ki imajo veliko različic sporočila, ki živijo drug ob drugem, so imela podatkovna skladišča neučinkovit model za naše potrebe. Našega obstoječega modela nismo mogli učinkovito prilagoditi podatkovnim skladiščem in delovanje je bilo veliko počasnejše, kot smo pričakovali. Preoblikovanje naših podatkov, da bi se prilagodili modelu podatkovnega skladišča, bi zahtevalo velike stroške za preoblikovanje v časovnici, ki smo jo imeli.

Druga rešitev, ki smo jo preučili, so bile hiše podatkovnih jezer. Podatkovne jezerce razširjajo koncepte podatkovnih skladišč, da omogočajo manj strukturirane podatke, cenejše shranjevanje in dodatno plast varnosti okoli občutljivih podatkov. Čeprav so podatkovna skladišča ponujala več, kot bi lahko podatkovna skladišča, niso bila tako učinkovita kot naša trenutna rešitev Hbase. S preizkušanjem našega zapisa spajanja in vzorcev obdelave vstavljanja in brisanja nismo mogli ustvariti sprejemljivih zakasnitev pisanja za naša paketna opravila.



Zmanjšanje režijskih stroškov in vzdrževanja z AWS EMR

Glede na to, kar smo izvedeli o skladiščenju podatkov in rešitvah lakehouse, smo začeli iskati alternativna orodja, ki poganjajo upravljano Hbase. Medtem ko smo se odločili, da je naša trenutna uporaba Hbase učinkovita za to, kar počnemo pri Sproutu, smo se vprašali: 'Kako lahko bolje izvajamo Hbase, da zmanjšamo naše operativno breme, hkrati pa ohranimo naše glavne vzorce uporabe?'

Takrat smo začeli ocenjevati Amazonovo upravljano storitev Elastic Map Reduce (EMR) za Hbase. Ocenjevanje EMR je zahtevalo oceno njegove učinkovitosti na enak način, kot smo testirali podatkovna skladišča in jezera, kot je testiranje vnosa podatkov, da bi ugotovili, ali lahko izpolni naše zahteve glede zmogljivosti. Preizkusiti smo morali tudi shranjevanje podatkov, visoko razpoložljivost in obnovitev po katastrofi, da bi zagotovili, da EMR ustreza našim potrebam z infrastrukturnega/administrativnega vidika.

Funkcije EMR so izboljšale našo trenutno samoupravljano rešitev in nam omogočile ponovno uporabo trenutnih vzorcev za branje, pisanje in izvajanje opravil na enak način kot s Hbase. Ena največjih prednosti EMR je uporaba datotečnega sistema EMR (EMRFS), ki shranjuje podatke v S3 in ne v samih vozliščih.

Izziv, ki smo ga ugotovili, je bil, da ima EMR omejene možnosti visoke razpoložljivosti, kar nas omejuje na izvajanje več glavnih vozlišč v enem območju razpoložljivosti ali enega glavnega vozlišča v več območjih razpoložljivosti. To tveganje je bilo zmanjšano z uporabo EMRFS, saj je zagotovil dodatno odpornost na napake za obnovitev po katastrofi in ločevanje shranjevanja podatkov od računalniških funkcij. Z uporabo EMR kot naše rešitve za Hbase lahko izboljšamo našo razširljivost in obnovitev napak ter zmanjšamo ročno posredovanje, potrebno za vzdrževanje gruč. Na koncu smo se odločili, da EMR najbolj ustreza našim potrebam.

Postopek selitve je bil predhodno preprosto preizkušen in izveden za selitev milijard zapisov v nove gruče EMR brez izpadov strank. Novi grozdi so pokazali izboljšano zmogljivost in zmanjšali stroške za skoraj 40 %. Če želite prebrati več o tem, kako je prehod na EMR pomagal zmanjšati stroške infrastrukture in izboljšati našo učinkovitost, si oglejte Študija primera družbe Sprout Social z AWS.

18 pomen angelskega števila

Kaj smo se naučili

Velikost in obseg tega projekta sta nam, ekipi Infrastructure Database Reliability Engineering, dala priložnost za medfunkcionalno delo z več inženirskimi ekipami. Čeprav je bilo zahtevno, se je izkazalo za neverjeten primer obsežnih projektov, ki se jih lahko lotimo v Sproutu kot sodelovalni inženirski organizaciji. S tem projektom je naša skupina za infrastrukturo pridobila globlje razumevanje, kako se podatki Sprouta uporabljajo, shranjujejo in obdelujejo, in smo bolje opremljeni za pomoč pri odpravljanju prihodnjih težav. Ustvarili smo skupno bazo znanja v več ekipah, ki nam lahko pomaga pri gradnji naslednje generacije funkcij za stranke.

Če vas zanima, kaj gradimo, pridruži se naši ekipi in se prijavi za eno od naših današnjih odprtih inženirskih vlog.

Delite S Prijatelji: