1
From Big Data to Big Science
Pierre-Marie Brunet,
Responsable du pôle HPC, CNES DSI/DV/AR

2
 Présentation du pôle HPC
 Introduction au BigProcessing
 Trois perspectives selon trois projets
 Interopérabilité entre centres de calcul

3
Deux grandes classes de calcul
 Simulation numérique (HPC)
 Recherche, phase amont des projets
 Optimisation algorithmique très poussée:
“proche du matériel
 Parallélisme à grain fin
 Traitement de données (HTC)
 Phase aval, traitement des données générées
par capteurs
 Données brutes des capteurs => données
intelligibles par scientifiques
 Parallélisme gros grain
Pôle calcul intensif du CNES

4
Datacenter

5
Infrastructure primaire

6
 Présentation du pôle HPC
 Introduction au BigProcessing
 Trois perspectives selon trois projets
 Interopérabilité entre centres de calcul

7
HPC et BigData

8
Présentation DCT
Contexte du Processing spatial
Le segment spatial
Le satellite
Les instruments
La plateforme / Les servitudes
Stations TM/TC Stations TMCU
Le segment sol
Segment sol de MissionSegment sol de
Commande Contrôle
Les utilisateurs
Le lanceur

9
Big Processing
Au cnes
Demain
Aujourd’hui
Hier

BigProcessing
Big problématiques
 Déplacement des données (acquisition / diffusion)
 Accès intelligent aux données (cataloguées/classées pour être utilisées)
 Exigences de distribution des données/traitements à l’échelle ESA
 Cacher la complexité croissante des centres de mission
 Offrir des interfaces de développement simples
 Application des politiques de sécurité publique (PPST, PSSIE)

 Présentation du pôle HPC
 Introduction au BigProcessing
 Trois perspectives selon trois projets
 Interopérabilité entre centres de calcul

12
GaiaEnjeux scientifiques
• Produire une cartographie
3D de notre proche galaxie
• Localisation de plus d’un
milliard d’objets avec une
précision inégalée
• Détermination des
paramètres
stellaires/astrophysiques
Focus sur les techniques de
développement

CRIP – 16/10/201313
Les chiffres:
- 10 chaines scientifiques
- 3Po de données
- 290 milliards d’entrée dans la
base de données
- Complexité des requêtes d’accès
- Plus de 1000 connexions
concurrentes à la base
Le développement:
- Language Java
- Pas de parallélisme (géré à haut niveau)
- Concept Façade
- Algorithmes scientifiques en boite noire
- Unification de l’invocation des modules
- Abstraction de l’accès aux données
L’architecture
- 6 datacenters impliqués
- Répartition statique des données
- Répartition statique des traitements

14
Etude technologique (2011-2012)
 Première architecture : données centralisées
» Stockage sur une baie SAN
» Accès concurrents à la BD PostgreSQL
» Traitements sur nœuds de calcul « classiques »
Architecture logicielle
point bloquant identifié
 Benchmark nouvelles technologies
» Performance
» Scalabilité de la solution
» Fiabilité (data safety)
» Impacts sur l’existant (software et hardware)
» Coût global
» Pérennité de la solution
» Exploitation de la solution

15
Hadoop & Cascading
Seconde architecture : données distribuées
 Hadoop :
 Batch execution framework : paradigme Map/Reduce (calcul parallèle gros grain)
 Système de fichier parallèle HDFS
 Avantages :
 Performance
 Scalabilité
 Ecosystème logiciel Hadoop
Calcul
Stockage
Rapprocher le calcul
des données

16
Hadoop & Cascading
Map/Reduce paradigm
UC BerkeleyX courses, Spark lectures

17
Cascading
 API Java pour les developpeurs au dessus de la couche Hadoop MapReduce
 Process Cascading sont traduits “à la volée” en tâches Map Reduce (5%
d’overhead constaté)
 Permet des opérations complexes (proches de SQL : join, group,…) sans
