Entretien avec Michel Edwell, Ingénieur DBA à la direction des systèmes d'information de Météo-France

Conformément à sa mission de service public, MétéoFrance se trouve placé au cœur d’attentes majeures de la société, exprimées aussi bien par les concitoyens que les pouvoirs publics ou les acteurs économiques. Soucieuse de mettre au service des individus, des collectivités et des organismes publics ou privés une prévision qui se situe au meilleur de l’état de l’art, Météo-France développe - dans un souci constant d’intéropérabilité - des infrastructures informatiques qu’elle met à disposition des techniciens et scientifiques en charge d’effectuer les prévisions. Autant que les supercalculateurs, les bases de données jouent un rôle essentiel dans l’accomplissement de la mission de l’institution scientifique.


Dans le cadre de son activité, Météo-France collecte, intègre dans ses bases et effectue des requêtes de volumes importants de données. Quel type de bases utilisez-vous et quelle est l’infrastructure existante ?

Nous traitons majoritairement des données structurées, aussi la plupart de nos bases de données sont des bases SQL. Actuellement, l’infrastructure bases de données chez Météo-France est composée de plus de 100 serveurs PostgreSQL,10 serveurs Rack Oracle (3 clusters) pour une volumétrie de 80TB.

Ce parc est majoritairement composé d’instances du SGBDR open source PostgreSQL. Pouvez-vous revenir sur l’historique de la constitution de cette infrastructure et nous éclairer sur ces choix ?

Météo-France, dans le cadre de sa mission de service public, a commencé à utiliser le SGBDR open source PostgreSQL dès 2001. Des tests plus poussés ont été effectués en 2003-2004 pour valider la mise en production en 2005 et l’utilisation sur des systèmes critiques en 2006.
Le choix de PostgreSQL a été stratégique et motivé par plusieurs raisons, les plus importantes étant l’absence de coût de licence et le respect des standards, un prérequis essentiel dans notre secteur où l’interopérabilité (SQL) est le gage de l’amélioration des prévisions aux niveaux national et international.
La facilité d'installation, une excellente réactivité de la communauté, des fonctionnalités équivalentes à celles des SGBDR traditionnels et le pré-compilateur C ont également joué en faveur de PostgreSQL.
Suite à ce choix, certaines applications métier ont été migrées depuis Oracle. La plupart des nouvelles applications ont reposé dès le départ sur PostgreSQL.

D’autres pays/institutions utilisent-ils PGSQL pour des besoins similaires ? Cela facilite-t-il l’intéropérabilité et les échanges d’information au niveau international ?

À ma connaissance les services météorologiques au Canada et la NOAA, l'Agence américaine responsable de l'étude de l'océan et de l'atmosphère, utilisent pour partie au moins PostgreSQL dans le cadre de leurs activités.
L’une des spécificités du SGBDR open source est la facilité avec laquelle on peut lui conférer une capacité géographique. Il existe par exemple une extension de PostgreSQL (PostGIS) qui active la manipulation d'informations géographiques sous forme de géométries, conformément aux standards établis par l'Open Geospatial Consortium. Il permet à PostgreSQL d'être utilisé en tant que SGBDR spatial et d’être utilisé par les systèmes d'information géographique.
Ce type d’alignement technologique sur des standards peut faciliter l’intégration de données géo-référencées à d’autres services d’information géographique dans une logique d’interopérabilité. Cette logique fait d’ailleurs partie des attentes de la directive européenne INSPIRE. En s'appuyant sur les standards d'interopérabilité traitant de données géospatiales, le système permet une combinaison des informations géographiques et météorologiques, un aspect essentiel de notre métier. De manière plus générale, le respect des standards ouverts permet de réexploiter de manière simple des jeux de données pour une meilleure compréhension globale des événements thématiques ou pour la mise en œuvre de nouveaux projets.

PostgreSQL est-il en mesure d’absorber les volumétries requises par ce type d’usage ?

Tout à fait ! Nos bases sont capables d’intégrer des centaines de mégaoctets de données en quelques minutes et de manière extrêmement régulière pour effectuer un relevé de la situation au moment présent, et réaliser des prévisions dans l’heure (cf. le service en ligne “Va-t-il pleuvoir dans l’heure ?“) qui suit le calcul et jusqu’à 6 heures après la prévision. Nos systèmes sont en permanence en train d’ajuster et d’affiner la prévision en fonction des données qu’ils ingèrent.
La base absorbe chaque jour d’importantes quantités de données (plusieurs dizaines de Go) qui viennent s’ajouter aux données “historiques”.
La taille minimum de nos bases est de quelques gigaoctets. La plus grosse de nos bases sous PostgreSQL est proche de 10To. Une table non partitionnée sur l’une de nos bases compte plus d'un milliard de tuples (regroupement de valeurs sans nom, mais ordonnées, de types éventuellement différents).

En lien avec le contrat d'objectifs et de performance 2012-2016, de nouveaux super-calculateurs qui devraient délivrer une puissance de 5 pétaFLOPS en 2016 ont été implémentés. Ces équipements sont indispensables à la prévision numérique du temps, au traitement des données d’observation, au calcul de l’évolution des paramètres météorologiques et pour effectuer les recherches nécessaires à l’amélioration des modèles numériques de prévision. Pour alimenter ces super-calculateurs, un nouveau système a été mis en place en vue de faciliter l’intégration d’informations de toutes natures et l’interopérabilité des données. Il est prévu que les bases PostgreSQL absorbent de nouveaux volumes de données en rapport avec ces nouveaux systèmes.
Cette démarche visant à tirer profit des innovations technologiques améliore continuellement la qualité des prévisions numériques du temps réalisées par Météo-France. Aujourd’hui, les prévisions à 4 jours sont aussi fiables que les prévisions à 3 jours au milieu des années 2000 !
Cet afflux de nouveaux volumes de données risque-t-il de poser problème ?

Sur la partie matérielle, nous avons effectivement anticipé et commencé à mettre en œuvre les stratégies pour éviter une potentielle perte de performance.
Sur la partie logicielle nous nous félicitons de notre choix d’un SGBDR open source : avec ces nouvelles volumétries et sans option alternative, nous aurions probablement vu le prix des licences Oracle s’envoler.

Quels changements prévoyez-vous en matière de volumes de données ?

Les volumétries vont augmenter, sans aucun doute. Mais disposant d’une alternative aux bases de données coûteuses, nous maîtrisons cet aspect et envisageons l’avenir avec sérénité.
Cet aspect est d’autant plus important pour nous que Météo-France, conformément aux exigences de la directive européenne INSPIRE, continue d’innover. Dans le cadre de ses missions, Météo-France produit tout un ensemble de données publiques. Pour faciliter l’accès à ces dernières, un portail d’accès sur internet a été créé en 2010. Il est prévu de poursuivre les changements largement amorcés: le portail de services intégré fournit des services de recherche, de visualisation, de découverte, d’extraction spatio-temporelle et de téléchargement de données numériques et cartographiques géo-référencées. Certaines des données associées à ces services seront hébergées dans les bases PostgreSQL. Nous sommes confiants dans la capacité du SGBDR à absorber et traiter ces nouveaux volumes d’autant que la future mouture (9.5) promet des innovations en matière de traitement des données massives.