grandi quantità di dati in molti file di testo - come elaborare?

Question

Ho grandi quantità di dati (alcuni terabyte) e accumuli ... Sono contenuti in molti file di testo piatto delimitati da tabulazioni (ciascuno di circa 30 MB). La maggior parte del lavoro consiste nella lettura dei dati e nell'aggregazione (sommatoria/mediazione + trasformazioni aggiuntive) su osservazioni/righe in base a una serie di istruzioni sui predicati e quindi salvataggio dell'output come testo, file HDF5 o SQLite, ecc. Normalmente utilizzo R per tali compiti, ma temo che questo potrebbe essere un po 'grande. Alcune soluzioni candidate devono

1. scrivere il tutto in C (o Fortran)
2. importare i file (tabelle) in un database relazionale direttamente e poi tirare fuori pezzi di R o Python (alcuni delle trasformazioni non sono suscettibili per le soluzioni SQL puro)
3. scrivere il tutto in Python

Would (3) essere una cattiva idea? So che puoi racchiudere le routine C in Python ma in questo caso poiché non c'è nulla di computazionalmente proibitivo (ad es., Routine di ottimizzazione che richiedono molti calcoli iterativi), penso che l'I/O possa essere un collo di bottiglia tanto quanto il calcolo stesso. Avete delle raccomandazioni su ulteriori considerazioni o suggerimenti? Grazie

Modifica Grazie per le vostre risposte. Sembra che ci siano opinioni contrastanti su Hadoop, ma in ogni caso non ho accesso a un cluster (anche se posso usare diverse macchine non collegate) ...

Answer 1

(3) non è necessariamente una cattiva idea - Python semplifica l'elaborazione del file "CSV" (e nonostante la C che sta per Comma, la tabulazione come separatore è altrettanto facile da gestire) e ovviamente ottiene una larghezza di banda pari a quella degli I/O op come qualsiasi altra lingua. Come per gli altri consigli, numpy, oltre al calcolo veloce (che potrebbe non essere necessario secondo le vostre dichiarazioni) fornisce array multi-dimensionali molto maneggevoli e flessibili, che possono essere molto utili per le vostre attività; e il modulo libreria standard multiprocessing consente di sfruttare più core per qualsiasi attività che sia facile da parallelizzare (importante dal momento che praticamente ogni macchina ha molti core ;-).

Answer 2

Dai un'occhiata allo Disco. È un leggero motore MapReduce distribuito, scritto in circa 2000 righe di Erlang, ma progettato specificamente per lo sviluppo di Python. Supporta non solo il lavoro sui dati, ma anche l'archiviazione affidabile di una replica. Hanno appena rilasciato la versione 0.3, che include un livello di indicizzazione e database.

Answer 3

Se si dispone di un cluster di macchine è possibile parallelizzare l'applicazione utilizzando Hadoop Mapreduce. Sebbene Hadoop sia scritto in Java, può eseguire anche Python. È possibile verificare il seguente link per i puntatori in parallelizzazione del codice - PythonWordCount

Answer 4

Sì. Hai ragione! I/O costerebbe la maggior parte del tempo di elaborazione. Non ti suggerisco di usare sistemi distribuiti, come hadoop, per questo compito.

L'attività potrebbe essere eseguita su una workstation modesta. Non sono un esperto di Python, penso che abbia il supporto per la programmazione asincrona. In F # /. Net, la piattaforma ha un buon supporto per questo. Una volta stavo facendo un lavoro di elaborazione delle immagini, il caricamento di immagini da 20K su disco e la loro trasformazione in vettori di funzionalità costava solo diversi minuti in parallelo.

tutto sommato, carica ed elabora i dati in parallelo e salva il risultato in memoria (se piccolo), nel database (se grande).

Answer 5

Con terabyte, si vorrà parallelizzare comunque le letture su molti dischi; così potrebbe anche andare dritto in Hadoop.

Utilizzare Pig o Hive per interrogare i dati; entrambi hanno un ampio supporto per le trasformazioni definite dall'utente, quindi dovresti essere in grado di implementare ciò che devi fare usando il codice personalizzato.

Answer 6

Ok, quindi, solo per essere diversi, perché non R?

• Lei sembra sapere R in modo si può arrivare a codice funzionante in modo rapido
• 30 MB per file non è grande su workstation standard con pochi GB di RAM
• la read.csv() variante di read.table() può essere molto efficace se si specificano i tipi di colonne tramite l'argomento colClasses: invece di guestimating tipi per la conversione, questi saranno gestito in modo efficiente
• il collo di bottiglia qui è i/o dal disco e che è lo stesso per tutte le lingue
• R ha multicore per impostare l'elaborazione parallela su macchine con più core (simile a multiprocessing di Python, sembra)
• Se si desidera utilizzare la struttura "imbarazzantemente parallela" del problema, R ha diversi pacchetti che sono adatti per i dati. problemi paralleli: es snow e foreach possono essere distribuiti su un solo computer o su un set di macchine in rete.

Answer 7

Quando dici "accumulare", la soluzione (2) sembra più adatta al problema.
Dopo il caricamento iniziale fino al database, si aggiorna solo il database con nuovi file (ogni giorno, ogni settimana? Dipende da quanto spesso è necessario).

Nei casi (1) e (3) è necessario elaborare i file ogni volta (ciò che è stato detto in precedenza come maggior parte del tempo/risorse), a meno che non si trovi un modo per archiviare i risultati e aggiornarli con nuovi file.

È possibile utilizzare R per elaborare file da csv a, ad esempio, database SQLite.

Answer 8

Ho avuto la fortuna di usare R con Hadoop su Amazon's Elastic Map Reduce. Con EMR paghi solo il tempo di utilizzo del computer che utilizzi e AMZN si occupa della rotazione e della rotazione delle istanze. Il modo esatto in cui strutturare il lavoro in EMR dipende in realtà da come è strutturato il flusso di lavoro dell'analisi. Ad esempio, sono tutti i record necessari per un lavoro contenuto completamente all'interno di ogni csv o hai bisogno di bit da ogni csv per completare un'analisi?

Ecco alcune risorse che possono essere utili:

• Pete Skomoroch parlando R and AMZN EMR on the AMZN discussion forum
• Il mio blog post su getting started with R and AMZN EMR
• La Rhipe project mira ad integrare R e Hadoop. Rhipe non è focalizzato su EMR, tuttavia, quindi non l'ho ancora usato. Sembra che dovrebbe essere in grado di superare l'EMR, tuttavia.

Il problema che ho citato nel post del mio blog è più di un limite di CPU, non di IO. I tuoi problemi sono più IO, ma i suggerimenti su come caricare librerie e file di cache potrebbero essere utili.

Mentre è allettante tentare di inserire questo/di un database relazionale, è consigliabile considerare attentamente se si ha realmente bisogno di tutto il sovraccarico di un RDB. In caso contrario, è possibile creare un collo di bottiglia e una sfida di sviluppo senza una vera ricompensa.