Moderniser les données d’entreprise : Hadoop, Netezza et le changement de cap des plateformes de données

L’état du patrimoine de données

Entrez dans le patrimoine de données d’une grande banque et vous découvrirez des strates d’histoire. Un grand système. Un entrepôt Oracle acquis dans les années 2000. Une appliance Netezza achetée pour absorber les déclarations réglementaires. Un cluster Hadoop mis en place par une équipe d’analyse. Des traitements SAS. Tableau. SQL Server. Une présence croissante sur Azure ou AWS. Chaque couche était la bonne réponse au problème rencontré le jour de son achat.

Le travail de l’architecte de données d’entreprise n’est pas de remplacer tout cela par une magnifique plateforme unique. Il consiste à tracer les limites : quelles charges appartiennent à quelle plateforme, quelles plateformes sont stratégiques, tactiques ou en fin de vie. Puis, tout aussi essentiel, à faire respecter ces limites — en conseillant, approuvant et recommandant le choix de plateforme pour chaque nouvelle initiative.

Hadoop comme zone d’accueil stratégique

Hadoop était le pari stratégique pour les charges nouvelles et non structurées. Le schéma à la lecture permettait de déposer des données brutes sans négocier d’abord un schéma cible ; HDFS et le métastore Hive offraient un emplacement physique unique pour les jointures interdomaines ; l’écosystème ouvert (Spark, Hive, Impala, notebooks en aval) donnait à chaque équipe d’analyse la souplesse nécessaire sans créer d’infrastructure sur mesure.

La règle architecturale que nous avons formulée était simple : si une nouvelle charge accueille des données événementielles brutes, effectue des jointures interdomaines ou sert des scientifiques des données ayant besoin d’un calcul flexible, la plateforme privilégiée est Hadoop. Si elle produit des déclarations réglementaires ligne par ligne sur un magasin de données strictement modélisé, elle reste où elle est.

Netezza comme outil tactique robuste

Netezza n’avait pas besoin d’être remplacé. Il fallait cesser d’y accumuler des charges pour lesquelles il n’était pas conçu. L’appliance excelle toujours dans son domaine : SQL structuré, ensembliste et de forme prévisible sur des tables de faits de l’ordre du téraoctet. Magasins réglementaires, rapports financiers, agrégation des risques — autant de bonnes charges Netezza, qui ont toutes été conservées.

Nous avons retiré de Netezza les charges qui n’auraient jamais dû s’y trouver : analyses exploratoires ponctuelles sur des flux d’événements bruts, jointures interdomaines qui auraient dû se faire dans une zone d’accueil et préparation ETL utilisant l’entrepôt comme table temporaire. Les retirer a permis à l’appliance de mieux remplir sa véritable fonction.

L’arbre de décision pour choisir une plateforme

L’approbation des choix de plateforme pour les nouvelles initiatives nécessite un arbre de décision reproductible, pas une réunion. Voici celui que nous utilisions :

• S’agit-il de déclarations réglementaires sur un magasin de données modélisé ? → Entrepôt existant (Netezza ou Oracle).
• Accueille-t-il des données événementielles brutes à schéma flexible ? → Zone d’accueil Hadoop.
• S’agit-il d’une charge transactionnelle ? → Base de données opérationnelle, pas le parc d’entrepôts.
• S’agit-il d’une analyse exploratoire pilotée par notebooks ? → Hadoop avec accès en lecture seule aux magasins modélisés par fédération.
• Le jeu de données est-il nouveau et son consommateur natif du cloud ? → Voie de plateforme de données cloud, avec un flux unidirectionnel délibéré vers le patrimoine sur site.

Cet arbre, associé à une revue d’architecture de données d’entreprise au début de chaque initiative, a empêché la prolifération du patrimoine. L’arbre est plus important que les choix technologiques qu’il produit.

Une gouvernance sans bureaucratie

La gouvernance des données a mauvaise réputation parce qu’elle se résume souvent à des politiques sans moyens d’application. La version qui fonctionne dans une grande banque est celle où la gouvernance fournit des outils et des garde-fous en même temps que les politiques : un catalogue de métadonnées réellement à jour, une classification des données appliquée dès l’ingestion, une traçabilité automatique plutôt que manuelle et une procédure d’escalade claire pour les exceptions inévitables.

Notre rôle d’architecte de données d’entreprise faisait le lien entre l’équipe de gouvernance et les équipes de livraison. La gouvernance fixait les règles ; nous veillions à ce qu’elles se reflètent systématiquement dans le choix de plateforme. Les projets qui le faisaient bien allaient plus vite, car ils n’avaient pas à reconstruire leur couche de données six mois plus tard.

Ce que cela signifie pour votre stratégie de données

• Ne cherchez pas la plateforme universelle. Cherchez la bonne frontière entre deux ou trois plateformes.
• Décommissionnez en retirant les charges, pas les plateformes. La plateforme se réduit naturellement lorsque vous cessez de lui confier les mauvais traitements.
• Revoyez l’architecture au début, pas à la fin. Approuver tôt le choix de plateforme coûte dix fois moins cher que reconstruire.
• Traçabilité et classification dès l’ingestion. Les ajouter après coup est la forme de dette technique la plus coûteuse dans un patrimoine de données.
• Le cloud est une destination, pas une échéance. Migrez les charges qui en bénéficient ; laissez les autres en place.

Vous repensez votre patrimoine de données ?

SEYSO a conseillé de grandes banques sur leur architecture de données d’entreprise — sélection des plateformes, retrait des doublons et gouvernance de patrimoines multiplateformes. Si vous faites face à un ensemble d’entrepôts tentaculaire, à un cluster Hadoop sous-utilisé ou à une migration de données cloud à séquencer, parlons-en.