Анализ данных - безусловно, одна из наиболее часто встречающихся задач как в бизнесе, так и в технологиях. Это ежедневный хлеб тысяч ученых-исследователей, банкиров, инженеров и, разумеется, специалистов по анализу данных. Интересно, что, несмотря на то, что это такое популярное занятие, похоже, нет единого мнения о том, что должно быть золотым стандартом. Это правда, что сравнивая, например, анализ опроса клиентов с, скажем, результатом эксперимента с адронным коллайдером, по крайней мере, ну… сложно. Верно также и то, что в любом случае можно сказать, хорошо или плохо прошел процесс.

В этой статье я хотел бы сосредоточиться на проведении хорошего процесса анализа данных. Подводя итог, мы ограничимся теми случаями, которые оправдывают использование программных методов, оставляя позади «excel engineering» или подготовленные информационные панели.

Я собираюсь поделиться с вами несколькими советами - вещи, которые сработали для меня на протяжении всей моей карьеры в области исследований и разработок в течение последних десяти лет. Хотя эта статья ни в коем случае не претендует на то, чтобы установить золотой стандарт. Я верю, что советы, о которых вы скоро прочитаете, сэкономят вам много времени.

Сохраняйте спокойствие и анализируйте данные

Анализ данных - это очень исследовательская работа. В отличие от разработки программного обеспечения, это большая редкость, когда кто-то может написать вам точный список дел. Чаще всего вы сталкиваетесь с определенной проблемой и списком желаний или предположений, которые необходимо проверить. На поиск правильных идей могут уйти часы или недели. Это зависит от многих факторов, таких как качество данных, сложность основной проблемы, потребность в обмене мнениями и ваши технические навыки. Это умственно истощающий процесс со множеством неопределенностей, в том числе с выбором правильных вопросов.

Поскольку анализ - это исследовательский процесс, наивно ожидать успеха без четко сформулированной гипотезы. Если это не часть описания задачи, ваша задача - сформулировать ее. Это сам процесс его формирования, который будет держать ваш ум сосредоточенным, а ваше время более продуктивным. Если предмет вашего анализа сложен, вы можете даже сформулировать целый набор гипотез. Как бы вы это ни делали, старайтесь работать систематически. Превратите гипотезы в свой план завоевания и помните, что отрицательный результат - это еще результат!

Устранение, устранение, устранение

Я упоминал, что это умственно истощающий процесс? Бьюсь об заклад, что если вы все еще можете разбираться в спортивных состязаниях по вечерам, значит, вы не работали ... То, что числа и десятичные дроби могут сделать с вашим мозгом, является абсолютной катастрофой. Следовательно, можно ввести по крайней мере некоторый уровень защиты, если вы просматриваете свои данные и устраняете любую потенциально избыточную информацию. Я знаю, что может быть сложно определить, какая информация может быть дублированной или избыточной, но вы должны попробовать. По возможности работайте с меньшим набором данных, удаляя все, что может быстро оказаться несущественным.

Обычно я делаю это, чтобы выделить несколько этапов своего анализа. Когда я нахожусь на каком-то этапе, я не включаю свой мозг в работу, которую я связываю с другими этапами. Например, когда я получаю данные, я не особо в них вникаю. Я даже не пытаюсь сформулировать наблюдения! Когда я очищаю данные, я сосредотачиваюсь исключительно на том, чтобы мой набор данных был согласован, в том числе, например, отбрасывание ненужных столбцов, работа с пропущенными значениями и т. д. Завершая наблюдения, я полагаюсь на свои более ранние работы и отказываюсь от более «инженерной стороны».

Все, я предпочитаю делать отдельные записные книжки (или сценарии) и возвращаться к более ранним этапам, если мне нужно повторно решить проблему. Этот процесс отражает как минимизацию набора данных, так и минимизацию объема работ. Как говорится, «по одному».

Воспроизводимость заменяет надежность

Инженеры-программисты делают упор на надежность. Они должны это сделать, потому что код, который они доставляют, предназначен для использования в производственной среде. После развертывания он становится цифровым продуктом или услугой. Поэтому они разработали всевозможные методы и инструменты, такие как рецензирование, модульное тестирование, интеграционное тестирование, контроль версий, линтеры, конвейеры CI и т. Д., Чтобы помочь им создавать надежное программное обеспечение.

