ATLAS et CMS, expériences phare au CERN, ont lancé un projet commun pour le développement d’une infrastructure de gestion de données de type Conditions de nouvelle génération. Au cœur de cette infrastructure, la « Conditions DB » est une base de données qui enregistre en continu l’état du détecteur et de tous les appareillages de l’expérience (déclenchement, alignement…) pendant la prise de données. Ces Conditions Data doivent ensuite pouvoir être lues de façon très efficace et en parallèle par les dizaines de milliers de jobs simultanés de la phase de reconstruction des évènements, puis des programmes d’analyse un peu partout dans le monde.

Les expériences LHC ont terminé en 2013 la première phase de prise de données (Run1). Celle-ci a permis entre autres la découverte du boson de Higgs. Pour obtenir ce résultat, les expériences ATLAS et CMS ont analysé dans un environnement de calcul distribué des centaines de Pétaoctets de données de Physique (ou Event Data). En complément, d’autres données, que nous appelons Conditions Data (faute de trouver un terme adéquat en français), ont été nécessaires à la reconstruction et l’analyse des évènements de physique. Celles-ci caractérisent les conditions dans lesquelles les Event Data ont été enregistrées. A la différence des Event Data, qui contiennent la réponse des détecteurs au passage des particules, les Conditions Data contiennent une grande variété d’informations provenant, par exemple : des calibrations des détecteurs, du contrôle des alignements, des mesures liées au faisceau du LHC telles que la luminosité, ou encore de certaines configurations utilisées par les différents détecteurs au cours de la prise de données. Dans le cadre de l’expérience ATLAS, cela représente environ 1,5 Téraoctet de données accumulées pendant le Run1.

Aujourd’hui, les systèmes de gestion des Conditions Data d’ATLAS et CMS diffèrent : le système adopté par ATLAS est basé sur COOL, la solution développée au CERN dans le cadre de LCG [1], et celui de CMS exclusivement sur la couche logicielle C++ CORAL (COmmon Relational Abstraction Layer). Mais les deux expériences font appel à la même solution de cache Frontier/squid pour améliorer les performances d’accès à la base de données, et utilisent des concepts très proches pour la définition des métadonnées. Ceci a permis aux équipes chargées de la mise en œuvre de ces systèmes d’entamer une réflexion sur une approche commune en vue du Run3 [2], qui puisse éventuellement être réutilisée dans le cadre d’autres expériences de physique. Pour l’instant, les équipes concernées par ce développement sont petites. En France, l’Irfu au CEA et le LAL à Orsay sont impliqués.

La définition de la nouvelle architecture de gestion des Conditions Data s’articule autour de trois éléments :

• La structure de la base de données : Il s’agit de bien définir les données descriptives (ou métadonnées) des quantités que l’on veut enregistrer, pour garantir la robustesse de la gestion de l’historique et des versions de Conditions Data.
• Le logiciel d’interaction avec la base de données : Pour isoler les clients de la complexité liée à la couche de persistance, nous avons décidé pour ce projet de regrouper toutes les fonctionnalités de gestion des Conditions Data au sein d’un serveur intermédiaire (suivant un classique modèle multi-tier, comme dans la plupart des services WEB). Ce serveur expose une partie de ces fonctionnalités à travers des services WEB de type REST.
• Les librairies clientes : celles-ci doivent tout simplement permettre d’interagir avec le middle-tier, en utilisant le langage de son choix (Python, C++, ...). Parmi ces clients, nous prévoyons aussi le développement d’une interface WEB générique pour la navigation dans les métadonnées (et d’un client Javascript).

Le modèle de données se décline dans un nombre très limité de tables (cf. Figure1), qui contiennent tous les éléments nécessaires aux data-flows impliquant les Conditions Data, et aux différents cas d’utilisation : traitement online, première reconstruction rapide au CERN, campagne de reprocessing etc. Il est important de souligner que les données utiles sont agrégées, sérialisées et enregistrées dans la base sous forme de BLOB (Binary Large Object), ensemble de données au format binaire sauvegardé comme une seule entité, ce qui signifie que l’infrastructure proposée ne peut effectuer aucune requête sur le contenu des Conditions Data proprement dites. Ainsi, la base de données est agnostique par rapport au contenu des Conditions Data, et même au format binaire utilisé par le client. Ceci permet de conserver une structure de base de données simple, en dépit de la variété des informations enregistrées et surtout de la complexité et de l’évolution des besoins de l’expérience. Ce choix rend également possible l’exploration de nouvelles solutions basées sur des technologies NoSQL par exemple.

Figure 1. Structure des données pour la nouvelle architecture

Les concepts principaux utilisés pour caractériser les Conditions Data sont les suivants :

• Payload : Ce terme représente la donnée utile, à un moment précis (par exemple un paramètre de correction pour la géométrie du détecteur à muons). Chaque Payload est associé à une information en temps ou à un run number.
• Iov (Interval Of Validity) : Une caractéristique des Conditions data est de varier (lentement) dans le temps. L’Iov représente l’intervalle de validité pour un Payload spécifique.
• Tag : Il regroupe de manière univoque l’historique d’une calibration, c’est-à-dire l’ensemble des Iovs pour des grandeurs (efficacités, corrections ou autres) qui résultent d’une même version d’un algorithme de calcul.
• Global Tag : Il permet d’identifier un ensemble cohérent de Tags réunissant toutes les données utiles (Payload) pour analyser les Event Data.

La Figure 2 montre les composants principaux de la nouvelle architecture. L’approche multi-tier constitue un élément fondamental pour l’environnement du calcul distribué dans lequel ces données sont utilisées. La mise en place d’une interface REST est aussi très importante, à la fois pour l’aspect multilangage qu’elle supporte de manière naturelle, mais aussi pour la possibilité d’utiliser des systèmes de cache de type WEB éprouvés, provenant de la communauté Open Source (comme Squid).

La première implémentation de l’application côté serveur utilise des technologies de type Java, avec l’utilisation des standards promus par les spécifications JEE notamment en termes de services REST (JAX-RS) ainsi que de persistance (JPA). Ceci garantit par exemple la portabilité de l’implémentation sur différentes technologies de back-end (comme des bases de données non relationnelles). Les données échangées entre les clients et le serveur sont de simples structures JSON ou XML.

Figure 2. Prototype pour la nouvelle architecture de gestion des Conditions Data

En conclusion, ce projet se propose d’explorer une solution simple, performante et générique pour la gestion des Conditions Data d’une expérience de physique. Les choix effectués en termes d’architecture et de modèle de données prennent en compte l’expérience accumulée dans ce domaine par ATLAS et CMS au cours des Run1 et 2 du LHC. Le projet suscite un vif intérêt au sein de la communauté HEP, et il est répertorié (parmi d’autres qui explorent des solutions différentes pour le même problème) dans les pages de la HSF (Hep Software Foundation).

Andrea FORMICA (IRFU)