Библиотека сайта rus-linux.net
Система VisTrails
Глава 23 из 1 тома книги "Архитектура приложений с открытым исходным кодом".
Оригинал: "VisTrails", глава из книги "The Architecture of Open Source Applications"Авторы: Juliana Freire, David Koop, Emanuele Santos, Carlos Scheidegger, Claudio Silva, and Huy T. Vo
Дата публикации: 2012 г.
Перевод: Н.Ромоданов
Дата перевода: март 2013 г.
Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.
23.4. Компоненты и возможности
23.4.3. Запрос информации о происхождении
Информация о происхождении данных, собираемая системой VisTrails, включает в себя набор, состоящий из процессов, каждый со своей собственной структурой, метаданных и журнала выполнения. Важно то, что пользователи могут получить доступ к этим данным и могут их изучить. В системе VisTrails есть как текстовый, так и визуальный (WYSIWYG) интерфейсы запросов. Для такой информации, как теги, аннотации и даты, пользователь может использовать поиск по ключевым словам с возможностью разметки. Например, найти все рабочие процессы с помощью ключевого слова plot, которые были созданы пользователем user:~dakoop. При этом запросы о конкретных подграфав рабочего процесс проще представить с помощью визуального интерфейса запросов по образцу, в котором пользователи могут либо создать запрос с нуля, либо скопировать и модифицировать часть уже существующего конвейера.
При разработке такого интерфейса запросов по образцу, мы взяли из существующего редактора рабочих процессов Workflow Editor большую часть кода без изменений, добавив лишь небольшие изменения, параметризирующие конструкцию. Что касается параметров, то чаще полезнее искать диапазоны значений и ключевые слова, а не точные значения. Поэтому, в поля значений параметров мы добавили модификаторы; когда пользователи добавляют или изменяет значение параметра, они могут выбрать один из этих модификаторов, которые по умолчанию, задают точное совпадение. Кроме того, что можно сделать визуальный запрос, результат запроса также можно получить в визуальном виде. Совпадающие версии подсвечиваются в дереве версий и любой выбранный рабочий процесс отображается с выделением соответствующей части. Пользователь может выйти из режима результатов запроса инициировав другой запрос или щелкнув по кнопке сброса.
23.4.4. Хранение данных
Система VisTrails хранит информацию о том, как были получены результаты, и с помощью каких шагов. Однако, заново воспроизвести рабочий процесс может быть трудно в случае, если данных, необходимых для рабочего процесса, больше нет. Кроме того, для длительных процессов для того, чтобы избежать повторных перевычислений, может быть полезным между сессиями сохранять промежуточные данные в кэше.
В многих системах, использующих рабочие процессы, в качестве информации о происхождении данных запоминаются пути к файлам в файловой системе, но при таком подходе возможны проблемы. Пользователь может переименовать файл, переместить рабочий процесс в другую систему и не скопировать данные или изменить содержимое данных. В любом из этих случаев, недостаточно в качестве информации о происхождении данных запомнить путь к файлу. Хеширование данных и сохранение хэш значения в информации о происхождении помогут определить, были ли изменены данные, но не помогут найти данные, если они есть. Чтобы решить эту проблему, мы создали пакет Persistence Package - пакет системы VisTrails, использующий инфраструктуру управления версиями для хранения данных, к которым можно обращаться как к информации о происхождении. В настоящее время мы для управления данными используем систему Git, хотя также просто можно пользоваться другими системами.
Мы, чтобы идентифицировать данные, используем универсальные уникальные идентификаторы (UUID) и хэш-значения, получаемые в Git при подтверждении сохранения версий. Если между двумя вычислениями данные изменились, то в репозитарий будет помещена новая версия данных. Таким образом, в любом случае данные можно найти с помощью составного идентификатора - кортежа (uuid, version). Кроме того, мы сохраняем хеш-значение и сигнатуру той части рабочего процесса, которая находится выше и с помощью которой были созданы эти данные (если они не являются входными). Это позволяет обращаться к данным, которые могут идентифицироваться по-разному, а также повторно использовать данные, когда снова запускается то же самое вычисление.
Главным, с чем мы столкнулись при разработке этого пакета было то, как пользователи смогут находить и повторно использовать свои данные. Также нам хотелось, чтобы данные хранились в одном и том же репозитарии независимо от того, используются ли они как входные, выходные и промежуточные (выходные данные одного рабочего процесса могут быть входными данными другого рабочего процесса). Есть два основных способа, с помощью которых пользователь может идентифицировать данные: создать новую ссылку на данные или использовать существующую. Обратите внимание, что после первого вычисления новая ссылка станет существующей, поскольку во время исполнения она будет сохранена; позже пользователь, если захочет, может решить создать другую ссылку, но это редкий случай. Поскольку пользователи часто хотят всегда пользоваться последней версией данных, ссылки, задаваемая без указания конкретной версии, будут, по умолчанию, указывать последнюю версию.
Вспомним, что перед выполнением модуля, мы рекурсивно обновляем все его входные данные. Модуль с хранящимися данными не будет обновлять свои входные данные в случае, если вычисления, находящиеся выше, уже отработали. Чтобы это определить, мы берем в репозитарии сигнатуру той части рабочего процесс, которая находится выше, и, если такая сигнатура существует, ищем в репозитарии ранее вычисленные данные. Кроме того, мы записываем идентификаторы и версии данных в виде информации об их происхождении, с тем, чтобы можно было повторно воспроизвести конкретное вычисление.
23.4.5. Обновления
Поскольку информация о происхождении данных является основой системы VisTrails, ключевым вопросом становится возможность обновлять старые рабочие процессы так, чтобы они могли выполняться с новыми версиями пакетов. Поскольку пакеты могут создаваться сторонними разработчиками, нам необходима как инфраструктура, позволяющая обновлять рабочие процессы, так и специальные средства с тем, чтобы разработчики пакетов могли указывать обновления путей к данным. Основным действием, выполняемым при обновлении рабочего процесса, является замена некоторого модуля его новой версией. Обратите внимание, что это действие осложняется тем, что мы должны изменить все подключения и все параметры старого модуля. Кроме того, например, при изменении интерфейса модуля, обновления могут потребовать переконфигурировать, переназначить или переименовать эти параметры или подключения такого модуля.
Каждый пакет (вместе со связанными с ним модулями) помечается номером версии, и когда эта версия изменяется, мы допускаем, что в этом пакете могут быть изменены также и модули. Обратите внимание, что некоторые из модулей или даже большая их часть могут остаться прежними, но без нашего собственного анализа кода мы это проверить не сможем. Но мы пытается автоматически обновить любой модуль, интерфейс которого не изменился. Чтобы сделать это, мы стараемся заменить модуль новой версией и выдать исключительное состояние в случае, если он не работает. Если разработчики изменяют интерфейс модуля или переименовывают модуль, мы даем им возможность указывать эти изменения явно. Чтобы сделать все это более контролируемым, мы создали метод remap_module, который позволяет разработчикам указывать только те места, где обновления, выполняемые по умолчанию, должны быть изменены. Например, разработчик, который переименовал входной порт "file" в "value", можен указать это конкретное переназначение с тем, чтобы, когда будет создан новый модуль, любое подключение к порту "file" в старом модуле было бы теперь подключением к порту "value". Ниже показан пример обновления для встроенного модуля VisTrails:
def handle_module_upgrade_request(controller, module_id, pipeline):
module_remap = {'GetItemsFromDirectory':
[(None, '1.6', 'Directory',
{'dst_port_remap':
{'dir': 'value'},
'src_port_remap':
{'itemlist': 'itemList'},
})],
}
return UpgradeWorkflowHandler.remap_module(controller, module_id, pipeline,
module_remap)
Этот фрагмент кода обновлений рабочих процессов, в которых старый модуль GetItemsFromDirectory (любой версии до 1.6) заменяется на модуль Directory. Здесь порт dir старого модуля отображается в порт value, а порт itemlist в порт itemList.
Любое обновление создает в дереве версий новую версию с тем, чтобы можно было отличать друг от друга и сравнивать исполнения рабочих процессов перед и после обновления. Вполне возможно, что обновление изменит выполнение рабочего процесса (например, если разработчик пакета исправит ошибку), и нам нужно отследить эту информацию о происхождении данных. Отметим, что в старых версиях VisTrails, для этого могло требоваться обновлять каждую версию в дереве. Чтобы избежать путаницы, мы обновляем только те версии, к которым пользователь может переходить. Кроме того, мы предоставляем механизм предпочтения, который позволяет пользователю отложить запоминание любого обновления до тех пор, пока рабочий процесс не будет модифицирован или выполнен; если пользователь просто просматривает такую версию, нет необходимости сохранять обновление.
23.4.6. Совместный доступ и публикация результатов, использующих информации о происхождении
Несмотря на то, что воспроизводимость результатов является краеугольным камнем научного метода, в текущих публикациях, описывающих вычислительные эксперименты, часто нет достаточного объема данных, позволяющих повторять или обобщать представленные результаты. В последнее время возобновляется интерес к публикациям с воспроизводимыми результатами. Основное препятствие к более широкому распространению такой практики в том, что трудно создать сборку данных, в которую бы входили все компоненты (например, данные, код, параметры настроек), необходимые при воспроизведении и проверке результата.
Благодаря сбору подробной информации о происхождении данных, а также многим возможностям, описанным выше, система VisTrails делает более простым этот процесс для вычислительных экспериментов, проводимых в рамках системы. Тем не менее, нужны средства как для ссылок на документы, так и для совместного доступа к информации о происхождении данных.
У нас есть разработаные пакеты VisTrails, которые позволяют представлять в статьях результаты вместе с информацией о происхождении данных. С помощью пакета LaTeX, который мы разработали, пользователи могут добавлять рисунки, относящиеся к рабочим процессам VisTrails. С помощью следующего кода на LaTeX будет создаваться рисунок с результатами выполнения рабочего процесса
\begin{figure}[t]
{
\vistrail[wfid=119,buildalways=false]{width=0.9\linewidth}
}
\caption{Visualizing a binary star system simulation. This is an image
that was generated by embedding a workflow directly in the text.}
\label{fig:astrophysics}
\end{figure}
Если документ собран с использованием pdflatex, то команда \vistrail вызовет скрипт Python с параметрами, полученными в ответ на сообщение XML-RPC, посланное на сервер VisTrails с тем, чтобы выполнить рабочий процесс с идентификатором id 119. Этот же скрипт Python с помощью генерации команд LaTeX с гиперссылкой \includegraphics, в которых указаны параметры компоновки документа (width=0.9\linewidth), выполнит загрузку результатов рабочего процесса с сервера и добавит их в результирующий документ PDF.
Кроме того, результаты, полученные в системе VisTrails, можно включать в веб-страницы, страницы вики, документы Word и презентации PowerPoint. Связь между Microsoft PowerPoint и системой VisTrails осуществляется через компонентную объектную модель Component Object Model (COM) и интерфейс связывания и внедрения объектов Object Linking and Embedding (OLE). Чтобы объект взаимодействовал с PowerPoint, в нем должны быть реализованы, по меньшей мере, интерфейсы IOleObject, IDataObject и IPersistStorage модели COM. Поскольку для сборки нашего объекта OLE мы используем класс QAxAggregated из Qt, который является абстракцией реализации интерфейсов COM, то инетерфейсы IDataObject и IPersistStorage будут с помощью Qt созданы автоматически. Таким образом, мы должны реализовать только интерфейс IOleObject. При этом самый важным будет обращение к DoVerb. Оно позволит системе VisTrails реагировать на определенные действия PowerPoint, например, на активацию объектов. В нашей реализации, когда объект VisTrails активируется, мы загружаем приложение VisTrails и позволяем пользователям открывать и взаимодействовать с конвейером, который они хотят вставить. После того, как они закроют систему VisTrails, результат работы конвейера будет показан в PowerPoint. Вместе с объектом OLE также хранится информация и о конвейере.
Чтобы позволить пользователям свободно обмениваться своими результатами вместе с сопутствующей информацией о происхождении данных, мы создали сайт crowdLabs. Сайт crowdLabs [7] является социальным веб-сайтом, на котором набор полезных инструментальных средств объединен с масштабируемой инфраструктурой с тем, чтобы можно было предоставить ученым среду для совместного анализа и визуализации данных. Сайт crowdLabs тесно интегрирован с системой VisTrails. Если пользователь хочет предоставить для общего пользования какие-нибудь результаты, полученные в системе VisTrails, он может непосредственно из системы VisTrails подключиться к серверу crowdLabs для загрузки этой информации. После того, как информация будет загружена, пользователи могут обращаться к рабочим процессам и выполнять их через веб-браузер — эти рабочие процессы выполняются сервером VisTrails, который поддерживает работу crowdLabs. Подробности о том, как система VisTrails используется для создания публикаций с воспроизводимыми данными, смотрите по ссылке http://www.vistrails.org.
Далее: 23.5. Усвоенные уроки