Une petite excursion dans les enjeux de l’intégration des données dans les systèmes distribuées à l’heure de la digitalisation.
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.
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.
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 !
