Aller à la navigation

Blog

Retour à l’accueil

23 Fév 2018

Retour d’expérience – Le Big Data, clé de l’implémentation des nouvelles réglementations bancaires

Pensées pour stabiliser le système financier, les récentes évolutions réglementaires (FRTB, MIFID II, etc..) font peser d’énormes contraintes sur les établissements financiers. Pour y répondre, ils ont été contraints de mettre en œuvre de grands projets informatiques. Les technologies Big Data, souvent encore au stade de POC au sein des directions relations clients se sont retrouvées en première ligne de ces mises en œuvre. Elles servent en effet de socle aux nouveaux systèmes et procédures capables de mieux évaluer les risques bancaires, quasiment en temps réel.

Quels sont les enjeux de la norme FRTB ?

La conformité avec les nouvelles réglementations est devenue un challenge pour l’IT, alors que le suivi du risque de marché FRTB (Fundamental Review of the Trading Book) entrera en vigueur en 2020 et les nouvelles fonctionnalités à implémenter imposent une refonte du calcul des sensibilités SBA et le remplacement de la VaR par les « Expected Shortfall (ES) comme mesure du risque. Ces opérations se nourrissent d’un grand volume de données historique et nécessitent une analyse la plus rapide possible.

Volumétrie, variété des données et vitesse de traitement… sont les critères même de définition d’un projet Big Data.

A la cible, ce sont des centaines de To de données qui seront stockées et mises à disposition d’autres applications –parfois injectées en seulement quelques heures.
Ce cas d’usage a été identifié comme le candidat idéal à la mise en place d’une plateforme Big Data basée sur Hadoop.

Les données et les systèmes au sein des banques étant très segmentés, la difficulté et l’intérêt d’une plateforme Hadoop ou d’un datalake, outre stocker et traiter de gros volumes, est de réunir et organiser ces données en provenance de système variés (Market Risk Var, Stress Var, Market Risk reporting, in house build solutions)

Comment mettre en œuvre un projet FRTB dans une banque CIB ?

1) Conception de l’architecture et mise en place d’une équipe Big Data

En 2015, nous avons été sélectionnés par notre client pour définir les contours du projet : les composants logiciels et l’architecture technique.
En parallèle, une étude comparative était réalisée par notre client pour la sélection d’une distribution adéquate : Cloudera, Hortonworks, MAPR. Le choix s’est porté sur la plateforme HDP d’Hortonworks en raison des fonctionnalités BluePrint et de sécurité (Ranger, intégration Kerberos) indispensables dans un contexte bancaire.

En 2016, une équipe pluridisciplinaire (data engineer, expert système, architecte, chef de projet) a été mise en place pour déployer les premiers clusters HDP à destination des équipes de développement avec les technologies suivantes : HDFS, Yarn, HBase, Hive , Spark et Kafka. Le choix d’Ansible a été fait comme technologie de provisioning.

Les premiers clusters mis à disposition des équipes de développement ont permis de réaliser des PoCs en mai 2016. Ceux-ci ont donné satisfaction au métier et le choix de continuer sur la plateforme d’Hortonworks a été retenu.

L’architecture Lambda nous a semblé correspondre aux besoins exprimés :

 

2) Couche acquisition et haute disponibilité

Ce type projet comporte le plus souvent 5 étapes :

• Data Ingestion
• Data Enrichment/Transformation
• Data Governance
• Analytic Definition
• Report Definition

Sur cette même année 2016, les équipes de développement se sont focalisés sur les stream d’ingestion dans le datalake en mode Batch ainsi que sur le data-enrichment, les technologies concernées ont été HDFS, Hive, Hbase, Spark.

Une fois les premiers clusters déployés nous avons travaillé sur la partie Haute Disponibilité et les aspects DRP (Disaster Recovery Plan). Notre équipe en place fonctionne en mode agile avec des sprints de 3 semaines, le résultat d’un sprint étant un ensemble de playbook Ansible qui permettait soit l’ajout d’un composant supplémentaire, soit la mise en haute disponibilité d’un composant.
Exemple : un playbook pour l’installation avec gestion de la haute disponibilité de la base PostgreSQL pour la base de données de Ambari.

Notre client dispose de plusieurs datacenters, et une de ses exigences était la continuité de service du cluster HDP sans perte de données même en cas de perte d’un site.
Le plus gros challenge a été la mise en place d’un cluster étendu sur deux sites pour respecter les contraintes de RPO 0 (Recovery Point Objective – perte de données maximale 0).
Pour ne pas perdre de données en cas de perte d’un site, le choix d’avoir 4 réplicas HDFS a été fait : 2 réplicas par datacenters. Pour ce faire, notre équipe s’est appuyée sur les fonctionnalités de rack-awareness de HDFS et une extension de Pivotal.
Enfin, pour éviter un split-brain, un nœud témoin Zookeeper a été ajouté dans un troisième datacenter :

3) Implementation de la sécurité et résilience

En 2017, pour respecter les contraintes de sécurité, Ranger a été mis en place pour la gestion des ACL et Kerberos pour la partie authentification.

La plateforme Hadoop a été mise en production en 2017 avec une première couche d’ingestion et de traitement de la donnée développée en Spark en mode Batch.
Exemple de traitement : Acquisition des données, envoi CFT vers une landing Zone (Partage NFS), traitement Spark pour ingestion dans HDFS, puis traitement / analyse de la donnée et restitution (Excel, Qlik, Tableau).

La couche streaming qui s’appuie sur SparkStreaming et Kafka est toujours en cours de développement, et la plateforme Big Data continuera d’évoluer dans ce sens.

Share our news :

-