Код анализа данных редко используется в производстве. Его определение надежности больше связано с воспроизводимостью числового результата. Чаще всего такой код является разовым «выстрелом», который никогда не будет поддерживаться. Что еще хуже, даже во время выполнения одной задачи код анализа может быстро выйти из-под контроля и съесть себя заживо. Трудно оправдать затраты времени на модульное тестирование, и экспертная оценка, кажется, имеет больше смысла при обсуждении идей, а не вопросов производительности (за исключением случаев). В этих условиях сложно обеспечить воспроизводимость.

Время от времени задача анализа данных начиналась как продолжение некоторой работы, выполненной кем-то в прошлом. Когда это происходит, есть как минимум две причины для раздражения:

  • «Что (черт возьми) он имел в виду, когда делал это или показывал то?»
  • «Как (черт возьми) мне запустить этот кусок?

Первый вопрос касается способа проведения анализа. Плохо выполненный анализ приведет к отображению полузапеченных фрагментов или мертвого кода, что является следствием неудачных попыток. Это загромождает картину десятками разноцветных бессмысленных сюжетов. Наконец, замечания и наблюдения, если таковые имеются, будут констатировать очевидное без объяснения намерения, лежащего в основе рассуждений. Даже повторяя все шаги, вполне можно прийти к другим выводам.

Второй вопрос - более «инженерный». Код есть код, и для его запуска вы должны воспроизвести среду, в которой он был создан. Код анализа имеет тенденцию довольно быстро дрейфовать. Поэтому очень важно фиксировать, замораживать и архивировать все зависимости - если вы не хотите начать незапланированный хакатон.

Не усложняй, чем нужно

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

Ниже я составил список предложений о том, что вы можете сделать, чтобы улучшить - то, о чем я хотел бы знать раньше:

  • Укажите, что такое черновик, а какой - чистый отчет. Это не то же самое, что использовать git, так как часто вам может понадобиться сохранить черновики. Помните, что суть анализа данных состоит в том, чтобы задокументировать ваши рассуждения. Поэтому постарайтесь отделить от лишней информации или хотя бы намекнуть своему коллеге, какие части не являются ключевыми результатами.
  • Сделайте ясность кода важнее производительности. Если выполнение какого-то кода занимает много времени, подумайте о переносе его в отдельный скрипт.
  • Не бойтесь использовать комментарии или уценку, особенно если идеи не передаются напрямую кодом.
  • Сделайте поток ноутбуков безусловным. Очень часто на них смотрят только для того, чтобы узнать результаты, не выполняя их. Несколько операторов «if-else» на уровне сценария быстро затемнят картину.
  • Восстановите записные книжки перед фиксацией. Git не знает о переменных в вашем пространстве имен. Следовательно, перезапуск ноутбука может помочь избежать внезапной ошибки NameError, ожидающей появления ошибки.
  • Используйте графики для передачи данных, а не для передачи эго. В мире полно пакетов, предлагающих красивые сюжеты. Более важно, чтобы вы позаботились о единицах измерения и метках на осях и легенде, а не встраивали цепляющие виджеты. Если отсортированная таблица показывает то, что вы хотите, даже не беспокойтесь о графиках.
  • Всегда приветствуется написание короткого README, в котором обсуждается содержание и то, как запускать код.
  • Нет ничего плохого в том, чтобы размещать утверждения на данных. Я охотно помещаю их в начало тетрадей и особенно перед разделами с более обширными вычислениями.
  • Используйте «seed» при работе с генераторами случайных чисел.
  • Покажите «заголовок» таблиц вашего процесса, желательно до и после. Это помогает понять обработку, не выполняя ее.

Последние мысли

Я знаю, что анализ данных подходит не всем. Это психологическая утечка… Ой, подождите… Я уже упоминал об этом. Это требует как терпения, так и интуиции, и трудно договориться о стандартизированном процессе. Однако, как я показал, вы можете предпринять некоторые действия, чтобы сделать это менее болезненным и приносящим удовлетворение.

Я уверен, что вы можете придумать еще больше способов улучшить эту деятельность. Конечно, список, который я здесь представил, можно расширять. Пожалуйста, не стесняйтесь и делитесь своими идеями в комментариях!