Лучшие практики для создания «аккуратных данных»

В прошлом году Хэдли Уикхем написала в JSS звездную статью под названием «Tidy Data» ( ссылка ) о манипулировании данными и приведении данных в «оптимальное» состояние для выполнения анализа. Однако мне было интересно, каковы наилучшие методы представления табличных данных в рабочих условиях? Допустим, ваш коллега просит вас предоставить ему некоторые данные. Какие общие правила вы используете при структурировании этих данных? Являются ли руководящие указания в "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 раза: каждый из размеров массива (боковые x и y и длина волны λ) станет столбцом плюс один столбец для интенсивности). Кроме того, моим первым шагом во время анализа данных, как правило, было бы приведение нормализованных длинных данных обратно в широкоспектральную форму.

  • Обычно для анализа данных требуется особая форма. Вот почему я советую поговорить с тем, кто будет анализировать данные.

• Работы по наведению порядка, к которым обращаются эти точки нормализации, являются утомительными и не очень хорошими. Однако на практике я обычно трачу гораздо больше времени на другие аспекты уборки

  • Обеспечение целостности и полноты данных на практике является большой частью моей работы с данными.

  • Данные не находятся в легко читаемом формате / переключение между немного различными форматами:

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

    Опечатки или небольшие изменения в шаблоне имен файлов вызывают много проблем.

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