Architettura per l'elaborazione dei dati in tempo reale

Question

Architettura per l'elaborazione dei dati in tempo reale

#1 da (1 voti)

4

Sto cercando di costruire l'architettura per il seguente, e volevo vedere cosa ne pensano gli altri.

Supponiamo che il sistema stia eseguendo un algoritmo non banale (quindi non è semplicemente una somma di qualcosa, ecc.) sui dati raccolti su ciascun utente. Alcuni utenti avranno 10 righe di dati, alcune avranno decine di migliaia. I dati saranno le posizioni geografiche dell'utente nel tempo. Ci saranno più di 10-100 milioni di utenti e i dati su molti utenti arriveranno ogni giorno, potenzialmente ogni minuto per alcuni.

A intervalli periodici (1/5/15 minuti, fondamentalmente il più presto possibile), vorrei eseguire quell'algoritmo non banale su ogni dato utente, che sputerebbe fuori un paio di numeri che sarebbero poi segnalati .

Un modo per modellare quello che è quello di archiviare in un db NoSQL ed elaborare i dati di ciascun utente su un cluster Akka. Qualche raccomandazione per il DB?

I dati utente qui sono fondamentalmente un log di append dove, una volta aggiunti, i dati non cambieranno, ma continua a crescere in continuazione, e alcuni utenti hanno sproporzionatamente più dati di altri. Per elaborare i dati per utente, tutto deve essere caricato in memoria da qualche parte, quindi il miglior scenario possibile è dove tutti i dati sono in memoria e rielaborati ad intervalli di un minuto - il lato negativo è che avrei bisogno di terabyte di RAM per farlo e se i server in memoria si abbassano, tutti i dati dovrebbero essere ricaricati e ci vorrebbe un po 'di tempo.

architecture nosql akka stream-processing analytics

posta kozyr 29.08.2016 - 21:27

fonte

1 risposta

Leggi altre domande sui tag architecture nosql akka stream-processing analytics

Organizzazione del progetto Java DDD Com'è pessima idea modificare un file in un hook pre o post-commit?

score 1 · Answer 1

È solo un lavoro (distribuito) che puoi fare in modo asincrono. Quando arrivano nuovi dati per l'utente, aggiungilo alla coda dei compiti.

Rileva i lavori precedenti e previene il lavoro duplicato

Quando il lavoro precedente di quell'utente è ancora lì, rimuovi quello vecchio e posizionane uno nuovo. Oppure aggiungi i nuovi dati a quello esistente. A seconda di come vuoi occupartene.

Scala

Quindi puoi ridimensionare i lavoratori che elaborano i dati e fanno i calcoli. Qui puoi essere un po 'furbo: cerca di ottimizzare il momento in cui calcoli i dati per un utente nel momento in cui vogliono vederlo.

Ottimizza risultati storici

Il migliore sarebbe se potessi memorizzare risultati intermedi in modo da non dover elaborare tutti i dati di un utente ancora e ancora. A seconda dell'algoritmo che può essere la migliore ottimizzazione perché con i mesi / anni tali compiti diventano sempre più grandi man mano che gli utenti ottengono più dati.

Dato che i lavoratori sono costantemente occupati (possono essere ridimensionati automaticamente) e fanno costantemente lo stesso lavoro, puoi ottimizzarli molto duramente. Inoltre riduce la quantità di picchi nel carico di lavoro che riduce i costi di capacità.

Piattaforma di scelta

Quale specifico database / piattaforma è la migliore non è responsabile. Ciò dipende strongmente dai dati reali e dalla quantità di letture, scritture e altri fattori. Sospetto che il saldo sarà di avere un sacco di dati a riposo, quindi appena memorizzato. E poi quando un utente diventa attivo e inizia a consegnare i dati lo svegli, prepara i suoi dati e i processi iniziano a funzionare.

Poiché ti aspetti una nuova richiesta abbastanza presto, puoi mantenerla in memoria se vuoi, in modo che tu possa procedere quando arriva la prossima. I test diranno se è effettivamente necessario. Caricare alcuni punti geografici per un utente non sarebbe il lavoro più difficile del tuo sistema e tenerli per un minuto nella memoria distribuita potrebbe effettivamente essere più costoso.