Strežniški analitični sistemi

To je drugi del serije člankov o analitičnih sistemih (povezava do 1. dela).

Danes ni dvoma, da lahko natančna obdelava podatkov in interpretacija rezultatov pomaga skoraj vsakemu poslu. V zvezi s tem postajajo analitični sistemi vedno bolj obremenjeni s parametri, število sprožilcev in uporabniških dogodkov v aplikacijah narašča.
Zaradi tega podjetja dajejo svojim analitikom vedno več »surovih« informacij, da jih analizirajo in spremenijo v prave odločitve. Ne gre podcenjevati pomena analitičnega sistema za podjetje, sam sistem pa mora biti zanesljiv in trajnosten.

Analitiki strank

Client analytics je storitev, ki jo podjetje prek uradnega SDK poveže za svojo spletno stran ali aplikacijo, jo integrira v lastno kodno bazo in izbere sprožilce dogodkov. Ta pristop ima očitno pomanjkljivost: vseh zbranih podatkov ni mogoče v celoti obdelati, kot bi želeli, zaradi omejitev izbrane storitve. Na primer, v enem sistemu ne bo enostavno izvajati nalog MapReduce, v drugem ne boste mogli izvajati svojega modela. Druga pomanjkljivost bo reden (impresiven) račun za storitve.
Na trgu je veliko rešitev za analitiko strank, vendar se analitiki prej ali slej soočijo z dejstvom, da ni univerzalne storitve, primerne za vsako nalogo (cene vseh teh storitev pa nenehno rastejo). V takšni situaciji se podjetja pogosto odločijo ustvariti lasten analitični sistem z vsemi potrebnimi nastavitvami in funkcijami po meri.

Analitiki strežnikov

Strežniška analitika je storitev, ki jo je mogoče namestiti interno na lastnih strežnikih podjetja in (običajno) interno. V tem modelu so vsi uporabniški dogodki shranjeni na notranjih strežnikih, kar razvijalcem omogoča, da preizkusijo različne baze podatkov za shranjevanje in izberejo najprimernejšo arhitekturo. In tudi če še vedno želite uporabljati analitiko na strani odjemalca tretjih oseb za nekatere naloge, bo to še vedno mogoče.
Analitiko na strani strežnika je mogoče uvesti na dva načina. Prvič: izberite nekaj odprtokodnih pripomočkov, jih namestite na svoje stroje in razvijte poslovno logiko.

Pros
Proti

Karkoli lahko prilagodite
Pogosto je zelo težko in potrebni so ločeni razvijalci

Drugič: uporabite storitve SaaS (Amazon, Google, Azure), namesto da jih namestite sami. O SaaS bomo podrobneje govorili v tretjem delu.

Pros
Proti

Pri srednjih količinah je lahko cenejši, vendar bo ob velikem povečanju še vedno predrag
Ni mogoče nadzorovati vseh parametrov

Administracija je v celoti preložena na pleča ponudnika storitev
Ni vedno znano, kaj je znotraj storitve (morda ni potrebno)

Kako zbirati analitiko strežnika

Če želimo pobegniti od uporabe analitike strank in zgraditi lastno, moramo najprej razmisliti o arhitekturi novega sistema. Spodaj vam bom korak za korakom povedal, kaj morate upoštevati, zakaj je vsak od korakov potreben in katera orodja lahko uporabite.

1. Pridobivanje podatkov

Tako kot v primeru analitike strank analitiki podjetja najprej izberejo vrste dogodkov, ki jih želijo nadalje preučiti, in jih zberejo na seznam. Običajno se ti dogodki odvijajo v določenem vrstnem redu, ki se imenuje "shema dogodkov".
Nadalje si predstavljajmo, da ima mobilna aplikacija (spletna stran) redne uporabnike (naprave) in veliko strežnikov. Za varen prenos dogodkov iz naprav v strežnike je potrebna vmesna plast. Odvisno od arhitekture se lahko pojavi več različnih čakalnih vrst dogodkov.
Apache Kafka - Je pub/sub čakalna vrsta, ki se uporablja kot čakalna vrsta za zbiranje dogodkov.

Glede na objavite na Quori leta 2014 se je ustvarjalec Apache Kafka odločil programsko opremo poimenovati po Franzu Kafki, ker »je sistem, optimiziran za pisanje« in ker so mu bili všeč Kafkovi spisi. — Wikipedia

V našem primeru je veliko proizvajalcev podatkov in njihovih potrošnikov (naprav in strežnikov), Kafka pa jih pomaga povezati med seboj. Potrošniki bodo podrobneje opisani v naslednjih korakih, kjer bodo glavni akterji. Zdaj bomo upoštevali samo proizvajalce podatkov (dogodke).
Kafka povzema koncepta čakalne vrste in particije, natančneje o tem je bolje prebrati drugje (npr. dokumentacijo). Ne da bi se spuščali v podrobnosti, si predstavljajmo, da se zažene mobilna aplikacija za dva različna operacijska sistema. Nato vsaka različica ustvari svoj ločen tok dogodkov. Producenti pošiljajo dogodke Kafki, ti so zabeleženi v primerni čakalni vrsti.

(slika zato)

Hkrati vam Kafka omogoča branje v kosih in obdelavo toka dogodkov v mini serijah. Kafka je zelo priročno orodje, ki se dobro prilagaja naraščajočim potrebam (na primer z geolokacijo dogodkov).
Običajno zadostuje že en shard, bolj zakomplicira pa se pri komunikaciji pri skaliranju (kot vedno). Verjetno nihče ne želi uporabljati samo enega fizičnega sharda v proizvodnji, saj mora biti arhitektura tolerantna na napake. Poleg Kafke obstaja še ena znana rešitev - RabbitMQ. V produkciji ga nismo uporabili kot čakalno vrsto za analizo dogodkov (če imate takšne izkušnje, nam o tem povejte v komentarjih!). Vendar je bil uporabljen AWS Kinesis.

