Quanto sono grandi i big data?

Molte persone usano il termine big data in un modo piuttosto commerciale , come mezzo per indicare che nel calcolo sono coinvolti grandi set di dati, e quindi le potenziali soluzioni devono avere buone prestazioni. Naturalmente, i big data portano sempre termini associati, come scalabilità ed efficienza, ma cosa definisce esattamente un problema come un problema di big data ?

Il calcolo deve essere correlato a una serie di scopi specifici, come il data mining / il recupero di informazioni, oppure un algoritmo per problemi di grafici generali può essere etichettato come big data se l'insieme di dati era abbastanza grande ? Inoltre, come grande è abbastanza grande (se questo è possibile definire)?

Per me (proveniente da uno sfondo di database relazionale), "Big Data" non riguarda principalmente la dimensione dei dati (che è la maggior parte di ciò che le altre risposte sono finora).

"Big Data" e "Bad Data" sono strettamente correlati. I database relazionali richiedono "dati incontaminati". Se i dati sono nel database, sono accurati, puliti e affidabili al 100%. I database relazionali richiedono "grandi dati" e viene impiegata un'enorme quantità di tempo, denaro e responsabilità per assicurarsi che i dati siano ben preparati prima di caricarli nel database. Se i dati sono nel database, sono "vangelo" e definiscono la comprensione del sistema della realtà.

I "Big Data" affrontano questo problema dall'altra parte. I dati sono definiti in modo inadeguato, molti di essi potrebbero essere inaccurati e molti di essi potrebbero in effetti essere mancanti. La struttura e il layout dei dati sono lineari rispetto a quelli relazionali.

I Big Data devono disporre di un volume sufficiente per rendere statisticamente insignificante la quantità di dati errati o mancanti. Quando gli errori nei tuoi dati sono abbastanza comuni da annullarsi a vicenda, quando i dati mancanti sono proporzionalmente abbastanza piccoli da essere trascurabili e quando i requisiti e gli algoritmi di accesso ai dati sono funzionali anche con dati incompleti e imprecisi, hai "Big Data" .

"Big Data" non riguarda in realtà il volume, riguarda le caratteristiche dei dati.

Come giustamente notate, in questi giorni i "big data" sono qualcosa che tutti vogliono dire di avere, il che comporta una certa scioltezza nel modo in cui le persone definiscono il termine. In generale, però, direi che hai sicuramente a che fare con i big data se la scala è tale che non è più possibile gestirli con tecnologie più tradizionali come RDBMS, almeno senza completarli con tecnologie per big data come Hadoop.

Quanto siano grandi i tuoi dati per essere veri è discutibile. Ecco un post sul blog (un po 'provocatorio) che afferma che non è proprio il caso di meno di 5 TB di dati. (Per essere chiari, non si afferma che "Meno di 5 TB non è un grosso dato", ma solo "Meno di 5 TB non è abbastanza grande da aver bisogno di Hadoop".)

Ma anche su set di dati più piccoli, le tecnologie di big data come Hadoop possono avere altri vantaggi, tra cui essere adatti alle operazioni batch, giocare bene con dati non strutturati (così come i dati la cui struttura non è nota in anticipo o potrebbe cambiare), scalabilità orizzontale ( ridimensionamento aggiungendo più nodi invece di rinforzare i server esistenti) e (come uno dei commentatori delle note di post collegate sopra) la possibilità di integrare l'elaborazione dei dati con set di dati esterni (pensate a una riduzione della mappa in cui il mappatore effettua una chiamata a un altro server). Altre tecnologie associate ai big data, come i database NoSql, enfatizzano le prestazioni veloci e la disponibilità costante mentre si occupano di grandi insiemi di dati, oltre a essere in grado di gestire dati semi-non strutturati e ridimensionare in orizzontale.

Naturalmente, i RDBMS tradizionali hanno i loro vantaggi, tra cui le garanzie ACID (Atomicità, Coerenza, Isolamento, Durabilità) e prestazioni migliori per determinate operazioni, oltre ad essere più standardizzate, più mature e (per molti utenti) più familiari. Quindi, anche per i dati "grandi" indiscutibilmente, può avere senso caricare almeno una parte dei dati in un database SQL tradizionale e utilizzarli insieme alle tecnologie dei big data.

Pertanto, una definizione più generosa sarebbe che si dispone di big data a condizione che sia sufficientemente grande che le tecnologie di big data offrano un valore aggiunto per te. Ma come puoi vedere, ciò può dipendere non solo dalla dimensione dei tuoi dati ma da come vuoi lavorare con essi e che tipo di requisiti hai in termini di flessibilità, coerenza e prestazioni. Come si sta utilizzando i dati è più rilevante per la domanda di quello che si sta utilizzando per (ad esempio il data mining). Detto questo, usi come il data mining e l'apprendimento automatico hanno maggiori probabilità di produrre risultati utili se si dispone di un set di dati abbastanza grande con cui lavorare.

Quantità totale di dati nel mondo: 2,8 zetabyte nel 2012, stimata a raggiungere 8 zetabyte entro il 2015 ( fonte ) e con un tempo di raddoppio di 40 mesi. Non posso diventare più grande di così :)

