Как контролировать предварительные анализы больших наборов данных?

Когда я начинаю исследовательский анализ большого набора данных (много выборок, много переменных), я часто оказываюсь с сотнями производных переменных и тоннами разных графиков, и у меня нет реального способа отслеживать, что и где происходит. Код заканчивается как спагетти, потому что нет направления с самого начала ...

Существуют ли рекомендуемые методы для проведения поискового анализа в чистоте и порядке? В частности, как вы справляетесь с несколькими ветвями исследования (включая тупиковые) и с разными версиями сюжетов?

Для справки, я работаю над геонаучными данными (многие переменные со временем, иногда также в космосе). Я обычно работаю с Python или R и храню все в git, а также пробовал IPython Notebook. Однако было бы хорошо, если бы ответы были несколько общими и полезными для людей во всех областях, с другими типами (большими?) Данными.

Я думаю, что часто, склонность чувствовать, что вы спустились в кроличью нору с предварительным анализом, происходит из-за того, что вы упускаете из виду существенный вопрос, который вы задаете. Иногда я делаю это сам, а потом должен напоминать себе, каковы мои цели. Например, пытаюсь ли я построить конкретную модель или оценить адекватность существующей? Я ищу доказательства проблем с данными (например, криминалистический анализ данных)? Или это на ранних этапах анализа, когда я неофициально изучаю конкретные вопросы (например, существует ли связь между двумя переменными?), Прежде чем перейти к разработке формальной модели? В общем, если вы ловите себя на том, что проверяете графики и таблицы, но не можете четко указать, какова ваша непосредственная цель или почему этот график / таблица имеет значение, то вы знаете, что «

Я стараюсь подойти к исследовательскому анализу данных, как пишу, будь то написание программы или написание статьи. В любом случае, я бы не стал сначала делать наброски. Конечно, эта схема может измениться (и часто меняется), но начинать писать без таковой неэффективно и часто приводит к плохому конечному продукту.

В организации WRT каждый аналитик должен найти рабочий процесс, который работает для него или ее - делать это для ИМО важнее, чем пытаться строго следовать чужому рабочему процессу (хотя всегда полезно получать идеи от того, что делают другие). Если вы работаете программно (то есть пишете код, который можно запустить для генерации / восстановления набора результатов) и проверяете свою работу в git, то вы уже намного опережаете многих в этом отношении. Я подозреваю, что вам, возможно, просто нужно потратить некоторое время на организацию своего кода, и для этого я бы предложил следовать вашему плану. Например, файлы анализа должны быть относительно короткими и целенаправленными, чтобы каждый отвечал на один конкретный вопрос (например, диагностические графики для конкретной модели регрессии). Организуйте их в подкаталоги на одном или двух уровнях, в зависимости от размера и сложности проекта. Таким образом, проект становится самодокументированным; представление списка каталогов, подкаталогов и файлов (вместе с комментарием вверху каждого файла) теоретически должно воспроизводить ваш контур.

Конечно, в большом проекте у вас также может быть код, который выполняет очистку и управление данными, код, который вы написали для оценки модели определенного типа, или другие написанные вами утилиты, и они не будут вписываться в основную часть. Схема для анализа данных, поэтому они должны быть организованы в другой части папки вашего проекта.

Обновление: после публикации я понял, что не обращался напрямую к вашему вопросу о «тупиках». Если вы действительно решили, что весь набор анализов не имеет смысла, то, если вы работаете в git, вы всегда можете удалить соответствующий файл (-ы) с сообщением о коммите, например: «Отказались от этой строки анализа, потому что она не была продуктивный «. В отличие от того, чтобы сложить то, что вы написали, и выбросить это в мусорное ведро, вы всегда можете вернуться к тому, что вы сделали позже, если хотите.

Тем не менее, я думаю, вы обнаружите, что если вы начнете с набросков, к которым вы подумали, у вас будет меньше так называемых тупиков. Вместо этого, если вы тратите время на исследование стоящего и уместного вопроса - даже если это приводит к нулевому результату или не получается так, как вы ожидали, - вы, вероятно, все еще хотите вести учет того, что вы сделали, и результата (в минимум, чтобы вы не ошиблись, повторив это позже). Просто переместите их в конец своего наброска, в виде «Приложения».

Я не знаю, насколько полезным будет общий ответ. Вы спрашиваете, как сделать что-то сложное; Хорошие ответы, вероятно, будут зависеть от дисциплины и, вероятно, будут длинными и нюансами. :)