penser en MapReduce
Hadoop & Cascading

18
Exemple
Requête SQL
Requête M/R (15 étapes)
Requête Cascading (7 étapes)

19
1ère leçon : Ca marche ! Mais quelques pistes d’optimisation
 Hadoop v1 : problème intrinsèque de performance
» Synchronisation parallèle par… les I/O Mappers & Reducers fixes
 Passsage à Hadoop v2
» Meilleure utilisation du hardware (cœurs de calcul)
» Upgrade toujours délicat sur une plateforme de production
REX Gaia

20
1ère leçon : Ca marche ! Mais quelques pistes d’optimisation
 Quantité de logs difficilement exploitable (métier, middleware, système).
Résolution d’incident complexe.
REX Gaia
R&T Fouille de données (w/ Atos)

21
1ère leçon : Ca marche ! Mais quelques pistes d’optimisation
 Quantité de logs difficilement exploitable (métier, middleware, système).
Résolution d’incident complexe.
REX Gaia
R&T Fouille de données (w/ Atos)

22
1ère leçon : Ca marche ! Mais quelques pistes d’optimisation
 Quantité de logs difficilement exploitable (métier, middleware, système).
Résolution d’incident complexe.
REX Gaia
R&T Fouille de données (w/ Atos)

23
Si on repartait à zéro…
 Nouvelles approches BigProcessing : InMemory
REX Gaia 2015
UC BerkeleyX courses, Spark lectures UC BerkeleyX courses, Spark lectures

EUCLID
24
Cartographier la géométrie de l’Univers Sombre
L’expansion de l’univers accélère !
L’accélération de l’univers
est dûe à l’énergie sombre
Focus sur l’architecture
du centre de mission

25
Concepts clefs d’architecture
 « cluster de clusters » : pas de centralisation de datacenter
 Distribution des données et du calcul
 Déplacer les calculs et non les données
 Les codes de calcul doivent pouvoir être exécutés sur toutes les plateformes
 Séparation des métadonnées des données (base de métadonnée centralisée)
 Deux niveaux de parallélisation
 Bas niveau : sur les tuiles (ensemble minimal de données traitable couvrant une
portion de ciel donnée) constituant des catalogues d’objets
 Haut niveau : cross matching/correlation
EUCLID

Mission
Operations
Centre
External
Data
Providers
Science
Operations
Centre
Public
Data
Level 1
Data Files
Metadata
(prime)
SDC-NL
Raw EXT
Data
Data
Files
Metadata
(backup)
SDC-DE
Raw EXT
Data
Data
Files
SDC-CH
Data
Files
SDC-ES
Data
Files
SDC-US
Data
Files
SDC-UK
Data
Files
SDC-FI
Data
Files
SDC-FR
Data
Files
Raw EXT
Data (TBC)
Sky allocation through Coordinator
EUCLID
Architecture

DB
Euclid Archive
Metadata
Storage System
Euclid Archive
Orchestration,
Monitoring &
Control
Computing
Infrastructure for
Processing Tasks
Manage Processing Tasks:
fetch/enhance/ingest data
configure/submit tasks
SDC
File
s
Euclid Archive
Data Storage
System
Infrastructure Abstraction
Layer
CODEEN
Managing and
Deploying Software
other SDCSOC
EUCLID
Architecture

28
Plateforme d’Exploitation des Produits Sentinels :
• accès libre et gratuit aux données via portail web.
• capacité de traitement sur les données.
PEPS
Focus sur les technologies
de stockage

Eléments directeurs
 Infrastructure de stockage
hautement scalable
 Profil d’utilisation fonction de l’intérêt
(temps, localisation, etc.)
 Fort couplage avec cluster de calcul
Architecture informatique CNES

Besoin de technologie de stockage…
… du futur

