Come tenere sotto controllo le analisi esplorative di grandi set di dati?

Quando inizio un'analisi esplorativa su un set di dati di grandi dimensioni (molti campioni, molte variabili), mi trovo spesso con centinaia di variabili derivate e tonnellate di grafici diversi e nessun modo reale per tenere traccia di ciò che sta andando dove. Il codice finisce come spaghetti, perché non c'è direzione dall'inizio ...

Esistono metodi consigliati per mantenere un'analisi esplorativa ordinata e ordinata? In particolare, come gestisci più rami dell'esplorazione (compresi quelli che erano vicoli ciechi) e con diverse versioni di trame?

Per riferimento, sto lavorando a dati geoscientifici (molte variabili nel tempo, a volte anche nello spazio). Di solito lavoro con Python o R, conservo tutto in git e ho provato anche il Notebook IPython. Tuttavia, sarebbe positivo se le risposte fossero in qualche modo generali e utili per le persone in tutti i campi, con altri tipi di dati (grandi?).

Penso che frequentemente, la tendenza a sentirti come se fossi caduto in una tana di coniglio con analisi esplorative è dovuta alla perdita di vista delle domande sostanziali che stai ponendo. Lo faccio da solo, ogni tanto, e poi devo ricordare a me stesso quali sono i miei obiettivi. Ad esempio, sto cercando di costruire un modello specifico o valutare l'adeguatezza di uno esistente? Sto cercando prove di problemi con i dati (es. Analisi dei dati forensi)? Oppure, è nelle prime fasi dell'analisi, in cui sto studiando informalmente domande specifiche (ad esempio, esiste una relazione tra due variabili?) Prima di passare a sviluppare un modello formale? In breve, se ti sorprendi a elaborare grafici e tabelle ma non riesci a indicare chiaramente qual è il tuo obiettivo immediato o perché tale trama / tavolo è pertinente, allora sai che '

Cerco di avvicinarmi all'analisi dei dati esplorativi come faccio io scrivendo, sia che si tratti di scrivere un programma o di scrivere un articolo. In entrambi i casi, non vorrei iniziare senza fare prima uno schema. Questo schema può cambiare (e spesso lo fa), ovviamente, ma iniziare a scrivere senza uno è inefficiente e spesso produce un prodotto finale scadente.

Organizzazione WRT, ogni analista deve trovare un flusso di lavoro che funzioni per lui - farlo è più importante dell'IMO che cercare di seguire rigidamente il flusso di lavoro di qualcun altro (anche se è sempre utile ottenere idee da ciò che fanno gli altri). Se stai lavorando a livello di codice (cioè scrivendo codice che può essere eseguito per generare / rigenerare un insieme di risultati) e controllando il tuo lavoro in git, allora sei già molto più avanti di molti in questo senso. Ho il sospetto che potresti aver solo bisogno di dedicare un po 'di tempo all'organizzazione del tuo codice e, per questo, suggerirei di seguire il tuo schema. Ad esempio, mantieni i tuoi file di analisi relativamente brevi e mirati, in modo che ognuno risponda a una domanda specifica (ad esempio, grafici diagnostici per un modello di regressione specifico). Organizzali in sottodirectory a uno o due livelli, a seconda delle dimensioni e della complessità del progetto. In questo modo, il progetto diventa auto-documentante; una vista elenco delle directory, delle sottodirectory e dei file (insieme al commento nella parte superiore di ogni file) dovrebbe, in teoria, riprodurre il tuo schema.

Naturalmente, in un grande progetto, potresti anche avere un codice che esegue la pulizia e la gestione dei dati, il codice che hai scritto per stimare un certo tipo di modello o altre utilità che hai scritto, e queste non si adattano al sostantivo struttura per l'analisi dei dati, quindi devono essere organizzati in una parte diversa della cartella del progetto.

Aggiornamento: dopo aver pubblicato questo, mi sono reso conto che non avevo indirizzato direttamente la tua domanda su "vicoli ciechi". Se decidi davvero che un intero set di analisi non ha alcun valore, quindi se lavori in git, puoi sempre eliminare i file corrispondenti con un messaggio di commit come "Abbandonato questa linea di analisi perché non lo era produttivo." A differenza di accartocciare ciò che hai scritto e gettarlo nella spazzatura, puoi sempre tornare a ciò che hai fatto in seguito, se lo desideri.

Tuttavia, penso che scoprirai che se passi da uno schema a cui hai pensato, avrai meno cosiddetti vicoli ciechi. Invece, se passi il tempo a indagare su una domanda utile e pertinente, anche se ciò porta a una scoperta nulla o non si presenta come previsto, probabilmente vorrai comunque tenere un registro di ciò che hai fatto e del risultato (a un minimo, in modo da non commettere l'errore di ripeterlo in seguito). Basta spostarli nella parte inferiore del contorno, in una sorta di "Appendice".

Non so quanto sarà utile una risposta generale. Stai chiedendo come fare qualcosa di difficile; le buone risposte dipenderanno probabilmente dalla disciplina e saranno probabilmente lunghe e sfumate. :)

