В прошлом году Хэдли Уикхем написала в JSS звездную статью под названием «Tidy Data» ( ссылка ) о манипулировании данными и приведении данных в «оптимальное» состояние для выполнения анализа. Однако мне было интересно, каковы наилучшие методы представления табличных данных в рабочих условиях? Допустим, ваш коллега просит вас предоставить ему некоторые данные. Какие общие правила вы используете при структурировании этих данных? Являются ли руководящие указания в "Tidy Data" такими же применимыми в тех случаях, когда вы делитесь данными со специалистами, не занимающимися данными? Очевидно, что это очень зависит от контекста, но я спрашиваю о «лучших методах» высокого уровня.
12
Ответы:
Как и следовало ожидать от Хэдли, его статья содержит хорошее определение аккуратных данных, и я согласен почти со всем в его статье и считаю, что это применимо не только к «профессионалам в области данных». Однако некоторые из его замечаний относительно легко исправить (например, с помощью пакетов, которые он создал), если избежать некоторых более фундаментальных проблем. Большинство из этих проблем являются результатом широкого использования Excel. Excel является ценным инструментом и имеет свои достоинства, но некоторые его возможности создают проблемы для аналитиков данных.
Некоторые моменты (из моего опыта):
Вероятно, есть несколько дополнительных моментов, которые не приходили мне в голову.
источник
Во-первых, я обычно тот, кто получает данные. Так что это может читаться как мой список пожеланий.
Поэтому мой самый важный момент: поговорите с тем, кто собирается анализировать данные.
Я быстро взглянул на статью: многое из того, что пишет Хэдли, можно суммировать с помощью «нормализации вашей реляционной базы данных».
Но он также упоминает, что в зависимости от того, что на самом деле происходит, может иметь смысл иметь одну и ту же переменную либо в длинной, либо в широкой форме.
Однако у ненормализованного отображения / распределения данных есть некоторые практические преимущества:
Может быть намного легче проверить, что данные полны .
Связанные таблицы, как в нормализованной реляционной базе данных, исправны, если данные фактически находятся в базе данных (в смысле программного обеспечения). Там вы можете поставить ограничения, обеспечивающие полноту. Если данные обмениваются в виде нескольких таблиц, на практике ссылки будут беспорядочными.
Нормализация базы данных устраняет избыточность. В реальной жизни лаборатории избыточность используется для двойной проверки целостности.
Таким образом, избыточная информация не должна удаляться слишком рано.
Размер памяти / диска в настоящее время кажется меньшей проблемой. Но также увеличивается количество данных, которые производят наши инструменты.
Я работаю с инструментом, который может легко создать 250 ГБ данных высокого качества в течение нескольких часов. Эти 250 ГБ в формате массива. Расширение этого до длинной формы увеличило бы его как минимум в 4 раза: каждый из размеров массива (боковые x и y и длина волны λ) станет столбцом плюс один столбец для интенсивности). Кроме того, моим первым шагом во время анализа данных, как правило, было бы приведение нормализованных длинных данных обратно в широкоспектральную форму.
Работы по наведению порядка, к которым обращаются эти точки нормализации, являются утомительными и не очень хорошими. Однако на практике я обычно трачу гораздо больше времени на другие аспекты уборки
Обеспечение целостности и полноты данных на практике является большой частью моей работы с данными.
Данные не находятся в легко читаемом формате / переключение между немного различными форматами:
Я получаю много данных в виде множества файлов, и обычно некоторая информация хранится в имени файла и / или пути к нему: программное обеспечение прибора и / или созданные форматы файлов не позволяют последовательно добавлять информацию, поэтому мы либо иметь дополнительную таблицу (как в реляционной базе данных), которая связывает метаинформацию с именем файла, либо имя файла кодирует важную информацию.
Опечатки или небольшие изменения в шаблоне имен файлов вызывают много проблем.
источник