Lloyds Banking Group traite en temps réel ses flux de données transactionnelles

Lloyds Banking Group prépare son pipeline de traitement de données et ses analyses en temps réel afin d’offrir aux clients un accès plus immédiat à leurs transactions financières. Cette évolution permettra également à la banque britannique de mieux détecter les tentatives de fraude en interne. Avec les changements réglementaires qui se profilent à l’horizon, le groupe bancaire veut faire évoluer son architecture de données en offrant à ses clients des données transactionnelles aussi proches du temps réel que possible**.** « De mon point de vue, cette nouvelle manière de considérer les données des clients est certainement pertinente en Europe. Les données ne nous appartiennent pas, elles sont la propriété de l'utilisateur et nous en sommes responsables », a déclaré Andrew McCall, ingénieur en chef pour le big data de la Lloyds Banking Group lors du DataWorks Summit qui se tenait cette semaine à Munich (5 et 6 avril). Selon lui, le fait de se rapprocher du traitement de l'information en temps réel permet à la banque « d’envisager de nombreuses solutions d'apprentissage machine, de mieux servir les clients et de leur proposer une analyse plus approfondie de leurs états financiers ».

Le temps réel sera également utile pour lutter contre la fraude. « Pour lutter contre la fraude, on ne peut pas être aussi efficace si l’ion repère l’événement frauduleux un jour après. Le temps réel nous permet de prendre des mesures immédiates », a-t-il encore expliqué. L’objectif de la banque « est de descendre en dessous d’une seconde de latence sur l'ensemble du domaine de données entre le système source et le consommateur ». Malgré la quantité de couches que les données doivent traverser, avec Apache Storm, le temps de latence est inférieur à 20 millisecondes. Les clients pourront recevoir instantanément des notifications de dépenses, comme celles envoyées via des apps mobiles par certaines banques plus agiles et plus avancées technologiquement. Pour en arriver là, la Lloyds Banking Group a entrepris de gros changements dans son architecture. L'équipe d’Andrew McCall a dû notamment intégrer des systèmes existants avec différentes techniques plus modernes, par exemple le Change Data Capture (CDC) qui permet de conserver un historique des modifications apportées aux données d’une ou plusieurs tables et les connecteurs Kafka pour atteindre la vitesse opérationnelle requise.

Une couche de cache supplémentaire

Pour Andrew McCall, l'architecture idéale serait une « architecture Lambda avec quelques microservices qui peuvent écrire et lire les données avant de les introduire dans le système d'information ». Mais, dans la réalité, la Lloyds possède d’anciens systèmes complexes qui ont du mal à fournir la latence souhaitée par l’ingénieur en chef. « Les sources sont multiples, il y a beaucoup d’utilisateurs et de nombreux types d'état dans ce système », a-t-il déclaré. « Il faut écrire des API, définir des files d'attente, programmer des traitements de flux par lots, planifier des tâches, lire des API, créer des files d'attente sortantes et des traitements de flux sortants par lots ». Pour son pipeline de traitement de données en temps réel, la banque utilise HBase qui sert de magasin de données et pour enrichir les données au fur et à mesure, Hive pour le chargement des données destinées à l’analyse, Storm comme moteur de traitement en temps réel, Spark pour ingérer et charger les données dans les différents systèmes, et enfin Kafka comme pipeline de traitement transversal. Toutes ces opérations sont réalisées sur site.

Pour protéger les données API, Lloyds a mis en place une couche de cache supplémentaire afin d’augmenter la sécurité. « Concernant notre API, nous voulions installer Cassandra ou quelque chose de ce genre pour éviter d’exposer certains systèmes vitaux. D’où la présence de cette sorte de couche de cache », a encore expliqué l’ingénieur en chef de Lloyds Banking Group.