Недавно в Томске состоялась конференция посвящённая BigData. Я представил на ней постерный доклад, который затем пришлось защищать перед небольшой аудиторией. Рассказал там о своём видении программного оснащения, которое можно было бы употребить для организации работы в небольших коллаборациях вроде тех в которых мне доводилось работать. Поскольку аудитория конференции проявила некоторый интерес к теме, я решил чуть более подробно изложить дело в блоге на тот случай, если кто‐то пожелает обсудить такой взгляд на вещи.

Preface

Use cases, которые мы рассмотрим типичны для физической коллаборации. Они легко сортируются на основные группы: Разработка числодробилок для рассчёта теоретической модели Монте‐Карло моделирование, ставшее, de facto, стандартом в физических IT Хранение статистики (эксперимента и моделлирования), её метаданных (metadata, это индексы событий, различная информация о том, что, где и как хранится), условий эксперимента (conditions — информация о постановке в какой‐то момент времени, геометрии детекторов, их вещества, перемещений, etc). Анализ данных

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

Числодробилки

Тут всё довольно просто и линейно. Конечно, редкий теоретик способен написать считалку на C/C++ так чтобы её не приходилось потом подолгу оптимизировать, однако с этим аспектом меньше всего проблем, поскольку для счёта обычно не нужны какие‐то специальные структуры и сложные отношения между компонентами. Их логика практически всегда линейна, и элементарно выражается в императивной или чисто‐функциональной парадигме. Биндинги процедур для интеграции тоже всегда делаются достаточно тривиально.

МК‐модели

Конечно, существуют реализации довольно интересных алгоритмов с точки зрения статистики (каскады на марковских цепях, привлечение нечётких методов, etc), однако чаще всего небольшой коллаборации лучше опираться на Geant4 (пока пятая версия только готовится). Сегодня этот пакет находится вне конкуренции по обилию охватываемых процессов, он хорошо протестирован и был неплохо спроектирован.

Однако Geant4 довольно ригиден и инвазивен в плане его интеграции со сторонним кодом. Логика построенная на интерфейсах оказалось весьма хороша, но со времён его разработки появилось очень много технологий учёта которых ему откровенно не хватает с архитектурной точки зрения. В его архитектуре ощутимо недостаточно шаблонов, модульность физики недостаточно прозрачна, а плохая интеграция с популярными геометрическими форматами обусловлена родовыми особенностями воксельного движка. Последний, хотя, очевидно и является довольно толковым сооружением, существует по большей части сам для себя, — предложив его, Geant4 не предлагает хорошего формата для описания геометрии, веля большинству разработчиков описывать геометрию на C++.

И вот тут был проделан на мой взгляд блестящий и очень недооценённый манёвр — создание схемы для XML‐диалекта и её интеграция во фреймворк. Речь идёт о GDML. Ниже я остановлюсь на нём подробнее.

Хранение данных

Наука нынче такова, что пара событий скорее всего относится к тому что мы уже довольно хорошо изучили, поэтому каков бы ни был эксперимент, чем больше статистики будет набрано, тем лучше. Отсюда вывод: нужно всегда быть готовым к тому что данных будет много, очень много, или фантастически много. HEP — одна из тех областей, которая хранит данные десятками и сотнями петабайт (ATLAS, CMS, etc).

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

Анализ данных

Главная черта присущая анализу данных в HEP — вам чаще всего нужно будет работать с очень большим количеством независимых структур данных близкой топологии, каждый экземпляр которых прекрасно поместится в RAM вашего PC. Более того, нередко вы сможете обойтись и без random access, так что необходимость упомянутых выше метаданных возникнет очень нескоро, и в небольшом количестве use cases.

Предложения

Повозившись какое‐то время с наиболее типичными задачками, я, как человек способный писать код помногу, но страшно боящийся дублирования, сплёл систему библиотек размещённых на различных уровнях абстракции. Базовый технологический стек использует как проверенные и общеупотребимые в HEP инструменты (ROOT, Geant4), так и парочку решений из более‐менее современного мира.

Protobuf

Одна из наиболее удачных находок — это Google Protocol Buffers. Оригинально, это набор инструментов для описания структуры высокогранулярных данных, позволяющих генерировать мультиязычные обёртки на основе этого описания. Их дизайн почти идеально подходит для хранения физических событий, поскольку все структуры имеют неглубокую, ацикличную топологию. Как правило, одно событие требует порядка сотен килобайт‐мегабайта памяти для хранения и может быть дополнено/изменено аналитическим кодом (возможно, из другой языковой среды).

На наиболее общем уровне, нам понадобится оперировать с абстрактным «событием», возможно различая смоделированное и экспериментальное. Кроме этого, неплохо бы предусмотреть какой‐нибудь гибкий формат хранения данных, более масштабируемый и прозрачный чем традиционные ROOT::TTree. В принципе, с небольшим вспомогательным кодом, хранение сжатие, а так же сопряжение с метаданными может быть предварительно организовано на самих protobuf'ах.

GDML

Как мне кажется сейчас, GDML был отличным решением, однако несколько запоздал с релизом и оказался весьма незаслуженно выставлен на задний двор. Кто‐то написал весьма неплохую, компактную и не лишённую элегантности XML‐схему для описания геометрических примитивов (CSG, Constructive Solid Geometry), операций над ними и связывания с этой геометрией физических параметров вещества. В той же степени детальности (достаточно лапидарной, надо сказать), в которой это поддерживается самим Geant4.

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

Недостатки с которыми я столкнулся в основном объясняются тяжёлым врождённым заболеванием XML, как раздутого, громоздкого и избыточного формата. Небольшая часть проблем возникла ещё и из‐за того что сообщество достаточно слабо развивает этот формат, — после того как энтузиазм к XML прогорел, возиться с ним сделалось уделом в основном унылых enterprise-разработчиков. Все крутые парни перешли на YAML, JSON и Lua table. В результате схема, хотя и выделилась в отдельный проект, не вполне учитывает некоторые нововведения и исправления в Geant4.

Ну и важная деталь — основным потребителем GDML‐геометрии после Geant4 должен был стать ROOT. И они написали парсер для ROOT, основанный на внутреннем XML‐парсере ROOT. Как и многие (очень многие!) вещи в ROOT, этот кусок софта получился ужасным. Он всё ещё работает, он способен вычитать GDML, который генерирует Geant4, но этим его практическая применимость исчерпывается.

Думаю, в своих проектах мне удалось в какой‐то мере решить некоторые недостатки GDML. Я даже написал собственный парсер GDML, помимо патча и расширений для его схемы. Во всяком случае, я страшно доволен теми промежуточными результатами, что он показывает мне: Мы располагаем человеко‐читаемым форматом для описания геометрии который легко понимать и сравнительно легко писать (намного легче, чем C/C++). Нам удалось реализовать хорошо структурированную, прозрачную библиотеку геометрии, формируемую динамически, явно связанную со вспомогательными структурами (информация о чувствительных детекторах, визуальные атрибуты, иерархия). * Мы располагаем парсером этого формата с возможностью сравнительно несложной конвертации геометрии, и превосходной расширяемостью как формата, так и парсера.

Pipeline

Эксперимент NA64 в котором я занят сейчас осуществляется коллаборацией в несколько десятков человек. Он унаследовал DAQ‐систему у эксперимента NA58 (COMPASS, в котором я тоже «замешан», но не слишком сильно пока), который производится силами коллаборации в три‐четыре сотни человек. В свою очередь, COMPASS развивает наследие эксперимента ATLAS, зачатого и осуществляемого коллаборацией в несколько тысяч человек.