При работе с такими уникальными установками, как Европейский рентгеновский лазер на свободных электронах XFEL (X-ray Free Electron Laser), Большой адронный коллайдер (БАК, или Large Hadron Collider (LHC)) в ЦЕРН, коллайдер НИКА (Дубна, Россия) и другие, получены сотни петабайт экспериментальных данных в области физики элементарных частиц, биоинформатики, геофизики и т. д. Их объемы будут расти и скоро достигнут экзабайтной отметки. Вся полученная в ходе экспериментов информация должна быть доступна членам научных сообществ, причем, в отличие от экспериментов ХХ века, участники коллективов почти всегда географически распределены. Задача хранения и управления метаданными становится фундаментальной, а отсутствие ее адекватного решения приводит к экономическим и функциональным потерям, грозя свести на нет значение эксперимента.

ATLAS (A Toroidal LHC ApparatuS) [1] — одно из крупнейших научных сообществ, проводящих исследования в области физики высоких энергий и ядерной физики на БАК, объединяющее более 3 тыс. ученых из 180 институтов и 40 стран. Обработка, хранение, анализ экспериментальных данных ATLAS ведется с помощью распределенной гетерогенной компьютерной инфраструктуры, включающей около 200 ЦОД, размещенных в России, Европе, Азии, Америке и Австралии. После запуска БАК в 2009 году стало ясно, что управляемый объем данных эксперимента (160 Пбайт в 2015 году) сравним с объемами данных, обрабатываемых компаниями Google (поисковый индекс 100 Пбайт) и Facebook (180 Пбайт), и на порядок превышает годовой объем информации в YouTube (15 Пбайт в год).

Как и при проведении всех крупных научных экспериментов, в ATLAS используются пакеты программ для распределенной обработки и управления данными, обеспечивающие управление данными в гетерогенной среде: запуск задач на высокопроизводительных системах, доступ к наборам данных, управление вычислительными ресурсами, формирование очередей выполнения задач и др. Одновременно создаются базы данных для хранения метаинформации (описание форматов данных, версия ПО для их обработки, параметры ускорителя: энергия, светимость и т. д.), необходимой для работы всего научного сообщества. Однако метаданные для отдельных систем (например, ускорителя), программных пакетов и этапов научного исследования сейчас, как правило, существуют независимо друг от друга и слабо связаны.

На очередном этапе работы БАКа и выводе ускорителя на повышенную светимость (запланировано на 2020 год) прогнозируется пятикратное увеличение потоков информации, полученных от экспериментов ATLAS и CMS (компактный мюонный соленоид), и 100-кратное — для тяжело-ионного эксперимента ALICE с последующим увеличением на два порядка объема данных для экспериментов на дальнейшем этапе superLHC. Все это может вызвать проблемы масштабирования баз данных и деградацию производительности работающих с ними сервисов. Кроме того, по мере увеличения объемов хранимой информации и сложности внутренних взаимосвязей возрастает и сложность SQL-запросов, это приводит к тому, что реляционные СУБД уже неспособны построить оптимальный план выполнения запроса без отступления от базовых принципов реляционной модели (непротиворечивость, согласованность, доступность данных в условиях многопоточности при сохранении производительности). Эти проблемы и призваны решить базы NoSQL, которые опираются на принципы менее строгих гарантий согласованности данных и могут подстраиваться под их специфику. Как следствие, сегодня наблюдается тенденция миграции от традиционных реляционных СУБД к нереляционным при одновременном развитии идеи их интеграции [2].

Гибридное хранилище метаданных

