Questa hè a seconda parte di una seria d'articuli nantu à i sistemi analitici ().
Oghje, ùn ci hè dubbitu chì u trattamentu precisu di e dati è l'interpretazione di i risultati ponu aiutà à quasi ogni tipu di cummerciale. In questu sensu, i sistemi analitici sò diventati sempre più carchi di parametri, u numeru di triggers è avvenimenti d'utilizatori in l'applicazioni hè in crescita.
Per via di questu, l'imprese dà à i so analisti più è più infurmazione "cruda" per analizà è trasfurmà in e decisioni ghjuste. L'impurtanza di un sistema analiticu per una sucità ùn deve esse sottovalutata, è u sistema stessu deve esse affidatu è sustinibili.
Analisti di i clienti
L'analisi di u cliente hè un serviziu chì una cumpagnia cunnetta per u so situ web o l'applicazione attraversu u SDK ufficiale, l'integra in a so propria basa di codice, è selezziunà i triggers di l'avvenimenti. Stu approcciu hà un svantaghju evidenti: tutti i dati raccolti ùn ponu esse trattati in u modu cumpletu chì vulete, per via di e limitazioni di qualsiasi serviziu sceltu. Per esempiu, in un sistema ùn serà micca faciule per eseguisce i travaglii di MapReduce, in un altru ùn puderà micca fà u vostru mudellu. Un altru svantaghju serà una fattura regulare (impresionante) per i servizii.
Ci sò parechje suluzioni analitiche di i clienti in u mercatu, ma prima o dopu, l'analisti sò affruntati cù u fattu chì ùn ci hè micca un serviziu universale adattatu per ogni compitu (mentre i prezzi per tutti questi servizii sò in constantemente crescente). In una tale situazione, l'imprese spessu decidenu di creà u so propiu sistema analiticu cù tutti i paràmetri è e funzioni persunalizati necessarii.
Analisti di u servitore
L'analisi di u latu di u servitore hè un serviziu chì pò esse implementatu internamente nantu à i servitori di l'impresa è (di solitu) in casa. In questu mudellu, tutti l'avvenimenti di l'utilizatori sò almacenati in i servitori internu, chì permettenu à i sviluppatori di pruvà diverse basa di dati per u almacenamentu è sceglie l'architettura più còmuda. E ancu s'è vo vulete ancu aduprà l'analitiche di u cliente di terzu partitu per alcune attività, serà sempre pussibule.
L'analisi di u latu di u servitore ponu esse implementate in dui maneri. Prima: sceglite alcune utilità open source, implementate nantu à e vostre macchine è sviluppate a logica cummerciale.
Плюсы
Минусы
Pudete persunalizà qualcosa
Spessu hè assai difficiule è i sviluppatori separati sò necessarii
Siconda: pigliate i servizii SaaS (Amazon, Google, Azure) invece di implementà sè stessu. Parleremu di SaaS in più detail in a terza parte.
Плюсы
Минусы
Pò esse più prezzu nantu à volumi mediani, ma cù un grande aumentu serà sempre troppu caru
Ùn hè micca capaci di cuntrullà tutti i paràmetri
L'amministrazione hè interamente spustata à e spalle di u prestatore di serviziu
Ùn hè micca sempre cunnisciutu ciò chì hè in u serviziu (pò esse micca necessariu)
Cumu cullà l'analisi di u servitore
Se vulemu alluntanassi da l'usu di l'analitiche di u cliente è di custruisce a nostra propria, prima di tuttu, avemu bisognu di pensà à l'architettura di u novu sistema. Sottu vi dicu passu à passu ciò chì vi tocca à cunsiderà, perchè ognunu di i passi hè necessariu è chì arnesi vi ponu aduprà.
1. Acquisizione di dati
Cum'è in u casu di l'analitiche di i clienti, prima di tuttu, l'analista di l'imprese selezziunate i tipi di avvenimenti chì volenu studià più è cullà in una lista. Di solitu, sti avvenimenti sò in un certu ordine, chì hè chjamatu "schema di l'avvenimentu".
In più, imaginemu chì una applicazione mobile (situ web) hà utilizatori regularmente (dispositivi) è parechji servitori. Per trasfirià in modu sicuru l'avvenimenti da i dispositi à i servitori, hè necessariu una capa intermedia. Sicondu l'architettura, ponu accade parechje file d'avvenimenti diffirenti.
Is , chì hè aduprata cum'è una fila per cullà avvenimenti.
Sicondu in 2014, u creatore di Apache Kafka hà decisu di chjamà u software dopu à Franz Kafka perchè "hè un sistema ottimizatu in scrittura" è perchè amava i scritti di Kafka. —
In u nostru esempiu, ci sò parechji pruduttori di dati è i so cunsumatori (dispositivi è servitori), è Kafka aiuta à cunnetta cù l'altri. I cunsumatori seranu descritti in più detail in i prossimi passi, induve seranu l'attori principali. Avà avemu da cunsiderà solu i pruduttori di dati (avvenimenti).
Kafka incapsula i cuncetti di fila è partizione, più specificamente nantu à questu hè megliu leghje in altrò (per esempiu, in ). Senza entre in dettagli, imaginemu chì una applicazione mobile hè lanciata per dui sistemi operativi diffirenti. Allora ogni versione crea u so propiu flussu di avvenimenti separati. I pruduttori mandanu avvenimenti à Kafka, sò arregistrati in una fila adattata.
(stampa )
À u listessu tempu, Kafka permette di leghje in pezzi è processà u flussu di l'avvenimenti in mini-batches. Kafka hè un strumentu assai cunvene chì scala bè cù i bisogni crescenti (per esempiu, per geolocalizazione di l'avvenimenti).
Di solitu un shard hè abbastanza, ma e cose diventanu più complicate cù a cumunicazione quandu scala (cum'è sempre). Probabilmente nimu ùn vole usà solu un shard fisicu in a produzzione, postu chì l'architettura deve esse tolerante à i difetti. In più di Kafka, ci hè una altra suluzione ben cunnisciuta - RabbitMQ. Ùn avemu micca usatu in a produzzione cum'è una fila per l'analitiche di l'avvenimenti (se avete una tale sperienza, diteci in i cumenti!). Tuttavia, AWS Kinesis hè stata utilizata.
Prima di passà à u passu prossimu, ci vole à menzionate una altra capa addiziale di u sistema - u almacenamentu di logs crudi. Questa ùn hè micca una capa obbligatoria, ma serà utile in casu chì qualcosa va male è e file di l'eventi in Kafka sò resettate à zero. L'almacenamiento di logs crudi ùn hè micca bisognu di una suluzione cumplessa è caru, pudete simpricimenti scrive in un locu in l'ordine currettu (ancu à un discu duru).
2. Manipulazione di flussi di avvenimenti
Dopu avè preparatu tutti l'avvenimenti è pusatu in i fili adatti, andemu à u passu di trasfurmazioni. Quì vi parleremu di e duie opzioni di trasfurmazioni più cumuni.
A prima opzione hè di attivà Spark Streaming in un sistema Apache. Tutti i prudutti Apache campanu nantu à HDFS, un sistema di fugliale di replica sicura. Spark Streaming hè un strumentu faciule d'utilizà chì processa dati in streaming è scala bè. Tuttavia, pò esse difficiule di mantene.
Un'altra opzione hè di custruisce u vostru propiu gestore di eventi. Per fà questu, per esempiu, avete bisognu di scrive una applicazione Python, custruisce in docker, è abbonate à e file di Kafka. Quandu i triggers venenu à i gestori in u docker, u processamentu principia. Cù stu metudu, avete bisognu di mantene l'applicazioni in esecuzione constantemente.
Assumimu chì avemu sceltu una di l'opzioni descritte sopra è passà à u prucessu stessu. I prucessori duveranu principià per verificà a validità di e dati, filtrà a basura è l'avvenimenti "rottu". Per a validazione, usualmente usemu . Dopu quì, a mappatura di dati pò esse fatta: dati da diverse fonti sò nurmalizzati è standardizati per esse aghjuntu à una tavula cumuna.
3. Database
U terzu passu hè di salvà avvenimenti nurmalizzati. Quandu u travagliu cù un sistema analiticu prontu, spessu avemu da accede à elli, per quessa hè impurtante di sceglie una basa di dati còmuda.
Se i dati si adattanu bè à un schema fissu, pudete sceglie o qualchì altra basa di dati di colonna. Allora l'agregazioni travaglià assai rapidamente. U svantaghju hè chì u schema hè rigidamente fissatu è per quessa ùn hà micca travagliatu per aghjunghje l'uggetti arbitrarii senza raffinamentu (per esempiu, quandu un avvenimentu micca standard). Ma pò esse fattu veramente veloce.
Per dati micca strutturati, pudete piglià NoSQL, per esempiu, . Funziona in HDFS, riplica bè, pudete suscitarà parechji casi, è hè tolerante à i difetti.
Pudete suscitarà qualcosa di più simplice, per esempiu, . Hè abbastanza lento ancu per i picculi volumi. Ma u plus hè chì hè assai simplice è dunque adattatu per inizià.
4. Aggregazioni
Dopu avè salvatu cù cura tutti l'avvenimenti, vulemu cullà tutte l'infurmazioni impurtanti da u batch chì hè vinutu è aghjurnà a basa di dati. In u mondu, vulemu dashboards è metriche pertinenti. Per esempiu, da l'avvenimenti per cullà un prufilu d'utilizatore è in qualchì modu misurà u cumpurtamentu. L'avvenimenti sò aggregati, cullati è salvati di novu (dighjà in tavule d'utilizatori). À u listessu tempu, hè pussibule di custruisce un sistema in modu chì un filtru hè ancu cunnessu à l'agregatore di coordinazione: per cullà l'utilizatori solu da un certu tipu d'avvenimenti.
Dopu quì, se qualcunu in a squadra hà bisognu solu analitiche d'altu livellu, pudete cunnette sistemi analitici esterni. Pudete piglià Mixpanel di novu. ma postu chì hè abbastanza caru, micca tutti l'avvenimenti di l'utilizatori sò mandati quì, ma solu ciò chì hè necessariu. Per fà questu, avemu bisognu di creà un coordinatore chì trasfirerà qualchi avvenimenti prima o qualcosa chì noi stessi avemu aghjustatu prima à sistemi esterni, API o piattaforme di publicità.
5. Frontend
Avete bisognu di cunnette u frontend à u sistema creatu. Un bon esempiu hè u serviziu. , hè una GUI di basa di dati chì aiuta à custruisce pannelli. Cumu funziona l'interazzione:
- L'utilizatore face una dumanda SQL.
- In risposta, riceve un segnu.
- Crea una "nova visualizazione" per ellu è riceve un bellu graficu chì pudete digià salvà.
I visualizazioni in u serviziu sò auto-aggiornati, pudete cunfigurà è seguità u vostru monitoraghju. Redash hè liberu, in u casu di self-hosted, ma cum'è SaaS costarà $ 50 per mese.
cunchiusioni
Dopu à compie tutti i passi sopra, vi creà u vostru analitiche latu servore. Per piacè nutate chì questu ùn hè micca cusì faciule cum'è solu cunnette l'analisi di u cliente, perchè tuttu deve esse cunfiguratu da u vostru propiu. Dunque, prima di creà u vostru propiu sistema, vale a pena paragunà a necessità di un sistema analiticu seriu cù e risorse chì site prontu à attribuisce.
Sè avete fattu tutte e matematiche è truvate chì i costi sò troppu altu, in a parti dopu vi parlerà di cumu fà una versione più economica di l'analisi back-end.
Grazie per a lettura! Seraghju felice di dumande in i cumenti.
Source: www.habr.com