Aceasta este a doua parte a unei serii de articole despre sisteme analitice ().
Astăzi nu mai există nicio îndoială că prelucrarea atentă a datelor și interpretarea rezultatelor pot ajuta aproape orice tip de afacere. În acest sens, sistemele analitice devin din ce în ce mai încărcate cu parametri, iar numărul declanșatorilor și evenimentelor utilizatorului din aplicații este în creștere.
Din această cauză, companiile oferă analiștilor lor din ce în ce mai multe informații brute pentru a le analiza și a le transforma în decizii corecte. Importanța unui sistem de analiză pentru o companie nu trebuie subestimată, iar sistemul în sine trebuie să fie fiabil și stabil.
Analiști clienți
Analiza clienților este un serviciu pe care o companie se conectează la site-ul sau la aplicația sa prin SDK-ul oficial, îl integrează în propria bază de cod și selectează declanșatorii de evenimente. Există un dezavantaj evident al acestei abordări: este posibil ca toate datele colectate să nu fie procesate exact așa cum ați dori din cauza limitărilor oricărui serviciu pe care îl alegeți. De exemplu, pe un sistem nu va fi ușor să rulați sarcini MapReduce, pe altul nu vă veți putea rula modelul. Un alt dezavantaj va fi factura obișnuită (impresionantă) pentru servicii.
Există multe soluții de analiză a clienților pe piață, dar mai devreme sau mai târziu analiștii se confruntă cu faptul că nu există un serviciu universal potrivit pentru fiecare sarcină (în timp ce prețurile pentru toate aceste servicii cresc tot timpul). Într-o astfel de situație, companiile decid adesea să-și creeze propriul sistem de analiză cu toate setările și capabilitățile personalizate necesare.
Analiști de server
Analiza pe server este un serviciu care poate fi implementat în cadrul unei companii pe propriile servere și (de obicei) cu propriile eforturi. În acest model, toate evenimentele utilizatorului sunt stocate pe servere interne, permițând dezvoltatorilor să încerce diferite baze de date de stocare și să aleagă cea mai convenabilă arhitectură. Și chiar dacă încă doriți să utilizați analizele clienților terți pentru anumite sarcini, va fi totuși posibil.
Analiza serverului poate fi implementată în două moduri. În primul rând: alegeți câteva utilități open source, implementați-le pe mașinile dvs. și dezvoltați logica de afaceri.
Pro
Contra
Puteți personaliza orice doriți
Acest lucru este adesea foarte dificil și necesită dezvoltatori separați
În al doilea rând: luați servicii SaaS (Amazon, Google, Azure) în loc să le implementați singur. Vom vorbi despre SaaS mai detaliat în partea a treia.
Pro
Contra
Poate fi mai ieftin la volume medii, dar cu o creștere mare va deveni totuși prea scump
Nu va fi posibil să controlați toți parametrii
Administrarea este transferată în întregime pe umerii furnizorului de servicii
Nu se știe întotdeauna ce este în interiorul serviciului (s-ar putea să nu fie necesar)
Cum să colectați analizele serverului
Dacă vrem să renunțăm la utilizarea analizei clienților și să ne construim propria noastră, în primul rând trebuie să ne gândim la arhitectura noului sistem. Mai jos vă voi spune pas cu pas ce trebuie să luați în considerare, de ce este necesar fiecare pas și ce instrumente puteți utiliza.
1. Primirea datelor
La fel ca și în cazul analizei clienților, în primul rând, analiștii companiei selectează tipurile de evenimente pe care doresc să le studieze în viitor și le adună într-o listă. De obicei, aceste evenimente apar într-o anumită ordine, numită „model de evenimente”.
Apoi, imaginați-vă că o aplicație mobilă (site web) are utilizatori obișnuiți (dispozitive) și multe servere. Pentru a transfera în siguranță evenimentele de la dispozitive la servere, este necesar un strat intermediar. În funcție de arhitectură, pot exista mai multe cozi de evenimente diferite.
- E , care este folosit ca o coadă pentru colectarea evenimentelor.
În conformitate cu în 2014, creatorul Apache Kafka a decis să numească software-ul după Franz Kafka pentru că „este un sistem optimizat pentru scris” și pentru că iubea lucrările lui Kafka. —
În exemplul nostru, există mulți producători de date și consumatori de date (dispozitive și servere), iar Kafka ajută la conectarea lor între ei. Consumatorii vor fi descriși mai detaliat în pașii următori, unde ei vor fi subiectele principale. Acum vom lua în considerare numai producătorii de date (evenimente).
Kafka încapsulează conceptele de coadă și partiție; este mai bine să citiți mai precis despre acest lucru în altă parte (de exemplu, în ). Fără a intra în detalii, să ne imaginăm că este lansată o aplicație mobilă pentru două sisteme de operare diferite. Apoi, fiecare versiune își creează propriul flux de evenimente separat. Producătorii trimit evenimente la Kafka, acestea sunt înregistrate într-o coadă potrivită.
(imagine )
În același timp, Kafka vă permite să citiți în bucăți și să procesați un flux de evenimente în mini-loturi. Kafka este un instrument foarte convenabil care se adaptează bine la nevoile tot mai mari (de exemplu, prin geolocalizarea evenimentelor).
De obicei, un ciob este suficient, dar lucrurile devin mai complicate la scalare (cum se întâmplă întotdeauna). Probabil că nimeni nu va dori să folosească un singur fragment fizic în producție, deoarece arhitectura trebuie să fie tolerantă la erori. Pe lângă Kafka, există o altă soluție binecunoscută - RabbitMQ. Nu l-am folosit în producție ca coadă pentru analiza evenimentelor (dacă aveți o astfel de experiență, spuneți-ne despre asta în comentarii!). Cu toate acestea, am folosit AWS Kinesis.
Înainte de a trece la pasul următor, trebuie să menționăm încă un strat suplimentar al sistemului - stocarea jurnalelor brute. Acesta nu este un strat obligatoriu, dar va fi util dacă ceva nu merge bine și cozile de evenimente din Kafka sunt resetate. Stocarea jurnalelor brute nu necesită o soluție complexă și costisitoare; pur și simplu le puteți scrie undeva în ordinea corectă (chiar și pe un hard disk).
2. Procesarea fluxurilor de evenimente
După ce am pregătit toate evenimentele și le-am plasat în cozile corespunzătoare, trecem la etapa de procesare. Aici vă voi spune despre cele două opțiuni de procesare cele mai comune.
Prima opțiune este să activați Spark Streaming în sistemul Apache. Toate produsele Apache trăiesc pe HDFS, un sistem de fișiere securizat cu replici de fișiere. Spark Streaming este un instrument ușor de utilizat care gestionează datele în flux și se scalează bine. Cu toate acestea, poate fi dificil de întreținut.
O altă opțiune este să vă construiți propriul handler de evenimente. Pentru a face acest lucru, trebuie, de exemplu, să scrieți o aplicație Python, să o construiți în Docker și să vă abonați la coada Kafka. Când declanșatoarele sosesc la manevrele docker, procesarea va începe. Cu această metodă, trebuie să mențineți aplicațiile să ruleze în orice moment.
Să presupunem că am ales una dintre opțiunile descrise mai sus și trecem la procesarea în sine. Procesatorii ar trebui să înceapă prin verificarea validității datelor, filtrarea gunoiului și a evenimentelor „efecte”. Pentru validare folosim de obicei . După aceasta, puteți face maparea datelor: datele din diferite surse sunt normalizate și standardizate pentru a fi adăugate la un tabel comun.
3. Baza de date
Al treilea pas este menținerea evenimentelor normalizate. Când lucrăm cu un sistem analitic gata făcut, va trebui să le accesăm des, așa că este important să alegem o bază de date convenabilă.
Dacă datele se încadrează bine într-o schemă fixă, puteți alege sau altă bază de date coloană. În acest fel, agregarile vor funcționa foarte repede. Dezavantajul este că schema este fixată rigid și, prin urmare, nu va fi posibil să adăugați obiecte arbitrare fără modificare (de exemplu, când are loc un eveniment nestandard). Dar poți număra foarte repede.
Pentru datele nestructurate, puteți lua NoSQL, de exemplu, . Funcționează pe HDFS, se replică bine, puteți ridica multe instanțe și este tolerant la erori.
De asemenea, puteți ridica ceva mai simplu, de exemplu, . Este destul de lent și pentru volume mici. Dar plusul este că este foarte simplu și, prin urmare, potrivit pentru pornire.
4. Agregările
După ce am salvat cu atenție toate evenimentele, dorim să colectăm toate informațiile importante din lotul sosit și să actualizăm baza de date. La nivel global, dorim să obținem tablouri de bord și valori relevante. De exemplu, colectați un profil de utilizator din evenimente și măsurați cumva comportamentul. Evenimentele sunt agregate, colectate și salvate din nou (în tabelele utilizatorilor). În același timp, puteți construi un sistem astfel încât să puteți conecta și un filtru la agregator-coordonator: colectați utilizatori doar dintr-un anumit tip de eveniment.
După aceea, dacă cineva din echipă are nevoie doar de analize de nivel înalt, sistemele de analiză externe pot fi conectate. Puteți lua Mixpanel din nou. dar din moment ce este destul de scump, nu toate evenimentele utilizator sunt trimise acolo, ci doar ceea ce este necesar. Pentru a face acest lucru, trebuie să creăm un coordonator care să transfere unele evenimente brute sau ceva pe care noi înșine l-am agregat mai devreme către sisteme externe, API-uri sau platforme de publicitate.
5. Frontend
Trebuie să conectați interfața la sistemul creat. Un bun exemplu este serviciul , este o interfață grafică a bazei de date care ajută la construirea tablourilor de bord. Cum funcționează interacțiunea:
- Utilizatorul face o interogare SQL.
- Ca răspuns, el primește un semn.
- Acesta creează o „nouă vizualizare” pentru acesta și obține un grafic frumos pe care îl puteți salva pentru dvs.
Vizualizările din serviciu se actualizează automat, vă puteți personaliza și urmări monitorizarea. Redash este gratuit dacă este auto-găzduit, dar ca SaaS va costa 50 USD pe lună.
Concluzie
După parcurgerea tuturor pașilor de mai sus, vă veți crea analizele serverului. Vă rugăm să rețineți că acest lucru nu este la fel de simplu ca doar conectarea analizelor clienților, deoarece totul trebuie configurat singur. Prin urmare, înainte de a vă crea propriul sistem, merită să comparați nevoia unui sistem de analiză serios cu resursele pe care sunteți dispus să le alocați acestuia.
Dacă ați făcut calculele și ați constatat că costurile sunt prea mari, în următoarea parte voi vorbi despre cum să faceți o versiune mai ieftină a analizei pe server.
Multumesc pentru lectura! Voi fi bucuros să pun întrebări în comentarii.
Sursa: www.habr.com