Come esempio di un'unica grande organizzazione, Facebook inserisce 500 terabyte al giorno, in un magazzino di 100 petabyte, ed esegue 70k query al giorno su di esso a partire dal 2012 ( fonte ). Il loro magazzino attuale è> 300 petabyte.

I big data sono probabilmente una buona parte dei numeri di Facebook (1/100 probabilmente sì, 1/10000 probabilmente no: è uno spettro non un singolo numero).

Oltre alle dimensioni, alcune delle caratteristiche che lo rendono "grande" sono:

• viene attivamente analizzato, non solo memorizzato (citazione "Se non stai sfruttando i big data, allora non hai grandi dati, hai solo una pila di dati" Jay Parikh @ Facebook)

• la costruzione e la gestione di un data warehouse è un grande progetto di infrastruttura

• sta crescendo a un ritmo significativo

• non è strutturato o ha struttura irregolare

Definizione di Gartner: "I big data sono risorse ad alto volume, ad alta velocità e / o ad alta varietà che richiedono nuove forme di elaborazione" (The 3Vs) Quindi pensano anche che "la grandezza" non sia interamente circa la dimensione del set di dati, ma anche sulla velocità, la struttura e il tipo di strumenti necessari.

Per me i Big Data riguardano principalmente gli strumenti (dopo tutto, è lì che è iniziato); un set di dati "grande" è troppo grande per essere gestito con strumenti convenzionali, in particolare abbastanza grande da richiedere archiviazione ed elaborazione su un cluster piuttosto che su una singola macchina. Questo esclude un RDBMS convenzionale e richiede nuove tecniche per l'elaborazione; in particolare, vari framework simili a Hadoop semplificano la distribuzione di un calcolo su un cluster, al costo di limitare la forma di questo calcolo. Secondo, il riferimento a http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html; Le tecniche dei Big Data sono l'ultima risorsa per i set di dati che sono semplicemente troppo grandi per essere gestiti in altro modo. Direi che qualsiasi set di dati per qualsiasi scopo potrebbe qualificarsi se fosse abbastanza grande, anche se se la forma del problema è tale che gli strumenti "big data" esistenti non sono appropriati, probabilmente sarebbe meglio inventarne uno nuovo nome.

Naturalmente c'è qualche sovrapposizione; quando (brevemente) ho lavorato su last.fm, abbiamo lavorato sullo stesso set di dati da 50 TB usando Hadoop e anche in un database SQL su un server abbastanza ridicolo (ricordo che aveva 1 TB di RAM, e questo è qualche anno fa). Il che in un certo senso significava che entrambi erano e non erano grandi dati, a seconda del lavoro a cui stavi lavorando. Ma penso che sia una caratterizzazione accurata; le persone che hanno lavorato ai lavori di Hadoop hanno trovato utile andare alle conferenze e ai siti Web di Big Data, mentre le persone che hanno lavorato ai lavori di SQL non lo hanno fatto.

I dati diventano "grandi" quando un singolo computer non può più gestire la quantità di dati che hai. Indica il punto in cui è necessario iniziare a pensare alla costruzione di supercomputer o all'utilizzo di cluster per elaborare i dati.

