Implémentation de SIAv2 sur le Data Butler de l'Observatoire Rubin

Informations de base

• ID de l'article: 2501.00544
• Titre: Implementing SIAv2 Over Rubin Observatory's Data Butler
• Auteurs: Tim Jenness, Stelios Voutsinas, Gregory P. Dubois-Felsmann, Andrei Salnikov
• Classification: astro-ph.IM (Astrophysique - Instruments et Méthodes)
• Date de publication: 31 décembre 2024
• Lien de l'article: https://arxiv.org/abs/2501.00544

Résumé

Le protocole IVOA Simple Image Access version 2 (SIAv2) définit une méthode simple pour fournir à la communauté l'accès aux collections de données. À l'Observatoire Vera C. Rubin, nous implémentons actuellement l'accès aux données ObsTAP via l'exportation ou la vue ObsCore du référentiel Data Butler. Cependant, cette approche présente certaines contraintes de déploiement, notamment la nécessité d'un support pgsphere et la compatibilité avec l'implémentation TAP du CADC. Par conséquent, nous avons décidé d'explorer la possibilité de fournir un service SIAv2 communiquant directement avec le Data Butler. Cet article décrit nos motivations, notre stratégie d'implémentation, l'état actuel du déploiement, ainsi que certains problèmes d'inadéquation des métadonnées entre le modèle de données Butler et SIAv2.

Contexte de recherche et motivations

Contexte du problème

Le système Data Butler de l'Observatoire Rubin se compose d'un registre de métadonnées et d'un stockage de données fichiers, le registre contenant suffisamment d'informations pour construire des enregistrements ObsCore. Deux approches ont été précédemment utilisées pour fournir la table ObsCore :

1. Exporter les enregistrements en fichiers CSV ou Parquet et les charger dans une base de données statique
2. Utiliser des crochets de backend de registre pour fournir une synchronisation en temps réel vers la table ObsCore

Limitations des approches existantes

1. Méthode d'exportation statique: Appropriée pour les publications de données formelles et intégrable dans la base de données Qserv haute performance, mais inadaptée aux ensembles de données dynamiques tels que les produits quotidiens
2. Méthode ObsCore en temps réel: Nécessite un environnement de déploiement supportant pgsphere et exige une reconstruction de la table entière lors de modifications de configuration

Motivations de la recherche

Ces limitations ont incité l'équipe de recherche à chercher une couche de requête plus simple mais standardisée, basée directement sur le système Butler. Le protocole SIAv2 de l'IVOA s'est avéré être un choix évident car :

• L'interface directe avec Butler offre une plus grande flexibilité
• Les modifications de configuration ne nécessitent qu'un simple redémarrage du service
• Peut fonctionner immédiatement avec n'importe quel référentiel Butler

Contributions principales

1. Conception et implémentation d'une interface directe SIAv2 vers Butler: Contournement de la couche intermédiaire de table ObsCore traditionnelle
2. Développement d'une architecture en couches: Séparation de la couche de service du traitement des requêtes SIAv2, améliorant la testabilité
3. Création de la bibliothèque dax_obscore: Fourniture d'une interface en ligne de commande, facilitant l'apprentissage et l'expérimentation des utilisateurs
4. Déploiement d'un service prêt pour la production: Déployé sur la plateforme scientifique Rubin et disponible pour le débogage des données
5. Identification et analyse des problèmes d'inadéquation des modèles de données: Fourniture d'une feuille de route claire pour les améliorations futures

Détails de la méthodologie

Définition de la tâche

Mapper directement les requêtes du protocole IVOA SIAv2 au système de requêtes du Data Butler Rubin, en implémentant une interface d'accès aux données astronomiques standardisée, tout en évitant les contraintes de déploiement de la méthode traditionnelle de table ObsCore.

Architecture du système

HTTP GET → Nginx → Service SIAv2 → dax_obscore → Référentiel Butler
sia/dp02/query?POS=..     ↓              ↓            ↓
                    Traitement des    Requête      Résultats
                    requêtes Butler   Butler       ↓
                         ↓              ↓            ↓
                    VOTable ObsCore ← Résultats ← DatasetRefs

Conception des composants principaux

1. Couche de service SIAv2
   • Développée en Python et FastAPI
   • Basée sur la plateforme de développement interne standard Rubin Phalanx
   • Fourniture d'une couche d'authentification standard et de capacités de déploiement
   • Traitement des paramètres SIAv2 bruts et encapsulation des résultats retournés
