Sustavi poslužiteljske analitike

Ovo je drugi dio serije članaka o analitičkim sustavima (link na dio 1).

Danas nema sumnje da točna obrada podataka i interpretacija rezultata može pomoći gotovo svakoj vrsti poslovanja. S tim u vezi, analitički sustavi postaju sve opterećeniji parametrima, raste broj okidača i korisničkih događaja u aplikacijama.
Zbog toga tvrtke svojim analitičarima daju sve više i više "sirovih" informacija da ih analiziraju i pretvore u ispravne odluke. Ne treba podcjenjivati ​​važnost analitičkog sustava za tvrtku, a sam sustav treba biti pouzdan i održiv.

Analitičari klijenata

Client analytics je usluga koju tvrtka povezuje za svoje web mjesto ili aplikaciju putem službenog SDK-a, integrira ga u vlastitu bazu kodova i odabire okidače događaja. Ovaj pristup ima očitu manu: svi prikupljeni podaci ne mogu se obraditi u potpunosti na željeni način, zbog ograničenja bilo koje odabrane usluge. Na primjer, na jednom sustavu neće biti lako pokrenuti MapReduce zadatke, na drugom nećete moći pokrenuti svoj model. Još jedan nedostatak bit će redoviti (impresivan) račun za usluge.
Na tržištu postoji mnogo rješenja za klijentsku analitiku, ali prije ili kasnije analitičari se suoče s činjenicom da ne postoji jedinstvena univerzalna usluga prikladna za bilo koju zadaću (a cijene svih tih usluga konstantno rastu). U takvoj situaciji tvrtke se često odlučuju za izradu vlastitog analitičkog sustava sa svim potrebnim prilagođenim postavkama i značajkama.

Analitičari poslužitelja

Analitika na strani poslužitelja usluga je koja se može implementirati interno na vlastitim poslužiteljima tvrtke i (obično) unutar tvrtke. U ovom modelu, svi korisnički događaji pohranjuju se na interne poslužitelje, omogućujući programerima da isprobaju različite baze podataka za pohranu i odaberu najprikladniju arhitekturu. Čak i ako još uvijek želite koristiti analitiku na strani klijenta treće strane za neke zadatke, to će i dalje biti moguće.
Analitika na strani poslužitelja može se implementirati na dva načina. Prvo: odaberite neke uslužne programe otvorenog koda, implementirajte ih na svoje strojeve i razvijte poslovnu logiku.

Prozodija
Cons

Možete prilagoditi bilo što
Često je to vrlo teško i potrebni su zasebni programeri

Drugo: uzmite SaaS usluge (Amazon, Google, Azure) umjesto da ih sami implementirate. O SaaS-u ćemo detaljnije govoriti u trećem dijelu.

Prozodija
Cons

Može biti jeftinije na srednjim količinama, ali s velikim povećanjem će ipak postati preskupo
Nije moguće kontrolirati sve parametre

Administracija je u potpunosti prebačena na pleća pružatelja usluge
Nije uvijek poznato što je unutar usluge (možda nije potrebno)

Kako prikupiti analitiku poslužitelja

Ako želimo pobjeći od korištenja klijentske analitike i izgraditi vlastitu, prije svega moramo razmisliti o arhitekturi novog sustava. U nastavku ću vam reći korak po korak što trebate uzeti u obzir, zašto je svaki od koraka potreban i koje alate možete koristiti.

1. Prikupljanje podataka

Baš kao i u slučaju analitike klijenata, prvo analitičari tvrtke odabiru tipove događaja koje žele dalje proučavati i prikupljaju ih u listu. Obično se ti događaji odvijaju određenim redoslijedom koji se naziva "shema događaja".
Nadalje, zamislimo da mobilna aplikacija (web stranica) ima redovite korisnike (uređaje) i mnogo poslužitelja. Za siguran prijenos događaja s uređaja na poslužitelje potreban je srednji sloj. Ovisno o arhitekturi, može se pojaviti nekoliko različitih redova događaja.
Apache Kafka - Je pub/sub red čekanja, koji se koristi kao red čekanja za prikupljanje događaja.

Prema objaviti na Quori 2014. tvorac Apache Kafka odlučio je nazvati softver po Franzu Kafki jer je "to sustav optimiziran za pisanje" i jer je volio Kafkine spise. — Wikipedia

U našem primjeru postoji mnogo proizvođača podataka i njihovih potrošača (uređaja i poslužitelja), a Kafka pomaže u njihovom međusobnom povezivanju. Potrošači će biti detaljnije opisani u sljedećim koracima, gdje će oni biti glavni akteri. Sada ćemo razmotriti samo proizvođače podataka (događaje).
Kafka sažima koncepte reda i podjele, točnije o tome je bolje pročitati negdje drugdje (npr. dokumentacija). Ne ulazeći u detalje, zamislimo da je mobilna aplikacija pokrenuta za dva različita operativna sustava. Zatim svaka verzija stvara svoj zasebni tok događaja. Producenti šalju događaje Kafki, oni se bilježe u odgovarajućem redu.

(slika stoga)

U isto vrijeme, Kafka vam omogućuje čitanje u dijelovima i obradu tijeka događaja u mini-serijama. Kafka je vrlo prikladan alat koji se dobro prilagođava rastućim potrebama (na primjer, geolociranjem događaja).
Obično je dovoljan jedan shard, no stvari se kompliciraju s komunikacijom kod skaliranja (kao i uvijek). Vjerojatno nitko ne želi koristiti samo jedan fizički shard u proizvodnji, budući da arhitektura mora biti tolerantna na pogreške. Osim Kafke, postoji još jedno poznato rješenje - RabbitMQ. Nismo ga koristili u produkciji kao red čekanja za analizu događaja (ako imate takvo iskustvo, recite nam o tome u komentarima!). Međutim, korišten je AWS Kinesis.