Per quanto riguarda l'organizzazione, stai già usando git, quindi dopo dovresti iniziare a usare un makefile per eseguire l'analisi. Il makefile stabilisce come i diversi file dipendono l'uno dall'altro (ovvero, quali statistiche derivano da quale codice) e quando chiami make, tutto ciò che deve essere aggiornato lo farà.

Ora, questo non aiuta con la parte esplorativa. Per EDA uso (principalmente) R in emacs tramite ESS. È necessario un REPL per EDA. Il mio flusso di lavoro è giocare con grafici, stime, ecc. In ESS (in un exploratory.Rfile di tipo), decidere cosa voglio conservare, quindi ricodificarlo in modo che possa essere eseguito in batch da make. Ri: git, non so come lo stai usando, ma uso un singolo repository per ogni progetto (di solito un singolo documento) e rifaccio l'inferno dal mio codice per mantenere una cronologia pulita; cioè io uso

$ git merge meandering-branch --squash
$ git add -p somefile
$ git rebase -i master
$ git reset HEAD --hard

molto più di quando ho iniziato con Git e molto più di quanto consiglierei a un principiante. Se non hai familiarità con tutti quei comandi e opzioni, potresti voler imparare più git. La cosa più grande che mi ha aiutato è essere disciplinato nel fare impegni logicamente distinti; cioè ogni commit dovrebbe contenere tutte le modifiche che potresti voler annullare tutte in una volta (e non più o meno).

Per quanto riguarda effettivamente l'esplorazione dei dati, ho trovato questi libri utili e interessanti e trattano specificamente set di dati di grandi dimensioni (almeno in parti):

• La grafica di grandi set di dati , a cura di Unwin, Theus e Hofmann. tramite springerlink se hai accesso, altrimenti i singoli capitoli sono probabilmente disponibili tramite google.

• Il manuale di visualizzazione dei dati , a cura di Chen, Härdle e Unwin. anche tramite springerlink

• Data Analysis di Huber (2011) ..

Due parole: mappa concettuale. Questo è l'unico modo efficace che ho trovato per dividere e conquistare grandi set di dati o qualsiasi concetto realmente contorto. http://en.wikipedia.org/wiki/Concept_maps

Personalmente, penso meglio sulla carta che sullo schermo, quindi mi limito a mappare ciò di cui mi occupo prima ancora di iniziare a fare qualsiasi analisi di base. Per un diagramma più professionale, ci sono molti software di mappatura mentale http://en.wikipedia.org/wiki/List_of_concept-_and_mind-mapping_software

La mappatura mentale presenta numerosi vantaggi:

• mi dice cosa ho in termini di variabili "core" e variabili derivate (se presenti)
• consente l'organizzazione / formulazione di un modello basato su teoria / logica
• indica quali variabili mi potrebbero mancare e / o potrei aggiungere se le relazioni tra le variabili principali non si aprono come penso che dovrebbero

Modifica :

Ad esempio, ecco la mappa concettuale per l'analisi dei fattori: http://www.metacademy.org/graphs/concepts/factor_analysis#focus=factor_analysis&mode=explore Ora questo è puramente per imparare il concetto, non eseguire analisi, ma l'idea è lo stesso: mappare in anticipo ciò che ha senso fare, e poi farlo.

Se stai cercando una versione automatizzata / codificata di questo, non penso che esista. Non puoi automatizzare il concetto di modellazione quando stai cercando di capire un sistema. (E questa è una buona cosa perché metterebbe molte persone fuori dal lavoro.)

Stai già usando git: perché non usare il controllo versione per organizzare la tua esplorazione? Crea un nuovo ramo per ogni nuovo "ramo" della tua esplorazione e biforziona anche i rami per diverse versioni di grafici. Questo metodo renderà leggermente più difficile combinare i risultati finali, ma è sempre possibile mantenere una directory non tracciata in cui è possibile inserire le "gemme" della propria analisi. Probabilmente vorrai in qualche modo etichettare i tuoi file in questa directory per indicare da quale fork / commit provengono. Questo metodo ha l'ulteriore vantaggio di rendere davvero semplice il contrasto di diverse analisi tramite il diffcomando.

Vorrei esaminare gli strumenti di Business Intelligence ... in cui sorgono problemi simili. In particolare (data warehouse, analisi dimensionale,) gerarchie e drill down.

L'idea di base è che si tenta di rappresentare i dati sottostanti come quantità aggregabili (conteggi, guadagni ecc. Anziché ad esempio percentuali). Quindi si progettano gerarchie per aggregare i dettagli (ad esempio mesi / settimane / ...). Ciò ti consente di avere una semplice panoramica di tutti i tuoi dati e quindi di ingrandire aree particolari. vedi ad esempio http://cubes.databrewery.org/ (python) o Excel pivot di potenza