Les petites cases

Comment mettre la donnée au coeur du SI ?

Le 19 novembre, 2016 - 10:39 — got

J’ai eu l’honneur et le plaisir de participer le 17 novembre à la conférence annuelle de Talend, le Talend Connect 2016, pour présenter comment, à l’Ina, nous avons mis la donnée au coeur de la refonte de notre système d’information.

CxdQ1VlXAAAPhZ5.jpg:large

Voilà une bonne occasion pour lever le voile sur ce projet qui m’occupe depuis deux ans et dont je parlais dans mon billet de bilan, au passage de respecter la promesse de le présenter plus longuement et de continuer à alimenter ce blog…

Voici le diaporama qui accompagnait ma présentation :

Contexte du projet

Quatre raisons principales nous ont amenés à mener cette réflexion :

  • l’urbanisation du SI.
    Comme tous les SI, celui de l’Ina s’est créé par couches successives selon les besoins métiers. De fait, il est composé de différents silos étanches répondant chacun à un besoin métier spécifique. Telle une myriade d’orchestre de chambres voire de solistes, les solutions de stockage et d’interrogation des données sont disséminées à travers l’ensemble du SI : différents SGBDR, instances de moteurs de recherche avec pour certains des index très proches, des scripts de traitement de données (export, import, calcul) un peu partout souvent pas ou peu supervisés dans des technos différentes et dont la maintenance s’avère fastidieuse. Suivant les différents axes de notre schéma directeur (robustesse, rationalisation et alignement stratégique), nous voulions transformer ces myriades de petits orchestres en une formation unique : un orchestre symphonique, plus facile à maîtriser, à diriger et à faire évoluer.
  • La refonte de notre SI métier
    Il existe historiquement deux collections à l’Ina (le dépôt légal et les archives dites professionnelles qui font l’objet d’une valorisation commerciale) qui, jusqu’à peu, étaient gérées par deux directions différentes avec deux SI différents. Regroupé depuis 3 ans au sein d’une direction unique, le métier souhaite maintenant disposer d’un SI unique. Il faut donc envisager la migration de sept instances de bases de données Oracle avec des structure et des logiques de données qui semblent identiques de loin mais qui s’avèrent bien différentes. En effet, les pratiques de travail sont différentes : l’objectif du dépôt légal est de documenter le flux pour en assurer la mémoire alors que les archives professionnelles sont documentées en vue de leur valorisation commerciale ou à destination du grand public. Bref, il faut tout revoir, tout refaire des systèmes de collecte des données au modèle de données en passant par le système de production.
  • Les nouvelles pratiques à prendre en compte en particulier la montée en puissance et l’importance aujourd’hui de l’indexation et la recherche plein texte qui a révolutionné les pratiques documentaires et l’augmentation de la disponibilité de données externes qui peuvent enrichir nos propres fonds ce qui est essentiel pour nous aider dans notre tâche.
  • Les nouvelles technologies telles que les systèmes de génération automatique de données (Speech to text, Extraction d’entités nommés…), les technologies ouvertes par le Big Data tant dans le stockage qui supporte des montées en charge importantes que dans le traitement des données (machine learning) que les technologies qui tournent autour de la notion de graphe popularisé par le Knowledge graph de Google.

Questions stratégiques

