...

пятница, 6 ноября 2015 г.

[Перевод] Профессия Data Scientist: общие сведения и основные сложности, с которыми сталкиваются «ученые по данным»

Примечание переводчика:В нашем блоге мы рассказываем об облачных сервисах, хостинге и соответствующих технологиях. Почерпнуть что-то интересное можно не только, анализируя инфраструктурные проекты компаний, но и изучая работу современных ИТ-специалистов. Сегодня мы представляем вашему вниманию адаптированный перевод статьи доцента компьютерных наук университета Рочестера Филиппа Гуо (Philipp Guo) о том, кто такие «ученые по данным», как они работают и с какими сложностями сталкиваются.

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

В 2012 году, вскоре после окончания написания моей диссертации, понятие «Наука о данных» [англ. data science] стало постепенно распространяться. Некоторые специалисты в этой области называют профессию «ученого по данным» [англ. data scientists] «одной из наиболее привлекательных в 21 веке». Помимо прочего, руководство университетов вкладывает немалые средства в создание институтов обработки данных [англ. data science institutes].

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

Чем же занимаются ученые по данным, и с какими трудностями им приходится сталкиваться?
В этой статье рассмотрены основные этапы исследования в науке о данных, взятые из Главы 2 моей диссертации на соискание степени Ph.D. под названием «Программные средства для удобства проведения программных исследований».

Основные этапы исследования в науке о данных


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

Стадия подготовки


Прежде чем проводить анализ, программист (ученый по данным) должен сперва собрать данные и привести их такому виду, чтобы на их основе можно было проводить вычисления.

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

  • Файлы с данными можно скачивать из онлайн-хранилищ, таких как публичные сайты (например, данные переписи населения США).
  • Можно запрашивать потоки данных с онлайн-источников через API (например, поток финансовых данных Bloomberg).
  • Данные можно генерировать с помощью специальной аппаратуры, например, оборудования для научных исследований, подключенного к компьютерам.
  • Данные можно генерировать с помощью специального программного обеспечения, например, лог-файлы, полученные с веб-сервера, или данные, отсортированные при помощи алгоритма машинного обучения.
  • Данные можно записать вручную в таблицу или текстовый файл.

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

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

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

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

Еще одной проблемой, которая может возникнуть в процессе сбора данных, является их хранение. Иногда данных может оказаться так много, что одного жесткого диска для них будет недостаточно, и придется хранить их на удаленных серверах.

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

Реформатирование и очистка данных


Необработанные данные, вероятно, будут представлены в форме, которая неудобна для проведения конкретного типа анализа. Причина, как правило, в том, что эти данные форматировались человеком, не заинтересованным в проведении на их основе научных экспериментов.

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

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

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

Кроме того, на данном этапе возникает проблема интеграции данных. Например, опытный разработчик Кристиан Берд, у которого я брал интервью в Microsoft Research, собирает исходные данные из различных файлов формата .csv и XML, запросов к системе управления версиями и базы данных ошибок [англ. bug databases], а также находит ценную информацию в архиве электронных писем. Он объединяет все данные, полученные из этих источников, в единую реляционную базу данных MySQL, которая играет роль основного источника данных в его исследованиях.

В дополнение, предлагаю ознакомиться со следующим отрывком из введения к книге «Написание скриптов на Python для проведения вычислительных экспериментов», в котором отражена значимость рутинных операций в ходе подготовки данных:

Вычислительные эксперименты – это не только обработка больших объемов данных. Многие специалисты в этой области занимаются разработкой численных методов и знают, что большая часть этой работы состоит не только в написании сложных алгоритмов численного анализа.

Очень часто бывает, что полученный код должен решать задачи постоянного перемещения данных из одного места в другое, конвертирования из одного формата в другой, извлечения численных данных из текста и проведения численных экспериментов с использованием большого числа файлов и хранилищ. Эти задачи гораздо быстрее выполнить, если использовать Python вместо Fortran, C, C++, C# или Java.


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

Этап проведения анализа


Основным этапом исследования в науке о данных является фактическое проведение анализа, которое заключается в написании, исполнении и улучшении компьютерных программ, позволяющих анализировать и извлекать ценную информацию из данных. Такие программы я буду называть скриптами для анализа данных, так как специалисты по работе с данными зачастую предпочитают пользоваться интерпретируемыми «скриптовыми» языками вроде Python, Perl, R и MATLAB. Однако при необходимости они также используют компилируемые языки, такие как C, C++ и Fortran.

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

Чем быстрее разработчик проходит через каждую из итераций, тем больше ценных сведений он теоретически может извлечь за единицу времени. Его скорость может снизиться по трем причинам:

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

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

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

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

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

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

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


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

Этап рефлексии


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

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

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

Цифровым вариантом обычно является запись в текстовый файл или на электронные стикеры, создание мультимедиа контента в PowerPoint или ведение заметок в специальном приложении, например, Evernote или Microsoft OneNote. У каждого варианта свои преимущества: рисунки и уравнения легче писать от руки на бумаге, а код и цифровые изображения лучше копировать и вставлять в электронные документы.

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

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

К встрече подготавливают копии визуального представления данных и отчеты о ходе выполнения работ, на основе которых строится обсуждение. После встречи составляется новый список задач для каждого из участников встречи. Например, во время летней стажировки в Microsoft Research я занимался исследованием на основе работы с данными [англ. data-driven study] – его целью было изучение факторов, влияющих на исправление багов – и каждый день я встречался со своим научным руководителем Томом Циммерманом.

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

Проведение сравнений и проверка альтернативных гипотез. Наиболее близким к фактическому анализу методом рефлексии является сопоставление выходных данных и проверка альтернативных гипотез путем регулирования параметров кода и его исполнения.

Ученые по данным любят открывать по несколько файлов с графическим представлением результатов на соседних мониторах, чтобы их можно было сравнить визуально и сопоставить их характеристики. Дайана МакЛин, анализируя деятельность ученых из Гарварда, пришла к следующему выводу:

Большая часть аналитической работы основана на методе проб и ошибок: ученый проводит эксперимент, выводить результаты на график, снова проводит эксперимент, снова выводит результаты на график и т.д. Ученые очень сильно зависят от графиков. Они пытаются все представить в графическом виде. Например, некоторые выводят график одной последовательности ДНК рядом с графиком другой.


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

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

Этап оформления результатов


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

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

Однако было бы намного лучше, если бы люди могли поработать с их программой и «прочувствовать» все методы, представленные в отчетах. В действительности же достаточно сложно распространить свой код так, чтобы остальные без труда могли запустить программу на своих компьютерах.

Прежде чем ваши коллеги смогут запустить вашу программу (пускай даже на той же операционной системе), им сначала придется ее скачать, произвести установку и подобрать совместимую версию необходимого программного обеспечения, связанного с огромным числом сопутствующих библиотек – процесс вызывает бурное негодование, так как в ходе него возникает слишком много ошибок. Если хоть один из зависимых элементов не может быть исполнен, то весь исходный код нельзя будет исполнить повторно.

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

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

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

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Комментариев нет:

Отправить комментарий