CC BY
48
УДК 007.51
МЕТОДЫ ХРАНЕНИЯ ЭКСПЕРИМЕНТАЛЬНЫХ ДАННЫХ ДЕТЕКТОРА ЭЛЕМЕНТАРНЫХ ЧАСТИЦ НА ПРИМЕРЕ ЭКСПЕРИМЕНТА ATLAS НА УСКОРИТЕЛЕ LHC (ЦЕРН)
Р.Ю.Машинистов, асп. управления Управление перспективных программ, проектов
и информационных технологий Тел.: (495) 323-94-01; E-mail: ruslan.mashinistov@cern.ch Ю.А. Чернышев, д.т.н.,проф. каф. Компьютерных систем и технологий Тел.: (495) 323-90-95; E-mail: yachernishev@mephi.ru Московский государственный инженерно-физический институт
http:// ww.mephi.ru
This article considers the principle of the organization of condition and configuration databases in the field of elementary particle physics, and also describes the mechanism of «intervals of va-lidity».
Данная статья рассматривает принцип организации баз данных условий и конфигураций в области экспериментальной физики элементарных частиц, а также описывает механизм интервалов истины.
Keywords: database, experiment, data store.
Ключевые слова: базы данных, эксперимент, хранение данных.
Введение
В ходе тестирования, отладки, ввода в эксплуатацию и эксплуатации на рабочих режимах оборудования, производящего экспериментальные измерения в области физике элементарных частиц, возникает необходимость в хранении и обработке больших объемов данных. Например, в настоящее время ведется подготовка четырех крупных экспериментов на крупнейшем в мире ускорителе LHC [1] в ЦЕРН (г. Женева, Швейцария). После начала работы всех четырех экспериментов на LHC будет ежегодно производиться около 15 Петабайт (15 млн гигабайт) физических данных, и несколько тысяч физиков со всего мира должны будут иметь к ним доступ для обработки и анализа [2].
Данные эксперимента различны по значению и целям использования. Ведущиеся в каждом отдельном эксперименте работы направлены на решение широкого спектра задач. Существуют различные проекты по организации баз данных и систем управления данными. Существует необходимость хранения как технических данных конструкции детектора, так и данных конфигурации запуска [3]. Под запуском здесь и далее по тексту подразумевается ограниченный во времени процесс сбора экспериментальных данных, выполненный при постоянных условиях. Запуски могут проходить с целью калибровки и тестирования оборудования и программного обеспечения, а также непосредственно для сбора экспериментальных данных. В последствии должен быть организован доступ к данным событий и соответствующих условий, при которых произошло каждое событие. Под событием в области физики элементарных частиц принято понимать факт регистрации трека элементарной частицы. В техническом плане событие определяется сигналом срабатывания триггера детектора частиц. Триггер является специальной подсистемой выработки сигнала события для системы записи данных. Триггер обрабатывает экспериментальные данные «на лету» и вырабатывает сигнал только в случае возникновения события, представляющего интерес для данного исследования. Данный подход позволяет минимизировать объем записываемых данных.
При создании инфраструктуры хранения экспериментальных данных к основным задачам относятся организация структурирован-
ного хранения данных с реализацией возможности совместного использования различных по типу и назначению баз данных, а также реализация рационального доступа к данным. Такая организация позволит в дальнейшем полностью восстановить процесс эксперимента и предоставит ученым всю необходимую информацию [3].
Проведение одного отдельного эксперимента требует большого числа различного рода данных и соответствующих программных служб. Например, в эксперименте ATLAS существуют технические данные, данные геометрии детектора, базы данных системы сбора данных DAQ (Data Acquisition system) и системы контроля детектора DCS (Detector Control System) [4]. Базы данных могут быть как реального времени, так и автономные. Также существуют данные событий, условий и конфигураций. Используются различные службы управления данными.
Для развития инфраструктуры обработки данных следует обеспечивать параллельную разработку, интеграцию и операционные возможности распределенных баз данных, программного обеспечения управления данными, а также инфраструктуры этих областей.
1. Данные условий и конфигурации в эксперименте ATLAS
Данные условий - это почти все данные, не относящиеся к событиям, производимые во время работы детектора. Совместно с данными условий данные событий становятся достаточными для процессов реконструкции и анализа события [3].
Данные условий изменяются со временем и обычно характеризуются так называемыми «интервалами истины» IOV (Interval of Validity) [3], т.е. период времени, в течение которого параметры условий принимали указанные значения, т. е. данные условий были истинны для этого интервала времени. Интервал истины выражается либо как диапазон абсолютных времен, либо номер запуска (рабочий запуск детектора) с номером события (срабатывание). Каждый интервал истины соответствует определенному событию.
Данные условий ATLAS включают в себя данные, полученные с систем контроля детектора DCS и сбора данных DAQ. Эти системы включают в себя автономные данные и данные реального времени калибровки и выравнивания сигналов событий, данные мониторинга, характеризующие работу детектора и программного обеспечения в течение определенного интервала времени.
Основная функция базы данных условий - это хранение самих данных вместе с соответствующими интервалами истины. В некоторых случаях (как, например, в системе DCS) данные и интервалы истины не разделяются и хранятся вместе в базе данных условий. В других случаях (при больших наборах калибровочных данных) данные могут изначально не иметь определенного интервала истины и только позднее быть приписанными к такому интервалу. В последнем случае данные условий могут храниться независимо от реляционной базы данных, хранящей интервалы истины. При этом интервалы истины будут действовать как механизм упорядочивания, индексируя объекты условий по времени. Данный механизм позволяет производить выборки поднаборов данных условий, относящихся к определенному временному интервалу. Таким образом, существует возможность разделения между небольшой базы данных интервалов истины, упорядочивающей данные условий, и большей базой данных условий, включающей уже и сами объекты. Приписанные к интервалу истины объекты данных иногда называют «полезным грузом» интервала истины [3].
Данные условий строго связаны с данными конфигурации. Данные конфигурации необходимы для установки и запуска аппаратуры детектора ATLAS и соответствующего программного обеспечения. Данные конфигурации главным образом определяются версией или целью (например, физический запуск, калибровочный или космический запуск), либо, в последствии, интервалом истины.
Как только данные конфигурации использованы при сборе данных при запуске, они становятся данными условий, истинными для определенного интервала времени. Таким образом, возможно полное восстановление данных конфигурации, соответствующих любому событию.
В ходе подготовки эксперимента ATLAS уже был получен достаточный опыт использования базы данных в режимах реального времени и автономном. И данный опыт послужил толчком для разработки нового продукта - базы данных условий по технологии COOL [5].
Финальная база данных условий эксперимента ATLAS будет создана с применением технологии COOL, обладающей расширенными возможностями. Многие интерфейсы и утилиты также разрабатываются с учетом возможностей COOL, чтобы поддерживать различные типы данных условий в эксперименте.
2. Архитектура базы данных условий
База данных условий обычно определяется интервалом истины и непосредственно данными условий, возможно также указание версии. Версия соответствует только некоторым типам данных, например, для идентификации различных наборов калибровочных данных истинных для одного и того же интервала истины, но относящихся к разным калибровочным алгоритмам или реконструкциям событий.
База данных условий COOL поддерживает как данные с версиями, так и без них. Также COOL предоставляет несколько возможностей хранения данных, и в базе данных условий, и внешним образом в других базах данных и файлах.
Система COOL является темпоральной базой данных. Система COOL является надстройкой над обычной реляционной базой данных под управлением таких СУБД, как Oracle, MySQL или SQLLite.
На самом нижнем уровне каждый набор объектов базы данных условий соответствует реляционной таблице со столбцами: столбец, содержащий интервал истины, необязательный столбец номера канала (позволяет хранить в базе данных несколько независимых, но сгруппированных измерений), а также один или более столбцов для хранения непосредственно данных стандартных простых типов. Вместо непосредственно данных в столбце также может храниться ссылка на данные, хранящиеся в другом месте, например, внешние ключи на таблицы баз данных или идентификатор внешнего файла. В этих случаях таблицы базы данных состояния используются для упорядочивания или индексирования данных, которые, возможно, независимо хранятся в другом месте.
В эксперименте ATLAS планируется хранение различного типа данных условий. Данные DCS обычно хранятся непосредственно в таблицах базы данных условий. В этом случае количество непосредственно данных на один интервал истины обычно мало и данные не могут быть отделены от интервала истины. Это означает, что измерения DCS всегда привязаны к определенной временной отметке. Данный подход также применим для других типов данных, где количество хранимых данных относительно мало и существует необходимость возможности реляционных запросов по интервалам истины и самим данным. Одним из типичных примеров является итоговые данные мониторинга, где запросы могут делаться в целях получения всех запусков, где выполняется определенное условие (например, определенная часть детектора имеет высокое значение процента срабатываний или, наоборот, не активна).
Данные могут храниться в базе данных условий, но в отдельных внешних таблицах, не имеющих структуры интервалов истины. В таком случае другие таблицы интервалов истины содержат внешние ключи, указывающие на строки в таблицах непосредственно полезных данных. Данный подход используется, когда данные изначально представляются в реляционных таблицах, но не имеют однозначного соответствия с интервалами истины, или по причине того, что один интервал истины указывает на несколько строк данных, использующих один и тот же ключ, или данные могут существовать вне контекста любых интервалов истины. Хранение таких данных непосредственно в базе данных условий имеет преимущества при доступе и при распространении данных.
Данные конфигурации поддетекторов эксперимента ATLAS обычно хранятся или в самой базе данных условий, или непосредственно, в таблицах интервалов истины, или в другой таблице реляционной базы данных. В последнем случае данные будут управляться вне контекста COOL. COOL в этом случае может использоваться только для определения того, какая версия конфигурации была использована для конкретного запуска.
Во всех случаях изменение конфигурации может быть произведено путем создания новой версии или нового интервала истины. Таким образом, данные, которые уже были использованы в предыдущих запусках, сохраняются на случай, если они потребуются автономно.
Средства системы COOL также могут быть использованы для поддержки нескольких параллельных версий конфигурации для физических, космических или калибровочных запусков. В настоящее время рабочие группы поддетекторов эксперимента ATLAS начали исследование возможностей использования баз данных условий для конфигурации.
3. Организации базы данных условий с использованием технологии COOL
Программный пакет COOL реализован на основе механизма интервалов истины, т.е. объекты или ссылки на объекты, хранящиеся в базе данных COOL, имеют соответствующее времена начала и окончания периода, в течение которого эти данные истинны. Данные в системе
COOL хранятся в так называемых папках, которые могут иметь иерархическую структуру [5]. В терминах Unix конечная папка соответствует файлу, а структура вложенных папок соответствует дереву каталогов Unix.
В каждой папке хранятся объекты одинакового типа, при этом каждый объект имеет свой интервал истины. Этот временной интервал может быть представлен или в виде номера запуска/события или в виде абсолютных времен, в зависимости от непосредственно хранящихся данных. Система COOL оптимизирована для хранения и получения объектов, относящихся к определенному временному интервалу.
Папки COOL могут иметь формат SingleVersion, когда только один объект может быть истинным в любой выбранный момент времени (например, данные системы DCS, когда в папках просто хранятся значения в порядке их изменения во времени), или формат MultiVersion, когда несколько объектов могут быть истинными в одно и то же время, но разделены указателями «тэгами». Указатель тэг позволяет объединять объекты, например, по цели использования. Таким образом, в одно и то же время могут существовать несколько наборов калибровочных данных [2].
Для того чтобы было удобнее хранить много объектов с одинаковой структурой (например, набор значений порогов срабатывания для считывающих чипов), объекты в каждой папке COOL могут быть определены номером канала (Channel ID). Каждый канал имеет свой собственный интервал истины. Это означает, что интервалы истины для объектов, приписанных к разным каналам, могут перекрываться. В рамках же одного канала объекты не могут иметь перекрывающихся интервалов истины (в случае SingleVersion).
В системе COOL каждую отдельную папку можно представить как таблицу реляционной базы данных, где каждому хранящемуся объекту соответствует строка в таблице. Таблица содержит специальные столбцы для времен начала и окончания интервалов истины для каждого объекта. При этом возможно использование столбца номера канала и указателя тэга. Также таблица содержит столбцы, соответствующие непосредственно хранящимся значениям. Пользователь сам генерирует структуру этих столбцов (тип, количество, имена). Также таблица COOL содержит дополнительные столбцы, например, время добавления каждой строки и др.
Представление структуры папки COOL как одной таблицы облегчает понимание, но не отражает ее внутреннего устройства. В действительности папке соответствует набор реляционных таблиц со сложной системой связи. Данная организация позволяет оптимизировать множество операций, таких как выбор объектов по временному интервалу или по принадлежности к заданному каналу, или по другому критерию.
Общий формат хранения данных в системе COOL представлен на рис.1. Столбцы Since и Until определяют границы интервала истины и имеют тип Time. Тип Time является типом данных COOL и представляет собой абсолютное время в миллисекундах, начиная с 1 января 1970 г. Данное представление времени соответствует формату POSIX-время и используется во всех Unix-подобных операционных системах. Отличием формата является то, что в POSIX-времени отсчет производится в секундах. Тип переменных времени начала и окончания интервала Time, по сути, является типом Си unsigned long long. Номер канала задается целым числом. Указатель тэг имеет тип строка.
Since Until Channel ID Payload Pa- Tag
(Time) (Time) (Integer) ta) (String)
Рис. 1. Общий формат хранения данных в системе COOL
На рис.2 представлена структура поля Payload. Данное поле полностью определяется пользователем в зависимости от того, какое количество данных и какого типа пользователь собирается хранить. При этом интерфейс COOL позволяет использовать стандартные типы данных языка программирования Си.
Paiam 1 (In- Paiam 2 Paiam 3 Paiam N
teger) (Float) (Double) (String)
Рис. 2. Структура поля Payload в папке COOL
При хранении данных в системе COOL пользователь может выполнять запросы. При этом запросы с учетом номера канала, указателя и интервала истины оптимизированы разработчиками пакета. Также возможны запросы на данные поля Payload. Но при этом разработчику при-
дется самому реализовать алгоритм выборки по условию. Также разработчику придется выполнить операции считывания данных, сравнения значений, условные переходы и т.д.
В рамках проекта разработки базы данных системы сбора данных DAQ поддетектора TRT [6] эксперимента было разработано приложение с применением пакета COOL. При этом база данных COOL реализовывала механизм интервалов истины. При этом непосредственно данные хранились в обычных таблицах СУБД Oracle.
В табл.1 представлены имена столбцов, их тип и размер таблицы Oracle, хранящей параметры DAQ для считывающих чипов детектора TRT. В таблице приведены только основные столбцы.
Таблица Oracle содержит следующие столбцы: уникальный идентификатор чипа dtmroc_UID, внешний ключ dtmroc_iovfk, связывающий строку в данной таблице со строкой в таблице интервалов истины COOL. Также таблица содержит столбец аппаратного адреса чипа HW_Addr_FE, непосредственно параметры: значения порогов срабатывания 1 и 0 и значения напряжений (Thresh0_Low_FE, Thresh0_High_FE, Thresh 1_Low_FE, Thresh 1_High_FE, VT_DAC0_FE, VT_DAC1_FE). Поле комментария Comment. Поле указателя версии данных roc_tag. Данный столбец позволяет хранить несколько версий значений для одного и того же временного интервала.
Таблица 1
Столбцы таблицы Oracle, хранящей параметры DAQ для считывающих чипов детектора TRT
Имя таблицы в Oracle: BDTMROC
Имя столбца Тип столбца Размер столбца
dtmroe UID NUMBER 10
dtmroe iovfk NUMBER 20
HW Addr FE NUMBER 5
ThreshO Low FE NUMBER 5
ThreshO Iligh FE NUMBER 5
Thresh 1 Low FE NUMBER 5
Thresh 1 High FE NUMBER 5
VT DACO FE NUMBER 5
VT DAC1 FE NUMBER 5
Comment VARCHAR2 4000
roc tag VARCHAR2 4000
Табл.2 представляет столбцы, их тип и размер для таблиц интервалов истины COOL, соответствующей таблице, хранящей значения DAQ для считывающих чипов.
К основным столбцам относится номер канала CHANNEL_ID. Данный столбец соответствует столбцу уникального номера чипа в табл. 1 и хранит аналогичные значения. Столбцы IOV_SINCE, IOV_UNTIL соответственно хранят значения времен начала и окончания интервала истины.
Следующий столбец относятся к области так называемых «полезных данных» базы данных COOL. Число столбцов, их тип и размер в области нагрузки задаются пользователем. В данном случае поле содержит один столбец - внешний ключ dtmroc_iovfk, указывающий на строки в табл. 1. Поле комментария Comment в данном случае идентично полю указателя тега версии roc_tag в табл. 1.
Таблица 2
Таблица интервалов истины COOL для таблицы DAQ для считывающих чипов
Теперь, если необходимо считать значение одного из параметров для конкретного чипа для определенной версии набора данных, следует сначала выполнить запрос в таблице интервалов истины. Входными значениями такого запроса будут: уникальный идентификатор чипа; интервал времени, в течение которого нас интересуют значения параметров; указатель тега версии (например, калибровочные данные).
Система COOL позволяет выполнять запросы такого вида. При этом в системе COOL оптимизированы алгоритмы выполнения запросов с представленными условиями на номер канала, временной интервал и поля комментария.
В результате выполнения запроса будет получена единственная строка в таблице, соответствующая заданным условиям. Система COOL устроена таким образом, что в заданном временном интервале она возвращает строку, соответствующую максимальному значению времени, не превышающему времени окончания интервала. В случаях, когда заданному временному интервалу не соответствует ни одна строка, система COOL возвращает стоку, соответствующую последнему изменению, прошедшему ранее заданного интервала истины.
Далее, считав в результирующей строке значение внешнего ключа, формируется запрос к непосредственно таблице, хранящей значения DAQ. Входными параметрами запроса теперь являются: уникальный номер чипа; указатель версии тэг; внешний ключ, полученный в предыдущем запросе.
Результатом запроса будет являться одна строка в таблице параметров DAQ. Теперь значение любого параметра можно получить, обратившись к соответствующему столбцу.
Как было сказано выше, таблица интервалов истины не обязательно должна являться папкой системы COOL. Возможно использование аналогичной стандартной таблицы Oracle. В этом случае разработчиком должны быть разработаны свои алгоритмы генерации интервалов истины в этой таблице.
4. Использование технологии CORAL для реализации таблицы интервалов истины
Альтернативным способом организации таблицы интервалов истины является создание стандартной таблицы Oracle, где в каждой строке будет храниться соответствие строке таблицы, хранящей непосредственно значения параметров, интервалу истины.
При таком подходе программисту необходимо реализовать алгоритмы генерации интервалов истины, а также запросов данных и операции вставки нового значения и др. В данном случае может быть использована система CORAL [7]. Система CORAL - это программный пакет, реализующий основные операции для работы с данными. Основной целью при разработке являлось создание программного продукта, осуществляющего доступ к данным, хранящимся в СУБД. При этом доступ данных с точки зрения программиста не должен зависеть от используемой технологии СУБД. Система CORAL работает со стандартными таблицами СУБД Oracle.
Для примера реализации стандартной таблицы интервалов истины будет использована заранее сгенерированная стандартная таблица Oracle. Имена столбцов, их тип и размер представлены в табл. 3.
В табл.3 столбцы уникального номера чипа, внешнего ключа и указателя тега аналогичны столбцам табл.1. Столбцы времени начала и окончания интервала истины time_since, time_until аналогичны столбцам границ интервала в табл.2.
Таблица 3
Таблица интервалов истины для таблицы DAQ для считывающих чипов
Имя таблицы в Oracle: DTMROC IOVS
Имя столбца Tim столбца Размер столбца
dtmroc UID NUMBER 10
dtmroc iovfk NUMBER 20
time since NUMBER 20
time until NUMBER 20
roc tag VARCHAR2 4000
На примере табл.1 и табл.3 будет продемонстрирован SQL запрос значений параметром DAQ. Данный запрос представлен в листинге 1.
Листинг 1. SQL запрос параметром системы DAQ
select * from
(select dtmroc_iovfk from DTMROC_IOVS where dtmroc_UID = '3101001' AND roc_tag = 'calib'
AND time_since <= '1103760000000000' AND time_until > '1103760000000000' ) t1,
BDTMROC t2
where t1.dtmroc_iovfk = t2.dtmroc_iovfk AND t1.dtmroc_UID = '3101001' AND t1.roc_tag = 'calib';
Приведенный SQL запрос иллюстрирует описанный выше алгоритм получения значений параметров системы DAQ. В данном примере временные отметки представлены в расширенном до микросекунд формате UNIX-время или POSIX-время.
Заключение
В данной статье было приведено описание системы хранения экспериментальных данных детектора элементарных частиц. Приведено структурированное описание систем управления и контроля детектора на примере эксперимента ATLAS. Представленное структурированное описание является универсальным для современных больших детекторов элементарных частиц. Статья содержит методологический материал, который может быть использован в качестве справочного материала при построении систем хранения экспериментальных данных.
Рассмотренная в статье проблема является одной из основных задач при проведении экспериментов в области физики элементарных частиц. Поставленная проблема требует системного подхода. При этом должна быть разработана подробная методология разработки систем хранения экспериментальных данных. Выполненная работа включает анализ типов экспериментальных данных, основных систем детектора, соответствующих им баз данных и их взаимосвязь.
Подход интервалов истины применим в области экспериментов физики элементарных частиц. В случае баз данных условий существует ограниченный набор параметров. Значения параметров меняются во времени от одного запуска к другому вследствие выполнения операций калибровок либо по другим причинам.
В статье описаны базы данных конфигураций и условий. База данных условий хранит значения параметров, таких как, например, пороги срабатывания считывающих чипов, рабочие напряжения, при которых проходил эксперимент. Так, например, одному файлу, содержащему информацию о треках зафиксированных частиц, проходивших при определенной конфигурации, соответствует один набор данных условий.
Данные конфигурации - это те значения вводных параметров экспериментальной аппаратуры, которые загружаются перед экспериментальным запуском. Как только данные конфигурации использованы при запуске экспериментальной установки, они автоматически становятся данными условий.
Использование той или иной системы доступа к данным определяется рациональностью использования, а также рекомендационными документами конкретной организации.
К основным недостаткам системы COOL относится необходимость поддержки баз данных различного типа, даже в случае, если таблицы COOL хранятся в одной схеме вместе со стандартными таблицами данных условий или конфигураций. К недостаткам системы CORAL относится необходимость реализации алгоритма интервалов истины. При этом совместное использование описанных систем является оптимальным вариантом организации системы хранения экспериментальных данных.
В рамках представленной работы был проведен анализ программных средств COOL и CORAL, используемых для создания базы данных и управления данными. Материал может быть использован в качестве руководства к выбору способа реализации базы данных.
Методология интервалов истины успешно используется в большинстве экспериментов, готовящихся к проведению на Большом Адроном Ускорителе. Описанный метод реализации интервалов истины с использованием пакета CORAL реализован в базе данных системы DAQ детектора TRT в эксперименте ATLAS.
Литература
1. LHC - The Large Hadron Collider: http://lhc.web.cern.ch.
2. Метечко В.И., Смирнов С.Ю. Создание многопроцессорной вычислительной фермы в рамках концепции распределенной сети GRID // Сб. тр. науч. сессии МИФИ-200З. - Т.10. -26с. - М:. МИФИ, 200З.
3. ATLAS Computing Technical Design Report, ATLAS TDR-017, CERN-LHCC-2005-022, CERN, Geneva, 20 June 2005, available at http://atlas.web.cern.ch/Atlas/internal/tdr.html.
4. ATLAS DAQ, DAQ, EF, LVL2 and DCS Technical Progress Report, CERN/LHCC 98-16, CERN, Geneva, З0 June 1998, available at http://atlas.web.cern.ch/Atlas/internal/tdr.html.
5. COOL - LCG Conditions Database Project: http://lcgapp.cern.ch/project/CondDB/.
6. TRT Transition Radiation Tracker: http://pcwetans.web.cern.ch/pcwetans/atlas-trt/.
7. CORAL COmmon Relational Abstraction Layer: http://pool.cern.ch/coral/.