L'ensemble de nos interrogations dans la phase de cadrage du projet peut être résumé en quatre questions :

  • Comment mener la trajectoire de transformations ?
    Comme d’habitude dans la construction d'un SI en passant par la modélisation des processus métiers et des fonctionnalités attendues par les utilisateurs ou en adoptant une démarche plus originale en séparant la donnée de l’usage et en s’occupant d’abord de la donnée ? Comme dans la musique, nous avons d’abord privilégié la musique, la donnée au processus, les répétitions et c’est logique dans la mesure où l’essentiel des verrous se situent là. Nous avons donc commencé par mettre au point un nouveau modèle de données avec le métier puis nous effectuons la migration des données, en mettant en place des systèmes d'alimentation différentiels depuis les systèmes actuels qui sont maintenus en production. Une fois les données migrées et les systèmes d'alimentation en place, nous allons construire le nouveau système. Nous décomissionnerons les anciens systèmes et les systèmes d'alimentation différentiels uniquement lorsque le métier considérera que le nouveau système est suffisamment mature, ce qui va en réalité se faire en plusieurs étapes.
  • Comment stocker et requêter des données ? Une base de données ou plusieurs bases de données ?
    Voilà une question sur laquelle j'ai beaucoup évolué au cours des années. J'ai longtemps pensé, d'une part, qu'il était essentiel de limiter la dissémination des données entre différents modèles et entre différents types de bases de données et d'autre part, qu'on pouvait se passer des bases de données relationnelles qui me semblent cruellement manquer de souplesse. Ainsi, j'ai vu dans le couple base de données RDF et moteur de recherche, au cœur de la vision du Linked Enterprise Data que nous avions promu chez Antidot, le moyen de répondre à la fois au besoin de réconcilier les données de tous les silos du SI et au besoin de les mettre efficacement à disposition. Mais, comme j'ai commencé à l'expliquer dans mon précédent billet, ces technologies présentent certaines limites (sur lesquelles il faudrait que je revienne plus longuement) qui nous empêchent d'en faire le centre de notre système. Par ailleurs, on aurait aussi pu se diriger vers des technologies basées sur Hadoop comme le font la grande majorité des projets de lac de données. Mais, dans ce cas, le lac de données ne remplace pas les silos existants, il n'est qu'un nouveau silo de plus, entrepôt intermédiaire de toutes les données du SI, genre de data warehouse foure-tout, en vue de leur traitement qui se limite dans la très grande majorité des cas à l'analytics. Il s'agit donc d'une base secondaire, alors que nous avions aussi besoin de gérer des bases de données primaires. Ainsi, pour répondre à tous les usages (production, traitement, recherche et analytics) et à l’hétérogénéité des données (structurées, semi-structurées et non structurées), nous étions convaincu de l’importance de disposer de différentes bases familles de bases de données pour profiter des avantages de chaque nature de bases de données.
  • Comment maîtriser les données ? Décentralisation ou centralisation ?
    Sept instances de bases de données relationnelles Oracle pour le cœur des données métiers, quatre instances différentes de moteurs de recherches pour les mêmes données réparties sur deux logiciels différents, des myriades de bases de données pour les autres données (commerciales, juridiques…), l’impossibilité de disposer à un instant T d’une idée de la nature et de la répartition de nos données. Il paraissait évident que la centralisation des données était un moyen de résoudre la complexité de traitement, de supervision et de maintenance…
  • Comment assurer la souplesse tout en gardant la maîtrise des données ?
    Comme je l'ai déjà rappelé ci-dessus, nous avons repris à zéro notre modèle de données métiers, tâche sur laquelle nous avons travaillé pendant 18 mois avec le métier. Mais plutôt qu’une stricte structure, nous avons préféré mettre en place un cadre conceptuel logique qui se traduit dans un modèle physique dans la base de données relationnelles, mais éventuellement différentes sérialisations dans une base de données orientée document ou le moteur de recherche en fonction des différents besoins. Bref, on sépare le voire les modèles de production des modèles d’usage et de valorisation et on assume complètement le fait de maintenir différents modèles de données physiques, l'interopérabilité étant assuré par le respect plus ou moins strict du cadre.

Les acteurs du projet

Comment sommes-nous organisés pour mener à bien ce chantier ? Une équipe dont le cœur est composé de 3 personnes :

  • Le chef de projet, notre chorégraphe, qui organise le travail, met au point et s'assure du respect des plannings et, point essentiel, il s'occupe des rapports avec les prestataires et avec les autres composantes de la DSI, en particulier avec les chefs de projets des applications métiers qui s'appuient sur l'infrastructure de stockage.
  • L’architecte des données, le compositeur, qui s’occupe de la structure logique de la donnée, de l’adéquation des systèmes de stockage avec les besoins des utilisateurs, de la migration des données vers la nouvelle infrastructure de stockage de données et de l’exposition des données sous sa forme logique.
  • Le devOps qui assure aussi le rôle de DBA, notre ingénieur du son, rouage essentiel, qui a en charge le fonctionnement de l’infrastructure, maintient le système en condition opérationnelle, les mécanismes d’intégration continue et de déploiement continu, le stockage physique des données et vérifie en rapport avec l’architecte de données que les développements respectent les SLA et répondent aux besoins métiers.
  • Les développeurs, les musiciens (et peut-être bientôt des solistes en la personne de data scientist) qui développent tous les mécanismes d’import, d’export, d’exposition, de synchronisation et de traitement des données.