Хранение и управление данными в ATLAS обеспечивается системой управления загрузкой PanDA [3], способной обрабатывать до 2 млн заданий (задач) в сутки. Ежесуточный объем сопутствующей метаинформации о времени и месте выполнения заданий обработки и анализа, о затраченных ресурсах, количестве ошибок составляет около 10 Гбайт — данная информация необходима для анализа работы всей системы и ее настройки. В базе хранятся сведения обо всех выполненных задачах начиная с 2006 года (общий архив занимает 4,2 Тбайт и содержит сведения о 900 млн задач). Вся эта информация может быть разделена на оперативную (данные о выполняемых задачах) и архивную (данные о завершенных задачах). Оказалось, что при использовании СУБД типа Oracle архивная информация не подвергается изменениям, а стремительный рост архива может привести к проблемам с масштабируемостью, эффективностью работы системы мониторинга и к задержкам в обеспечении ученых информацией о выполненных задачах. Требовалось спроектировать, разработать и внедрить архитектуру хранения данных с учетом новых технологий управления данными, поэтому хранилище было разделено на реляционную часть, где должны храниться оперативные данные, и нереляционную — для архивной информации. Основными программными модулями, обеспечивающими функционирование такого гибридного хранилища Hybrid Metadata Storage Framework (HMSF) как единого целого, являются Storage (программная оболочка вокруг различных баз данных, модули импорта, экспорта и синхронизации данных) и Storage API. Архитектура HMSF позволяет приложению взаимодействовать с различными базами данных. После анализа нескольких нереляционных систем выбор пал на распределенную, масштабируемую, высокодоступную отказоустойчивую поколоночную базу данных с открытым исходным кодом Apache Cassandra. Проект распределенной структуры основан на Amazon Dynamo, а модель данных — на Google Bigtable. Для работы с хранилищем применяется SQL-подобный язык запросов, а СУБД позволяет обеспечить согласованность данных, поддержать репликацию и работу со схемами данных. Cassandra использует механизмы фоновой оптимизации данных (компактизацию) для поддержки оптимального способа хранения данных.

Одно из основных назначений систем мониторинга научного эксперимента состоит в поиске ошибок при выполнении задач обработки и анализа данных. В эксперименте ATLAS ошибки встречаются примерно в 11% от общего числа выполненных задач. Из-за больших объемов метаинформации, связанной с каждой задачей, поиск ошибок превращается в достаточно ресурсоемкую процедуру.

Изначально данные об ошибках хранились совместно с метаданными о задачах в единой реляционной таблице СУБД Oracle, разбитой на разделы по временным интервалам (день, три дня, неделя), что позволяло ускорить поиск данных о выполненных задачах. Однако отображение статистической информации об ошибках в виде сводных таблиц и графиков, осуществляемое в веб-приложении PanDA Monitor мониторинга системы распределенной обработки и анализа данных PanDA, связано с дополнительными накладными расходами на предварительную обработку и агрегацию данных о задачах. Как следствие, для формирования отчета об ошибках требовалось больше времени, чем в среднем уходило на ожидание загрузки веб-страницы.

Для оптимизации процесса генерации отчета об ошибках была проведена частичная сегментация данных о задачах — для Cassandra была разработана модель метаданных, адаптированная под требования системы мониторинга. Общепринятая стратегия моделирования для Cassandra заключается в том, чтобы данные хранить в таблицах, структура которых адаптирована под конкретные пользовательские запросы, а поскольку в Cassandra нет внешних ключей, как в реляционных базах, и, соответственно, нет операций соединения (JOIN) нескольких таблиц, то для лучшей производительности требуется, чтобы все данные, необходимые для выполнения запроса, находились в одной таблице. Таблицы, в свою очередь, разбиваются на разделы, а для равномерного распределения данных по узлам кластера в Cassandra используются композитные распределительные ключи, которые и определяют, какими будут эти разделы. Для группировки данных внутри разделов используются кластерные ключи. Все это позволяет гибко управлять расположением данных, однако накладывает существенные ограничения на способы получения данных из таблиц. Например, при использовании композитного ключа необходимо в запросе последовательно указывать значения каждого ключа и нельзя указывать произвольный порядок ключей в условии WHERE. Фактически при помещении данных в Cassandra из них формируется иерархическая структура, что требуется учитывать.

Приложение PanDA Monitor позволяет анализировать данные, полученные за различные интервалы времени. Изначально программа мониторинга проводила агрегацию данных из реляционных таблиц, обеспечивая фильтрацию метаданных о задачах по их состоянию и коду ошибки. Отфильтрованные данные группировались по различным параметрам — например, по имени пользователя, запустившего задачу, по названию вычислительного центра, на котором задача выполнялась, и др. Поскольку этот процесс выполнялся в оперативной памяти, для задач долгосрочной аналитики время выполнения запроса увеличивалось экспоненциально. Разработанная NoSQL-модель, а также сервис экспорта и агрегации данных из Oracle в Cassandra позволили оптимизировать процесс формирования отчета о задачах, выполненных с ошибками.

