当我开始对大型数据集（许多样本、许多变量）进行探索性分析时，我经常发现自己有数百个派生变量和大量不同的图，并且没有真正的方法来跟踪哪里发生了什么。代码最终像意大利面一样，因为从一开始就没有方向......
是否有任何推荐的方法来保持探索性分析的整洁？特别是，你如何处理多个探索分支（包括那些死胡同），以及不同版本的情节？
作为参考，我正在研究地球科学数据（随着时间的推移，许多变量，有时也在空间上）。我通常使用 Python 或 R，并将所有内容存储在 git 中，并且一直在尝试 IPython Notebook。但是，如果答案对所有领域的人都具有通用性和有用性，以及其他类型的（大？）数据，那将是一件好事。
我认为，经常感觉你在探索性分析中掉进了兔子洞的倾向是由于忽视了你所问的实质性问题。我自己做，偶尔，然后不得不提醒自己我的目标是什么。例如，我是在尝试构建特定模型，还是评估现有模型的充分性？我是否在寻找数据存在问题的证据（即法证数据分析）？或者，这是在分析的早期阶段，在继续开发正式模型之前，我正在非正式地调查特定问题（例如，两个变量之间是否存在关系？）？总而言之，如果您发现自己在制作图表和表格，但不能清楚地说明您的近期目标是什么或为什么该图表/表格是相关的，那么您知道您
我尝试像写作一样进行探索性数据分析，无论是编写程序还是撰写文章。在任何一种情况下，如果不先制作大纲，我都不会开始。当然，该大纲可以更改（并且经常更改），但是在没有大纲的情况下开始编写是低效的，并且通常会产生糟糕的最终产品。
在 WRT 组织中，每个分析师都必须找到适合他或她的工作流程——这样做比试图严格遵循其他人的工作流程更重要（尽管从其他人的工作中获取想法总是有帮助的）。如果您以编程方式工作（即编写可以运行以生成/重新生成一组结果的代码）并将您的工作检查到 git 中，那么您在这方面已经领先许多人了。我怀疑您可能只需要花一些时间来组织您的代码，为此，我建议您遵循您的大纲。例如，使您的分析文件相对较短且有针对性，以便每个文件都回答一个特定问题（例如，特定回归模型的诊断图）。根据项目的规模和复杂性，将它们组织到一个或两个级别的子目录中。这样，项目就变成了自文档化的；理论上，目录、子目录和文件的列表视图（以及每个文件顶部的注释）应该重现您的大纲。
当然，在一个大型项目中，您可能还拥有进行数据清理和管理的代码、为估计某种类型的模型而编写的代码，或者您编写的其他实用程序，这些不符合实质性数据分析的大纲，因此它们应该组织在项目文件夹的不同部分中。
更新：发布此消息后，我意识到我没有直接解决您关于“死胡同”的问题。如果你真的认为一整套分析没有价值，那么如果你在 git 中工作，你总是可以删除相应的文件，并带有提交消息，例如“放弃这行分析，因为它不是富有成效的。” 不像把你写的东西揉成一团扔进垃圾桶，如果需要，你总是可以回到你以后做的事情。
但是，我想你会发现，如果你从一个你已经考虑过的大纲开始，你就会有更少的所谓死胡同。相反，如果你花时间调查一个有价值且相关的问题——即使这会导致一个无效的发现或结果不像你预期的那样——你可能仍然希望记录你所做的事情和结果（在最低限度，这样您以后就不会犯错重复此操作）。只需将它们移到大纲的底部，类似于“附录”。
我不知道一般答案会有多大帮助。你在问如何做一些困难的事情；好的答案可能取决于学科，并且可能会很长且有细微差别。:)
就组织而言，您已经在使用 git，因此接下来您应该开始使用makefile来执行分析。makefile 列出了不同文件如何相互依赖（即，哪些统计信息来自哪些代码）以及当您调用 时make，需要更新的所有内容都会更新。
现在，这对探索部分没有帮助。对于 EDA，我通过 ESS 在 emacs 中使用（主要）R。您需要 EDA 的 REPL。我的工作流程是在 ESS（在exploratory.R类型文件中）中使用绘图、估计等，决定我要保留的内容，然后对其进行重新编码，以便它可以通过 make 批量执行。回复：git，我不知道你是如何使用它的，但我为每个项目使用一个存储库（通常是一篇论文），并从我的代码库中重新设置基准以保持干净的历史；即我使用
$ git merge meandering-branch --squash
$ git add -p somefile
$ git rebase -i master
$ git reset HEAD --hard
比我开始使用 git 时要多得多，也比我推荐的初学者要多得多。如果您不熟悉所有这些命令和选项，您可能想了解更多 git。对我最大的帮助是在做出逻辑上不同的提交时要自律；即每次提交都应该包含您将来可能想要一次性撤消的所有更改（不多也不少）。
就实际探索数据而言，我发现这些书有用且有趣，它们专门处理大型数据集（至少部分处理）：
大数据集的图形，由 Unwin、Theus 和 Hofmann 编辑。如果您有权访问，请通过 springerlink，否则个别章节可能通过谷歌搜索获得。
数据可视化手册，由 Chen、Härdle 和 Unwin 编辑。也通过 springerlink
Huber 的数据分析(2011)..
两个字：概念图。这是我发现划分和征服大型数据集或任何真正令人费解的概念的唯一有效方法。http://en.wikipedia.org/wiki/Concept_maps
就个人而言，我认为在纸上比在屏幕上更好，所以在我开始做任何基本分析之前，我只是在脑海中映射我正在处理的内容。对于更专业的图表，有很多思维导图软件http://en.wikipedia.org/wiki/List_of_concept-_and_mind-mapping_software
思维导图有几个优点：
编辑：
例如，这里是因子分析的概念图：http ://www.metacademy.org/graphs/concepts/factor_analysis#focus=factor_analysis&mode=explore现在这纯粹是为了学习概念，而不是执行分析，而是思想是一样的：提前规划出有意义的事情，然后去做。
如果您正在寻找它的自动/编码版本，我认为不存在。当你试图理解一个系统时，你不能自动化建模的概念。（这是一件好事，因为它会让很多人失业。）
您已经在使用 git：为什么不使用版本控制来组织您的探索？为您的探索的每个新“分支”创建一个新分支，并为不同版本的绘图分叉分支。这种方法会使合并最终结果变得稍微困难一些，但您始终可以维护一个未跟踪的目录，您可以在其中放入分析的“宝石”。您可能希望以某种方式标记此目录中的文件以指示它们来自哪个 fork/commit。这种方法还有一个额外的好处，就是可以很容易地通过diff命令对比不同的分析。