Toute organisation manipule des données qui comptent. Seule une partie d'entre elles est critique, et la distinction ne tient ni à la taille ni à la sophistication ; elle tient à la conséquence. Une donnée est critique lorsque le fait d'être fausse, en retard ou indisponible entraîne un coût asymétrique et souvent irréversible : une transaction bookée face à un prix périmé, une limite de risque franchie sans que personne ne le voie, une anomalie qui se propage dans un système alors que le tableau de bord affiche encore du vert. Dans ces contextes, la valeur de la donnée ne réside pas dans son stockage mais dans son usage, et cet usage est lié à un instant. Faites-le correctement une heure plus tard et vous n'aurez pas résolu le problème ; vous l'aurez documenté.
Ce qui rend ce type de données véritablement difficile n'est aucune propriété prise isolément. C'est que les workflows critiques exigent presque toujours deux sortes de données à la fois, et que ces deux sortes ne se comportent en rien de la même manière. Il y a les données en mouvement : les ticks, les événements, les mises à jour arrivant en continu et hors du contrôle de l'opérateur. Et il y a les données au repos : les positions, les enregistrements de référence, l'historique, l'état accumulé qui donne son sens à un événement en mouvement. Une variation de prix ne signifie pas grand-chose en soi. Elle signifie beaucoup au regard de la position qu'elle revalorise, de la limite dont elle se rapproche et de l'entité à laquelle elle appartient. La donnée en mouvement et la donnée au repos doivent être jointes, et elles doivent être jointes maintenant.
Les systèmes de streaming sont conçus pour faire circuler les données et sont généralement mauvais pour conserver un état riche et répondre à des questions ad hoc contre celui-ci. Les systèmes de bases de données sont conçus pour conserver un état et répondre à des questions, et sont généralement mauvais pour absorber un changement à haute cadence et le pousser plus loin à l'instant où il arrive. Chaque régime est optimisé pour ce que l'autre fait mal. Faire le pont entre eux, réconcilier les données en mouvement avec les données au repos en continu, sous charge, et sans perdre en exactitude, est une désadaptation d'impédance, et c'est la maladie dont découlent la plupart des symptômes bien connus.
Ces symptômes sont habituellement catalogués sous quatre propriétés : variété, vélocité, volume et véracité. Cette partie les examine tour à tour, mais les traite délibérément comme des symptômes plutôt que comme le problème lui-même. La variété est difficile parce que les éléments à joindre ont des formes différentes et des horloges différentes. La vélocité est difficile parce que la jointure a une échéance. Le volume est difficile parce que la jointure doit tenir sur une énorme cardinalité et un long historique. La véracité est difficile parce que la jointure doit rester correcte pendant que tout ce qui précède est en flux. Une cinquième propriété, la valeur et l'économie qui l'entoure, est ce qui met les quatre premières en perspective, car c'est la propriété sur laquelle les décideurs de haut niveau tranchent réellement et celle que les quatre premières ignorent manifestement.
Aucune de ces propriétés n'est particulièrement difficile isolément. La difficulté, c'est qu'on ne les rencontre jamais isolément.
La variété est un problème d'exactitude, pas d'ingestion
La lecture conventionnelle de la variété est un catalogue de formats : tables structurées, messages semi-structurés, texte non structuré et la ménagerie croissante de flux qu'une entreprise doit ingérer. Cette lecture n'est pas fausse, mais elle pointe vers la partie la moins intéressante du problème. La diversité des formats est, pour l'essentiel, une discipline résolue ; les parseurs et les connecteurs sont matures, et ajouter une nouvelle forme de flux relève de l'ingénierie, non de l'invention. La variété qui menace réellement un système critique se situe un niveau plus profond, dans trois dimensions qu'un catalogue de formats masque.
La première est la variété sémantique. Deux sources peuvent s'accorder parfaitement sur la structure et diverger totalement sur le sens. Le "notionnel" d'un système est l'"exposition" d'un autre ; l'identifiant d'instrument d'un flux est clé sur un symbole de bourse, celui d'un autre sur un référentiel de titres interne, celui d'un troisième sur un code fournisseur. Les joindre n'est pas une affaire d'alignement de colonnes mais de réconciliation de ce que ces colonnes signifient, et c'est dans cette réconciliation que se cachent les erreurs, car un désaccord produit un nombre qui paraît tout à fait plausible et qui est tout à fait faux. Les données de référence sont le tissu conjonctif ici : les correspondances, les hiérarchies et les enregistrements maîtres qui permettent de rattacher un événement en mouvement à l'entité qu'il concerne réellement. La capacité d'un système à gérer la variété est, en grande partie, sa capacité à maintenir ce tissu conjonctif correct et à jour.
La deuxième est la variété temporelle, et c'est la dimension la plus souvent oubliée. Les sources n'ont pas seulement des formes différentes ; elles arrivent sur des horloges différentes. Un flux de données de marché se met à jour des milliers de fois par seconde ; un référentiel de positions se met à jour quand les transactions se bookent ; un fichier de référence se met à jour une fois par jour, parfois en retard, parfois avec des corrections. Joindre à travers ces horloges revient à décider ce que "courant" signifie lorsque les entrées ne sont jamais toutes courantes au même instant. Enrichissez-vous un événement à arrivée rapide avec l'enregistrement de référence tel qu'il était il y a un instant, ou tel qu'il sera une fois le fichier du jour arrivé ? La question n'a pas de réponse universellement juste, mais un système critique doit y répondre délibérément et de manière cohérente, car y répondre par accident est la façon dont un système produit des chiffres qui ne peuvent être ni reproduits ni expliqués.
La troisième est la variété de cardinalité : le fait que les éléments à joindre existent à des granularités différentes. Un événement concerne un seul ordre ; la position qu'il affecte est l'une de millions ; la limite qu'il teste appartient à un book, un desk, une entité juridique, chacun à un niveau différent d'une hiérarchie. Une jointure à travers la variété est donc rarement une simple recherche à plat. C'est une traversée, et la structure qu'elle traverse est elle-même changeante.
La raison pour laquelle la variété figure en tête de cette liste est qu'elle recadre l'ensemble du problème. Il est tentant de traiter la variété comme une question d'ingestion : tout faire entrer, tout normaliser, et passer à autre chose. Mais la difficulté ne finit pas à l'ingestion ; elle y commence. La variété est fondamentalement un problème d'exactitude, car chaque jointure à travers une forme, un sens, une horloge et une granularité discordants est une occasion de se tromper avec assurance. Les trois propriétés restantes sont, en un sens, la variété observée sous pression : ce qui arrive à ces jointures lorsqu'elles doivent aussi être rapides, volumineuses et dignes de confiance.
La vélocité est une échéance, pas une vitesse
La vélocité est couramment décrite comme une vitesse : à quelle rapidité les données arrivent, mesurée en messages ou en mises à jour par seconde. Cette description est exacte et presque inutile, car une cadence isolée ne dit rien sur le fait qu'elle constitue ou non un problème. Un million de mises à jour par seconde est trivial si rien n'en dépend pendant une heure, et une poignée de mises à jour par seconde est une crise si une décision à échéance dépend de la dernière. La vélocité ne devient significative que lorsqu'on la confronte à ce qui la consomme, et la manière utile de penser la vélocité n'est donc pas comme une propriété de la donnée mais comme une relation entre deux horloges : l'horloge selon laquelle la donnée change, et l'horloge selon laquelle une décision doit être prise.
Ce recadrage trace une ligne que le mot "rapide" occulte : la ligne entre le rapide et le temps réel. Le rapide est un énoncé sur le débit ; un traitement par lots peut être rapide. Le temps réel est un énoncé sur la latence relative à une échéance : un système est en temps réel lorsque l'intervalle entre la survenue d'un événement et sa prise en compte là où une décision se prend reste à l'intérieur du budget que la décision autorise. Un workflow de surveillance qui doit signaler un motif avant que le prochain ordre ne soit envoyé a un budget mesuré en millisecondes. La vue intrajournalière de liquidité d'un trésorier a un budget mesuré en secondes ou en minutes. Les deux sont en temps réel au sens qui compte ; ce qui diffère, c'est la taille du budget, et c'est le budget, non la cadence brute, qui dicte l'ingénierie.
Deux conséquences en découlent, et toutes deux reviennent tout au long du livre. La première est que les consommateurs d'une même donnée vivent souvent sur des horloges entièrement différentes. Une machine qui exécute face à un prix a besoin de chaque mise à jour à la vitesse de la machine. Un humain qui observe une vue agrégée du même marché ne peut percevoir, et ne devrait pas recevoir, des milliers de mises à jour par seconde ; les livrer malgré tout gaspille des ressources et dégrade la vue même censée informer la personne. Le même flux doit donc être servi à différentes vélocités à différents consommateurs sans qu'aucun ne soit mal servi, une exigence que la partie suivante traite directement sous le nom de conflation.
La seconde conséquence est que la vélocité interagit avec tout ce qui la précède et la suit. Elle interagit avec la variété, car une jointure doit être recalculée chaque fois que l'une de ses entrées change, et l'entrée la plus rapide impose le rythme de toute la jointure. Elle est en tension avec le volume, car le coût d'absorption d'une cadence élevée dépend de la quantité d'état que chaque mise à jour doit toucher. Et elle contraint la véracité, car l'ordre, la complétude et la correction deviennent tous plus difficiles à mesure qu'il reste moins de temps pour les établir. La vélocité, en somme, est l'échéance que les autres propriétés doivent respecter. C'est ce qui transforme un problème de données en un problème de systèmes.
Le volume, c'est l'ensemble de travail actif, pas l'archive
La lecture conventionnelle du volume est la grandeur : téraoctets, pétaoctets, la masse totale brute de données qu'une entreprise accumule. Cette lecture pointe, une fois de plus, vers la partie la moins difficile du problème. La taille totale au repos est en grande partie une question de stockage, et le stockage est bon marché et bien compris ; vous pouvez conserver presque n'importe quoi indéfiniment si vous acceptez de le garder au froid. Le volume qui menace réellement un système critique en temps réel n'est pas la taille de l'archive mais la taille de l'ensemble de travail actif : la quantité d'état vivant, changeant et interrogeable que le système doit tenir cohérente à la fois. Ce volume pèse sur trois axes distincts, et la raison de sa difficulté est que les axes se multiplient plutôt qu'ils ne s'additionnent.
Le premier axe est la cardinalité, le nombre d'entités vivantes distinctes que le système doit suivre simultanément. Ce ne sont pas des lignes posées dans un entrepôt mais des instruments qui cotent, des ordres qui travaillent, des positions qui se revalorisent, des limites qui surveillent. Chacun est une petite chose individuellement ; il y en a simplement un nombre énorme, et chacun doit rester individuellement adressable, individuellement modifiable et individuellement à jour. C'est un problème de mémoire et de cohérence plutôt qu'un problème de disque, et il ne cède pas aux techniques qui rendent le stockage à froid bon marché. Vous ne pouvez pas répondre à une question sur l'ensemble de travail actif en balayant une archive, car le temps que le balayage se termine, la réponse a changé.
Le deuxième axe est la profondeur d'historique : jusqu'où le système doit remonter et, de manière décisive, si cet historique doit être joint au présent vivant. Un historique qui n'a besoin d'être récupéré que sur demande peut résider dans le stockage à froid et être extrait quand on le sollicite. Un historique qui doit être comparé en continu au maintenant en mouvement, comme un plus haut de séance, un cours moyen pondéré par les volumes, une variation depuis la clôture précédente ou un écart par rapport à une référence glissante, ne le peut pas. Il doit être résident et maintenu aux côtés de l'état vivant, car le calcul qui en a besoin s'exécute à chaque mise à jour. L'exigence n'est pas de stocker le passé mais de le tenir face au présent, ce qui ramène directement à la désadaptation d'impédance : l'enregistrement au repos et l'événement en mouvement doivent occuper le même calcul au même instant.
Le troisième axe est le nombre de consommateurs, le volume qui apparaît du côté de la sortie. La même donnée doit généralement atteindre de nombreux consommateurs à la fois, chacun pouvant vouloir une tranche différente, une vue différente ou une granularité différente. Une mise à jour d'une entité peut exiger un travail proportionnel au nombre de parties qui l'observent, et le nombre de parties est lui-même une dimension de mise à l'échelle indépendante de la vitesse à laquelle la donnée circule ou de la quantité qu'il y en a.
La propriété décisive du volume dans un système en temps réel est que ces axes sont multiplicatifs, non additifs. Le travail que le système doit accomplir croît à peu près comme la cardinalité multipliée par la cadence de mise à jour multipliée par le nombre de consommateurs multiplié par la complexité des jointures que chaque mise à jour déclenche. Parce que les axes se multiplient, on ne peut pas raisonner séparément sur le volume et la vélocité ; une cadence de données modeste face à un grand ensemble de travail actif avec une large diffusion peut être bien plus exigeante qu'une cadence furieuse face à une poignée d'entités que personne n'observe. C'est aussi pourquoi la mise à l'échelle naïve déçoit : doubler un seul axe peut plus que doubler le travail total, de sorte que jeter du matériel sur la taille totale s'attaque à la mauvaise quantité.
La véracité se maintient, elle ne s'hérite pas
La lecture conventionnelle de la véracité est la qualité des données : si l'entrée est propre ou sale, exacte ou corrompue. Cette lecture n'est pas fausse, mais elle situe la véracité dans l'entrée, comme si l'exactitude était une propriété que la donnée possède ou n'a pas à l'arrivée. Dans un système critique en temps réel, la véracité se comprend mieux comme une propriété que le système doit maintenir en continu : non pas "cette donnée est-elle correcte" mais "la vue présentée en ce moment est-elle une représentation fidèle et explicable du monde tel qu'il peut être connu au mieux à cet instant, et cette vue peut-elle être reconstruite plus tard". La distinction compte parce qu'un monde au repos et un monde en mouvement établissent la vérité de manières entièrement différentes. Au repos, la vérité est une chose stabilisée sur laquelle on converge à loisir par la validation, la réconciliation et le nettoyage. En mouvement, la vérité ne se stabilise jamais, et le système doit rétablir une image fidèle encore et encore à mesure que les entrées arrivent incomplètes, dans le désordre et sujettes à révision, le tout à l'intérieur du même budget de latence qui régit tout le reste.
La première dimension est la complétude. Un calcul effectué avant que toutes ses entrées aient répondu produit un nombre qui est faux de la manière la plus dangereuse, car il paraît achevé. Un système en temps réel doit donc distinguer entre "la réponse est X" et "la réponse est X jusqu'ici", et doit savoir laquelle des deux il présente. Une image partielle rendue avec une pleine assurance est pire qu'aucune image, car elle invite à l'action.
La deuxième dimension est l'ordre. Pour tout calcul à état, l'ordre dans lequel les événements sont appliqués change le résultat, et dans un cadre distribué à haute vélocité, l'ordre dans lequel les événements arrivent n'est pas l'ordre dans lequel ils se sont produits. Les arrivées tardives et dans le désordre font diverger le temps de traitement et le temps d'événement, et un système qui ignore la différence calculera avec assurance contre une séquence qui n'a jamais eu lieu. Bien gérer cela signifie être explicite sur l'horloge à laquelle un résultat est rattaché et sur ce qui est fait lorsqu'un retardataire arrive après que l'instant auquel il appartenait est déjà passé.
La troisième dimension est la correction. Le monde se révise lui-même : une transaction est amendée, une impression est annulée, un enregistrement de référence est restaté après coup. Un système critique ne peut traiter comme définitif aucun fait sur lequel il a agi, car le fait peut changer, et lorsqu'il le fait, le changement doit se propager à travers tout ce qui en aval en dépendait. C'est le point où le traitement fondé sur les deltas de la Partie 2 cesse d'être une optimisation de performance et devient une exigence d'exactitude, car un système qui ne peut qu'ajouter, et ne peut réviser ce qu'il a déjà émis, ne peut rester véridique dans un monde qui se révise.
La quatrième dimension est la traçabilité, et avec elle la confiance. La confiance n'est pas l'affirmation qu'un nombre est juste ; c'est la capacité de démontrer pourquoi il est juste, ou, lorsque quelque chose a mal tourné, de trouver pourquoi. Dans les contextes réglementés et à forte conséquence, l'exigence se durcit en reconstructibilité : les mêmes entrées, appliquées dans le même ordre, doivent reproduire le même résultat, et le chemin de l'entrée à la sortie doit être ouvert à l'inspection. Un nombre qui ne peut être expliqué n'est pas digne de confiance même lorsqu'il se trouve être correct, car on ne peut ni s'appuyer sur son exactitude ni la défendre.
Prises ensemble, ces dimensions montrent pourquoi la véracité en mouvement est une discipline différente de la véracité au repos, et pourquoi c'est la vélocité qui la rend difficile. Le système doit être suffisamment correct maintenant, sous une échéance, et pleinement réconciliable plus tard, sans échéance. C'est la forme la plus aiguë de la désadaptation d'impédance : le monde au repos suppose une vérité stabilisée contre laquelle joindre, tandis que le monde en mouvement n'en offre qu'une provisoire, et la jointure entre eux doit être fidèle à un instant qui est toujours sujet à révision ultérieure.
