Amin Mesmoudi & Mohand-Saïd Hacid Traitement parallèle et déclaratif de requêtes sur des masses de données issues d'observations astronomiques

Contexte Prises d’image toutes les 15 s, 1 visite/ 3 jours 10 ans, 60 Peta-octets de données 2

Les données LSST TableTaille#enregistrements#attributs Object109 To38 B470 Moving Object5 Go6 M100 Source3.6 Po5 T125 Forced Source1.1 Po32 T7 Difference Image Source 71 To200 B65 CCD Exposure0.6 To17 B45 3

Accès aux données : les besoins LSST Accès Requêtes déclaratives (SQL) Possibilité de définir des fonctions ad hoc (UDF) areaspec_boxangSep < dist Exemple: areaspec_box, angSep < dist 500,000 requêtes/jour fluxToAbMag SELECT objectId, taiMidPoint, fluxToAbMag(psfMag) USINGJOINUSING FROM Source JOIN Object USING(objectId) JOIN Filter USING(filterId) ANDAND WHERE areaSpec_box(:raMin, :declMin, :raMax, :declMax) AND filterName = 'u' AND variability BETWEEN :varMin AND :varMax ASC ORDER BY objectId, taiMidPoint ASC fluxToAbMag SELECT objectId, taiMidPoint, fluxToAbMag(psfMag) USINGJOINUSING FROM Source JOIN Object USING(objectId) JOIN Filter USING(filterId) ANDAND WHERE areaSpec_box(:raMin, :declMin, :raMax, :declMax) AND filterName = 'u' AND variability BETWEEN :varMin AND :varMax ASC ORDER BY objectId, taiMidPoint ASC 4

Objectifs généraux Passage à l’échelle 10 PB Proposer une plateforme parallèle capable de stocker +10 PB de données Open Source Shared-Nothing Performances secondes jours Pouvoir évaluer aussi bien des requêtes simples (quelques secondes de calcul) que des requêtes complexes (des jours de calcul) 5

Nos travaux Evaluation des capacités des systèmes existants sur des échantillons de données LSST Campagne d’évaluation des systèmes MapReduce et supportant SQL F. Toumani En collaboration avec F. Toumani Proposition de nouvelles techniques Stockage Partitionnement Evaluation parallèle des requêtes F. ToumaniE. CoqueryM. Haddad En collaboration avec F. Toumani, E. Coquery et M. Haddad 6

Evaluation des systèmes existants Configurations différentes Indexation Données Indexées vs. non indexées 5 indexes Données 250 GO vs. 500 GO vs. 1 TO vs. 2 TO Partitionnement Partitionnement lié vs. non lié aux jeux de requêtes Clusters 25 vs. 50 vs. Hive vs. HadoopDB Requêtes: Q1-Q11 Temps de chargement Temps d’exécution 7

Synthèse – expérimentations (1/2) Requête Job 1 Map Reduce Job 2 Map Reduce Job n Map Reduce Application de la fonction Map Application de la fonction Reduce Transfert réseau Ecriture des données dans le HDFS Lecture des données a partir du HDFS Accès aux données Phase 1: pousser les traitements vers les données Phase 2: pousser les données vers les traitements 8

Synthèse – expérimentations (2/2) EtapeComparaisonExceptions Sans Indexes: HadoopDB * Effet de la compression et du buffer Temps d’accès avec JDBC domine le temps d’accès Avec Indexes: Hive * Indexation globale HadoopDB *Buffer et compression (Moins de données) Hive * Utilisation de plusieurs machines Partitionnement personnalisé Hive * Utilisation de plusieurs machines Partitionnement personnalisé Les sélections avec deux attributs Accès aux données Application de la fonction Map Transfert réseau Application de la fonction Reduce 9

Chargement de données Partitionnement personnalisé de données - nécessaire pour optimiser l'évaluation de certains types de requêtes Les outils existants ne répondent que partiellement aux exigences LSST d’accès aux données Plusieurs techniques d'optimisation (indexation, partitionnement, utilisation de tampons,...) devraient être revisitées SGBD doit être en mesure de s'adapter aux requêtes Enseignements tirés des expérimentations 10

