Інструменти та протокол для відтворення даних з використанням Python

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

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

Тема відтворюваних досліджень (RR) сьогодні дуже популярна і, отже, величезна , але я сподіваюся, що моя відповідь буде достатньо вичерпною як відповідь і дасть достатньо інформації для подальших досліджень , якщо ви вирішите це зробити.

Незважаючи на те, що спеціальні інструменти Python для RR, безумовно, існують там, я думаю, що має сенс зосередитись на більш універсальних інструментах (ви ніколи не знаєте напевно, з якими мовами програмування та обчислювальним середовищем ви будете працювати в майбутньому). Сказавши це, давайте подивимося, які інструменти доступні у вашому списку.

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

2) Інструменти для управління робочими процесами та експериментами . Ось перелік найпопулярніших інструментів цієї категорії, наскільки мені відомо (у порядку зменшення популярності):

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

• Проект Kepler ( 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 для додавання інформації про мету, результат та інші параметри.

Я написав невелике розширення для мобільних комірок для ноутбуків 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 (не забувайте про магію % logon та% logstart ). Порада: щоб переконатися, що ваш ноутбук відтворюється, перезапустіть ядро ​​і спробуйте запустити всі комірки зверху вниз (кнопка Виконати всі клітини): якщо вона працює, то збережіть все в архівному файлі ("заморожування"), інше, особливо якщо вам потрібно запускати клітинки нелінійним та не послідовним та неочевидним способом, щоб уникнути помилок, вам потрібно трохи переробити.

Ще одним чудовим інструментом, який зовсім недавно (2015 р.) Є реципієнт , який дуже схожий на сумару (див. Нижче), але зроблений спеціально для Python. Я не знаю, чи працює він із ноутбуками Юпітера, але я знаю, що автор їх часто використовує, тому я здогадуюсь, що якщо він наразі не підтримується, це буде в майбутньому.

Git також приголомшливий, і він не прив'язаний до Python. Це допоможе вам не тільки зберегти історію всіх ваших експериментів, коду, наборів даних, фігур тощо, але й надасть вам інструменти для підтримки ( git pickaxe ), співпраці ( вини ) та налагодження ( git - бісект ) за допомогою наукової роботи метод налагодження (називається дельта налагодження ). Ось історія вигаданого дослідника, який намагається зробити власну систему реєстрації експериментів, доки вона не стане факсимілею Git.

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

Ось як працює Суматра: для кожного експерименту, який ви проводите через Суматру, це програмне забезпечення буде діяти як "збереження ігрового стану", яке часто зустрічається у відеоіграх. Точніше, це заощадить:

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

Потім буде створена база даних із позначкою часу та іншими метаданими для кожного з ваших експериментів, яку ви згодом можете сканувати за допомогою webGUI. Оскільки Sumatra зберегла повний стан вашої заявки для конкретного експерименту в один конкретний момент часу, ви можете відновити код, який дав конкретний результат у будь-який момент, коли вам захочеться, таким чином, у вас є повторювані дослідження з низькою вартістю (за винятком зберігання, якщо ви працюєте над величезними наборами даних, але ви можете налаштувати винятки, якщо не хочете щоразу зберігати все).

Іншим дивовижним інструментом є Zeitgeist GNOME (раніше кодований в Python, але тепер перенесений на Vala), всеохоплююча система журналу дій, яка записує все, що ви робите, і вона може використовувати машинне навчання для підбиття підсумків за певний проміжок часу, на який ви хочете відносини між предметами. щодо подібності та форм використання, наприклад, відповідаючи на запитання на кшталт "Що для мене було найбільш актуальним, коли я працював над проектом X протягом місяця минулого року?" . Цікаво, що Zim Desktop Wiki , додаток для запису приміток, подібний до Evernote, має плагін для роботи з Zeitgeist.

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

/ EDIT: dsign торкнувся тут дуже важливого моменту: копіюваність вашої установки настільки ж важлива, як і копічність вашої програми. Іншими словами, ви повинні принаймні надати повний список використаних вами бібліотек та компіляторів, а також їх точні версії та деталі вашої платформи .

Особисто я в наукових обчисленнях з Python виявив, що упаковка додатка разом із бібліотеками є занадто болючою, тому я зараз просто використовую всебічний науковий пакет python, такий як Anaconda (з чудовим конда- менеджером пакунків ), і просто порадити користувачам використовувати той самий пакет. Іншим рішенням може бути створення сценарію для автоматичного генерування virtualenv або пакування всього, використовуючи комерційну програму Docker, як це цитується dsign або відкритим вихідним кодом Vagrant (з прикладом pylearn2-in-a-box, який використовує Vagrant для створення легко перерозподіляється пакет віртуального середовища).

Нарешті, щоб дійсно забезпечити, що у вас є повністю робоче середовище кожного разу, коли вам потрібно, ви можете зробити віртуальну машину (див. VirtualBox), і навіть можете зберегти стан машини (знімок), коли ваш експеримент буде готовий запуститися всередину. Тоді ви можете просто поділитися цією віртуальною машиною з усім включеним, щоб кожен міг повторити ваш експеримент із точним налаштуванням. Це, мабуть, найкращий спосіб копіювання експерименту на основі програмного забезпечення. Контейнери можуть бути більш легкою альтернативою, але вони не включають все середовище, так що вірність тиражування буде менш надійною.

/ EDIT2: Ось чудове відео, що підсумовує (для налагодження, але це також можна застосувати до досліджень), що є основним для відтворюваного дослідження: реєстрація ваших експериментів та інших кроків наукового методу, свого роду "явний експеримент" .

Не забудьте перевірити докер ! І взагалі всі інші хороші речі, які інженерія програмного забезпечення створювала протягом десятиліть для забезпечення ізоляції та відтворюваності.

Я хотів би підкреслити, що недостатньо мати лише відтворювані робочі процеси, а й легко відтворювати робочі процеси. Дозвольте мені показати, що я маю на увазі. Припустимо, що ваш проект використовує Python, базу даних X та Scipy. Напевно, ви будете використовувати певну бібліотеку для підключення до вашої бази даних з Python, а Scipy, в свою чергу, буде використовувати деякі розріджені алгебраїчні процедури. Це, звичайно, дуже проста установка, але не зовсім проста в налаштуванні, призначена каламбуром. Якщо хтось хоче виконати ваші сценарії, їй доведеться встановити всі залежності. Або ще гірше, у неї можуть бути вже встановлені несумісні версії. Виправлення цих речей вимагає часу. Також вам знадобиться час, якщо вам в якийсь момент потрібно перенести свої обчислення в кластер, в інший кластер або на якісь хмарні сервери.

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

• Почніть з базового бінарного середовища, наприклад Ubuntu
• Встановіть libsparse-dev
• (Pip) Встановіть numpy та scipy
• Встановити X
• Встановіть libX-dev
• (Pip) Встановіть python-X
• Встановіть IPython-Notebook
• Скопіюйте мої сценарії / ноутбуки python в моє бінарне середовище, ці файли даних і ці конфігурації, щоб робити інші речі. Щоб забезпечити відтворюваність, скопіюйте їх із названого URL замість локального файлу.
• Можливо, запустіть IPython-Notebook.

Деякі з рядків будуть встановлювати речі в Python за допомогою pip, оскільки pip може зробити дуже чисту роботу при виборі конкретних версій пакету. Перевірте це теж!

І це все. Якщо після створення Dockerfile він може бути побудований, то його можна побудувати будь-де, будь-ким (за умови, що вони також мають доступ до файлів, що стосуються вашого проекту, наприклад, тому що ви розміщуєте їх у відкритому URL-адресі, на який посилається Dockerfile). Що найкраще, ви можете завантажувати отримане середовище (яке називається "зображення") на загальнодоступний або приватний сервер (який називається "зареєструватися") для використання іншими людьми. Отже, коли ви публікуєте робочий процес, у вас є як повністю відтворюваний рецепт у формі докерфайлу, так і простий спосіб для вас або інших людей відтворити те, що ви робите:

docker run dockerregistery.thewheezylab.org/nowyouwillbelieveme

Або якщо вони хочуть розібратися у ваших сценаріях тощо:

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

На жаль, мені не вистачає репутаційних балів, щоб відповісти на повідомлення Планка, тому мушу відповісти цілою темою - вибачте про це.

Я фактично розробник згаданої вище Рамки колективного знання з відкритим кодом. Він намагається спростити обмін артефактами та експериментальними робочими процесами як багаторазовими та відтворюваними компонентами Python з уніфікованим API JSON та мета JSON, що ділиться через GitHub. Вони також можуть бути підключені до прогностичної аналітики з тим же уніфікованим API JSON.

Ми тільки що випустили нову версію 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 за допомогою API JSON або командного рядка
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) Нарешті, напишіть деяку документацію, щоб новий експериментатор / розробник зміг переглянути ваш код, повторити його з оточенням і побачити, де ви зберегли свої конфігурації та показники продуктивності.