2. Bibliothèque dax_obscore
   • Analyse des paramètres SIAv2
   • Conversion des paramètres en requêtes Butler
   • Exécution des requêtes et retour de résultats standardisés
   • Génération de sortie au format VOTable compatible avec Astropy
   • Utilisation du modèle de données Felis pour définir la structure des tables et assurer la cohérence
3. Compatibilité de l'interface Butler
   • Support transparent du Butler "direct" natif et du nouveau Butler distant client/serveur
   • Exploitation du support natif des requêtes de région et de temps de Butler

Points d'innovation technique

1. Avantages de la conception en couches
   • Séparation de la couche de service du traitement des requêtes, améliorant la testabilité
   • dax_obscore peut être installé et utilisé indépendamment
   • Support du développement et de la maintenance parallèles
2. Accès direct à Butler
   • Contournement de la couche intermédiaire de table ObsCore
   • Réduction des dépendances de déploiement (pas besoin de pgsphere)
   • Réponse plus rapide aux modifications de configuration
3. Sortie standardisée
   • Utilisation du modèle de données Felis pour assurer la cohérence des résultats
   • Format VOTable conforme aux normes IVOA
   • Support de l'ensemble standard des paramètres SIAv2

Configuration expérimentale

Paramètres de requête supportés

Le package dax_obscore supporte actuellement les paramètres de requête SIAv2 suivants :

• MAXREC: Limite du nombre maximum d'enregistrements
• INSTRUMENT: Filtrage par instrument
• POS: Requête de position/région
• TIME: Requête de plage temporelle
• BAND: Filtrage par bande
• EXPTIME: Temps d'exposition
• CALIB: Type d'étalonnage

Paramètres à supporter prochainement

• ID: Requête par identifiant
• TARGET: Objet cible
• FACILITY: Nom de l'installation (prévoyant l'utilisation de « Rubin:Simonyi » et « Rubin:1.2m »)
• COLLECTION: Collection de données

Environnement de déploiement

• Déploiement sur la plateforme scientifique Rubin
• Disponible pour l'accès aux données de débogage
• Support de l'outil en ligne de commande installable via PyPI

Résultats expérimentaux

État actuel du déploiement

1. Disponibilité du service: Déploiement réussi et utilisation active sur la plateforme scientifique Rubin
2. Vérification des fonctionnalités: Les fonctionnalités de requête des paramètres SIAv2 principaux fonctionnent correctement
3. Compatibilité: Support simultané des modes d'accès Butler direct et Butler distant
4. Outils utilisateur: Interface en ligne de commande fournie pour l'expérimentation et l'apprentissage locaux

Avantages de performance

1. Déploiement simplifié: Pas de dépendance pgsphere
2. Configuration flexible: Les modifications ne nécessitent qu'un redémarrage du service
3. Disponibilité immédiate: Peut fonctionner immédiatement avec n'importe quel référentiel Butler

Travaux connexes

Protocoles standards IVOA

• Protocole SIAv2: Norme recommandée IVOA définie par Dowler et al. en 2015
• Service ObsTAP: Protocole d'accès aux tables basé sur ObsCore, standardisé par Louys et al. en 2017

Pile technologique de l'Observatoire Rubin

• Système Data Butler: Système de gestion des données développé par Jenness et al. en 2022
• Base de données Qserv: Base de données distribuée haute performance développée par Mueller et al. en 2023
• Butler distant: Architecture client/serveur développée par Jenness et al. en 2024

Conclusions et discussion

Conclusions principales

1. Faisabilité de l'implémentation: L'implémentation de SIAv2 au-dessus du Data Butler est un processus relativement simple
2. Avantages architecturaux: La stratégie de développement en couches permet le développement parallèle et fournit des outils en ligne de commande supplémentaires
3. Succès du déploiement: Le service a été déployé avec succès et est disponible pour l'environnement de production

Problèmes d'inadéquation des modèles de données

1. Informations d'instrument manquantes pour les piles coaddées

• Problème: Les piles coaddées (co-adds) dans le registre Butler n'ont pas d'informations d'instrument associées
• Impact: Impossible de distinguer les sources de données dans les référentiels contenant des données LATISS et LSSTCam
• Solution: Détermination future des instruments des ensembles de données originaux via un suivi complet de la provenance

2. Temps d'exposition des piles coaddées

