Architecture du marché de données
Introduction
Notre client, l'un des principaux fournisseurs mondiaux de solutions d'investissement, de conseil et de gestion des risques, dont le siège social est situé à New York, possède 70 bureaux dans 30 pays et des clients dans 100 pays. Il cherchait à améliorer la performance de sa plateforme de marché de données interne, en accordant une attention particulière à la rapidité d'intégration des données, afin d'assurer la satisfaction tant des clients internes qu'externes lors du lancement du produit.
Le défi
Créer des pipelines de données dans une infrastructure hautement volatile
L’équipe HCLTech a réalisé une analyse des pipelines de données du produit du client et a mis en évidence les défis suivants :
- Durant le développement, le client était insatisfait du temps requis pour intégrer de nouveaux jeux de données et les rendre utilisables sur la plateforme
- Ce problème sous-jacent entraînait des retards de plusieurs mois avant qu’un jeu de données puisse être partagé sur la place de marché de données
- L’absence d’une stratégie d’intégration standardisée et rationalisée pour ingérer des données provenant de jeux de données tiers ainsi que les limitations techniques de la base de données héritée Sybase
- De plus, les responsables de données devaient maîtriser Perl, Java, Python et Informatica PowerCenter pour pouvoir intégrer de nouveaux jeux de données, ce qui provoquait d’autres retards
L’Objectif
Améliorer la satisfaction des clients grâce à une meilleure performance du produit
Le client désirait concevoir et mettre en œuvre une solution afin d’améliorer la performance de la plateforme et d’assurer la satisfaction des clients lors du lancement du produit.
- Pour permettre un débit de données plus rapide, le client devait passer d’un traitement par lots à une architecture fondée sur les flux. Ce changement entraînerait toutefois une augmentation substantielle du volume de données que le système devrait prendre en charge
- Le système devrait analyser des fichiers XML de 5 à 10 Go en tables relationnelles et traiter rapidement 300 000 à 400 000 petits fichiers

La solution
Concevoir et déployer un système d’ingestion axé sur les métadonnées
Notre équipe a conçu l’architecture et la configuration des données, géré la mise en place de l’ingestion et de la transformation, et créé une stratégie de partage des données afin d’améliorer la performance de la plateforme.
- L’équipe a remplacé la base de données Sybase désuète par un système reposant principalement sur Snowflake et dbt
- Les données ont été chargées dans Snowflake à partir de l’object store vers la couche brute du stade 0 pour maximiser la performance et tirer parti des capacités de dbt pour transformer les données et effectuer des vérifications de qualité
- Pour réduire les exigences de compétences techniques en gestion des données, l’équipe a mis en place une plateforme d’ingestion automatique axée sur les métadonnées. Avec cette plateforme, les gestionnaires de données devaient simplement remplir des gabarits de métadonnées afin que les données soient récupérées automatiquement par le cadre de travail
- Cette stratégie et ce système ont éliminé la nécessité d’interagir avec une base de données, un outil ETL ou d’orchestration, car le nouveau cadre de travail générait automatiquement tout en fonction des métadonnées
- L’équipe a construit un lac de données qui pouvait accommoder des données structurées, non structurées ou semi-structurées. Cela a permis à notre équipe d’accéder rapidement et efficacement à tous les actifs de données, quel que soit le format
- L’équipe a atteint cet objectif en utilisant un backend basé sur Python, où le code Python a été écrit pour analyser les fichiers de configuration et de métadonnées afin de générer automatiquement des pipelines comportant des étapes pour l’extraction, le chargement, la transformation et les vérifications de qualité des données
L’incidence
Des analyses plus rapides grâce à la réduction du temps de chargement des données
Le client a reçu une solution hautement performante, robuste et modulaire pour l’intégration des ensembles de données. Il peut maintenant intégrer de nouveaux ensembles de données en quelques jours, plutôt qu’en plusieurs mois. La nouvelle architecture a permis une consommation des données plus facile pour les clients du client et leur a donné accès à une réplique isolée via le Snowflake Data Exchange. Alors que l’architecture héritée du client avait une latence moyenne de trois jours avec de plus grands ensembles de données, la nouvelle solution peut maintenant charger près de 4 To de données XML semi-structurées en quelques heures.
