Sprout Social savā būtībā ir uz datiem balstīts uzņēmums. Sprout katru dienu apstrādā miljardiem ziņojumu no vairākiem sociālajiem tīkliem. Tādēļ Sprout inženieri saskaras ar unikālu izaicinājumu — kā saglabāt un atjaunināt vairākas viena un tā paša ziņojuma versijas (t.i., retvītus, komentārus utt.), kas mūsu platformā nonāk ļoti lielā apjomā.



Tā kā mēs glabājam vairākas ziņojumu versijas, Sprout inženieru uzdevums ir “atjaunot pasauli” vairākas reizes dienā — tas ir būtisks process, kurā ir nepieciešams atkārtot visu datu kopu, lai katru sociālā ziņojuma daļu apvienotu vienā “patiesības avotā”.



ko nozīmē 110

Piemēram, sekot līdzi vienas Twitter ziņas atzīmei Patīk, komentāriem un retvītiem. Vēsturiski mēs esam paļāvušies uz pašu pārvaldītām Hadoop klasteriem, lai uzturētu un apstrādātu tik lielu datu apjomu. Katrs Hadoop klasteris būtu atbildīgs par dažādām Sprout platformas daļām — šī prakse tiek izmantota visā Sprout inženieru komandā, lai plašā mērogā pārvaldītu lielus datu projektus.

Atslēgas Sprout lielo datu pieejai

Mūsu Hadoop ekosistēma bija atkarīga no Apache Hbase — mērogojamas un izplatītas NoSQL datu bāzes. Hbase ir ļoti svarīga mūsu pieejai lielu datu apstrādei, jo tā spēj ne tikai veikt ātrā diapazona skenēšanu visās datu kopās, bet arī veikt ātru, nejaušu, viena ieraksta meklēšanu.

Hbase arī ļauj mums lielapjomā ielādēt datus un atjaunināt nejaušus datus, lai mēs varētu vieglāk apstrādāt ziņojumus, kas nonāk ne kārtībā vai ar daļējiem atjauninājumiem, kā arī citas problēmas, kas saistītas ar sociālo mediju datiem. Tomēr pašpārvaldītas Hadoop klasteri apgrūtina mūsu infrastruktūras inženierus ar augstām darbības izmaksām, tostarp manuāli pārvaldot avārijas seku atkopšanu, klasteru paplašināšanu un mezglu pārvaldību.

Lai palīdzētu samazināt laiku, kas nepieciešams šo sistēmu pārvaldīšanai ar simtiem terabaitu datu, Sprout infrastruktūras un attīstības komandas sanāca kopā, lai atrastu labāku risinājumu nekā pašpārvaldīto Hadoop klasteru vadīšana. Mūsu mērķi bija:

  • Ļaujiet Sprout inženieriem labāk izveidot, pārvaldīt un darbināt lielas datu kopas
  • Samaziniet laika ieguldījumu no inženieriem, lai manuāli pārvaldītu un uzturētu sistēmu
  • Samaziniet nevajadzīgās izmaksas, kas saistītas ar pārmērīgu nodrošinājumu klasteru paplašināšanas dēļ
  • Nodrošiniet labākas avārijas seku novēršanas metodes un uzticamību

Izvērtējot alternatīvas mūsu pašreizējai lielo datu sistēmai, mēs centāmies atrast risinājumu, kas būtu viegli integrējams ar mūsu pašreizējo apstrādi un modeļiem un atvieglotu darbību, kas saistīta ar klastera manuālu pārvaldību.



Jaunu datu modeļa alternatīvu izvērtēšana

Viens no risinājumiem, ko mūsu komandas apsvēra, bija datu noliktavas. Datu noliktavas darbojas kā centralizēts datu analīzes un apkopošanas veikals, bet vairāk līdzinās tradicionālajām relāciju datu bāzēm salīdzinājumā ar Hbase. Viņu dati ir strukturēti, filtrēti, un tiem ir stingrs datu modelis (t.i., vienam objektam ir viena rinda).

Mūsu izmantošanas gadījumā, glabājot un apstrādājot sociālos ziņojumus, kuriem blakus ir vairākas ziņojuma versijas, datu noliktavām bija mūsu vajadzībām neefektīvs modelis. Mēs nevarējām efektīvi pielāgot savu esošo modeli datu noliktavām, un veiktspēja bija daudz lēnāka, nekā mēs gaidījām. Datu pārformatēšana, lai pielāgotos datu noliktavas modelim, prasīs lielas pieskaitāmās izmaksas, lai pārstrādātu mūsu rīcībā esošajā laika grafikā.

