Data in the center of the Information System
•Download as PPTX, PDF•
2 likes•15,159 views
Diaporama de la présentation faite lors du Talend Connect 2016 sur la stratégie orientée données déployée à l'Institut national de l'audiovisuel (Ina). Pour en savoir plus, vous pouvez lire ce billet de blog : http://www.lespetitescases.net/comment-mettre-la-donnee-au-coeur-du-si
Recommended
Recommended
More Related Content
Viewers also liked
Similar to Data in the center of the Information System
Similar to Data in the center of the Information System (20)
More from Gautier Poupeau
More from Gautier Poupeau (19)
Recently uploaded
Recently uploaded (20)
Data in the center of the Information System
- 1. #TalendConnect #TalendConnect Data in the center of the Information System Example of the IT Department of Ina Gautier Poupeau, @lespetitescases
- 2. #TalendConnect Company Preserve Enhance Train 24h/7 160 TV and radio broadcasts 50 million records 1.4 million of hours digitalized including 450k hours publicly available 470 internships for 3000 professionals/year 14 trainings from BTS to Master Our main missions
- 3. #TalendConnect Company 14.7 million hours of TV and radio documents Our collections 2 million hours of professional archives 12.7 million hours legal deposit 1.2 millions of pictures 3.29 Po of Web archives
- 4. #TalendConnect Why change? Urbanization of the Information System Redesigning the business information system New practices Rational, robust, strategically aligned New technologies Legal Deposit Professional archives Offering a unique tool for business users
- 5. #TalendConnect How to change ? A matter of strategy How to deal with change path ? Process first Data first vs
- 6. #TalendConnect How to change ? A matter of strategy How to store and request data ? One big database Different databases vs
- 7. #TalendConnect How to change ? A matter of strategy How to control data ? Decentralize data Centralize data vs
- 8. #TalendConnect How to change ? A matter of strategy How to keep flexibility and control ? Strict structure Data framework with variations vs
- 9. #TalendConnect How to change ? Actors Business Application Users Project manager Data Architect DevOps DBA Developper Data scientist Data Team
- 10. #TalendConnect Solution Instruments A conductor Databases Development and processing environment or or
- 12. #TalendConnect Why Talend ? Development environment Talend is the conductor of our infrastructure
- 13. #TalendConnect Why Talend ? Processing environment Talend is the conductor of our infrastructure
- 14. #TalendConnect Expected Benefits Break down silos Offering a transversal and consistent vision of data
- 16. #TalendConnect Expected Benefits Centralized infrastructure Improve supervision and accelerate evolution
- 17. #TalendConnect Expected Benefits Mastering data Roll out data governance
Editor's Notes
- Présentation de l’intervenant : Gautier Poupeau, architecte de données à l’Institut national de l’Audiovisuel (Ina) L’ina est un établissement public à caractère industriel et commercial (EPIC) créé en 1976. A l’éclatement de l’ORTF, la société de radio-télévision de l’état, les chaînes de radio ont été rassemblés autour de Radio France, les chaînes de télévision TF1 (alors public), Antenne 2 et FR3 sont devenus indépendantes et l’Ina a été créé pour reprendre les autres activités de l’ORTF qui restent la base des missions principales de l’Ina : Conserver : l’Ina est la mémoire de l’audiovisuel français limité initialement au TV/Radio public puis depuis 1995 le dépôt légal de la radio et télévision depuis 2001, l’Ina capte 24h/24 7j/7 160 chaînes de radio et de télévision, conserve et documente ce flux permanent ce qui représente plus de 50 millions de notices documentaires. Valoriser : L’ina valorise ces images selon 3 vecteurs : à destination des chercheurs pour le dépôt légal, en B2B via le service InaMediaPro pour les fonds pour lesquels nous avons un mandat commercial et en B2C via ina.fr Former : enfin l’Ina a une mission de formation qui se concrétise par 470 formations continues et 14 formations initiales du BTS (Bac +2) au Master (Bac +5)
- Nos collections sont uniques dans le monde: Quasiment 15 millions d’heures de documents radio et télé (intégralement numérisés en 2021) Plus d’un million de photos 3,29 Po d’archives du Web puisque le dépôt légal concerne maintenant le Web dont l’Ina partage la responsabilité avec la Bibliothèque nationale de France
- Pourquoi avons-nous lancé cette réflexion ? Quatre raisons principales nous ont amené à mener cette réflexion et à lancer notre chantier : l’urbanisation de notre SI, comme tous les SI, le SI 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 à un besoin métier spécifique. Tels une myriade d’orchestre de chambres voire de solistes, les solutions de stockage et d’interrogation des données sont disséminés à 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 telle un orchestre d’opera, plus facile à maîtriser, à diriger et à faire évoluer La refonte de notre SI métier: une des meilleures preuves de cette éparpillement est le SI métier. Comme nous l’avons vu, il existe historiquement deux collections qui jusqu’à peu étaient gérés par deux services différents avec deux SI différents. Regroupés 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 7 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ère bien différents car 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 documentent 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 importante que dans le traitement des données (machine learning) que les technologies qui tournent autour de la notion de graphe popularisées par le Knowledge graph de Google Ce sont ces différents objectifs que nous avions au moment de déclencher la transformation de notre SI
- Mais comment mener à bien cette transformation. 4 questions principales nous ont guidé pour mettre au point notre stratégie Comment mener la trajectoire de transformation ? Comme d’habitude dans la construction du SI en passant par la modélisation des processus et des fonctionnalités 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, aux répétitions et c’est logique dans la mesure où l’essentiel des verrous se situe là et que nous disposons déjà des données. Ça permet de mieux contrôler la trajectoire de transformation.
- Comment stocker et requêter des données ? Une base de données ou plusieurs bases de données ? Pour répondre à tous les usages (production, recherche, 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 ? 17 instances de bases de données relationnelles Oracle pour le cœur des données métiers, 4 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 ? Il nous a fallu refaire 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é édicter un cadre conceptuel logique qui se traduit dans un modèle physique dans une BDR, mais éventuellement différentes sérialisations dans le document DB ou le moteur de recherche en fonction des différents besoins bref, on sépare le voire les modèles de production et de stockage des modèles d’usage et de valorisation
- Comment s’est on organisé pour mener à bien ce chantier ? Une équipe dont le cœur est composée de 3 personnes : Le chef de projet, notre chorégraphe, qui organise le travail, s’assure des délais, plannings, des rapports avec les prestataires et avec les autres composantes de la DSI L’architecte des données, le compositeur, moi-même, 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 notre 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, 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, 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. A signaler que le développement est pour le moment assuré via un marché public en collaboration avec un consortium d’entreprises composé de Fast Connect, filiale d’Atos et de Smile Les applications métiers, nos danseurs qui exploitent les données de notre infrastructure Et enfin les utilisateurs, notre public….
- Tout d’abord, les instruments : comme je l’ai expliqué précédemment, nous étions convaincus de deux choses : un type de base de données ne pouvait répondre à tous nos besoins et à l’hétérogénéité de nos données et il était essentiel pour nous d’inscrire clairement la structure des données, nous ne pouvions pas nous contenter de la vision habituelle du lac de données dans lequel on déverse les données pour une hypothétique utilisation d’analyctis. Ainsi, nous avons d’abord fait le choix : d’un moteur de recherche, ElasticSearch, d’une BD document, MongoDB, d’une base de données graphe capable de manipuler du RDF, la norme de graphe mis au point par le W3C et à la base du Web sémantique, Virtuoso d’Open Link, enfin nous allons bientôt déployer un SGBDR mais nous n’avons pas encore fait le choix entre Oracle, MariaDB et PostgreSQL. Si disposer de ces différentes bases nous permet de répondre à tous les cas d’usage et aux différents SLA associés, il était nécessaire de disposer d’un moyen d’assurer la cohérence et l’intégrité des données entre ces différentes bases, c’est-à-dire de pouvoir traiter de manière coordonnée les données et c’est là qu’entre en jeu Talend, notre chef d’orchestre, environnement de développement et d’exécution sur lequel je vais revenir. Finalement, notre infrastructure, notre orchestre (qu’on a nommé de manière assez impropre finalement le lac de données…) constitue une architecture MVC : les bases sont le modèle, Talend, notre module de traitement, le contrôleur et notre module de suivi et de gestion, la vue, avec deux types d’interface : synchrones avec des APIs REST et asynchrones via le système de fichiers.
- Tout d’abord, les instruments : comme je l’ai expliqué précédemment, nous étions convaincus de deux choses : un type de base de données ne pouvait répondre à tous nos besoins et à l’hétérogénéité de nos données et il était essentiel pour nous d’inscrire clairement la structure des données, nous ne pouvions pas nous contenter de la vision habituelle du lac de données dans lequel on déverse les données pour une hypothétique utilisation d’analyctis. Ainsi, nous avons d’abord fait le choix : d’un moteur de recherche, ElasticSearch, d’une BD document, MongoDB, d’une base de données graphe capable de manipuler du RDF, la norme de graphe mis au point par le W3C et à la base du Web sémantique, Virtuoso d’Open Link, enfin nous allons bientôt déployer un SGBDR mais nous n’avons pas encore fait le choix entre Oracle, MariaDB et PostgreSQL. Si disposer de ces différentes bases nous permet de répondre à tous les cas d’usage et aux différents SLA associés, il était nécessaire de disposer d’un moyen d’assurer la cohérence et l’intégrité des données entre ces différentes bases, c’est-à-dire de pouvoir traiter de manière coordonnée les données et c’est là qu’entre en jeu Talend, notre chef d’orchestre, environnement de développement et d’exécution sur lequel je vais revenir. Finalement, notre infrastructure, notre orchestre (qu’on a nommé de manière assez impropre finalement le lac de données…) constitue une architecture MVC : les bases sont le modèle, Talend, notre module de traitement, le contrôleur et notre module de suivi et de gestion, la vue, avec deux types d’interface : synchrones avec des APIs REST et asynchrones via le système de fichiers.
- Pourquoi Talend ? D’abord, le studio nous offre un environnement de développement qui assure : Rapidité pour prototyper et/ou développer de nouveaux traitements via ses capacités graphiques Une homogénéité dans les développements mise au point de pattern de développement à suivre et une IHM permet en un coup d’œil de visualiser tous les jobs/services déjà développés et leurs contenus Des composants prêts à l’emploi Une philosophie proche de la nôtre : traitement de la donnée plutôt que traitement métier…
- Et puis une suite complète ave l’environnement d’exécution via le TAC et surtout le runtime/job server qui simplifie le déploiement et le suivi des différents traitements Seul bémol : il reste encore des progrès à faire dans le domaine de l’intégration et du déploiement continu et dans la gestion des retours des différents composants, le passé d’ETL de Talend est encore présent mais la transformation en une plate forme d’intégration de données est en marche et nous sommes déjà pleinement satisfaits.
- 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 1è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 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 son évolution
- Enfin, last but not least, maîtriser les données pour être capable de déployer une gouvernance de données et ainsi être plus efficace dans la réponse aux besoins métiers ou aux nouvelles demandes de nos utilisateurs finaux.