Як перевірити дослідницький аналіз великих наборів даних?

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

Чи є які-небудь рекомендовані методи для того, щоб тримати дослідний аналіз акуратним та охайним? Зокрема, як ви маєте справу з кількома галузями розвідки (включаючи ті, що були тупиками) та з різними версіями сюжетів?

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

Я думаю, що часто схильність відчувати себе так, ніби ви спустилися з кролячої нори за допомогою дослідницьких аналізів, через втрату зору предметних питань, які ви задаєте. Я роблю це час від часу, а потім доводиться нагадувати собі, яка моя мета. Наприклад, я намагаюся побудувати конкретну модель чи оцінювати адекватність існуючої? Я шукаю докази проблем із даними (тобто, криміналістичний аналіз даних)? Або це на ранніх етапах аналізу, де я неформально досліджую конкретні питання (наприклад, чи існує зв’язок між двома змінними?), Перш ніж перейти до розробки формальної моделі? Підсумовуючи це, якщо ви спіймаєте викручування сюжетів та таблиць, але не можете чітко вказати, яка ваша найближча мета або чому цей сюжет / таблиця є актуальним, то ви знаєте,

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

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

Звичайно, у великому проекті у вас також може бути код, який здійснює очищення та управління даними, код, який ви написали для оцінки певного типу моделі, або інші утиліти, які ви написали, і вони не впишуться в предметне контур для аналізу ваших даних, тому вони повинні бути організовані в іншій частині папки вашого проекту.

Оновлення: Опублікувавши це, я зрозумів, що не звертався безпосередньо до вашого питання про "тупики". Якщо ви дійсно вирішите, що цілий набір аналізів не має ніякої цінності, тоді, якщо ви працюєте в git, ви завжди можете видалити відповідний файл (и) з повідомленням про фіксацію типу "Покинув цей рядок аналізу, оскільки його не було" продуктивний ». На відміну від того, щоб розчавити те, що ви написали, і викинути його у смітник, ви завжди можете повернутися до того, що ви зробили пізніше, якщо бажаєте.

Однак, я думаю, ви виявите, що якщо виходити з контуру, до якого ви задумалися, у вас буде менше так званих тупиків. Натомість, якщо ви витрачаєте час на дослідження вартісного та актуального питання - навіть якщо це призводить до нульової знахідки чи не виходить так, як ви передбачали, ви, ймовірно, все ще хочете вести облік того, що ви зробили, та про результати (на як мінімум, щоб ви не помилилися повторити це згодом). Просто перемістіть їх у нижній частині контуру, у вигляді "Додаток".

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

Що стосується організації, то ви вже використовуєте git, тож далі ви повинні почати використовувати makefile для виконання аналізу. Makefile визначає, як різні файли залежать один від одного (тобто, яка статистика виходить з якого коду) і коли ви телефонуєте make, все, що потрібно оновити, буде.

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

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

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

Що стосується насправді вивчення даних, я вважаю ці книги корисними та цікавими, і вони мають справу з великими наборами даних (принаймні частинами):

• «Графіка великих наборів даних» під редакцією Unwin, Theus та Hofmann. через Springerlink, якщо у вас є доступ, в іншому випадку окремі глави, ймовірно, доступні в Google.

• Довідник із візуалізації даних під редакцією 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: чому б не використовувати контроль версій для організації свого дослідження? Створіть нову гілку для кожної нової «гілки» вашої розвідки, а також роздрібніть гілки для різних версій ділянок. Цей метод зробить трохи складніше поєднання ваших кінцевих результатів, але ви завжди зможете вести каталог без треку, куди можна потрапити в "дорогоцінні камені" вашого аналізу. Ви, мабуть, хочете якось позначити свої файли в цьому каталозі, щоб вказати, з якого вилка / фіксатора вони взялися. Цей метод має додаткову перевагу, завдяки чому можна легко порівняти різні аналізи за допомогою diffкоманди.

Я роздивився б інструменти Business Intelligence ... там, де виникають подібні проблеми. Зокрема (сховища даних, розмірний аналіз), ієрархії та скорочення.

Основна ідея полягає в тому, що ви намагаєтеся представляти основні дані як сукупні величини (рахунки, прибуток тощо, а не як відсотки). Тоді ви проектуєте ієрархії для об'єднання деталей (наприклад, місяців / тижнів / ...). Це дозволяє вам мати простий огляд усіх своїх даних, а потім збільшувати масштаб певних областей. див., наприклад, http://cubes.databrewery.org/ (python) або перевершує потужність шарніру