Vēl viens risinājums, ko mēs izskatījām, bija datu ezeru mājas. Datu ezeru mājas paplašina datu noliktavas koncepcijas, lai nodrošinātu mazāk strukturētus datus, lētāku uzglabāšanu un papildu drošības līmeni ap sensitīviem datiem. Lai gan datu noliktavas piedāvāja vairāk nekā datu noliktavas, tās nebija tik efektīvas kā mūsu pašreizējais Hbase risinājums. Pārbaudot sapludināšanas ierakstu un ievietošanas un dzēšanas apstrādes modeļus, mēs nevarējām ģenerēt pieņemamus rakstīšanas latentumus saviem pakešdarbiem.



Samaziniet pieskaitāmās izmaksas un apkopi, izmantojot AWS EMR

Ņemot vērā to, ko uzzinājām par datu noliktavas un ezera glabāšanas risinājumiem, mēs sākām meklēt alternatīvus rīkus, kuros darbojas pārvaldītā Hbase. Kamēr mēs nolēmām, ka mūsu pašreizējā Hbase izmantošana ir efektīva tam, ko mēs darām Sprout, mēs sev jautājām: “Kā mēs varam labāk palaist Hbase, lai samazinātu mūsu darbības slogu, vienlaikus saglabājot mūsu galvenos lietošanas veidus?”

Šajā laikā mēs sākām novērtēt Amazon elastīgo karšu samazināšanas (EMR) pārvaldīto pakalpojumu Hbase. Lai novērtētu EMR, bija jānovērtē tā veiktspēja tādā pašā veidā, kā mēs pārbaudījām datu noliktavas un ezeru noliktavas, piemēram, pārbaudot datu uzņemšanu, lai noskaidrotu, vai tas atbilst mūsu veiktspējas prasībām. Mums bija arī jāpārbauda datu glabāšana, augsta pieejamība un avārijas atkopšana, lai nodrošinātu, ka EMR atbilst mūsu vajadzībām no infrastruktūras/administratīvā viedokļa.

EMR funkcijas uzlaboja mūsu pašreizējo pašpārvaldīto risinājumu un ļāva mums atkārtoti izmantot pašreizējos lasīšanas, rakstīšanas un darbu izpildes modeļus tāpat kā ar Hbase. Viena no lielākajām EMR priekšrocībām ir EMR failu sistēmas (EMRFS) izmantošana, kas datus glabā S3, nevis pašos mezglos.

Problēma, ko atklājām, bija tas, ka EMR bija ierobežotas augstas pieejamības iespējas, kas liedza mums darbināt vairākus galvenos mezglus vienā pieejamības zonā vai vienu galveno mezglu vairākās pieejamības zonās. Šis risks tika samazināts, izmantojot EMRFS, jo tas nodrošināja papildu kļūdu toleranci katastrofu atkopšanai un datu krātuves atsaisti no skaitļošanas funkcijām. Izmantojot EMR kā mūsu Hbase risinājumu, mēs varam uzlabot savu mērogojamību un kļūdu atkopšanu, kā arī samazināt manuālo iejaukšanos, kas nepieciešama kopu uzturēšanai. Galu galā mēs nolēmām, ka EMR ir vislabāk piemērota mūsu vajadzībām.

Migrācijas process tika viegli pārbaudīts iepriekš un izpildīts, lai migrētu miljardiem ierakstu uz jaunajām EMR kopām bez klientu dīkstāves. Jaunie klasteri uzrādīja uzlabotu veiktspēju un samazināja izmaksas par gandrīz 40%. Lai uzzinātu vairāk par to, kā pāreja uz EMR palīdzēja samazināt infrastruktūras izmaksas un uzlabot mūsu veiktspēju, skatiet Sprout Social gadījuma izpēte ar AWS.

Ko mēs uzzinājām

Šī projekta apjoms un apjoms deva mums, infrastruktūras datu bāzes uzticamības inženieru komandai, iespēju sadarboties ar vairākām inženieru komandām. Lai gan tas bija sarežģīti, tas izrādījās neticams piemērs liela mēroga projektiem, kurus mēs varam risināt Sprout kā sadarbības inženieru organizācija. Izmantojot šo projektu, mūsu infrastruktūras komanda ieguva dziļāku izpratni par to, kā Sprout dati tiek izmantoti, glabāti un apstrādāti, un mēs esam labāk sagatavoti, lai palīdzētu novērst turpmākās problēmas. Mēs esam izveidojuši kopīgu zināšanu bāzi vairākām komandām, kas var palīdzēt mums izveidot nākamās paaudzes klientu funkcijas.

Ja jūs interesē tas, ko mēs veidojam, pievienojies mūsu komandai un piesakies vienai no mūsu atvērtajām inženieru lomām šodien.

Dalieties Ar Draugiem: