Sistemi serverske analize

Ovo je drugi dio serije članaka o analitičkim sistemima (link do 1. dijela).

Danas nema sumnje da tačna obrada podataka i interpretacija rezultata mogu pomoći gotovo svakoj vrsti poslovanja. S tim u vezi, analitički sistemi postaju sve opterećeniji parametrima, raste broj okidača i korisničkih događaja u aplikacijama.
Zbog toga kompanije svojim analitičarima daju sve više "sirovih" informacija da ih analiziraju i pretvore u prave odluke. Ne treba potcenjivati ​​značaj analitičkog sistema za kompaniju, a sam sistem treba da bude pouzdan i održiv.

Klijentski analitičari

Client analytics je usluga koju kompanija povezuje za svoju web stranicu ili aplikaciju putem službenog SDK-a, integrira ga u vlastitu bazu koda i odabire pokretače događaja. Ovaj pristup ima očigledan nedostatak: svi prikupljeni podaci ne mogu se u potpunosti obraditi kako biste željeli, zbog ograničenja bilo koje odabrane usluge. Na primjer, na jednom sistemu neće biti lako pokrenuti MapReduce zadatke, na drugom nećete moći pokrenuti svoj model. Još jedan nedostatak će biti redovan (impresivan) račun za usluge.
Na tržištu postoji mnogo rješenja za analitiku klijenata, ali prije ili kasnije analitičari se susreću s činjenicom da ne postoji univerzalna usluga koja bi odgovarala bilo kojem zadatku (dok cijene svih ovih usluga stalno rastu). U takvoj situaciji kompanije se često odlučuju za kreiranje vlastitog analitičkog sistema sa svim potrebnim prilagođenim postavkama i funkcijama.

Server Analyst

Analitika na strani servera je usluga koja se može primijeniti interno na vlastitim serverima kompanije i (obično) interno. U ovom modelu, svi korisnički događaji se pohranjuju na internim serverima, omogućavajući programerima da isprobaju različite baze podataka za skladištenje i odaberu najprikladniju arhitekturu. Čak i ako i dalje želite koristiti analitiku treće strane za neke zadatke, to će i dalje biti moguće.
Analitika na strani servera može se primijeniti na dva načina. Prvo: odaberite neke uslužne programe otvorenog koda, implementirajte ih na svoje mašine i razvijte poslovnu logiku.

Plûsy
Minusy

Možete prilagoditi bilo šta
Često je to veoma 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.

Plûsy
Minusy

Može biti jeftiniji na srednjim količinama, ali sa velikim povećanjem i dalje će postati preskup
Nije moguće kontrolisati sve parametre

Administracija je u potpunosti prebačena na ramena pružaoca usluga
Nije uvijek poznato šta se nalazi unutar servisa (možda nije potrebno)

Kako prikupiti serversku analitiku

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

1. Prikupljanje podataka

Kao iu slučaju analitike klijenata, prije svega, analitičari kompanije odabiru tipove događaja koje žele dalje proučavati i prikupljaju ih u listu. Obično se ovi događaji dešavaju određenim redoslijedom, koji se naziva "šema događaja".
Nadalje, zamislimo da mobilna aplikacija (web stranica) ima redovne korisnike (uređaje) i mnogo servera. Za siguran prijenos događaja sa uređaja na servere, potreban je srednji sloj. Ovisno o arhitekturi, može se pojaviti nekoliko različitih redova događaja.
Apache Kafka Je pub/sub red, koji se koristi kao red za prikupljanje događaja.

Prema objavite na Quori 2014. godine, kreator Apache Kafke odlučio je da softver nazove po Franzu Kafki jer je „to sistem optimizovan za pisanje“ i zato što je voleo Kafkine spise. — Wikipedia

U našem primjeru postoji mnogo proizvođača podataka i njihovih potrošača (uređaja i servera), a Kafka pomaže da se međusobno povežu. Potrošači će biti detaljnije opisani u narednim koracima, gdje će oni biti glavni akteri. Sada ćemo razmotriti samo proizvođače podataka (događaje).
Kafka obuhvata koncepte reda i particije, konkretnije o tome je bolje pročitati na drugom mjestu (na primjer, u dokumentaciju). Ne ulazeći u detalje, zamislimo da je pokrenuta mobilna aplikacija za dva različita operativna sistema. Zatim svaka verzija kreira svoj zasebni tok događaja. Proizvođači šalju događaje Kafki, oni se snimaju u odgovarajućem redu.

(slika odavde)

U isto vrijeme, Kafka vam omogućava da čitate u komadima i obrađujete tok događaja u mini serijama. Kafka je vrlo zgodan alat koji se dobro prilagođava rastućim potrebama (na primjer, geolociranjem događaja).
Obično je dovoljan jedan sard, ali stvari se kompliciraju s komunikacijom prilikom skaliranja (kao i uvijek). Vjerovatno nitko ne želi koristiti samo jednu fizičku dionicu u proizvodnji, jer arhitektura mora biti tolerantna na greške. Osim Kafke, postoji još jedno dobro poznato rješenje - RabbitMQ. Nismo ga koristili u produkciji kao red za analizu događaja (ako imate takvo iskustvo, recite nam o tome u komentarima!). Međutim, korišten je AWS Kinesis.

Prije nego što pređemo na sljedeći korak, potrebno je spomenuti još jedan dodatni sloj sistema - skladištenje sirovih trupaca. Ovo nije obavezan sloj, ali će biti koristan u slučaju da nešto krene po zlu i da se redovi događaja u Kafki resetuju na nulu. Čuvanje neobrađenih dnevnika 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 postavili ih u odgovarajuće redove, prelazimo na korak obrade. Ovdje ću govoriti o dvije najčešće opcije obrade.
Prva opcija je da omogućite Spark Streaming na Apache sistemu. Svi Apache proizvodi žive na HDFS-u, bezbednom sistemu replika datoteka. Spark Streaming je alat lak za korištenje koji obrađuje streaming podatke i dobro se mjeri. Međutim, može biti teško održavati.
Druga opcija je da napravite svoj vlastiti obrađivač događaja. Da biste to učinili, na primjer, trebate napisati Python aplikaciju, ugraditi je u Docker i pretplatiti se na Kafkine redove. Kada okidači dođu do rukovatelja u dockeru, obrada će započeti. Uz ovu metodu, morate stalno pokretati aplikacije.
Pretpostavimo da smo odabrali jednu od gore opisanih opcija i prijeđimo na samu obradu. Procesori bi trebali početi provjeravanjem valjanosti podataka, filtriranjem smeća i "pokvarenih" događaja. Za validaciju obično koristimo cerberus. Nakon toga se može izvršiti mapiranje podataka: podaci iz različitih izvora se normalizuju i standardizuju kako bi se dodali u zajedničku tabelu.

3. Baza podataka

Treći korak je spremanje normaliziranih događaja. Kada radimo sa gotovim analitičkim sistemom, često ćemo morati da im pristupimo, pa je važno odabrati prikladnu bazu podataka.
Ako se podaci dobro uklapaju u fiksnu šemu, možete birati clickhouse ili neku drugu bazu podataka kolona. Dakle, agregacije će raditi vrlo brzo. Nedostatak je što je shema strogo fiksirana i stoga neće raditi za dodavanje proizvoljnih objekata bez preciziranja (na primjer, kada se dogodi nestandardni događaj). Ali to se može uraditi veoma 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 podići nešto jednostavnije, npr. MongoDB. Prilično je spor čak i za male količine. Ali plus je što je vrlo jednostavan i stoga pogodan za početak.

4. Agregacije

Pošto smo pažljivo sačuvali sve događaje, želimo da prikupimo sve važne informacije iz serije koja je stigla i ažuriramo bazu podataka. Globalno, želimo relevantne kontrolne table i metrike. Na primjer, od događaja za prikupljanje korisničkog profila i na neki način mjerenje ponašanja. Događaji se agregiraju, prikupljaju i ponovo spremaju (već u korisničkim tabelama). Istovremeno, moguće je izgraditi sistem na način da je filter povezan i sa koordinirajućim agregatorom: da prikuplja korisnike samo iz određene vrste događaja.
Nakon toga, ako nekome u timu treba samo analitika visokog nivoa, možete povezati eksterne analitičke sisteme. Možete ponovo uzeti Mixpanel. ali pošto je to prilično skupo, ne šalju se svi korisnički događaji tamo, već samo ono što je potrebno. Da bismo to učinili, moramo kreirati koordinatora koji će prenijeti neke neobrađene događaje ili nešto što smo sami ranije agregirali na vanjske sisteme, API-je ili platforme za oglašavanje.

5. Frontend

Potrebno je da povežete frontend sa kreiranim sistemom. Dobar primjer je usluga. redash, je GUI baze podataka koji pomaže u izgradnji panela. Kako funkcionira interakcija:

1. Korisnik postavlja SQL upit.
2. Kao odgovor, dobija znak.
3. Kreira 'novu vizualizaciju' za to i dobija prekrasan grafikon koji već možete sami sačuvati.

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

zaključak

Nakon što završite sve gore navedene korake, kreirat ćete svoju analitiku na strani servera. Imajte na umu da ovo nije tako jednostavno kao jednostavno povezivanje analitike klijenta, jer sve morate sami konfigurirati. Stoga, prije kreiranja vlastitog sistema, vrijedi uporediti potrebu za ozbiljnim analitičkim sistemom sa resursima koje ste spremni da mu dodijelite.
Ako ste sve izračunali i otkrili da su troškovi previsoki, u sljedećem dijelu ću govoriti o tome kako napraviti jeftiniju verziju back-end analitike.

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

izvor: www.habr.com