Big Data: può essere pre-elaborato?

Question

Big Data: può essere pre-elaborato?

#1 da (4 voti)
#2 da (2 voti)
#3 da (0 voti)

4

La mia domanda riguarda i "big data". Fondamentalmente, i big data implicano l'analisi di una grande quantità di dati per ricavarne approfondimenti significativi.

Vorrei sapere:

Indipendentemente dal fatto che grandi quantità di dati possano essere pre-elaborate? (ad esempio, ad esempio, si sta eseguendo un servizio di corrispondenza per le persone, quindi si prendono tutte le informazioni che si hanno sulle persone e le si elabora a un certo punto per utilizzarle in seguito)

Se è possibile la pre-elaborazione, come faresti normalmente a fare questo?

Per aiutare a restringere l'ambito della mia domanda, guarda questo scenario ipotetico.

Say I have a customer database and my company is a global retailer that is using some type of points system to reward the shoppers (for arguments sake, the points are tallied up on a type of electronic card or mobile app).

So based on my rewards system, I am now able to fully aware of exactly what a shopper is purchasing and when they normally make purchases of recurring items.

My database is growing all the time with this information and I would now like to make recommendations (or send notifications) to shoppers about special offers of products they buy or related products that may interest them, when they enter 1 of the stores.

Instead of processing all the accumulated data when a shopper enters the store, I would like to continually process the data-stream as the data comes in (meaning from previous shopping experiences), so that when it comes time to make a recommendation (for the next time a shopper walks into the store), it is simply a matter of retrieving the recommendations and providing a list of it to the shopper.

With this method in mind, I can easily space out my CPU-intensive tasks, instead of say: processing all customer data on a busy day when foot-traffic is at peak volumes.

Chiedendo come farei questo, mi riferirò ai metodi comuni disponibili per raggiungere questo obiettivo. Questo può includere database speciali o tecniche di programmazione o persino software specializzati in grado di eseguire questi calcoli temporizzati che possono "preelaborare" i dati in momenti specifici, al fine di bilanciare le attività a uso intensivo della CPU.

È possibile considerare lo scenario di raccomandazione del cliente come la "situazione". È lo scenario di esempio migliore che potrei pensare che spiegherebbe perché il "pre-processing" (o il calcolo delle raccomandazioni in momenti specifici) avrebbe senso.

data big-data analytics

posta Joe 24.02.2014 - 16:46

fonte

3 risposte

Leggi altre domande sui tag data big-data analytics

Revisione della struttura dell'applicazione Web MongoDB è appropriato per i sistemi che probabilmente cambieranno?

score 4 · Answer 1

In genere ho sentito che questo è gestito dal modello OLTP vs. OLAP . Essenzialmente la T in OLTP significa "transazionale", quindi questo è il tipico database utilizzato per le operazioni quotidiane. Quindi scrivi una sorta di logica traslazionale che trasforma il database OLTP in un database OLAP (la A sta per analitico).

Fondamentalmente stai parlando degli stessi dati rappresentati in 2 modi diversi. Il database OLTP si concentra sulla normalizzazione, ma il database OLAP è strutturato in più di un modello "a stella" con molta più ripetizione dei dati. È di sola lettura e ottimizzato per le query.

Quindi l'ingegneria sta studiando come eseguire la traduzione da OLTP a OLAP, con quale frequenza farlo e se è possibile farlo in modo incrementale, in modo che il database OLAP non sia troppo indietro rispetto al "tempo reale".

score 2 · Answer 2

In un lavoro passato, ero un DBA per un'azienda di soluzioni globali in cui i database con milioni e miliardi di righe erano la norma.

Man mano che i set di dati diventavano più grandi, diventava sempre più problematico girare le query complesse in modo tempestivo.

Tra le molte strategie che abbiamo adottato, 4 mi viene in mente:

I set di risultati per le query comuni sono stati memorizzati in quelli che abbiamo chiamato "strisce". Si trattava sostanzialmente di tabelle organizzate su indici che memorizzavano le chiavi per bloccare i join ripetuti nelle query successive
Le tabelle denormalizzazione hanno apportato enormi vantaggi per ridurre il numero di join
Le tabelle sono state partizionate in linea con le query comuni, ad es. codice postale / codice postale ecc.
Mentre tutti i dati erano disponibili nel repository, solo i dati completi e i dati purificati sono stati permessi al mart per interrogare

Oltre a questo puoi sovrapporre i segmenti precalcolati. Ad esempio, piuttosto che cercare di tirare dire, tutti gli operai nel paese, puoi utilizzare la segmentazione per sondare solo in quelle aree che sono prevalentemente colletti blu.

EDIT (seguito dall'aggiornamento di Joe)

In questo caso potresti voler creare un mart report oltre al mart e al repository che ho descritto sopra, che è snello, medio e ottimizzato per query veloci e rapporti MI.

score 0 · Answer 3

Sicuramente è a favore di un riduzione della mappa incrementale . In pratica, si esegue un'operazione sulla raccolta che elabora i documenti esistenti e li inserisce in una nuova raccolta e man mano che si aggiungono nuovi documenti si uniscono tali righe nella raccolta derivata.