Кращі практики створення "Охайних даних"

У минулому році Хедлі Вікхем написала зоряну статтю під назвою "Охайні дані" ( посилання ) про маніпулювання даними та введення даних у "оптимальне" стан для проведення аналізу. Однак мені було цікаво, які найкращі практики щодо представлення табличних даних у робочих умовах? Скажімо, ваш колега просить вас надати йому деякі дані. Які основні правила ви використовуєте при структуруванні цих даних? Чи вказівки в "Tidy Data" настільки ж застосовні у випадках, коли ви обмінюєтесь даними з професіоналами, які не надають дані? Очевидно, це дуже контекстно, але я запитую про "найкращі практики" високого рівня.

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

Деякі моменти (з мого досвіду):

1. Деяким людям подобаються барвисті електронні таблиці та широко використовують параметри форматування. Це все добре, якщо це допоможе їм упорядкувати свої дані та підготувати таблиці для презентації. Однак це небезпечно, якщо колір клітини насправді кодує дані. Втратити ці дані легко і дуже важко отримати такі дані, імпортовані в статистичне програмне забезпечення (наприклад, дивіться це запитання щодо переповнення стека).
2. Іноді я отримую якісь добре відформатовані дані (після того, як я розповів людям, як їх підготувати), але, незважаючи на те, що вони просять використовувати виділений стовпець або окремий файл для коментарів, вони вирішують помістити коментар у стовпчик значення. Мало того, що мені потрібно особливо імпортувати цей стовпець під час імпорту даних, але головна проблема полягає в тому, що мені потрібно прокрутити всю таблицю, щоб побачити такі коментарі (що зазвичай не робив би). Це стає ще гірше, якщо вони використовують засоби коментування Excel.
3. Електронні таблиці з декількома таблицями в них, декількома заголовками рядків або підключеними клітинками призводять до ручної роботи з підготовки їх до імпорту в статистичне програмне забезпечення. Хороші аналітики даних зазвичай не насолоджуються подібною ручною роботою.
4. Ніколи, ніколи не ховайте стовпці в Excel. Якщо вони не потрібні, видаліть їх. Якщо вони потрібні, покажіть їх.
5. xls та його нащадки не є підходящими форматами файлів для обміну даними з іншими особами або їх архівації. Формули оновлюються, коли файл відкривається, і різні версії Excel можуть обробляти файли по-різному. Я замість цього рекомендую простий файл CSV, оскільки майже все програмне забезпечення, що стосується даних, може імпортувати це (навіть Excel), і можна очікувати, що це не зміниться незабаром. Однак майте на увазі, що Excel округляє до видимих ​​цифр при збереженні в CSV (тим самим відкидаючи точність).
6. Якщо ви хочете полегшити життя іншим, дотримуйтесь принципів, наведених у статті Хедлі. Складіть стовпчик значень для кожної колони змінної та факторів, що визначають шари.

Напевно, є кілька додаткових моментів, які мені не спадали на думку.

По-перше, я зазвичай той, хто отримує дані. Отже, це може читатися як мій список побажань.

• Тому найголовнішим моїм моментом є: поговорити з тим, хто збирається аналізувати дані.

• Я швидко проглянув документ: багато того, що пише Хедлі, можна було б узагальнити «нормалізацією вашої реляційної бази даних».

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

  $I$$λ$$λ_i$$λ_i$$λ_i$

• Однак є деякі практичні переваги щодо ненормованого відображення / розповсюдження даних:

  • Це може бути набагато простіше , щоб перевірити , що дані в комплекті .

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

  • Нормалізація бази даних видаляє надлишки. У реальному житті лабораторії скорочення використовуються для подвійної перевірки цілісності.
    Таким чином, зайву інформацію не слід видаляти занадто рано.

  • Здається, розмір пам’яті / диска на сьогодні є меншою проблемою. Але також збільшується кількість даних, які виробляють наші інструменти.

    Я працюю з інструментом, який може легко створити 250 ГБ високоякісних даних протягом декількох годин. Ці 250 ГБ у форматі масиву. Розширення цієї форми на довгу форму може підірвати її в коефіцієнт щонайменше 4: кожен з розмірів масиву (бічні х і у, довжина хвилі λ) стане стовпцем, плюс один стовпчик для інтенсивності). Крім того, моїм першим кроком під час аналізу даних зазвичай було б повернення нормалізованих даних довгої форми в загальну спектральну форму.

  • Зазвичай для аналізу даних знадобиться певна форма. Ось чому я раджу поговорити з тим, хто буде аналізувати дані.

• Прибирання роботи, яку вирішують ці пункти нормалізації, є втомливою і не приємною роботою. Однак на практиці я зазвичай витрачаю набагато більше часу на інші аспекти прибирання

  • Забезпечення цілісності та повноти даних на практиці є великою частиною моєї роботи з прибирання даних.

  • Дані не мають легко читабельного формату / перемикання між дещо різними форматами:

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

    Друкарські помилки або незначні зміни в шаблоні назв файлів викликають тут багато проблем.

  • Прибирання з точки зору вимірювання: позбавлення від помилкових вимірювань (як правило, викликаних відомими фізичними процесами, як, наприклад, хтось випадково вмикає світло, космічні промені, що потрапляють на детектор, зрушення камери камери, ...).