Fonctionnalités requises L'accès aux données avec compression et indexation Techniques de partitionnement flexibles qui tiennent compte des caractéristiques des données Evaluation des requêtes Parallélisation Accès au réseau uniquement si nécessaire Tirer profit du partitionnement pour éviter certains transferts de données inutiles SGBD – adaptation aux jeux de requêtes en changeant l'emplacement des données 11

Stockage SPO et OPS B+Tree pour chaque combinaison– recherche de triplets: log(n) Hybride: ligne et colonne Plusieurs combinaisons peuvent être utilisées x1 l1 z1 n1 k1 a b c d e y1 z2 x2 y2 a b c x1ay1 x1bz1 x1cl1 x2ay2 x2bz2 x2cl1 y1dk1 y1en1 SPO k1dY1 l1cx1 l1cx2 n1ey1 ax1 y2ax2 z1bx1 z2bx2 OPS ?x k1 ?z a b 12

Trouver le meilleur plan Ensemble ordonné d’étoiles [SQ1, SQ2,…, SQn] forward et backward stars ‘’Forward stars’’ ?x, ?y, ?l ‘’Backward stars’’ ?y, ?z, C1, ?l, ?n, ?m, C2 ?x ?n ?z C2 ?m a b c d e ?y C1 ?l f k 13 Classe de complexité: NP-Hard preuve: ’’Vertex Cover’’

Partitionnement des données Graphe Partitionnement métiers Exemple: Découpage spatial (RA,Decl) Worker 2 P5 P6 P7 P8 Worker 1 P1 P2 P3 P4 Worker 4 P13 P14 P15 P16 Worker 3 P9 P10 P11 P12 Stratégies Fragmentation horizontale (spatiale, hachage,…) Fragmentation horizontale dérivée 14

Evaluation de requêtes avec BSP SQ1SQ2 SQ3 SQ4 SQ5 S1 S2 S3 S4 S5 Réseau Sync 15

Fonctionnalités requises L'accès aux données avec compression et indexation Techniques de partitionnement flexibles qui tiennent compte des caractéristiques des données Evaluation des requêtes Parallélisation Accès au réseau uniquement si nécessaire Tirer profit du partitionnement pour éviter certains transferts de données inutiles SGBD – adaptation aux jeux de requêtes en changeant l'emplacement des données 16

Réaffectation des partitions P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 Analyser les coûts de transferts réseaux liés à un jeux de requêtes Affectation des partitions Modification de l'affectation de la partition sans modifier la structure physique de la partition P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 17

Approches 18

Implémentation et résultats préliminaires (1/2) Implémentation MapReduce Partitionner: MapReduce - Hadoop 2.6 (5k lignes de code) Stockage: RDF-3X, C++ (3k lignes de code) Moteur d’évaluation : Java et JNI (20k lignes de code) Premières expérimentations Données: 250 GO Requêtes: 7 requêtes avec SELECTION, PROJECTION et JOINTURE Q1-Q4 et Q7-Q9 Plateforme de calcul : 25 machines Chaque machine: 350 GO d’espace disque et 8 GO de RAM 19

Implémentation et résultats préliminaires (2/2) Temps de chargement: ~24 heures vs. 9 heures (HadoopDB) vs. 3 heures (Hive) Partitionnement (80 %) et chargement de données (20 %) 20

Travaux en cours Optimisation du partitionnement 24 heures pour 250 GO et pour 1 PO ? YARN pourrait représenter les alternatives Intégrer les fonctions ad hoc (ex. jointure par distance) Campagne d’évaluation en comparant notre système avec Hive et HadoopDB sur d’autres jeux de données avec les systèmes de gestion de triplets Etudier expérimentalement les heuristiques proposées en utilisant d’autres jeux de données (ex. SDSS) 21

Merci 22

Conclusion Une campagne d’évaluation permettant d’analyser les capacités des systèmes SQL-on-MapReduce à gérer les données LSST Proposition de quelques techniques permettant d’accélérer l’évaluation des requêtes Stockage graphe Evaluation parallèle avec BSP Partitionnement guidé par le schéma performances satisfaisantes Les premiers résultats de performances de notre approche semblent très satisfaisantes en les comparant avec ceux obtenus pour les systèmes basés sur le modèle MapReduce. Etude de la complexité de deux problèmes d’optimisation 23