Preden preidemo na naslednji korak, je treba omeniti še eno dodatno plast sistema - shranjevanje neobdelanih dnevnikov. To ni obvezna plast, vendar bo uporabna, če gre kaj narobe in se čakalne vrste dogodkov v Kafki ponastavijo na nič. Shranjevanje neobdelanih dnevnikov ne zahteva zapletene in drage rešitve, preprosto jih lahko zapišete nekam v pravilnem vrstnem redu (tudi na trdi disk).

2. Ravnanje s tokovi dogodkov

Ko smo pripravili vse dogodke in jih uvrstili v ustrezne čakalne vrste, preidemo na korak obdelave. Tukaj bom govoril o dveh najpogostejših možnostih obdelave.
Prva možnost je omogočiti Spark Streaming v sistemu Apache. Vsi izdelki Apache živijo v HDFS, varnem datotečnem sistemu replike. Spark Streaming je orodje, preprosto za uporabo, ki obdeluje pretočne podatke in se dobro prilagaja. Vendar ga je lahko težko vzdrževati.
Druga možnost je izdelava lastnega obdelovalca dogodkov. Če želite to narediti, morate na primer napisati aplikacijo Python, jo zgraditi v dockerju in se naročiti na Kafkine čakalne vrste. Ko sprožilci pridejo do upravljavcev v dockerju, se začne obdelava. S to metodo morate nenehno izvajati aplikacije.
Predpostavimo, da smo izbrali eno od zgoraj opisanih možnosti in preidimo na samo obdelavo. Obdelovalci naj začnejo s preverjanjem veljavnosti podatkov, filtriranjem smeti in "pokvarjenih" dogodkov. Za validacijo običajno uporabljamo Cerberus. Po tem se lahko izvede preslikava podatkov: podatki iz različnih virov se normalizirajo in standardizirajo, da se dodajo v skupno tabelo.

3. Baza podatkov

Tretji korak je shranjevanje normaliziranih dogodkov. Pri delu z že pripravljenim analitičnim sistemom bomo morali pogosto dostopati do njih, zato je pomembno izbrati priročno bazo podatkov.
Če se podatki dobro ujemajo s fiksno shemo, lahko izbirate clickhouse ali kakšno drugo bazo podatkov stolpcev. Tako bodo združevanja delovala zelo hitro. Slaba stran je, da je shema togo fiksna, zato ne bo delovalo dodajanje poljubnih predmetov brez izboljšave (na primer, ko pride do nestandardnega dogodka). Ampak to je mogoče storiti zelo hitro.
Za nestrukturirane podatke lahko vzamete na primer NoSQL, Apache Cassandra. Deluje na HDFS, se dobro replicira, dvignete lahko veliko primerkov in je odporen na napake.
Lahko dvignete nekaj preprostejšega, npr. MongoDB. Je precej počasen tudi pri majhnih količinah. Ampak plus je, da je zelo preprost in zato primeren za začetek.

4. Združevanja

Po skrbnem shranjevanju vseh dogodkov želimo zbrati vse pomembne informacije iz prispele serije in posodobiti bazo podatkov. Globalno želimo ustrezne nadzorne plošče in meritve. Na primer od dogodkov za zbiranje uporabniškega profila in nekako merjenje vedenja. Dogodki so združeni, zbrani in ponovno shranjeni (že v uporabniških tabelah). Hkrati je možno zgraditi sistem tako, da je na koordinacijski agregator povezan tudi filter: zbirati uporabnike samo iz določene vrste dogodkov.
Po tem, če nekdo v ekipi potrebuje samo analitiko na visoki ravni, lahko povežete zunanje analitične sisteme. Ponovno lahko vzamete Mixpanel. a ker je precej drago, se tja ne pošiljajo vsi uporabniški dogodki, ampak samo tisto, kar je potrebno. Da bi to naredili, moramo ustvariti koordinatorja, ki bo prenesel nekaj neobdelanih dogodkov ali nekaj, kar smo sami prej združili v zunanje sisteme, API-je ali oglaševalske platforme.

5. Frontend

Čelni del morate povezati z ustvarjenim sistemom. Dober primer je storitev. redash, je grafični uporabniški vmesnik baze podatkov, ki pomaga graditi plošče. Kako deluje interakcija:

1. Uporabnik naredi poizvedbo SQL.
2. V odgovor prejme znak.
3. Zanj ustvari 'novo vizualizacijo' in dobi čudovit graf, ki ga lahko shranite že sami.

Vizualizacije v storitvi se samodejno posodabljajo, spremljanje lahko konfigurirate in spremljate. Redash je brezplačen v primeru lastnega gostovanja, kot SaaS pa bo stal 50 USD na mesec.

Zaključek

Ko dokončate vse zgornje korake, boste ustvarili analitiko na strani strežnika. Upoštevajte, da to ni tako enostavno kot samo povezovanje analitike odjemalca, ker je treba vse konfigurirati sami. Zato je pred ustvarjanjem lastnega sistema vredno primerjati potrebo po resnem analitičnem sistemu s sredstvi, ki ste mu pripravljeni nameniti.
Če ste naredili vso matematiko in ugotovili, da so stroški previsoki, bom v naslednjem delu govoril o tem, kako narediti cenejšo različico back-end analitike.

Hvala za branje! Vesel bom vprašanj v komentarjih.

Vir: www.habr.com