De l’intégration des données

Une petite excursion dans les enjeux de l’intégration des données dans les systèmes distribuées à l’heure de la digitalisation.

reactive

Architecture orientée flux et architecture orientée ressource

Probablement une des choses qui change le plus quand on passe d’une architecture dite d’ « entreprise » à l’architecture d’un pure player du web, c’est l’orientation nette vers une logique de flux.

Un architecte d’entreprise vous présentera son architecture en commençant par les grands blocs applicatifs puis continuera par le système d’échange et d’intégration des données entre les différents systèmes applicatifs.

A l’inverse, l’architecte d’un pure player présentera son architecture dans la perspective d’un flux : de la collecte des données à leur mode de persistance en passant par les divers traitements. On a tout de suite le sentiment d’avoir l’orchestration temporelle d’une suite d’événements.

Dans un cas on met l’accès sur les données comme ressources applicatives, dans l’autre on met l’accent sur le flux des données. Là où la première conception est plutôt spatiale et statique, la deuxième est plutôt temporelle et dynamique.

On sait que les organisations ressemblent à leur systèmes techniques, c’est pourquoi on peut faire le parallèle entre les deux types d’architecture introduites ci-dessus (entreprise et pure player) avec deux organisations : celles qui privilégient l’efficience des ressources et celles qui privilégient l’efficience du flux

lean.001

C’est un des principes du Lean que de privilégier le flux ; en effet, une organisation peut très bien arguer que tous les départements de l’entreprise sont très occupés et travaillent dur sans que rien de bien n’en sorte (en terme de qualité et de Time-to-Market).

Des îlots d’efficience ne font pas nécessairement une bonne efficience globale.

lean.002

C’est donc très logiquement que l’on va retrouver des types de démarche dans l’architecture d’entreprise qu’on ne retrouve pas chez les pure players. La plus symptomatique d’entre elles étant certainement le fameux « schéma directeur » : nul doute  que ce type de démarche n’a aucune place dans un système 100% digital.

Dans les architectures des acteurs du Digital, la notion de Flow et d’architecture événementielle est omniprésente : un schéma d’architecture se lit en suivant le flux – le pipeline – de traitement. Ici, le dynamisme du traitement de l’information prévaut sur l’image statique de l’ensemble des composants. On pourrait les qualifier d’architectures « Spin » ; çà rentre, çà tourne et çà sort. 

Collecte des données et traitement des données.

De fait, le choix d’une architecture dépend grandement de la manière dont les données sont collectées : des données collectées par batch induisent forcément un traitement par batch, et les données collectée en flux sont également tendances à être traitées en flux (« dis-moi comment tu collectes tes données et je te dirai quel style d’architecture tu utilises »).

Dès que l’on est dans des logiques séquentielles de lots et de batchs, on tend à concevoir des systèmes moins réactifs, moins sensibles aux évènements et qui ont tendance à s’encroûter dans des ilots applicatifs qui, certes, gèrent leur autonomie, mais parfois au détriment d’une vision plus globale et systémique.

À ce stade on pourrait dire que tout le monde n’est pas un pure player du digital et n’a donc pas besoin d’adopter cette logique de flux : tout le monde n’est pas en temps-réel continu !

Mais un flux n’est pas pour autant quelque chose de continu ; il est toujours constitué d’éléments discrets que sont les événements. Toutes les architectures ont un certain rapport au temps : une banque qui traite en batch l’ensemble des événements d’une journée a une unité temporelle de traitement qui est journalière, mais derrière cette journée, il y a toujours des événements qui s’inscrivent dans des unités de temps beaucoup plus petits.

De prime abord, les architectures qui reposent sur des traitements batch  semblent donc plus facile à gérer : elles tendent à créer des silos, plus ou moins grands, qui ont certes des avantages mais qui sont aussi une plaie en matière d’inter-opérabilité. Ces silos sont créés sur la base de « visions du monde » qui n’a pas de sens à l’extérieur. 

Du coup on essaye de fonder l’inter-opérabilité au niveau sémantique en faisant des «  alignements de vocabulaire ».   Traitée à ce niveau, la question d’intégration des données est toujours plus ou moins douloureuse (LinkedData, MDM).

En contre partie, les systèmes qui collectent et traitent de l’information en flux disposent d’un avantage très intéressant pour intégrer les données, y compris dans un environnement distribué : cet avantage c’est le TimeStamp. L’index temporel des logs d’un système est l’élément clé du succès d’une interopérabilité des données assurée, non pas au niveau sémantique, mais à un niveau technique plus bas. 

L’inégration des données via une log

Jay Kreps, qui a écrit l’article « The Log: What every software engineer should know about real-time data unifying abstraction », et dont je reprends ici les arguments, a une façon très simple de définir la question de l’intégration des données : il s’agit de « rendre disponible toutes les données d’une organisation au travers de tous ses systèmes et ses services ». Ce n’est qu’à partir de là que des questions de plus haut niveau comme les modèles de données et leur sémantique peut être traitée ; trop d’organisations partent bille en tête sur l’intégration des modèles de données à un trop haut niveau sans s’apercevoir que les données ne sont tout simplement pas disponibles et accessibles.

