Инструменты и протокол для воспроизводимых данных науки с использованием Python

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

1. Инструменты для контроля версий данных.
2. Инструменты, позволяющие воспроизводить этапы и эксперименты.
3. Протокол и предлагаемая структура каталогов для такого проекта.
4. Автоматизированные инструменты сборки / запуска.

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

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

1) Инструменты для контроля версий данных . Я полагаю, что если вы не планируете работать с (очень) большими данными , имеет смысл использовать те же данные git, которые вы используете для контроля версий исходного кода. Инфраструктура уже есть. Даже если ваши файлы являются двоичными и большими, этот совет может быть полезен: https://stackoverflow.com/questions/540535/managing-large-binary-files-with-git .

2) Инструменты для управления рабочими процессами RR и экспериментами . Вот список наиболее популярных инструментов в этой категории, насколько мне известно (в порядке убывания популярности):

• Taverna Workflow Management System ( http://www.taverna.org.uk ) - очень солидный, хотя и слишком сложный, набор инструментов. Основным инструментом является настольное программное обеспечение на основе Java. Однако он совместим с порталом онлайн-хранилища рабочих процессов myExperiment ( http://www.myexperiment.org ), где пользователь может хранить свои рабочие процессы RR и предоставлять к ним общий доступ . Веб-портал RR, полностью совместимый с Taverna , называется Taverna Online , но он разрабатывается и поддерживается совершенно другой организацией в России (именуемой OnlineHPC : http://onlinehpc.com ).

• Проект Кеплера ( https://kepler-project.org )

• VisTrails ( http://vistrails.org )

• Мадагаскар ( http://www.reproducibility.org )

ПРИМЕР . Вот интересная статья о научных рабочих процессах с примером реального дизайна рабочих процессов и анализа данных, основанного на использовании проектов Kepler и myExperiment : http://f1000research.com/articles/3-110/v1 .

Есть много инструментов RR, которые реализуют парадигму грамотного программирования , примером которой является LaTeXсемейство программного обеспечения. Инструменты, которые помогают в создании и представлении отчетов, также являются большой категорией, где Sweaveи knitr, вероятно, являются наиболее известными. Sweaveэто инструмент, ориентированный на R, но он может быть интегрирован с проектами на основе Python, хотя и с некоторыми дополнительными усилиями ( https://stackoverflow.com/questions/2161152/sweave-for-python ). Я думаю, что это knitrможет быть лучшим вариантом, так как он современный, имеет широкую поддержку популярных инструментов (таких как RStudio) и не зависит от языка ( http://yihui.name/knitr/demo/engines ).

3) Протокол и предлагаемая структура каталогов . Если я правильно понял, что вы подразумевали, используя термин « протокол» ( рабочий процесс ), в целом я думаю, что стандартный рабочий процесс анализа данных RR состоит из следующих последовательных этапов: сбор данных => подготовка данных (очистка, преобразование, объединение, выборка) => анализ данных => представление результатов (генерация отчетов и / или презентаций). Тем не менее, каждый рабочий процесс зависит от проекта и, следовательно, некоторые конкретные задачи могут потребовать добавления дополнительных шагов.

Для примера структуры каталогов, вы можете взглянуть на документацию для пакета R ProjectTemplate( http://projecttemplate.net ), как попытку автоматизировать рабочие процессы и проекты анализа данных:

4) Автоматизированные инструменты сборки / запуска . Поскольку мой ответ сфокусирован на универсальных (не зависящих от языка) инструментах RR, наиболее популярными являются make. Прочитайте следующую статью по некоторым причинам, которые следует использовать makeв качестве предпочтительного инструмента автоматизации рабочего процесса RR: http://bost.ocks.org/mike/make . Конечно, есть и другие подобные инструменты, которые либо улучшают некоторые аспекты make, либо добавляют некоторые дополнительные функции. Например: ant(официально Apache Ant: http://ant.apache.org ), Maven(«следующее поколение ant»: http://maven.apache.org ), rake( https://github.com/ruby/rake ) , Makepp( http://makepp.sourceforge.net). Полный список таких инструментов см. В Википедии: http://en.wikipedia.org/wiki/List_of_build_automation_software .

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

1) Поместите все под контроль версий, например, Git:

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

2) Я делаю большинство моих анализов вместе с документацией на ноутбуки IPython. Для меня очень организовано (для меня) иметь код, графики и обсуждение / заключение в одном документе. Если я запускаю большие сценарии, я обычно помещаю их в отдельные файлы .py сценариев, но я все равно выполняю их из записной книжки IPython через% run magic, чтобы добавить информацию о цели, результате и других параметрах.

Я написал небольшое расширение cell-magic для ноутбуков IPython и IPython под названием «водяной знак», которое я использую для удобного создания временных отметок и отслеживания различных версий пакетов, которые я использовал, а также хешей Git.

Например

%watermark

29/06/2014 01:19:10

CPython 3.4.1
IPython 2.1.0

compiler   : GCC 4.2.1 (Apple Inc. build 5577)
system     : Darwin
release    : 13.2.0
machine    : x86_64
processor  : i386
CPU cores  : 2
interpreter: 64bit

%watermark -d -t

29/06/2014 01:19:11 

%watermark -v -m -p numpy,scipy

CPython 3.4.1
IPython 2.1.0

numpy 1.8.1
scipy 0.14.0

compiler   : GCC 4.2.1 (Apple Inc. build 5577)
system     : Darwin
release    : 13.2.0
machine    : x86_64
processor  : i386
CPU cores  : 2
interpreter: 64bit

Для получения дополнительной информации см. Документацию здесь .

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

experiment/input ; expected ; observation/output ; current hypothesis and if supported or rejected
exp1 ; expected1 ; obs1 ; some fancy hypothesis, supported

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

Отличным инструментом воспроизводимости для Python с низкой кривой обучения, конечно же, является IPython / Jupyter Notebook (не забудьте про магию % logon и% logstart ). Совет: чтобы убедиться, что ваш ноутбук воспроизводим, перезапустите ядро ​​и попробуйте запустить все ячейки сверху вниз (кнопка Run All Cells): если это работает, сохраните все в архивном файле («зависание»), в противном случае, особенно если вам нужно запускать ячейки нелинейным, непоследовательным и неочевидным образом, чтобы избежать ошибок, вам нужно немного переделать.

Еще один замечательный инструмент, появившийся совсем недавно (2015), - это recy , который очень похож на суматру (см. Ниже), но создан специально для Python. Я не знаю, работает ли он с ноутбуками Jupyter, но я знаю, что автор часто использует их, поэтому я предполагаю, что, если он не поддерживается в настоящее время, он будет в будущем.

Git также великолепен и не привязан к Python. Это поможет вам не только вести историю всех ваших экспериментов, кода, наборов данных, рисунков и т. Д., Но также предоставит вам инструменты для поддержки ( git pickaxe ), совместной работы ( обвинение ) и отладки ( git - bisect ) с использованием научного метод отладки (называется дельта-отладка ). Вот история вымышленного исследователя, пытающегося создать свою собственную систему регистрации экспериментов, пока она не станет факсимильной версией Git.

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

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

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

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

Еще одним замечательным инструментом является GNIT Zeitgeist (ранее написанный на Python, но теперь перенесенный на Vala), система регистрации действий, которая полностью записывает все, что вы делаете, и может использовать машинное обучение для подведения итогов за период времени, когда вы хотите, чтобы отношения между элементами основывались о сходстве и моделях использования, например, отвечая на вопросы типа «Что было наиболее актуально для меня, когда я работал над проектом X, в течение месяца в прошлом году?» , Интересно, что Zim Desktop Wiki , приложение для создания заметок, похожее на Evernote, имеет плагин для работы с Zeitgeist.

В конце концов, вы можете использовать либо Git, либо Sumatra, либо любое другое программное обеспечение, которое вам нужно, они предоставят вам примерно ту же мощность репликации, но Sumatra специально предназначена для научных исследований, поэтому предоставляет несколько необычных инструментов, таких как веб-интерфейс для сканирования. ваши результаты, в то время как Git более приспособлен для сопровождения кода (но у него есть инструменты отладки, такие как git-bisect, так что если ваши эксперименты включают в себя коды, это может быть и лучше). Или, конечно, вы можете использовать оба!

/ РЕДАКТИРОВАТЬ: dsign коснулся очень важного момента: тиражируемость вашей установки так же важна, как и тиражируемость вашего приложения. Другими словами, вы должны по крайней мере предоставить полный список используемых вами библиотек и компиляторов , а также их точные версии и сведения о вашей платформе .

Лично в научных вычислениях на Python я обнаружил, что упаковка приложения вместе с библиотеками слишком болезненна, поэтому сейчас я просто использую универсальный научный пакет Python, такой как Anaconda (с великолепным менеджером пакетов conda ), и просто посоветуйте пользователям использовать один и тот же пакет. Другое решение может состоять в том, чтобы предоставить скрипт для автоматической генерации virtualenv или упаковать все, используя коммерческое приложение Docker, упомянутое dsign или Vagrant с открытым исходным кодом (например, с pylearn2-in-a-box, который использует Vagrant для создания легко распространяемого пакета). пакет виртуальной среды).

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

/ РЕДАКТИРОВАТЬ 2: Вот отличное видео, суммирующее (для отладки, но это также может быть применено к исследованиям), что является фундаментальным для воспроизводимых исследований: регистрация ваших экспериментов и каждого другого шага научного метода, своего рода «явное экспериментирование» .

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

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

Здесь я нахожу докер полезным. Docker - это способ формализовать и скомпилировать рецепты для двоичных сред. Вы можете написать следующее в Dockerfile (здесь я использую простой английский вместо синтаксиса Dockerfile):

• Начните с базовой двоичной среды, такой как Ubuntu
• Установить libsparse-dev
• (Пип) Установить NumPy и Scipy
• Установить X
• Установите libX-dev
• (Pip) Установить Python-X
• Установить IPython-Notebook
• Скопируйте мои скрипты / записные книжки на python в мою двоичную среду, эти файлы данных и эти конфигурации для выполнения других разных задач. Чтобы обеспечить воспроизводимость, скопируйте их с именованного URL-адреса вместо локального файла.
• Может быть, запустить IPython-Notebook.

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

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

docker run dockerregistery.thewheezylab.org/nowyouwillbelieveme

Или, если они хотят покопаться в ваших сценариях и так далее:

docker run -i -t dockerregistery.thewheezylab.org/nowyouwillbelieveme /bin/bash

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

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

Мы только что выпустили новую версию V1.8.1 и предоставили обширную документацию, поэтому, надеюсь, вам будет легче понять концепции сейчас: http://github.com/ctuning/ck/wiki

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

Мы также отслеживаем различные ресурсы, связанные с воспроизводимой наукой, здесь: https://github.com/ctuning/ck/wiki/Enabling-open-science

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

Существует целый курс, посвященный воспроизводимым исследованиям. https://www.coursera.org/learn/reproducible-research Этот курс основан на R, но основную идею можно выучить.

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

Недавно я наткнулся на следующий инструмент - http://github.com/ctuning/ck . Он уже написан на Python и, кажется, включает в себя то, что вам нужно (мой коллега использует его в пилотном проекте для автоматизации распознавания изображений).

Плюсы:

1. очень маленький, портативный и настраиваемый
2. включает в себя веб-сервер для распространения экспериментов и их обработки с использованием прогнозной аналитики
3. есть отличный пример использования краудсорсинга и воспроизведения оптимизации компилятора - http://cknowledge.org/repo

Минусы:

1. немного низкий уровень - вам нужно реализовать свой собственный рабочий процесс из компонентов Python, совместно используемых через GitHub, используя JSON API или командную строку
2. документация несколько сложна - я очень надеюсь, что они найдут время, чтобы обновить ее в ближайшее время.

Я создал и недавно выпустил инструмент с открытым исходным кодом http://dvc.org или DVC, который делает именно то, что вы пытаетесь достичь:

1. [Инструменты для контроля версий данных.] DVC работает поверх Git, добавляет контроль версий файлов данных (файлы хранятся вне Git) и отслеживает зависимости между кодом и файлами данных. DVC автоматически получает график зависимости (DAG) для кода и данных.
2. [Инструменты, позволяющие воспроизводить этапы и эксперименты.] dvc repro data/scores.csvВоспроизводит все необходимые этапы, касающиеся DAG.
3. [Протокол и предлагаемая структура каталогов для такого проекта.] DVC требовал каталог данных ( dataпо умолчанию), где вы должны хранить все файлы данных. Тем не менее, DVC прозрачно перемещает фактический контент в .cacheкаталог и создает символические ссылки (да, я также сделал это для работы в Windows). .cacheКаталог не синхронизируются с Git , но он может быть синхронизирован через облако (S3 или GCP) по команде dvc sync data/scores.csv(он синхронизируется соответствует файл данных из кэша , как .cache/scores.csv_29de545)
4. [Автоматизированные инструменты сборки / запуска.] См. Выше.

Учебное пособие по DVC - хорошая отправная точка - «Контроль версий данных: итеративное машинное обучение» .

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я работаю в компании, Datmo , которая создает инструмент с открытым исходным кодом для этого.

Лучшая практика для воспроизводимости заключается в следующем:

1) Сначала поместите вашу среду в среду Docker, создав Dockerfile и убедившись, что все зависимости включены в этот файл. Я считаю этот ресурс лучшим ( https://arxiv.org/pdf/1410.0846.pdf )

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

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