Nous avons donc séparé le travail sur les données, leur stockage et leur traitement des usages qui en sont faits dans les applications métiers. Nous voudrions ainsi aboutir à un état où les MOE des applications métiers se concentrent uniquement sur la réponse aux besoins métiers et ne perdent plus de temps sur le stockage des données dont ils ont besoin. La couche de données est alors à l'image de la couche d'infrastructure mutualisée entre tous les projets.

La solution technique

Comme expliqué ci-dessus, nous avons fait le choix de déployer plusieurs systèmes de stockage de données pour répondre aux différents cas d'usage et à l'hétérogénéité des données, par ordre de choix :

  • Un moteur de recherche en l'occurrence ElasticSearch pour non seulement répondre de manière efficiente aux requêtes des utilisateurs et aussi pour offrir une vue consolidée de données issues de différents silos en vue d'accélérer les interrogations croisées (par exemple, entre nos données documentaires, juridiques et commerciales) et de promouvoir un usage transverse des données par les applications métiers.
  • la base de données orientée document, MongoDB, qui sert à la fois de base de données secondaires pour les données provenant de silos externes à l'infrastructure centralisée de stockage (en particulier pour les progiciels qui garderont leur base native ou les applications qu'il n'est pas prévu de migrer pour le moment) et de base de données primaires pour les différents systèmes de génération automatique de métadonnées (speech to text, extraction d'entités nommées, reconnaissance d'entités visuelles ou sonores...).
  • la base de données graphes (et en particulier RDF), OpenLink Virtuoso, qui permet de stocker les données nativement en RDF issues de certains projets de recherche de l'Ina ou de données externes, d'effectuer des calculs s'appuyant sur les particularités du graphe (traversée de graphe, raisonnement, inférence) et peut-être à terme d'offrir une vue facilement requêtable de l'ensemble de nos données (si les problèmes de scalabilité de ces technos sautent...). Nous avons hésité avec Blazegraph qui, tout en étant fait à la base pour stocker du RDF, commence à s'ouvrir au property graph en proposant une implémentation de l'API Tinkerpop et donne des résultats intéressants en tant que sparql endpoint de Wikidata. Malheureusement, la faiblesse de l'implémentation de l'API Sesame, le manque de documentation et de retour concret de projet en production dans la communauté nous ont fait reculer pour le moment. Mais, je ne désespère pas de voir émerger bientôt une solution (celle-là ou une autre comme Stardog ?) qui implémente à la fois RDF et son langage de requêtes, SPARQL et les property graph et leurs langages de requête, Gremlin.
  • la base de données relationnelles. Nous nous sommes longtemps demandés si nous pouvions nous passer d'un SGBDR. Mais, il a fallu nous rendre à l'évidence : ces technologies offrent aujourd'hui des performances inégalées, lorsqu'il s'agit de stocker des données fortement reliées comme le sont nos données documentaires tout en assurant une intégrité des transactions. Bref, pour résumer la situation, nous avions besoin de respecter les principes de l'ACID et à ce jeu-là les BDR restent encore la bonne solution. A signaler que nous n'avons pas fait encore de choix de solutions à ce niveau, il devrait être fait dans les prochains mois.

Deux points méritent d'être notés 

  • comme base de données secondaire des silos externes, nous aurions pu choisir, à la place de MongoDB et comme beaucoup d'autres, de déverser l'ensemble de ces données dans des fichiers au format Parquet au sein d'un système HDFS. Mais, outre que nous manquions alors de maturité sur ces solutions, je ne suis pas sûr au regard de la volumétrie que cela se justifie, de plus MongoDb offre un langage de requêtes natif qui simplifie largement l'exploitation de ces données tout en offrant des perspectives de scalabilité.
  • Nous n'avons pas encore fait le choix de la (ou des) technologies que nous allons utiliser pour construire nos data warehouse en vue des traitements d'informatique décisionnelle. A priori, nous allons nous appuyer sur les bases que nous avons déjà déployées, mais nous pouvons aussi pour ce genre d'usage avoir besoin de déployer des bases de données orientées colonnes. A suivre...

