Comment contrôler les analyses exploratoires de grands ensembles de données?

Lorsque je commence une analyse exploratoire sur un grand ensemble de données (de nombreux échantillons, de nombreuses variables), je me retrouve souvent avec des centaines de variables dérivées, et des tonnes de graphiques différents, et aucun moyen réel de garder une trace de ce qui se passe où. Le code finit comme des spaghettis, car il n'y a pas de direction dès le départ ...

Existe-t-il des méthodes recommandées pour maintenir une analyse exploratoire propre et ordonnée? En particulier, comment traitez-vous plusieurs branches d'exploration (y compris celles qui étaient des impasses), et avec différentes versions de parcelles?

Pour référence, je travaille sur des données géoscientifiques (de nombreuses variables dans le temps, parfois aussi dans l'espace). Je travaille généralement avec Python ou R, et stocke tout dans git, et j'ai également essayé le bloc-notes IPython. Cependant, il serait bon que les réponses soient quelque peu générales et utiles pour les personnes dans tous les domaines, avec d'autres types de données (volumineuses?).

Je pense que souvent, la tendance à se sentir comme si vous étiez allé dans un terrier de lapin avec des analyses exploratoires est due à la perte de vue des questions de fond que vous posez. Je le fais moi-même, à l'occasion, puis je dois me rappeler quel est mon objectif. Par exemple, est-ce que j'essaie de construire un modèle spécifique ou d'évaluer l'adéquation d'un modèle existant? Suis-je à la recherche de preuves de problèmes avec les données (c.-à-d., Analyse de données médico-légales)? Ou est-ce aux premiers stades de l'analyse, où j'étudie des questions spécifiques de manière informelle (par exemple, y a-t-il une relation entre deux variables?) Avant de passer à l'élaboration d'un modèle formel? En somme, si vous vous surprenez à lancer des graphiques et des tableaux mais que vous ne pouvez pas indiquer clairement quel est votre objectif immédiat ou pourquoi ce graphique / tableau est pertinent, alors vous savez que vous ''

J'essaie d'aborder l'analyse exploratoire des données comme j'écris, qu'il s'agisse d'écrire un programme ou d'écrire un article. Dans les deux cas, je ne commencerais pas sans faire d'abord un plan. Ce schéma peut changer (et change fréquemment), bien sûr, mais commencer à écrire sans un est inefficace et donne souvent un mauvais produit final.

En tant qu'organisation WRT, chaque analyste doit trouver un flux de travail qui fonctionne pour lui - il est plus important de le faire à l'OMI que d'essayer de suivre rigoureusement le flux de travail de quelqu'un d'autre (bien qu'il soit toujours utile d'obtenir des idées de ce que font les autres). Si vous travaillez par programme (c.-à-d., Écrivez du code qui peut être exécuté pour générer / régénérer un ensemble de résultats) et archivez votre travail dans git, alors vous avez déjà des kilomètres d'avance sur beaucoup à cet égard. Je soupçonne que vous pourriez avoir juste besoin de passer du temps à organiser votre code, et pour cela, je vous suggère de suivre votre plan. Par exemple, gardez vos fichiers d'analyse relativement courts et ciblés, afin que chacun réponde à une question spécifique (par exemple, les tracés de diagnostic pour un modèle de régression spécifique). Organisez-les en sous-répertoires à un ou deux niveaux, selon la taille et la complexité du projet. De cette façon, le projet devient auto-documenté; une vue de liste des répertoires, sous-répertoires et fichiers (avec le commentaire en haut de chaque fichier) devrait, en théorie, reproduire votre plan.

Bien sûr, dans un grand projet, vous pouvez également avoir du code qui effectue le nettoyage et la gestion des données, du code que vous avez écrit pour estimer un certain type de modèle, ou d'autres utilitaires que vous avez écrits, et ceux-ci ne rentreront pas dans le fond pour votre analyse des données, elles doivent donc être organisées dans une autre partie du dossier de votre projet.

Mise à jour: Après avoir posté cela, j'ai réalisé que je n'ai pas directement répondu à votre question sur les "impasses". Si vous décidez vraiment qu'un ensemble complet d'analyses n'a aucune valeur, alors si vous travaillez dans git, vous pouvez toujours supprimer le (s) fichier (s) correspondant (s) avec un message de validation comme "Abandonné cette ligne d'analyse parce qu'elle n'était pas productif." Contrairement à froisser ce que vous avez écrit et à le jeter à la poubelle, vous pouvez toujours revenir à ce que vous avez fait plus tard, si vous le souhaitez.

Cependant, je pense que vous constaterez que si vous procédez à partir d'un schéma auquel vous avez réfléchi, vous aurez moins de soi-disant impasses. Au lieu de cela, si vous passez du temps à enquêter sur une question utile et pertinente - même si cela conduit à une conclusion nulle ou ne se révèle pas comme vous l'aviez prévu - vous voulez probablement garder une trace de ce que vous avez fait et du résultat (à un minimum, pour ne pas faire l'erreur de répéter cela plus tard). Déplacez-les simplement au bas de votre plan, dans une sorte d '"Annexe".

Je ne sais pas à quel point une réponse générale sera utile. Vous demandez comment faire quelque chose de difficile; les bonnes réponses dépendront probablement de la discipline et seront probablement longues et nuancées. :)

En ce qui concerne l'organisation, vous utilisez déjà git, vous devez donc commencer à utiliser un makefile pour exécuter l'analyse. Le makefile indique comment les différents fichiers dépendent les uns des autres (c'est-à-dire quelles statistiques sont dérivées de quel code) et quand vous appelez make, tout ce qui doit être mis à jour le sera.

Maintenant, cela n'aide pas avec la partie exploratoire. Pour EDA, j'utilise (principalement) R dans emacs via ESS. Vous devez avoir besoin d'un REPL pour EDA. Mon flux de travail consiste à jouer avec des tracés, des estimations, etc. dans ESS (dans un exploratory.Rfichier de type), décider ce que je veux conserver, puis le recoder afin qu'il puisse être exécuté par lots par make. Re: git, je ne sais pas comment vous l'utilisez, mais j'utilise un seul référentiel pour chaque projet (généralement un seul papier) et rebase l'enfer de ma base de code pour garder un historique propre; c'est à dire que j'utilise

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

bien plus que lorsque j'ai commencé avec git, et bien plus que je ne recommanderais un débutant. Si vous n'êtes pas familier avec toutes ces commandes et options, vous voudrez peut-être en savoir plus sur git. La plus grande chose qui m'a aidé est d'être discipliné pour faire des commits logiquement distincts; c'est-à-dire que chaque commit doit contenir toutes les modifications que vous pourriez vouloir annuler en une seule fois dans le futur (et pas plus ou moins).

En ce qui concerne réellement l'exploration des données, j'ai trouvé ces livres utiles et intéressants, et ils traitent spécifiquement des grands ensembles de données (au moins en partie):

• The Graphics of Large Datasets , édité par Unwin, Theus et Hofmann. via springerlink si vous y avez accès, sinon des chapitres individuels sont probablement disponibles sur Google.

• Le manuel de visualisation des données , édité par Chen, Härdle et Unwin. également via springerlink

• Analyse des données par Huber (2011) ..

Deux mots: carte conceptuelle. C'est le seul moyen efficace que j'ai trouvé pour diviser et conquérir de grands ensembles de données ou tout concept vraiment compliqué. http://en.wikipedia.org/wiki/Concept_maps

Personnellement, je pense mieux sur le papier que sur l'écran, donc je pense à ce à quoi je fais face avant même de commencer à faire une analyse de base. Pour un schéma plus professionnel, il existe de nombreux logiciels de mind mapping http://en.wikipedia.org/wiki/List_of_concept-_and_mind-mapping_software

La cartographie mentale présente plusieurs avantages:

• me dit ce que j'ai en termes de variables "de base" et de variables dérivées (le cas échéant)
• permet l'organisation / la formulation d'un modèle basé sur la théorie / la logique
• indique quelles variables je pourrais manquer et / ou pourrait ajouter si les relations entre les variables de base ne se déroulent pas comme je pense qu'elles devraient

Modifier :

À titre d'exemple, voici la carte conceptuelle de l'analyse factorielle: http://www.metacademy.org/graphs/concepts/factor_analysis#focus=factor_analysis&mode=explore Maintenant, c'est uniquement pour apprendre le concept, pas pour effectuer l'analyse, mais pour l'idée est la même: tracer à l'avance ce qu'il est logique de faire, puis le faire.

Si vous cherchez une version automatisée / codée de cela, je ne pense pas qu'il existe. Vous ne pouvez pas automatiser le concept de modélisation lorsque vous essayez de comprendre un système. (Et c'est une bonne chose car cela mettrait beaucoup de gens sans emploi.)

Vous utilisez déjà git: pourquoi ne pas utiliser le contrôle de version pour organiser votre exploration? Créez une nouvelle branche pour chaque nouvelle "branche" de votre exploration, et dérivez également les branches pour différentes versions de parcelles. Cette méthode rendra un peu plus difficile la combinaison de vos résultats finaux, mais vous pourrez toujours conserver un répertoire non suivi où vous pourrez déposer les "joyaux" de votre analyse. Vous voudrez probablement étiqueter vos fichiers dans ce répertoire pour indiquer de quel fork / commit ils sont issus. Cette méthode a l'avantage supplémentaire de faciliter le contraste de différentes analyses via la diffcommande.

J'examinerais les outils de Business Intelligence ... où des problèmes similaires se posent. En particulier (entrepôts de données, analyse dimensionnelle,) hiérarchies et hiérarchies.

L'idée de base est que vous essayez de représenter vos données sous-jacentes sous forme de quantités agrégables (comptes, gains, etc. plutôt que par exemple des pourcentages). Ensuite, vous concevez des hiérarchies à agréger sur les détails (par exemple mois / semaines / ...). Cela vous permet d'avoir un aperçu simple de toutes vos données, puis de zoomer sur des zones particulières. voir par exemple http://cubes.databrewery.org/ (python) ou excel power pivot