31
Disques vs bandes
Disque Bande
Bande passante 150 Mo/s 350Mo/s
Latence 6ms 60s
Capacité 8To 10To
Evolution 20To * 120 To
Durée de vie (REX) 3-5 ans 10-20 ans
Coût ($/To) 30 - 50 12 - 20
Consommation (idle) 6-8W 0W

32
2 Po
6To480 x
Bases DB2
Core Server VFS Servers
2 x baies NetApp E5560
2 x baies NetApp E2724
DataMovers
Cache disque HPSS
Stockage bande
IBM TS4500
6 x Jaguar 5
14 Po
Méta données
HPSS
2 x Dell R730
vue filesystem
NFS
FTP
ou pFTP
Dell R730 Dell R730
10Gbe
10Gbe
10Gbe
SAS
SAS FC
Accès utilisateurs
10Gbe
10 Gbe
Staging
Migration

ForumHPC – CLS – 15/10/201533
2015

34
 Présentation du pôle HPC
 Introduction au BigProcessing
 Trois perspectives selon trois projets
 Interopérabilité entre centres de calcul

35
Interopérabilité
Objectifs
Exécuter un traitement sur « n’importe quel
centre de calcul » ou comment abstraire une
infrastructure de calcul parallèle…
Permettre aux développeurs de déposer des
traitements au plus proche de la donnée « sans
contrainte ».

36
Concepts clefs d’une plateforme fédérée
 Cacher la complexité !
Les scientifiques/développeurs doivent se concentrer sur les algorithmes
Notion de notebook pour les maquettages rapides
 Un seul portail pour accéder/télécharger/traiter les données
 Multi paradigmes (Spark, MPI, OpenMP, etc.)
 Interfaces génériques pour :
 rechercher et décrire la donnée
 lancer un traitement
 échanger des données entre centres de calcul
 exécuter des codes de calcul

37
Exploitation des Données Interopérables Multicentres
Euclid

38
Euclid
Bilbio :
- Wes. Felter, Alexandre. Ferreira, Ram. Rajamony and Juan. Rubio, “An Updated Performance Comparison of Virtual
Machines and Linux Containers” IBM Research Report, vol. 28, July, 2014
- MORABITO, Roberto, KJÄLLMAN, Jimmy, et KOMU, Miika. Hypervisors vs. Lightweight Virtualization: a Performance
Comparison.
Passer des applications aux containers applicatifs

39
Euclid
Performance container vs exécution native

40
Prototypage R&T multicentre
15/03/201640

41
results
15/03/201641

42
results
15/03/201642

43
results
15/03/201643

44 15/03/201644
Prototypage R&T multicentre

45 15/03/201645
Prototypage R&T multicentre

46 15/03/201646
Prototypage R&T multicentre

47 15/03/201647

48 15/03/201648

49 15/03/201649
Prototypage R&T multicentre

50
Results
15/03/201650

51
Exploitation des Données Interopérables Multicentres
Euclid
REX Prototype
 Fonctionnel mais pas industrialisable
 Les batch/schedulers HPC ont pris le train en marche
» PBSPro compatible Docker
 Proactive en tant que metascheduler

52
Cas d’utilisation « cluster de clusters »
Euclid
PBSPro
v13
Hadoop
Amazon,
Openstack,
etc.
Slurm
Chronos/
Mesos
Proactive
jobs

53
Conclusion
 Convergence du HPC et BigData
 Les données sont de moins en moins transportables,
besoin d’avoir des portails thématiques (visualisation,
traitement)
 Les algorithmes sont la vraie valeur ajoutée, besoin de
les mettre au centre des plateformes
 REX CNES : travailler en mémoire, distribuer
dynamiquement les calculs, considérer les stockages
hiérarchiques passé un certain seuil

54
Pour aller plus loin…
Contact :
jerome.gasperi@cnes.fr
pierre-marie.brunet@cnes.fr
R&T CNES
https://rt-theses.cnes.fr

Présentation générale du CNES – Janvier 201555
Merci pour votre attention