Что касается организации, то вы уже используете git, поэтому затем вы должны начать использовать make-файл для выполнения анализа. Makefile определяет, как разные файлы зависят друг от друга (т. Е. Какая статистика получается из какого кода) и когда вы вызываете make, все, что нужно обновить, будет.

Теперь, это не помогает с исследовательской частью. Для EDA я использую (в основном) R в Emacs через ESS. Вам нужно, нужен ответ на EDA. Мой рабочий процесс состоит в том, чтобы поиграть с графиками, оценками и т. Д. В ESS (в exploratory.Rфайле типов), решить, что я хочу сохранить, а затем перекодировать его, чтобы он мог быть выполнен пакетным способом make. Re: мерзавец, я не знаю, как вы используете его, но я использую один репозиторий для каждого проекта (обычно один документ) и перебираю ад из моей кодовой базы, чтобы сохранить чистую историю; т.е. я использую

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

намного больше, чем когда я начинал с git, и намного больше, чем я бы рекомендовал новичку. Если вы не знакомы со всеми этими командами и опциями, вы можете узнать больше о git. Самая важная вещь, которая помогла мне - это быть дисциплинированным в совершении логически различных коммитов; т. е. каждый коммит должен содержать все изменения, которые вы можете отменить все сразу в будущем (и не более или менее).

Что касается фактического изучения данных, я нашел эти книги полезными и интересными, и они имеют дело именно с большими наборами данных (по крайней мере, по частям):

• Графика больших наборов данных , отредактированная Unwin, Theus и Hofmann. через Springerlink, если у вас есть доступ, в противном случае отдельные главы, вероятно, доступны путем поиска в Google.

• Справочник по визуализации данных , отредактированный Ченом, Хердле и Унвином. также через Springerlink

• Анализ данных по Huber (2011) ..

Два слова: концептуальная карта. Это единственный эффективный способ, который я нашел для разделения и завоевания больших наборов данных или любой действительно замысловатой концепции. http://en.wikipedia.org/wiki/Concept_maps

Лично я думаю, что лучше на бумаге, чем на экране, поэтому я просто мысленно сопоставляю то, с чем имею дело, прежде чем даже приступить к какому-либо основному анализу. Для более профессиональной схемы существует множество программ для составления карт разума http://en.wikipedia.org/wiki/List_of_concept-_and_mind-mapping_software

Mind Mapping имеет несколько преимуществ:

• говорит мне, что у меня есть с точки зрения «основных» переменных и производных переменных (если таковые имеются)
• позволяет организовать / сформулировать модель, основанную на теории / логике
• указывает на то, какие переменные я могу пропустить и / или мог бы добавить, если отношения между основными переменными не складываются, как я думаю, они должны

Редактировать :

В качестве примера приведем концептуальную карту для факторного анализа: http://www.metacademy.org/graphs/concepts/factor_analysis#focus=factor_analysis&mode=explore Теперь это просто для изучения концепции, а не для выполнения анализа, но идея то же самое: заранее наметить, что имеет смысл делать, а затем сделать это.

Если вы ищете автоматизированную / закодированную версию этого, я не думаю, что она существует. Вы не можете автоматизировать концепцию моделирования, когда пытаетесь понять систему. (И это хорошо, потому что это лишит людей работы.)

Вы уже используете git: почему бы не использовать контроль версий для организации своего исследования? Создайте новую ветвь для каждой новой «ветви» вашего исследования, а также разветвите ветки для разных версий графиков. Этот метод немного усложнит объединение ваших конечных результатов, но вы всегда можете поддерживать не отслеживаемый каталог, в который можно было бы поместить «жемчужины» вашего анализа. Возможно, вы захотите как-нибудь пометить ваши файлы в этом каталоге, чтобы указать, с какого форка / коммита они пришли. Этот метод имеет дополнительное преимущество, заключающееся в упрощении сопоставления различных анализов с помощью diffкоманды.

Я бы посмотрел на инструменты бизнес-аналитики ... где возникают подобные проблемы. В частности (хранилища данных, анализ измерений), иерархии и детализация.

Основная идея заключается в том, что вы пытаетесь представить свои базовые данные в виде суммируемых количеств (количество, прибыль и т. Д., А не, например, проценты). Затем вы разрабатываете иерархии для агрегирования по деталям (например, месяцы / недели / ...). Это позволяет вам иметь простые обзоры всех ваших данных и затем увеличивать в определенных областях. см., например, http://cubes.databrewery.org/ (python) или Excel Power Pivot