Une fois qu'on prend acte dans l'architecture des systèmes de stockage de la coexistence de plusieurs familles de bases de données et a fortiori de plusieurs modèles de données, il faut déployer une brique de traitement capable de s'assurer de la cohérence des données et donc de la synchronisation entre les différentes bases, de l'abstraction des différents systèmes de stockage, donc du routage vers la bonne base de données des requêtes externes à l'infrastructure et, last but not least, de la centralisation de l'ensemble de ces traitements. Bref, il nous fallait un chef d'orchestre et à bien y réfléchir, c'est cette brique qui constitue le cœur de notre infrastructure, qui en détient les clés et l'intelligence.

Pour relever ce rôle aussi important, nous avons choisi les solutions de la société Talend. Pourquoi ? Car ils offrent une suite complète, cohérente et intégrée : de l'environnement de développement avec le studio qui permet de développer graphiquement des chaînes de la traitement (appelés Job) de la donnée homogènes, car elles s'appuient non seulement sur des composants de traitement unitaire natifs à la solution (plusieurs centaines dont les connecteurs à toutes les bases de données les plus connues du marché) mais aussi sur la possibilité de visualiser voire récupérer tout ou partie de jobs existants jusqu'à l'environnement d'exécution qui permet de déployer le job sur une infrastructure basée sur Karaf et de le superviser depuis une interface Web, le Talend Administration Center. Il est ainsi très facile dans un environnement intégré comme celui-ci de répondre très rapidement à un nouveau besoin.

Finalement, une troisième brique, le module de gestion et de suivi, construite en java permet d'exposer les interfaces qui sont de deux types : REST pour les requêtes synchrones à travers laquelle nous exposons des vues logiques et métiers de la donnée et NFS pour les requêtes asynchrones, de s'assurer d'une stricte abstraction entre les utilisateurs et les différents systèmes de stockage, de configurer les nouvelles ressources à exposer, de proposer un annuaire des ressources exposées et de suivre le fonctionnement de l'ensemble de la plateforme.

Ainsi, l'architecture, notre orchestre, suit les principes du patron MVC : les bases de données sont les modèles, le module de traitement avec Talend joue le rôle de contrôleur et le module de suivi et de gestion expose la vue.

Les bénéfices attendus

Il est encore trop tôt pour parler de bénéfices puisque nous sommes en cours de déploiement de notre infrastructure, les développements de la première version ayant abouti à la fin de l’été. Mais, si on parle de bénéfices attendus. Ils sont au nombre de quatre :

  • casser les silos de données pour offrir une vision transverse et cohérente de nos données et permettre l’apparition d’usages transverses de nos données ;
  • souplesse pour faciliter l’innovation et simplifier l’émergence de nouveaux usages ;
  • une infrastructure centralisée pour améliorer la supervision et accélérer simplifier son évolution ;
  • maîtriser les données pour être capable de déployer une gouvernance de données et ainsi être plus efficace et confiant dans la réponse aux besoins métiers ou aux nouvelles demandes de nos utilisateurs finaux.

Merci à Talend de m'avoir offert l'opportunité de présenter notre projet à côté d'entreprises mondialement connues ! Merci à Nicolas Bogucki de m'avoir fait confiance et de m'avoir accompagné pour faire émerger ce projet... Bonne continuation pour la suite de tes aventures ! Merci à mes si précieux collègues : Julien, le chef de projet sans qui j'aurais déjà baissé les bras depuis longtemps en face de la complexité d'un tel projet, en particulier dans les interactions qu'ils demandent et à Stanislas, le devOps/DBA, sans qui ce projet ne serait pas ce qu'il est et qui, chaque jour, me fait découvrir les complexités de la couche physique de stockage et de traitement de la donnée et à tous ceux qui participent à ce projet si stimulant !

Management de l'information Système d'information Causeries