Особенностью моделирования данных в Cassandra является необходимость специально под запрос создавать таблицу (BigTable). Если системе мониторинга требуется генерировать отчет об ошибках с группировкой по различным параметрам, то фактически для каждой группировки приходится создавать отдельную таблицу. В случае, когда нужны более гибкие группировки и фильтры (например, по набору из нескольких параметров), можно использовать Apache Spark для получения данных из нескольких таблиц и проведения с ними аналитических операций в памяти, в том числе MapReduce.

Для минимизации объемов данных, обрабатываемых в памяти при генерации отчета, а также для формирования отчетов на различных уровнях детализации была разработана модель данных со ступенчатой агрегацией. Минимизация количества данных, обрабатываемых приложением мониторинга, осуществляется за счет того, что вся логика по фильтрации данных об ошибках, по их группировке, перенесена в HMSF, откуда обработанные данные импортируются в базу данных Cassandra.

Данные об ошибках разбиты на разделы по дням, для каждого из которых определены временные интервалы (минута, 30 минут, час, день, 10 дней). В эти интервалы записываются агрегированные данные об ошибках, отфильтрованные по кодам и другим значимым для аналитики параметрам. Фактически каждый раздел (день) можно использовать для получения детальной краткосрочной аналитики. А при необходимости выполнения анализа, например, за месяц подсчитанные в каждом разделе данные за последующие 10 дней позволяют существенно ускорить процесс формирования отчета, опрашивая не 30 разделов, а три.

На данном этапе удалось значительно ускорить составление отчета об ошибках благодаря тому, что процесс агрегации данных происходит независимо, с использованием модулей HMSF. При хранении данных в Oracle за 160 мс можно сформировать отчет для 60 тыс. задач, а с применением нереляционного хранилища и модулей независимой агрегации за то же время можно получить информацию о 2,5 млн задач [4].

База научных знаний

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

Конечным результатом цепочки преобразований научных данных являются «золотые выборки», которые используются для физического анализа, получения физического результата и его публикации. Публикации могут быть основаны на анализе различных наборов данных или использовать данные, полученные путем различных преобразований. Вся метаинформация должна быть зафиксирована для обеспечения сравнения, повторяемости и воспроизводимости физических результатов.

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

Исторически методы хранения и управления данными реализуются специализированными программно-аппаратными системами, такими как PanDA Workload Management System в коллаборации ATLAS, работа которых сопровождается накоплением сопутствующей метаинформации, описывающей цикл работы с данными, а также каталогов публикаций, функционирующих отдельно. В этой связи работу большинства научных сообществ затрудняет отсутствие связности метаданных, описывающих цикл обработки данных, и метаданных представления жизненного цикла научного исследования в целом, включая аннотирование, индексацию и публикацию результатов. Требуется обеспечить агрегацию всех источников информации, импортируя результаты в хранилище без строгой схемы данных. Иначе говоря, нужна динамическая интеллектуальная база научных знаний, обладающая собственным визуальным интерфейсом взаимодействия с пользователем.

На рис. 1 показан пример взаимодействия различных систем хранения метаданных в инфраструктуре ATLAS. Базы данных DEFT (сведения о вычислительных задачах) и JEDI (хранилище метаинформации о заданиях) косвенно связаны между собой через программные интерфейсы. Используемая в ЦЕРН коммерческая система отслеживания ошибок JIRA компании Atlassian Software Systems, а также разработанный специально для коллаборации агрегатор баз данных AMI (ATLAS Metadata Interface), применяемый для поиска наборов данных по различным параметрам (название эксперимента, начальные условия, тип файлов и др.), имеют API для связи с пользователями и внешними приложениями. Программа Rucio DDM обеспечивает формирование наборов научных данных из файлов, объединение данных в контейнеры и управление распределением и репликацией в грид. Каждая вычислительная задача обращается за файлами через Rucio API. Кроме того, в коллаборации существуют независимые источники метаданных, получаемых от сервисов (Glance Project) поиска научных публикаций эксперимента ATLAS и всех документальных информационных материалов (CERN Document Server), а также от открытых средств поиска в системе документирования и аннотирования для членов коллаборации — CERN Twiki.

 

Рис. 1. Источники метаданных в ATLAS
Рис. 1. Источники метаданных в ATLAS

 

