Dit is it twadde diel fan in searje artikels oer analytyske systemen ().
Tsjintwurdich is d'r gjin twifel mear dat soarchfâldige gegevensferwurking en ynterpretaasje fan resultaten hast elk type bedriuw kin helpe. Yn dit ferbân wurde analytyske systemen hieltyd mear laden mei parameters, en it oantal triggers en brûkerseveneminten yn applikaasjes groeit.
Hjirtroch jouwe bedriuwen har analisten hieltyd mear rauwe ynformaasje om te analysearjen en om te setten yn sûne besluten. It belang fan in analytysk systeem foar in bedriuw moat net ûnderskatte wurde, en it systeem sels moat betrouber en stabyl wêze.
Client analysts
Klantanalyse is in tsjinst dy't in bedriuw ferbynt mei har webside of applikaasje fia de offisjele SDK, yntegreart yn har eigen koadebase en selekteart barrens. D'r is in dúdlike neidiel oan dizze oanpak: alle sammele gegevens wurde miskien net krekt ferwurke lykas jo wolle, fanwegen de beheiningen fan elke tsjinst dy't jo kieze. Bygelyks, op ien systeem sil it net maklik wêze om MapReduce-taken út te fieren, op in oar sil jo jo model net kinne útfiere. In oar neidiel sil de reguliere (yndrukwekkende) rekken foar tsjinsten wêze.
D'r binne in protte oplossings foar klantanalyse op 'e merk, mar ier of letter wurde analysten konfrontearre mei it feit dat d'r gjin ien universele tsjinst is dy't geskikt is foar elke taak (wylst de prizen foar al dizze tsjinsten hieltyd omheech geane). Yn sa'n situaasje beslute bedriuwen faak har eigen analytyksysteem te meitsjen mei alle nedige oanpaste ynstellings en mooglikheden.
Tsjinner analysts
Server-side analytics is in tsjinst dy't kin wurde ynset binnen in bedriuw op syn eigen servers en (meastentiids) mei syn eigen ynspannings. Yn dit model wurde alle brûkerseveneminten opslein op ynterne servers, wêrtroch ûntwikkelders ferskate opslachdatabases kinne besykje en de meast handige arsjitektuer kieze. En sels as jo noch klantanalyses fan tredden wolle brûke foar guon taken, sil it noch altyd mooglik wêze.
Server-side analytics kinne wurde ynset op twa manieren. Earst: kies wat iepen boarne-hulpprogramma's, ynset se op jo masines en ûntwikkelje bedriuwslogika.
Плюсы
Минусы
Jo kinne alles oanpasse wat jo wolle
Dit is faaks heul lestich en fereasket aparte ûntwikkelders
Twad: nim SaaS-tsjinsten (Amazon, Google, Azure) ynstee fan it sels yn te setten. Wy sille prate oer SaaS yn mear detail yn it tredde diel.
Плюсы
Минусы
It is mooglik goedkeaper by middelgrutte folumes, mar mei grutte groei wurdt it noch te djoer
It sil net mooglik wêze om alle parameters te kontrolearjen
Administraasje wurdt folslein oerdroegen oan 'e skouders fan' e tsjinstferliener
It is net altyd bekend wat der binnen de tsjinst is (it is miskien net nedich)
Hoe te sammelje server analytics
As wy fuort wolle fan it brûken fan klantanalyse en ús eigen bouwe, moatte wy earst troch de arsjitektuer fan it nije systeem tinke. Hjirûnder sil ik jo stap foar stap fertelle wat jo moatte beskôgje, wêrom elke stap nedich is en hokker ark jo kinne brûke.
1. Untfange gegevens
Krekt as yn it gefal fan klantanalyse, selektearje bedriuwsanalisten earst de soarten eveneminten dy't se yn 'e takomst wolle studearje en sammelje se yn in list. Typysk, dizze eveneminten foarkomme yn in spesifike folchoarder, neamd in "evenemint patroan."
Stel jo dan foar dat in mobile applikaasje (webside) reguliere brûkers (apparaten) en in protte servers hat. Om eveneminten feilich oer te bringen fan apparaten nei servers, is in tuskenlizzende laach nedich. Ofhinklik fan 'e arsjitektuer kinne d'r ferskate ferskillende eveneminten wêze.
Is , dy't brûkt wurdt as wachtrige foar it sammeljen fan eveneminten.
Neffens yn 2014 besleat de skepper fan Apache Kafka om de software nei Franz Kafka te neamen, om't "it in systeem is optimalisearre foar skriuwen" en om't hy fan Kafka's wurken hâlde. -
Yn ús foarbyld binne d'r in protte gegevensprodusinten en gegevenskonsuminten (apparaten en servers), en Kafka helpt se mei elkoar te ferbinen. Konsuminten wurde yn 'e folgjende stappen yn mear detail beskreaun, wêr't se de haadûnderwerpen sille wêze. No sille wy allinich gegevensprodusinten (eveneminten) beskôgje.
Kafka encapsulates de begripen fan wachtrige en partition it is better om te lêzen mear spesifyk oer dit earne oars (bygelyks, yn; ). Sûnder yn details te gean, litte wy ús foarstelle dat in mobile applikaasje wurdt lansearre foar twa ferskillende OS's. Dan makket elke ferzje syn eigen aparte evenemintstream. Produsinten stjoere eveneminten nei Kafka, se wurde opnommen yn in passende wachtrige.
(ôfbylding )
Tagelyk lit Kafka jo yn brokken lêze en in stream fan eveneminten yn mini-batches ferwurkje. Kafka is in heul handich ark dat goed skaleart mei groeiende behoeften (bygelyks troch geolokaasje fan eveneminten).
Meastentiids is ien shard genôch, mar dingen wurde komplisearre by skaalfergrutting (lykas se altyd dogge). Wierskynlik sil gjinien mar ien fysike shard brûke wolle yn produksje, om't de arsjitektuer fault-tolerant wêze moat. Neist Kafka is d'r in oare bekende oplossing - RabbitMQ. Wy hawwe it net brûkt yn produksje as wachtrige foar analyse fan eveneminten (as jo sa'n ûnderfining hawwe, fertel ús der oer yn 'e opmerkingen!). Wy hawwe lykwols AWS Kinesis brûkt.
Foardat wy trochgeane nei de folgjende stap, moatte wy noch ien ekstra laach fan it systeem neame - rûge log opslach. Dit is gjin fereaske laach, mar it sil nuttich wêze as der wat mis giet en de barrenswachtrige yn Kafka wurde weromset. It opslaan fan rau logs fereasket gjin komplekse en djoere oplossing, jo kinne se gewoan earne yn 'e juste folchoarder skriuwe (sels op in hurde skiif).
2. Ferwurkjen evenemint streamen
Nei't wy alle eveneminten hawwe taret en se yn 'e passende wachtrige pleatst, geane wy troch nei de ferwurkingsstap. Hjir sil ik jo fertelle oer de twa meast foarkommende ferwurkingsopsjes.
De earste opsje is om Spark Streaming yn te skeakeljen yn it Apache-systeem. Alle Apache-produkten libje op HDFS, in feilich bestânsysteem mei bestannen replika's. Spark Streaming is in maklik te brûken ark dat streaminggegevens omgiet en goed skaleart. It kin lykwols lestich wêze om te ûnderhâlden.
In oare opsje is om jo eigen event handler te bouwen. Om dit te dwaan moatte jo bygelyks in Python-applikaasje skriuwe, it yn Docker bouwe en abonnearje op de Kafka-wachtrige. As triggers oankomme by de docker-hannelers, sil de ferwurking begjinne. Mei dizze metoade moatte jo applikaasjes altyd rinnend hâlde.
Litte wy oannimme dat wy ien fan 'e hjirboppe beskreaune opsjes hawwe keazen en trochgean nei de ferwurking sels. Prozessoren moatte begjinne mei it kontrolearjen fan de jildigens fan 'e gegevens, filterjen fan ôffal en "brutsen" eveneminten. Foar falidaasje brûke wy normaal . Hjirnei kinne jo gegevensmapping dwaan: gegevens út ferskate boarnen wurde normalisearre en standerdisearre om te wurde tafoege oan in mienskiplike tabel.
3. Databank
De tredde stap is om normalisearre eveneminten te behâlden. By it wurkjen mei in ready-made analytysk systeem, sille wy faak tagong moatte ta har, dus it is wichtich om in handige databank te kiezen.
As de gegevens goed passe yn in fêst skema, kinne jo kieze of in oare kolomdatabase. Op dizze manier sille de aggregaasjes heul rap wurkje. It neidiel is dat it skema stiif fêst is en dêrom sil it net mooglik wêze om willekeurige objekten ta te foegjen sûnder wiziging (bygelyks as in net-standert evenemint foarkomt). Mar jo kinne echt hiel fluch telle.
Foar net-strukturearre gegevens kinne jo bygelyks NoSQL nimme, . It rint op HDFS, replikearret goed, jo kinne in protte eksimplaren ophelje, en is fouttolerant.
Jo kinne ek wat ienfâldiger ophelje, bygelyks, . It is frij stadich en foar lytse folumes. Mar it pluspunt is dat it hiel ienfâldich is en dus geskikt om te begjinnen.
4. Aggregaasjes
Nei't wy alle barrens foarsichtich hawwe bewarre, wolle wy alle wichtige ynformaasje sammelje fan 'e batch dy't oankaam en de databank bywurkje. Globaal wolle wy relevante dashboards en metriken krije. Sammelje bygelyks in brûkersprofyl fan eveneminten en mjitte op ien of oare manier gedrach. Eveneminten wurde aggregearre, sammele en opnij bewarre (yn brûkerstabellen). Tagelyk kinne jo in systeem bouwe sadat jo ek in filter kinne ferbine mei de aggregator-koördinator: sammelje brûkers allinich fan in bepaald type evenemint.
Dêrnei, as immen yn it team allinich analytyk op heech nivo nedich hat, kinne eksterne analytyske systemen ferbûn wurde. Jo kinne Mixpanel wer nimme. mar om't it frij djoer is, wurde net alle brûkerseveneminten dêr stjoerd, mar allinich wat nedich is. Om dit te dwaan, moatte wy in koördinator oanmeitsje dy't guon rauwe eveneminten as wat wy sels earder aggregearre sille oerdrage nei eksterne systemen, API's of advertinsjeplatfoarms.
5. Frontend
Jo moatte de frontend ferbine mei it oanmakke systeem. In goed foarbyld is tsjinst , is in databank GUI dy't helpt by it bouwen fan dashboards. Hoe't de ynteraksje wurket:
- De brûker makket in SQL-query.
- As reaksje krijt er in teken.
- It makket der in 'nije fisualisaasje' foar en krijt in prachtige grafyk dy't jo sels kinne bewarje.
Fisualisaasjes yn 'e tsjinst wurde automatysk bywurke, jo kinne jo tafersjoch oanpasse en folgje. Redash is fergees as sels-hosted, mar as SaaS sil it $ 50 per moanne kostje.
konklúzje
Nei it foltôgjen fan alle boppesteande stappen, sille jo jo serveranalyse oanmeitsje. Tink derom dat dit net sa ienfâldich is as gewoan ferbinen fan klantanalyse, om't alles sels konfigureare moat. Dêrom, foardat jo jo eigen systeem meitsje, is it de muoite wurdich om de needsaak foar in serieus analytysk systeem te fergelykjen mei de boarnen dy't jo ree binne om dêroan te tawizen.
As jo de wiskunde hawwe dien en fûn dat de kosten te heech binne, sil ik yn it folgjende diel prate oer hoe't jo in goedkeapere ferzje meitsje fan serverside-analyse.
Tank foar it lêzen! Ik sil bliid wêze om fragen te stellen yn 'e opmerkings.
Boarne: www.habr.com
