Comment Natixis booste les performances de ses clusters Hadoop

Kerberos, la seule façon de sécuriser un cluster Hadoop

Pour généraliser au plus vite les usages d'Hadoop, Natixis a fait le choix de travailler non pas sur des échantillons de données mais sur des données de production qui sont, par définition dans une banque, hautement confidentielles.

Pierre-Alexandre Pautrat a donc du particulièrement soigner la sécurisation du premier cluster Hadoop dédié à recevoir les "Proof of Concept". « Nous n'avons pas souhaité déployé un cluster dit "de développement" au sens habituel. Ce premier cluster devant héberger des données sensibles, nous devions le sécuriser. Cela nous a aussi permis de nous préparer au passage en production. Par conséquent, nous avons fait le choix de souscrire aux licences Hortonworks et de sécuriser ce premier cluster. Kerberos s'est imposé à nous car c'est la seule façon de sécuriser un cluster Hadoop."

Pour pouvoir stocker des données de production, le cluster Hadoop a dû être intégré aux procédures de provisioning des systèmes informatiques et donc du système de gestion des profils et habilitations de la banque. L'Active Directory Natixis a ainsi été connecté à Ranger, la brique qui gèrent les profils d'utilisateurs dans la suite Hortonworks.

« Dès le départ, nous avons voulu connecter Kerberos à l'Active Directory car nous avions la vision que presque tous les utilisateurs allaient être un jour habilités. L'intérêt de Kerberos, c'est qu'il est disponible sur chaque poste de travail Natixis, sur chaque serveur, donc directement exploitable pour nous. »

Si réaliser une telle intégration de la sécurité sur un simple cluster de développement semble une forte contrainte, une telle approche présente l'avantage de faire travailler les développeurs et les administrateurs dans une configuration très proche des conditions du cluster de production, notamment en termes de volumétrie de données.

« L'idée pour nous était de créer une vague au niveau développement et des tests, puis ensuite de surfer sur cette vague jusqu'à ce que celles-ci arrivent en production. Cela nous a permis d'anticiper et de savoir ce qui allait se passer 8 à 9 mois plus tard, au moment où les projets entrent en production. Les équipes peuvent ainsi identifier très en amont les problèmes potentiels, et avoir une mise en production que je qualifierais de sereine. »

« Ce qui est intéressant dans cette méthodologie, c'est que lorsqu'on a pu qualifier un cluster de qualification, la mise en production n'est qu'une simple duplication sans beaucoup de modification à apporter hormis la configuration du plan de secours. »

Un déploiement mené par vagues successives

Cette notion de vague permet aux développeurs d'identifier le plus vite possible les RATS (Riskiest Assumption Tests), c'est à dire les points dangereux et risqués dans le déroulement du projet et y répondre avec les MVP (Minimum Viable Products).

« Nous avions tant de tâches à mener que nous n'avions pas toujours le temps de chercher la meilleure solution, donc dès que nous avions une solution qui fonctionnait, nous passions à la suite, sachant que le décalage entre la vague en phase développement et la mise en production nous donnait ensuite le temps d'améliorer l'ensemble par la suite. »

Le seul véritable problème reconnu par Pierre-Alexandre Pautrat s'est localisé au niveau des outils de restitution. « C'est assez classique lorsqu'on travaille sur des bases de plusieurs centaines de millions d'enregistrements. Tous ceux qui travaillent avec Hive ont pu constater le temps mis par leurs requêtes. C'est un point que nous avons souhaité améliorer car les utilisateurs attendent aujourd'hui des résultats immédiats ».

En effet, la DSI de Natixis a déployé des solutions telles que Oracle Exadata, Sybase IQ ou des cubes OLAP afin de délivrer des performances optimales à ses utilisateurs d’Excel, de Tableau, de Qlik et de D3 via des interfaces standards ODBC, JDBC, XMLA/MDX.

Pierre-Alexandre Pautrat souhaitait offrir des temps de réponse inférieurs à la seconde sur les requêtes réalisées sur le cluster Hadoop tout en conservant cette identification Kerberos et en visant plusieurs milliers d'utilisateurs à terme.

Indexima, bien plus rapide qu'Apache Spark

C'est au Salon Big Data 2016, lors d'une présentation Mappy que le responsable de Natixis a trouvé un moyen de booster les requêtes sur ses clusters Hadoop.

« Mappy avait un problème de performance sur la connexion de ses outils de restitution à ses cluster Hadoop », explique Florent Voignier, fondateur d'Indexima. « Ce problème a rendu nécessaire le développement d'une nouvelle solution afin de répondre en quelques millisecondes, quelle que soit la volumétrie du cluster Hadoop, sachant qu'une solution de type in-memory comme Spark n'était pas jugée assez performante ».

Cet architecte de Mappy a développé Indexima, une solution qu'il définit comme un index multidimensionnel qui réalise une préaggregation in-memory. « Chez Mappy, une requête Spark SQL sur 1 milliard de ligne demandait 29 secondes, nous sommes descendus à 90 ms avec Indexima grâce à ces pré agrégats. Cela veut dire que l'on peut faire aujourd'hui de l'interactif sur du Big Data sachant que les tableaux de bord Mappy sont aujourd'hui en production sur plus de 10 milliards de lignes et plusieurs To de données avec toujours les mêmes temps de réponse ».

La solution Indexima est désormais commercialisée indépendamment de Mappy et sa mise en œuvre chez Natixis a été particulièrement rapide comme l'explique Pierre-Alexandre Pautrat. « Nous avons installé Indexima en 2 jours seulement sur une plateforme assez différente de celle de Mappy puisque ils utilisent leur propre distribution Hadoop. Sur notre plateforme Hortonworks "Kerberisée" nous avons tout d'abord mis en place Indexima pour Tableau Software, puis nous avons eu une demande pour Excel car c'est clairement l'outil qui reste le plus utilisé par nos analystes ».

En quelques semaines, Indexima a développé une interface MDX/XLMA pour simuler un serveur OLAP via Mondrian et donc donner accès au cluster Hadoop "accéléré" aux utilisateurs Excel.

Parmi les autres adaptations réalisées sur Indexima pour Natixis, le passage à un fonctionnement multi-utilisateur ainsi que l'inévitable support de Kerberos avec une gestion des droits extrêmement fine qui descend au niveau de la table, de chaque colonne et même de chaque ligne de données.

Actuellement, Natixis dispose de 4 clusters Hadoop avec un cluster de développement, un cluster de qualification, un cluster en production actif réparti sur 2 datacenters avec 6 nœuds de parts et d'autres et un cluster "coffre" totalement dédiée à l'archivage.

« Le cluster de qualification a récemment passé avec succès un test d'intrusion, ce qui démontre qu'il est possible de sécuriser un cluster Hadoop correctement », se félicite Pierre-Alexandre Pautrat. « Nous allons mener des tests d'intrusion sur tous nos clusters sachant que le cluster coffre doit récupérer toutes les réplications, les snapshots et qui est inaccessible aux développeurs afin d'éviter toute erreur de manipulation. D'une très grande capacité, il permettra de conserver de nombreuses versions de nos données ».

Trente projets Big Data sont actuellement en phase de développement chez Natixis pour plus de dix projets déjà en production. Le Machine Learning est aujourd'hui très utilisé. De même que Spark et Kafka montent en puissance dans les projets des équipes Natixis.