Платформа Data Knowledge Catalog (DKC), разрабатываемая для ATLAS, предназначена для регистрации и интеграции всей метаинформации, и сейчас идет разработка прототипов такой базы знаний на основе технологий нереляционных СУБД. На рис. 2 приведена схема архитектуры прототипа, разрабатываемого в НИЦ «Курчатовский институт» на базе Cassandra и Spark. Для всей совокупности первичных источников метаинформации определяются параметры группировки и фильтрации данных. Для каждого параметра реализуется конвейер-обработчик, содержащий сервисы экспорта (включающие проверку целостности), агрегации и импорта данных в таблицы Cassandra. Структура каждой нереляционной таблицы имплементирует определенную группировку данных. Для получения метаданных, агрегированных по нескольким параметрам, используется Apache Spark: с его помощью таблицы Cassandra преобразуются в распределенные наборы данных, над которыми можно выполнять операции MapReduce, фильтрации, определения уникальных элементов в наборе данных, объединения/пересечения, картезианского произведения и др.

Рис. 2. Архитектура Data Knowledge Catalog
Рис. 2. Архитектура Data Knowledge Catalog

 

В DKC имеется веб-интерфейс, предоставляющий сервисы визуального отображения агрегированных данных в виде таблиц, графиков, диаграмм и других объектов. Для каждого варианта использования DKC будет реализован API, позволяющий получать данные в универсальном формате JSON.

Поскольку пока нет единого мнения относительно выбора нереляционных технологий для хранения данных экзабайтного масштаба, в Томском политехническом университете создается еще один прототип DKC, построенный на связке HBase, Hadoop и Lucene (свободная библиотека для высокоскоростного полнотекстового поиска).

***

Интерес к нереляционным и гибридным системам хранения информации обусловлен тем, что строгие гарантии целостности и непротиворечивости данных, предоставляемые реляционными СУБД, не критичны при обработке огромных объемов данных, поэтому в ряде случаев можно использовать различные технологии, например: гибридные хранилища, объединяющие функциональность реляционных и нереляционных баз; базы NoSQL (HBase, MongoDB, Cassandra и др.) со схемой данных, адаптируемой под конкретные задачи; связки нереляционных хранилищ данных с системами распределенной обработки данных (Apache Spark, Hadoop); системы индексирования и полнотекстового поиска (Lucene, ElasticSearch). Созданный в НИЦ «Курчатовский Институт» и Брукхейвенской национальной лаборатории прототип гибридного хранилища метаданных подтвердил целесообразность использования гибридных технологий при построении хранилищ для масштабных научных экспериментов.

Литература

  1. The ATLAS Experiment at the CERN Large Hadron Collider. The ATLAS Collaboration (G. Aad et al.). JINST 3 S08003 doi: 10.1088/1748-0221/3/08/S08003 (2008).
  2. Сергей Кузнецов, Андрей Посконин. Возможно ли сотрудничество SQL и NoSQL? // Открытые системы.СУБД. — 2013. — № 9. — С. 38–41. URL: http://www.osp.ru/os/2013/09/13038285 (дата обращения: 18.12.2015).
  3. Evolution of the ATLAS PanDA workload management system for exascale computational science By ATLAS Collaboration (K.De, A.Klimentov, T.Maeno et al.). 10.1088/1742-6596/513/3/032062. J.Phys.Conf.Ser. 513 (2014) 032062.
  4. Grigorieva M., Golosova M., Klimentov A. et al. The development of hybrid metadata storage for PanDA Workload Management System // XXV Symposium on Nuclear Electronics and Computing — NEC'2015, Будва, Черногория. URL: https://indico-new.jinr.ru/getFile.py/access?contribId=33&sessionId=10&resId=0&materialId=slides&confId=60 (дата обращения: 18.12.2015).

Мария Григорьева (grigorieva_ma@nrcki.ru), Марина Голосова (golosova.marina@gmail.com), Евгений Рябинкин (rea@grid.kiae.ru) — НИЦ «Курчатовский Институт»; Алексей Климентов (alexei.klimentov@cern.ch) — Брукхейвенская национальная лаборатория, НИЦ «Курчатовский Институт» (Москва). Статья подготовлена на основе материалов доклада, представленного на VI Московском суперкомпьютерном форуме (МСКФ-2015, грант РФФИ 15-07-20824-г).