Настоящая заметка напасина в не слишком формальном стиле, и изначально была предназначена для наших коллег в качестве внутренней записки, иллюстрирующей наши (довольно скромные, though) компетенции. По некоторому размышлению, я решил добавить её в блог в качестве небольшой milestone-отметки — интересно будет посмотреть через несколько лет, к чему мы придём, а так же в качестве небольшого intro «для своих» — спецов‐прикладников занятых в соответствующей области, которым излишняя официальность и необходимость подыскивать эквивалентную русскоязычную номенклатуру с потерей семантики вяжет зубы.

Этот софт расчитан в основном на небольшие и средние эксперименты, где типичный объём данных собираемый в течении одной сессии составляет до нескольких террабайт. Для больших объёмов нужен уже другой стек технологий, с распределёнными хранилищами и grid'ом, но его и без нас активно развивают (e.g. PanDA).

Goo

Мы разрабатываем маленькую библиотечку общего назначения, обеспечивающую механизм сквозного конфигурирования и (необязательный) объектный дизайн приложения (goo). Гибкое run-time-конфигурирование использует систему классов упорядочивающих конфигурации в расширяемые иерархические словари. Это как boost::variables_map, только без ограничения на вложенность, с более лаконичным синтаксисом и упрощённым жизненным циклом, и поддержкой YAML (yaml-cpp).

StromaV

На основе Goo мы развиваем библиотеку StromaV, в которой реализуется обобщённая функциональность для работы в HEP/ЯФ-экспериментах (пока на уровне обобщённых интерфейсов, без привязки к конкретным экспериментам): в основном это интеграция MC-процедур и аналитики (небольшой пост в блоге с некоторыми деталями). Несколько ключевых черт дизайна:

• В качестве внутреннего формата данных для представления физического события используются Google Protocol Buffers. Кросс‐языковая совместимость, эффективная сериализация «из коробки», возможность держать описание топологии структур данных в выделенном файле со специально предназначенной для такого описания лексикой, хорошо протестированный код, встроенные механизмы интроспекции данных, возможность интеграции с IPC/RPC сервисами Google.
• Концепция pipeline для обработки данных формализована в виде объектной модели (посты в блоге с деталями: 1, 2):
  • Источник данных веделен в интерфейс (декларация), свойства которого можно определять через mixins реализованные через ромбовидное наследование (индексирование обеспечивает поддержку произвольного доступа (декларация), связь с записями в БД (декларация) — калибровки, conditions, геометрия, online-источник/приёмник (декларация), etc.
  • Интерфейс обработчика данных (handler, декларация, во внутренней номенклатуре — processor) с предсказуемым жизненным циклом подразумевает создание атомарных простых процедур обработки, в том числе и на высокоуровневых языках.
  • Параллелизм заложен в концепцию (когда независимые ресурсоёмкие обработчики исполняются на нескольких ядрах или узлах), однако пока не вполне реализован.
• Геометрия установок описывается на GDML — XML, с определённой XSD-схемой. Наличие схемы позволяет легко создавать для него расширения и автоматически генерировать трансляторы (так, мы сами написали конвертер GDML -> ROOT::TGeo, поскольку штатный ROOT'овый признан негодным), а текстовый формат позволил нам работать с геометрией в рамках REST API и реализовать параметризуемое динамическое конструирование CSG-геометрии средствами текстового шаблонизатора (Jinja2). На практике это показало себя как чрезвычайно удобный подход.

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

Сервер ресурсов StromaV

Писать интеграцию C++-кода с БД обычно довольно неудобно — многое зависит от back-end'а, конкретной computing-инфраструктуры в коллаборации, исторически-утверждённого цикла разработки и сопровождения софта, поэтому мы ввели промежуточный слой, объединяющий StromaV и сервисы уже работающие в коллаборации: калибровочные БД, logbook'и, библиотеку геометрии, хранилища и production в рамках RESTful-приложения, которое мы называем «сервер ресурсов». В этом случае, запросы к хранилищам можно делать через обычный вызов cURL‐процедур. «Сервер» может работать и локально, но в основном он упрощает работу с системами аутентификации (Kerberos, AD). Написан на Python (Flask).

Управление хранилищами

CERN предоставляет в пользование сервис с хранилищами CASTOR на магнитных лентах, и low-latency распределённое хранилище EOS. Мы интегрировали их, а так же управление данными на отдельных хостах в рамках приложений и модулей на Python в проекте castlib. Это сравнительно небольшой пакет расширяющий возможности StromaV и ресурсного сервера для работы со всякими экзотическими хранилищами и автоматизации long running tasks.

Прочее

Мы активно используем Docker в тех случаях когда встаёт вопрос о зависимостях, поскольку этот инструмент позволяет о них не думать вовсе. У нас есть образ дистрибутива на основе Gentoo с небольшим оверлеем, в который включены все необходимые зависимости, и всё что нужно от пользователя для начала работы — это тривиально‐устанавливаемый Docker (есть во всех современных дистрибутивах Linux в виде пакета, а так же на Mac OS) и ~7Gb трафика для скачивания образа (основной объём там — Geant4 и ROOT 6). Помимо трафика и места на диске, абсолютно никаких накладных расходов этот подход не несёт, в отличие от классических виртуальных машин.

Для автоматизации многих длительных задач мы используем Rundeck. Это очень гибкий scheduler со сравнительно удобным Web UI, возможностью администрирования как отдельных узлов, так и кластеров.

Сейчас мы работаем над Python‐биндингами к StromaV, которые можно будет использовать в интерактивных записных книжках Jupyter. Это должно существенным образом ускорить цикл и достоверность анализа.

Биндинги, кстати, делаются на SWIG, так что после Python мы сможем, как минимум, задействовать R и Java, к чему есть интерес со стороны студентов-аналитиков.

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

Распределение задач, документирование багов, обсуждения и база знаний у нас размещены на redmine (https://rm.epl.tpu.ru/), там намного больше информации, но мы пока стараемся вести его приватно, — после регистрации привелегии распределяются вручную.

Пример

Сравнительно целостным и проработанным этот софт представлен в сборке для эксперимента NA64 (CERN). Он представлен «суперпроектом» (термин из номенклатуры git) со скриптами сборки и файлами предпочтений для основных окружений, библиотекой, реализующей интерфейсы StromaV, и всем прочим софтом, который мы встроили в нашу экосистему.

Проблемы и апология

Поскольку нам частенько приходится встраивать в наш код уже существующие или появляющиеся внутри коллабораций вещи, нельзя сказать, что некая standalone-сборка всей экосистемы гарантирует стабильную работу — там всегда довольно много прототипов, попадающих в основные development‐ветки. Хотя на устранение ошибок и несовместимостей по мере развития этого подхода тратится всё меньше времени, у них (ошибок) всегда довольно сильный психологический эффект, и это вполне понятно, поэтому мы не пропагандируем эти решения и пользуемся ими в основном внутри группы. Доведение кода до ума в смысле целостных релизов в духе FairROOT силами такого небольшого сообщества, без выделенной финансовой поддержки, разумеется, невозможно.

Всё же, по мере развития т.н. Data Science в других областях (Big Data, image processing, финансы, аналитика больших экспериментов) новые технологии набирают популярность, и позволяют решать классические проблемы эффективнее. Так, работа со статистикой в R намного лаконичнее и выразительнее, чем скрипты на CINT/CLING, а интеграция Jupyter позволяет делиться аналитическими наработками одной ссылкой на его «записные книжки» (поддерживающие в т.ч. и CLING), или использовать библиотеки anaconda, существенно превосходящие ROOT в инструментальном отношении для аналитики.