Prije nego prijeđemo na sljedeći korak, potrebno je spomenuti još jedan dodatni sloj sustava - pohranjivanje neobrađenih zapisa. Ovo nije obavezan sloj, ali će biti koristan u slučaju da nešto pođe krivo i da se redovi događaja u Kafki ponište na nulu. Pohranjivanje sirovih zapisa ne zahtijeva složeno i skupo rješenje, možete ih jednostavno zapisati negdje ispravnim redoslijedom (čak i na tvrdi disk).

2. Rukovanje tokovima događaja

Nakon što smo pripremili sve događaje i smjestili ih u odgovarajuće redove, prelazimo na korak obrade. Ovdje ću govoriti o dvije najčešće opcije obrade.
Prva opcija je omogućiti Spark Streaming na Apache sustavu. Svi Apache proizvodi žive na HDFS-u, sigurnoj replici datotečnog sustava. Spark Streaming alat je jednostavan za korištenje koji obrađuje strujanje podataka i dobro se mjeri. Međutim, može biti teško održavati.
Druga je mogućnost da napravite vlastiti rukovatelj događajima. Da biste to učinili, na primjer, trebate napisati Python aplikaciju, izgraditi je u dockeru i pretplatiti se na Kafkine redove. Kada okidači dođu do rukovatelja u dockeru, započet će obrada. Ovom metodom morate neprestano pokretati aplikacije.
Pretpostavimo da smo odabrali jednu od gore opisanih opcija i prijeđimo na samu obradu. Procesori bi trebali započeti provjerom valjanosti podataka, filtriranjem smeća i "pokvarenih" događaja. Za provjeru valjanosti obično koristimo Cerberus. Nakon toga se može napraviti mapiranje podataka: podaci iz različitih izvora se normaliziraju i standardiziraju kako bi se dodali u zajedničku tablicu.

3. Baza podataka

Treći korak je spremanje normaliziranih događaja. Kada radimo s gotovim analitičkim sustavom, često ćemo im morati pristupati, stoga je važno odabrati prikladnu bazu podataka.
Ako se podaci dobro uklapaju u fiksnu shemu, možete birati klikanica ili neka druga baza podataka stupaca. Tako će agregacije raditi vrlo brzo. Loša strana je što je shema rigidno fiksna i stoga neće raditi dodavanje proizvoljnih objekata bez dorade (na primjer, kada se dogodi nestandardni događaj). Ali može se učiniti jako brzo.
Za nestrukturirane podatke, možete uzeti NoSQL, na primjer, Apache cassandra. Radi na HDFS-u, dobro se replicira, možete pokrenuti mnoge instance i otporan je na greške.
Možete podignuti nešto jednostavnije, npr. MongoDB. Prilično je spor čak i za male količine. Ali plus je što je vrlo jednostavan i stoga prikladan za početak.

4. Agregacije

Pažljivo pohranjujući sve događaje, želimo prikupiti sve važne informacije iz pristigle serije i ažurirati bazu podataka. Globalno, želimo relevantne nadzorne ploče i metrike. Na primjer, iz događaja prikupiti korisnički profil i nekako izmjeriti ponašanje. Događaji se agregiraju, prikupljaju i ponovno spremaju (već u korisničkim tablicama). Istovremeno, moguće je izgraditi sustav na način da se na koordinirajući agregator poveže i filter: prikupljati korisnike samo iz određene vrste događaja.
Nakon toga, ako netko u timu treba samo analitiku visoke razine, možete povezati vanjske analitičke sustave. Možete ponovno uzeti Mixpanel. ali pošto je prilično skup, tamo se ne šalju svi korisnički događaji, već samo ono što je potrebno. Da bismo to učinili, moramo stvoriti koordinatora koji će prenijeti neke sirove događaje ili nešto što smo sami ranije agregirali na vanjske sustave, API-je ili platforme za oglašavanje.

5. Prednji dio

Morate spojiti frontend na stvoreni sustav. Dobar primjer je usluga. preraditi, GUI je baze podataka koji pomaže u izradi ploča. Kako funkcionira interakcija:

1. Korisnik postavlja SQL upit.
2. Kao odgovor dobiva znak.
3. Stvara 'novu vizualizaciju' za to i dobiva prekrasan grafikon koji već možete sami spremiti.

Vizualizacije u servisu se automatski ažuriraju, možete konfigurirati i pratiti svoje praćenje. Redash je besplatan, u slučaju samostalnog hostinga, ali kao SaaS koštat će 50 USD mjesečno.

Zaključak

Nakon što dovršite sve gore navedene korake, izradit ćete analitiku na strani poslužitelja. Imajte na umu da to nije tako jednostavno kao samo povezivanje analitike klijenta, jer sve morate konfigurirati sami. Stoga, prije kreiranja vlastitog sustava, vrijedi usporediti potrebu za ozbiljnim analitičkim sustavom sa resursima koje ste spremni za njega izdvojiti.
Ako ste dobro izračunali i ustanovili da su troškovi previsoki, u sljedećem ću dijelu govoriti o tome kako napraviti jeftiniju verziju back-end analitike.

Hvala na čitanju! Bit će mi drago na pitanja u komentarima.

Izvor: www.habr.com