I Big Data sono definiti dal volume di dati, giusto, ma non solo. La particolarità di grande dati è che è necessario memorizzare un sacco di diversi e talvolta non strutturati stoffe tutti i tempi e da un tonnellate di sensori , di solito per anni o dieci anni .

Inoltre hai bisogno di qualcosa di scalabile, in modo che non ti occorra un anno e mezzo per ritrovare i dati.

Ecco quindi i Big Data, in cui il metodo tradizionale non funzionerà più. SQL non è scalabile. E SQL funziona con dati molto strutturati e collegati (con tutti quei messaggi di chiave primaria ed esterna, innerjoin, richiesta integrata ...).

Fondamentalmente, poiché l'archiviazione diventa sempre più economica e i dati diventano sempre più preziosi, il grande manager chiede all'ingegnere di registrare tutto. Aggiungi a questo tonnellate di nuovi sensori con tutti quei dispositivi mobili, social network, elementi incorporati ... ecc. Quindi, poiché i metodi classici non funzionano, devono trovare nuove tecnologie (archiviare tutto in file, in formato json, con grande indice, ciò che chiamiamo noSQL).

Quindi i Big Data possono essere molto grandi ma non possono essere così grandi ma complessi non strutturati o vari dati che devono essere archiviati rapidamente e in esecuzione in un formato non elaborato. In un primo momento ci concentriamo e memorizziamo, quindi osserviamo come collegare tutto insieme.

Condividerò come sono i Big Data nella genomica, in particolare nell'assemblea de novo.

Quando eseguiamo il sequenziamento del tuo genoma (ad esempio: individuazione di nuovi geni), prendiamo miliardi di letture di prossima generazione. Guarda l'immagine qui sotto, dove proviamo a mettere insieme alcune letture.

Sembra semplice? Ma cosa succede se hai miliardi di quelle letture? Cosa succede se quelle letture contengono errori di sequenza? Cosa succede se la RAM non ha memoria sufficiente per conservare le letture? Che dire delle regioni ripetitive del DNA, come l' Alu Element molto comune ?

L'assemblaggio de-novo viene realizzato costruendo un grafico De-Bruijn :

Il grafico è una struttura di dati elaborata in modo intelligente per rappresentare letture sovrapposte. Non è perfetto ma è meglio che generare tutte le possibili sovrapposizioni e memorizzarle in un array.

Il completamento del processo di assemblaggio potrebbe richiedere alcuni giorni, poiché ci sono un certo numero di percorsi che un assemblatore dovrebbe percorrere e crollare.

In genomica, hai grandi quantità di dati quando:

• Non puoi forzare brutalmente tutte le combinazioni
• Il tuo computer non ha memoria fisica sufficiente per archiviare i dati
• È necessario ridurre le dimensioni (ad esempio: comprimendo percorsi grafici ridondanti)
• Ti arrabbi perché dovresti aspettare giorni per fare qualsiasi cosa
• È necessaria una struttura dati speciale per rappresentare i dati
• È necessario filtrare il set di dati per errori (ad es. Errori di sequenziamento)

https://en.wikipedia.org/wiki/De_Bruijn_graph

C'è qualcosa di speciale nel rappresentare graficamente algoritmi, domande originali che rendono poi speciali, che riguardano essenzialmente la sua capacità di partizionare i dati.

Per alcune cose, come l'ordinamento dei numeri su un array, non è troppo difficile suddividere il problema sulla struttura dei dati in pezzi disgiuntivi più piccoli, ad es. Qui: Parallel in place merge sort

$NP-hard$