• Problème: Le temps d'exposition médian des piles coaddées est une quantité dérivée, inconnue lors de la définition de l'espace de coordonnées Butler
• Solution: Prévision du support du stockage des métadonnées dérivées dans la feuille de route de développement future

3. Date d'observation des piles coaddées

• Problème: Les piles coaddées perdent les informations de date des observations individuelles
• Solution: Possibilité de déduire les plages de dates après l'implémentation future du système de provenance Butler

4. Normalisation des types de données

• Problème: Les types de données Butler (tels que visit_image, difference_image) n'ont pas de méthode de requête standardisée dans SIAv2
• Solution: Considération de l'ajout d'un paramètre de requête d'extension DPSUBTYPE, utilisant possiblement le préfixe lsst

Orientations futures

1. Support des métadonnées dérivées: Implémentation du support de requête pour les métadonnées calculées
2. Système de provenance complet: Résolution des problèmes de métadonnées manquantes des piles coaddées via les informations de provenance
3. Support de paramètres étendus: Achèvement de l'implémentation des paramètres ID, TARGET, FACILITY, COLLECTION
4. Extensions personnalisées: Implémentation de paramètres de requête spécifiques à Rubin tels que DPSUBTYPE

Évaluation approfondie

Points forts

1. Conception architecturale excellente
   • La conception en couches améliore la maintenabilité et la testabilité du système
   • L'interface Butler directe évite la complexité de la couche intermédiaire
   • Support de multiples modes de déploiement Butler
2. Valeur pratique élevée
   • Résolution des problèmes de déploiement concrets (dépendance pgsphere, flexibilité de configuration)
   • Fourniture d'une interface d'accès aux données standardisée
   • L'outil en ligne de commande augmente l'utilisabilité du système
3. Compatibilité avec les normes
   • Respect strict de la norme IVOA SIAv2
   • Sortie au format VOTable standard
   • Compatibilité avec l'écosystème existant d'accès aux données astronomiques

Limitations

1. Limitations du modèle de données
   • Plusieurs problèmes importants d'inadéquation des métadonnées restent non résolus
   • Les capacités de requête des piles coaddées sont limitées
   • Nécessite un développement ultérieur du système Butler
2. Complétude des fonctionnalités
   • Certains paramètres SIAv2 ne sont pas encore implémentés
   • Les extensions personnalisées sont encore en phase de planification
   • Le support des requêtes complexes peut être limité
3. Profondeur de la documentation
   • Absence de données de référence de performance
   • Discussion insuffisante de la gestion des erreurs et des cas limites
   • Analyse comparative détaillée limitée avec d'autres systèmes

Impact

1. Contribution à la gestion des données astronomiques
   • Fourniture d'un cas pratique d'accès aux données standardisé pour les grands projets de relevé astronomique
   • Démonstration de la façon d'implémenter des protocoles traditionnels sur des systèmes modernes de gestion des données
   • Fourniture d'une référence pour des implémentations similaires dans d'autres observatoires
2. Valeur de promotion technologique
   • L'implémentation open source (package dax_obscore) facilite l'adoption et l'amélioration par la communauté
   • La conception architecturale en couches peut être appliquée à d'autres projets similaires
   • L'outil en ligne de commande réduit les coûts d'apprentissage des utilisateurs

Scénarios d'application

1. Grands projets de relevé astronomique: Projets nécessitant une interface d'accès aux données standardisée
2. Centres de données et observatoires: Institutions souhaitant fournir des services compatibles IVOA
3. Communauté de recherche: Chercheurs ayant besoin d'un accès programmatique aux données astronomiques
4. Fins éducatives: Environnement d'apprentissage et d'expérimentation du protocole SIAv2

Références bibliographiques

Cet article cite les références clés suivantes :

1. Dowler, P., et al. (2015). IVOA Simple Image Access Version 2.0 - Définition de la norme du protocole SIAv2
2. Jenness, T., et al. (2022). Article fondamental sur l'architecture du système Rubin Data Butler
3. Louys, M., et al. (2017). Modèle de données ObsCore et norme d'implémentation TAP
4. Salnikov, A. (2022). Note technique sur ObsCore en tant que vue du registre Butler

Résumé: Cet article présente un cas d'étude réussi de pratique d'ingénierie, résolvant les problèmes de déploiement pratiques tout en maintenant la compatibilité avec les normes internationales. Bien que certains défis d'inadéquation des modèles de données subsistent, l'implémentation globale fournit une référence et des outils précieux pour le domaine de la gestion des données astronomiques.