Хороші відповіді вже з’явилися. Тому я просто поділюся деякими думками, заснованими на особистому досвіді: адаптуйте відповідні до вашої власної ситуації за потребою.
Для фону та контексту- тож ви можете пояснити будь-які особисті упередження, які могли б повзати в цьому повідомленні - значна частина моєї роботи була спрямована на те, щоб допомогти людям приймати важливі рішення на основі порівняно невеликих наборів даних. Вони невеликі, тому що дані можуть бути дорогими для збирання (наприклад, 10 000 доларів за перший зразок свердловини з підземних вод, або кілька тисяч доларів за аналіз незвичайних хімічних речовин). Я звик отримувати якнайбільше будь-яких наявних даних, досліджувати їх до смерті, а також придумувати нові методи аналізу їх, якщо це необхідно. Однак в останні кілька років я займався роботою над деякими досить великими базами даних, такими як соціально-економічні та інженерні дані, що охоплюють всю США на рівні блоку перепису (8,5 млн записів,
З дуже великими наборами даних весь підхід і зміна мислення . Зараз є занадто багато даних для аналізу. Деякі з безпосередніх (і, ретроспективно) очевидних наслідків (з акцентом на регресійне моделювання) включають
Будь-який аналіз, який ви думаєте про здійснення, може зайняти багато часу та обчислень. Вам потрібно буде розробити методи піддиагностики та роботи над частковими наборами даних, щоб ви могли спланувати свій робочий процес під час обчислення з усім набором даних. (Підгруппа може бути складною, тому що вам потрібний представницький підмножина даних, яка є такою ж багатою, як і весь набір даних. І не забувайте про перехресну перевірку ваших моделей із затриманими даними.)
Через це ви будете витрачати більше часу на документування того, що ви робите, та все сценарії (щоб це можна було повторити).
Як @dsimcha щойно зазначив, корисні навички програмування корисні. Насправді, вам не потрібно багато на шляху досвіду роботи з програмуючими середовищами, але вам потрібна готовність до програми, здатність розпізнавати, коли програмування допоможе (практично на кожному кроці, справді) та добре розуміння основних елементів інформатики, таких як проектування відповідних структур даних та аналіз складності алгоритмів обчислювальної техніки. Це корисно для того, щоб заздалегідь дізнатися, чи буде код, який ви плануєте написати, масштабувати до повного набору даних.
Деякі набори даних є великими, оскільки вони мають багато змінних (тисячі чи десятки тисяч, всі вони різні). Розраховуйте витратити багато часу на узагальнення та розуміння даних . Кодова книга або словник даних , а також інші форми метаданих , стають істотними.
Значна частина вашого часу витрачається просто на переміщення даних і переформатування. Вам потрібні вміння обробляти великі бази даних та вміння підсумовувати та графікувати великі обсяги даних. (Тут Мале множина Туфте виходить на перший план.)
Деякі з ваших улюблених програмних засобів не вдасться. Забудьте, наприклад, таблиці. Багато програмного забезпечення з відкритим кодом та академічним програмним забезпеченням просто не вирішуватимуть обробку великих наборів даних: обробка триватиме назавжди або програмне забезпечення вийде з ладу. Очікуйте цього і переконайтеся, що у вас є кілька способів виконання ключових завдань.
Практично будь-який статистичний тест, який ви проводите, буде настільки потужним, що майже впевнено визначити «значний» ефект. Вам потрібно набагато більше орієнтуватися на статистичну важливість , наприклад, на розмір ефекту, а не на значущість.
Аналогічно, вибір моделі є клопітким, оскільки майже будь-яка змінна та будь-яка взаємодія, про яку ви могли б розглянути, виглядатиме суттєвою. Вам потрібно більше зосередитися на значущості змінних, які ви вирішите проаналізувати.
Буде більш ніж достатньо інформації для виявлення відповідних нелінійних перетворень змінних. Знайте, як це зробити.
У вас буде достатньо даних для виявлення нелінійних зв’язків, зміни тенденцій, нестаціонарності, гетеросцедастичності тощо.
Ви ніколи не закінчите . Є так багато даних, що ви могли б вивчити їх назавжди. Тому важливо спочатку встановити свої аналітичні цілі та постійно пам’ятати про них.
Я закінчу короткий анекдот, який ілюструє одну несподівану різницю між регресійним моделюванням з великим набором даних у порівнянні з меншим. Наприкінці проекту з даними перепису було розроблено я регресійну модель, необхідну для впровадження в обчислювальній системі клієнта, що означало запис SQL-коду у реляційну базу даних. Це звичайний крок, але код, згенерований програмістами бази даних, включав тисячі рядків SQL. Це зробило майже неможливим гарантувати, що він не містить помилок - хоча ми могли виявити помилки (це дало різні результати за тестовими даними), виявлення їх було іншою справою. (Все, що вам потрібно, - одна типографічна помилка в коефіцієнті ...) Частиною рішення було написати програму, яка генерувала команди SQL безпосередньо з оцінок моделі. Це запевнило, що те, що вийшло з пакету статистики, саме те, що потрапило в RDBMS. Як бонус, кілька годин, витрачених на написання цього сценарію, замінили, можливо, кілька тижнів кодування та тестування SQL. Це невелика частина того, що означає для статистиків можливість повідомляти свої результати.