Quindi, mentre 10 GB di numeri da ordinare potrebbero essere un problema molto accessibile su un normale PC (puoi farlo tramite la programmazione dinamica e avere un'ottima prevedibilità sul flusso del programma), lavorare con una struttura di dati del grafico da 10 GB può già essere una sfida.

Esistono numerosi framework specializzati come GraphX ​​che utilizzano metodi e paradigmi informatici speciali per aggirare in qualche modo le sfide intrinseche dei grafici.

Quindi, per rispondere brevemente alla tua domanda: come accennato in precedenza da altri, quando i tuoi dati non rientrano nella memoria principale di un normale PC ma hai bisogno di tutto per rispondere al tuo problema, è un buon suggerimento che i tuoi dati siano già in qualche modo grandi. L'etichettatura esatta dipende però, penso un po 'dalla struttura dei dati e dalla domanda posta.

Penso che i big data inizino nel punto in cui la dimensione ti impedisce di fare quello che vuoi. Nella maggior parte degli scenari, esiste un limite al tempo di esecuzione considerato fattibile. In alcuni casi è un'ora, in alcuni casi potrebbero essere poche settimane. Fintanto che i dati non sono abbastanza grandi da consentire l'esecuzione solo di algoritmi O (n) nell'intervallo di tempo fattibile, non è stato possibile raggiungere i big data.

Mi piace questa definizione poiché è indipendente da volume, livello tecnologico e algoritmi specifici. Non è agnostico per le risorse, quindi uno studente laureato raggiungerà il punto di big data molto prima di Google.

Per poter quantificare quanto sono grandi i dati, mi piace considerare il tempo necessario per il backup. Dal momento che la tecnologia avanza, i volumi considerati grandi alcuni anni fa sono ora moderati. Il tempo di backup migliora, come la tecnologia migliora, proprio come il tempo di esecuzione degli algoritmi di apprendimento. Ritengo sia più sensato parlare di un set di dati che richiede X ore per il backup e non di un set di dati di Y byte.

PS.

È importante notare che anche se hai raggiunto il punto big data e non puoi eseguire algoritmi di complessità più di O (n) in modo diretto, c'è molto che puoi fare per beneficiare ancora di tali algoritmi.

Ad esempio, la selezione delle funzioni può ridurre il numero di funzioni dalle quali dipende il tempo di esecuzione di molti algoritmi. In molte distribuzioni a coda lunga, focalizzare l'attenzione sui pochi elementi nella testa potrebbe essere di beneficio. È possibile utilizzare un campione ed eseguire su di esso gli algoritmi più lenti.

I dati sono "Big Data" se hanno un volume tale da essere meno costoso analizzarli su due o più computer di consumo rispetto a un computer di fascia alta.

Questo è essenzialmente il modo in cui il file system "BigFiles" di Google ha avuto origine. Page e Brin non potevano permettersi un server Sun sofisticato per archiviare ed eseguire ricerche nel loro indice Web, quindi hanno collegato diversi computer di largo consumo

Tendo ad essere d'accordo con ciò che @Dan Levin ha già detto. Alla fine, dal momento che vogliamo trarre utili informazioni dai dati piuttosto che archiviarli, è la capacità di apprendere algoritmi / sistemi che dovrebbe determinare ciò che viene chiamato "Big data". Con l'evolversi dei sistemi ML, ciò che oggi era Big Data non sarà più Big Data domani.

Un modo per definire i big data potrebbe essere:

• Big data : dati su cui non è possibile costruire modelli ML in tempi ragionevoli (1-2 ore) su una normale workstation (con diciamo 4 GB di RAM)
• Dati non grandi : complemento di quanto sopra

Supponendo questa definizione, fintanto che la memoria occupata da una singola riga (tutte le variabili per un singolo punto dati) non supera la RAM della macchina, dovremmo essere nel regime di dati non big .

Nota: Vowpal Wabbit (di gran lunga il sistema ML più veloce di oggi) può imparare su qualsiasi set di dati purché una singola riga (punto dati) sia <RAM (diciamo 4 GB). Il numero di righe non è una limitazione perché utilizza SGD su più core. Parlando per esperienza, puoi addestrare un modello con 10k funzioni e 10MN righe su un laptop in un giorno.

I "big data" sono letteralmente solo molti dati. Sebbene sia più un termine di marketing che qualsiasi altra cosa, di solito la conseguenza è che hai così tanti dati che non puoi analizzare tutti i dati contemporaneamente perché la quantità di memoria (RAM) sarebbe necessaria per conservare i dati in memoria elaborarlo e analizzarlo è maggiore della quantità di memoria disponibile.

Ciò significa che le analisi di solito devono essere eseguite su segmenti casuali di dati, il che consente di creare modelli per il confronto con altre parti dei dati.