Questa è la seconda parte di una serie di articoli sui sistemi analitici ().
Oggi non vi è più alcun dubbio che un’attenta elaborazione dei dati e l’interpretazione dei risultati possano aiutare quasi ogni tipo di azienda. A questo proposito, i sistemi analitici sono sempre più carichi di parametri e il numero di trigger ed eventi utente nelle applicazioni è in aumento.
Per questo motivo, le aziende forniscono ai propri analisti sempre più informazioni grezze da analizzare e trasformare in decisioni valide. L’importanza di un sistema di analisi per un’azienda non deve essere sottovalutata e il sistema stesso deve essere affidabile e stabile.
Analisti clienti
L'analisi dei clienti è un servizio che un'azienda collega al proprio sito Web o alla propria applicazione tramite l'SDK ufficiale, integra nella propria base di codice e seleziona i trigger di eventi. C'è un ovvio svantaggio in questo approccio: tutti i dati raccolti potrebbero non essere elaborati esattamente come vorresti a causa delle limitazioni di qualsiasi servizio tu scelga. Ad esempio, su un sistema non sarà facile eseguire le attività MapReduce, su un altro non sarà possibile eseguire il modello. Un altro svantaggio sarà la fattura regolare (impressionante) dei servizi.
Esistono molte soluzioni di analisi dei clienti sul mercato, ma prima o poi gli analisti si trovano ad affrontare il fatto che non esiste un servizio universale adatto a ogni compito (mentre i prezzi per tutti questi servizi sono in costante aumento). In una situazione del genere, le aziende spesso decidono di creare il proprio sistema di analisi con tutte le impostazioni e funzionalità personalizzate necessarie.
Analisti di server
L'analisi lato server è un servizio che può essere implementato all'interno di un'azienda sui propri server e (di solito) con i propri sforzi. In questo modello, tutti gli eventi utente vengono archiviati su server interni, consentendo agli sviluppatori di provare diversi database di archiviazione e scegliere l'architettura più conveniente. E anche se desideri comunque utilizzare l'analisi dei client di terze parti per alcune attività, sarà comunque possibile.
L'analisi lato server può essere distribuita in due modi. Primo: scegli alcune utilità open source, distribuiscile sulle tue macchine e sviluppa la logica di business.
Pro
Contro
Puoi personalizzare tutto ciò che desideri
Questo è spesso molto difficile e richiede sviluppatori separati
Secondo: prendi i servizi SaaS (Amazon, Google, Azure) invece di distribuirli tu stesso. Parleremo di SaaS in modo più dettagliato nella terza parte.
Pro
Contro
Potrebbe essere più economico con volumi medi, ma con una crescita elevata diventerà comunque troppo costoso
Non sarà possibile controllare tutti i parametri
L'amministrazione è interamente trasferita alle spalle del fornitore di servizi
Non sempre si sa cosa c'è all'interno del servizio (potrebbe non essere necessario)
Come raccogliere analisi del server
Se vogliamo abbandonare l'utilizzo dell'analisi dei clienti e costruirne una nostra, dobbiamo prima di tutto pensare all'architettura del nuovo sistema. Di seguito ti dirò passo dopo passo cosa devi considerare, perché è necessario ogni passaggio e quali strumenti puoi utilizzare.
1. Ricezione dei dati
Proprio come nel caso dell’analisi dei clienti, gli analisti aziendali selezionano innanzitutto le tipologie di eventi che desiderano studiare in futuro e li raccolgono in un elenco. In genere, questi eventi si verificano in un ordine specifico, denominato "modello di eventi".
Successivamente, immagina che un'applicazione mobile (sito Web) abbia utenti regolari (dispositivi) e molti server. Per trasferire in modo sicuro gli eventi dai dispositivi ai server, è necessario un livello intermedio. A seconda dell'architettura, potrebbero esserci diverse code di eventi.
- E ' , che viene utilizzato come coda per la raccolta degli eventi.
Secondo nel 2014, il creatore di Apache Kafka ha deciso di intitolare il software a Franz Kafka perché “è un sistema ottimizzato per la scrittura” e perché amava le opere di Kafka. —
Nel nostro esempio, ci sono molti produttori e consumatori di dati (dispositivi e server) e Kafka aiuta a collegarli tra loro. I consumatori verranno descritti più in dettaglio nei passaggi successivi, dove saranno i soggetti principali. Considereremo ora solo i produttori di dati (eventi).
Kafka incapsula i concetti di coda e partizione; è meglio leggere più specificatamente questo argomento altrove (ad esempio in ). Senza entrare nei dettagli, immaginiamo che un'applicazione mobile venga lanciata per due diversi sistemi operativi. Quindi ogni versione crea il proprio flusso di eventi separato. I produttori inviano gli eventi a Kafka, questi vengono registrati in un'apposita coda.
(immagine )
Allo stesso tempo, Kafka ti consente di leggere in blocchi ed elaborare un flusso di eventi in mini-batch. Kafka è uno strumento molto conveniente che si adatta bene alle crescenti esigenze (ad esempio, mediante la geolocalizzazione degli eventi).
Di solito è sufficiente uno shard, ma le cose diventano più complicate quando si scala (come sempre). Probabilmente nessuno vorrà utilizzare un solo frammento fisico in produzione, poiché l’architettura deve essere tollerante ai guasti. Oltre a Kafka esiste un'altra soluzione ben nota: RabbitMQ. Non l'abbiamo utilizzato in produzione come coda per l'analisi degli eventi (se hai tale esperienza, raccontacelo nei commenti!). Tuttavia, abbiamo utilizzato AWS Kinesis.
Prima di passare alla fase successiva, dobbiamo menzionare un ulteriore livello aggiuntivo del sistema: l'archiviazione dei log grezzi. Questo non è un livello obbligatorio, ma sarà utile se qualcosa va storto e le code degli eventi in Kafka vengono reimpostate. L'archiviazione dei log grezzi non richiede una soluzione complessa e costosa; puoi semplicemente scriverli da qualche parte nell'ordine corretto (anche su un disco rigido).
2. Elaborazione dei flussi di eventi
Dopo che abbiamo preparato tutti gli eventi e averli inseriti nelle apposite code, passiamo alla fase di elaborazione. Qui ti parlerò delle due opzioni di elaborazione più comuni.
La prima opzione è abilitare Spark Streaming nel sistema Apache. Tutti i prodotti Apache risiedono su HDFS, un file system sicuro con repliche di file. Spark Streaming è uno strumento facile da usare che gestisce lo streaming di dati e si adatta bene. Tuttavia, potrebbe essere difficile da mantenere.
Un'altra opzione è creare il proprio gestore di eventi. Per fare ciò è necessario, ad esempio, scrivere un'applicazione Python, compilarla in Docker e iscriversi alla coda Kafka. Quando i trigger arrivano ai gestori della finestra mobile, verrà avviata l'elaborazione. Con questo metodo è necessario mantenere le applicazioni sempre attive.
Supponiamo di aver scelto una delle opzioni sopra descritte e passiamo all'elaborazione vera e propria. I processori dovrebbero iniziare controllando la validità dei dati, filtrando la spazzatura e gli eventi “non funzionanti”. Per la convalida usiamo solitamente . Successivamente, puoi eseguire la mappatura dei dati: i dati provenienti da diverse fonti vengono normalizzati e standardizzati per essere aggiunti a una tabella comune.
3. Banca dati
Il terzo passo è mantenere gli eventi normalizzati. Quando lavoriamo con un sistema analitico già pronto, dovremo accedervi spesso, quindi è importante scegliere un database conveniente.
Se i dati si adattano bene a uno schema fisso, puoi scegliere o qualche altro database a colonne. In questo modo le aggregazioni funzioneranno molto velocemente. Lo svantaggio è che lo schema è rigidamente fissato e quindi non sarà possibile aggiungere oggetti arbitrari senza modifiche (ad esempio, quando si verifica un evento non standard). Ma puoi contare davvero molto velocemente.
Per i dati non strutturati, puoi prendere NoSQL, ad esempio, . Funziona su HDFS, si replica bene, puoi generare molte istanze ed è tollerante agli errori.
Puoi anche sollevare qualcosa di più semplice, ad esempio, . È piuttosto lento e per piccoli volumi. Ma il vantaggio è che è molto semplice e quindi adatto per iniziare.
4. Aggregazioni
Dopo aver salvato con cura tutti gli eventi, vogliamo raccogliere tutte le informazioni importanti dal batch arrivato e aggiornare il database. A livello globale, vogliamo ottenere dashboard e metriche pertinenti. Ad esempio, raccogli un profilo utente dagli eventi e misura in qualche modo il comportamento. Gli eventi vengono aggregati, raccolti e salvati nuovamente (nelle tabelle utente). Allo stesso tempo, puoi costruire un sistema per poter collegare anche un filtro all'aggregatore-coordinatore: raccogliere gli utenti solo da un certo tipo di evento.
Successivamente, se qualcuno nel team necessita solo di analisi di alto livello, è possibile collegare sistemi di analisi esterni. Puoi riprendere Mixpanel. ma poiché è piuttosto costoso, non tutti gli eventi utente vengono inviati lì, ma solo ciò che è necessario. Per fare ciò, dobbiamo creare un coordinatore che trasferirà alcuni eventi grezzi o qualcosa che noi stessi abbiamo aggregato in precedenza a sistemi esterni, API o piattaforme pubblicitarie.
5. Front-end
È necessario connettere il frontend al sistema creato. Un buon esempio è il servizio , è una GUI di database che aiuta a creare dashboard. Come funziona l'interazione:
- L'utente effettua una query SQL.
- In risposta riceve un segno.
- Crea una "nuova visualizzazione" e ottiene un bellissimo grafico che puoi salvare per te stesso.
Le visualizzazioni nel servizio si aggiornano automaticamente, puoi personalizzare e monitorare il tuo monitoraggio. Redash è gratuito se ospitato autonomamente, ma come SaaS costerà $ 50 al mese.
conclusione
Dopo aver completato tutti i passaggi precedenti, creerai l'analisi del tuo server. Tieni presente che questo non è semplice come collegare semplicemente l'analisi dei clienti, perché tutto deve essere configurato da solo. Pertanto, prima di creare il proprio sistema, vale la pena confrontare la necessità di un sistema di analisi serio con le risorse che si è disposti a destinargli.
Se hai fatto i conti e hai scoperto che i costi sono troppo alti, nella parte successiva parlerò di come realizzare una versione più economica dell'analisi lato server.
Grazie per aver letto! Sarò felice di porre domande nei commenti.
Fonte: habr.com