Une log est le « journal de bord » des écritures des différents systèmes inter-connectés, elle  permet d’assurer la structure du flux, sa cohérence et sa mémoire (c’est à dire la capacité à retrouver un état antérieur).

Le côté génial de la démarche – dans cette façon de penser l’intégration des données via un système de log – c’est de ne pas s’intéresser à la donnée en tant que telle, mais à son écriture et à sa date. Toutes les données du monde peuvent être très divergentes, il n’en reste pas moins qu’elles ont toutes été écrites à une date et une heure fixe (pour peu que l’on dispose d’un bon système d’enregistrement des traces de ces écritures).

On ne cherche plus à aligner les vocabulaires, la sémantique des données, mais simplement à enregistrer l’ordre des écritures comme référentiel d’alignement universel. Les questions sémantiques ne sont pas pour autant réglés, mais elles peuvent dès lors bénéficier d’un Framework universel d’inter-opérabilité basé sur la mesure du temps.

Dualité

Il y a une dualité [mot qui a un sens précis en mathématique dans la théorie des catégories, cf. Sens et enjeux des modèles de stockage et d’accès aux données] entre un système de log et une table de base de données : la table reflète la valeur actuelle d’une donnée dans le système, là où la log garde la trace ordonnée dans le temps de l’ensemble des opérations effectuées. De fait, une table peut toujours être reconstituée en reproduisant l’ordre et la nature des écritures enregistrées dans les logs.

On peut également, à partir des logs, décider de ne pas reproduire à l’identique une table existante mais une table dérivée pour d’autres besoins que la reproduction stricto-sensu. On pense tout de suite aux systèmes de gestion de version des codes sources avec leur système de branches pour garder la mémoire de l’ensemble des actions (des patchs) effectués sur un code source.

Toutes ces remarques sur l’utilité des logs ne valent que pour autant  que les écritures enregistrées sont de type déterministes, c’est à dire que le fait de rejouer une écriture doit produire toujours le même résultat. Un traitement qui, par exemple, introduirait une variable aléatoire (Random) impliquerait la présence d’une action non-déterministe, et donc les logs ne serait d’aucune utilité pour reconstituer à l’identique le film des événements.

L’avènement des données événementielles 

Deux tendances complexifient l’intégration des données, c’est à dire leur disponibilité et leur accessibilité au travers tous les services et les systèmes de l’organisation : l’avènement des données événementielles (que j’ai déjà évoqué plus haut) et la prolifération de systèmes de données disparates.

Les données événementielles sont essentiellement les données qui proviennent d’enregistrements de comportements : données produites par les traces des utilisateurs sur les sites web, données produites par les capteurs RFID, données issue du comportement des machines de production, etc. Là est certainement une des manières de caractériser les entreprises qui sont digitales : ce sont celles qui intègrent les données événementielles à leur système.

Ces nouvelles catégories de données  (événementielles et comportementales) ont suscité l’apparition de nouveaux système de stockage et de manipulation des données (depuis les systèmes de cube décisionnels, jusqu’aux bases NoSQL, en passant par les index des moteurs de recherche, les annuaires, les systèmes de batch processing à la Hadoop, etc. Il est évident que la diversité des systèmes renforce le challenge de l’intégration des données.

La réponse à ces enjeux de déluge des données événementielles et de multiplication des systèmes qui les manipulent passe par une log centralisée, véritable épine dorsale du système global qui va jouer le rôle d’une chambre d’enregistrement. C’est notamment ce qu’a fait Jay Kreps chez LindedIn avec Kafka.

Je vous invite bien sûr à lire l’article de Jay et également à consulter l’article d’Alex Dean qui reprend cette même vision en présentant trois évolution des architectures d’intégration des données : Three area of business data processing  

Grand merci à Erwan Alliaume qui a attiré mon attention sur l’article de Jay !

Merci pour ton billet qui tombe à pic, puisque nous sommes précisément en train de réfléchir à l’INA à une architecture d’intégration de données.

La proposition d’en passer par un système de centralisation de log est intéressante car elle acte d’une architecture de flux qui s’intègre bien dans l’activité de LinkedIn. Pourtant, certaines organisations ont un modèle hybride (c’est le cas de mon nouvel employeur et j’ai reconnu bien des éléments dans la première partie de ton billet qui confirme un certain nombre de nos réflexions actuelles) qui gère à la fois du flux et du stock. L’intégration de données dans ce cas qui n’est pas rare ne peut donc s’appuyer sur un seul modèle et c’est bien toute la difficulté.

De plus, si le principe d’en passer par les logs et leur centralisation règle à merveille et proprement la problématique du transport des données (nous avons d’ailleurs envisagé une telle piste), elle ne résout qu’une partie des problèmes de l’interopérabilité sémantique, à savoir sur la couche d’activités qui impactent les différentes ressources manipulées par l’organisation. Certes cela crée du lien entre les ressources par le référentiel d’événements. Or, cela est suffisant si tu ne manipules que du flux, mais restera limitée dans bon nombre de cas et tu le dis toi-même, cela ne résout pas entièrement la problématique de l’intéropérabilité sémantique (=mise en relation des ressources elles-mêmes ou à travers des référentiels non événementiels) qui est à la fois la plus complexe à mettre en place, à maintenir et à exploiter tant il est nécessaire de panacher les différentes technologies actuelles si on veut exploiter les données de l’organisation à son plein potentiel.

Bref, si je suis titillé par le concept d’architecture orientée flux, séduit par l’utilisation des logs comme un référentiel commun, système de transport et base de l’interopérabilité des données et convaincu depuis plusieurs années par l’intérêt de la modélisation orientée événement, l’expérience m’a montré à plusieurs reprises que les modèles sont bien souvent hybrides et que la modélisation orientée « événement » ne peut capturer l’ensemble de l’activité d’une organisation. De plus, elle peut s’avérer à la fois plus verbeuse mais aussi plus complexe à appréhender par les équipes de développement et donc faire peser un risque sur la maintenance du système ce qui n’est pas rien à l’heure de faire des choix de modélisation et d’architecture.

A ta dispo pour en discuter quand tu veux 🙂

PS : bien d’accord sur le fait que le Linked Data n’a rien résolu quant à la douleur d’un projet d’intégration de données, même si le résultat est séduisant au niveau des données elles-même (cf. mon petit laïus final 😉 ).

[Reply]

J’ai un peu du mal avec le vocabulaire que tu as choisi pour faire ressortir une des nombreuses opposition des acteurs « Enterprise » VS « Web ».
Tu parles d’architecture de ressources (ce qui me fait immanquablement penser au web) pour décrire le côté statique d’une architecture d’entreprise.
Et d’architecture de flux (qui évoque immédiatement le diagramme de flux, un incontournable de l’architecture d’entreprise) pour décrire la prépondérance des événements et du temps réel chez les acteurs du numérique.

[Reply]

Concernant les architectures orientées événements , on les trouve aussi dans le monde de l’Enterprise. Particulièrement du côté de Microsoft avec l’event sourcing et le CQRS de Greg Young.

Et pour rebondir sur le problème des événements déterministes ou pas, dans l’event sourcing on enregistre (on log) le résultat de l’événement et non l’événement lui même. Rien n’empêche d’enregistrer aussi l’événement mais ce sont deux choses différentes. Par exemple certains événements peuvent ne produire aucun changement d’état dans ce cas on ne logue rien en sortie.

[Reply]

Oui, je vois ce dont tu parles.
Tout à fait d’accord avec tes remarques.
Mais ici le terme « ressources » n’a pas le même sens qu’une ressource dans l’architecture du web. 🙂 (c’est un peu ma faute, je n’ai pas pris de précautions)
Le mot important est « efficience », et l’ « efficience des ressources » est à comprendre dans le sens où, par exemple, on parle du « taux d’utilisation » d’une ressource (ex: « 80% de ressources CPU utilisées »).

[Reply]

Bonjour,

les évènements ne sont en effet pas du tout suffisant pour résoudre les problèmes de sémantique. Ce qu’ils apportent de plus intéressant, à mon avis, c’est la flexibilité dans l’utilisation. Je décrirais ça de la façon suivante : avec une représentation des données unique en base, dans le log, on est capable de construire librement (ou presque) les représentations que l’on veut dans nos applications. On aura une forme de sémantique et de liens entre les données de l’event store, c’est indispensable pour construire une application digne de ce nom. Ces liens ne sont cependant que la première étape.

C’est la flexibilité qui va aider à capturer les activités diverses d’une organisation. À partir d’un même ensemble de données, on va pouvoir représenter le monde de points de vues différents. Si les données sont suffisamment structurée dans le log, tout est possible…

L’approche évènementielle ne coûte à mon avis pas plus cher. À partir des évènements, on va pouvoir construire une ou plusieurs applications que l’on pourra théoriquement repenser de fond en comble sans toucher aux données. En d’autres termes, on à de la donnée immuable et du code périssable… et c’est plutôt pratique. Ça coûte beaucoup moins cher de rajouter un type d’évènement dans son log que de modifier le schéma d’une base de données.

Enfin, pour ce qui est de la complexité de l’approche… quand j’étais à l’école, on m’a appris SQL et les SGBD relationnels, et c’est tout. C’est un moule dans lequel j’ai été formé. Ce qui est dur, à mon avis, c’est plus de réussir à changer de moule que de comprendre l’approche évènementielle à proprement parler. On a des réflexes, il faut les « désapprendre » dans le cadre de l’évènementiel.

PS : je suis probablement assez biaisé dans ma réflexion, je ne fais que de l’event-sourcing depuis quelques temps déjà.

[Reply]

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.