Si vous avez déjà travaillé avec des données de marché en temps réel dans une banque, un hedge fund ou une salle de marché, il y a de fortes chances que ces données aient été capturées, stockées et analysées à l’aide de kdb+.
Dans le paysage numérique actuel, les données inondent les organisations à un rythme sans précédent — des transactions financières aux interactions sur les réseaux sociaux. Le défi est clair : comment traiter et analyser ces données en temps réel ?
Prenons les marchés financiers, où même quelques millisecondes de retard peuvent signifier des opportunités manquées ou des pertes tangibles. kdb+ a été conçu pour répondre précisément à ce type de demande. Il est largement adopté par les banques et les institutions financières, mais aussi dans l’industrie, l’aérospatiale et les télécommunications.
kdb+ est une base de données orientée colonnes et en mémoire, conçue pour des performances extrêmes sur les séries temporelles. Il est livré avec q, un langage de traitement vectoriel concis, spécialement conçu pour interroger et manipuler de grands ensembles de données avec une syntaxe minimale.
Ensemble, ils forment un système étroitement intégré où le langage et le moteur de stockage ne font qu’un — il n’y a pas d’incohérence entre la façon dont vous écrivez vos requêtes et la façon dont les données sont stockées. C’est l’une des raisons principales pour lesquelles kdb+ surpasse systématiquement les bases de données polyvalentes sur les charges de travail de séries temporelles, traitant des millions d’enregistrements par seconde avec une latence inférieure à dix millisecondes.
Chaque instance de l’interpréteur q est appelée un processus q. Les systèmes kdb+ réels se composent de nombreux processus q, chacun ayant un rôle spécifique et communiquant les uns avec les autres.
Dans cette série en trois parties, nous allons construire une architecture kdb+ tick complète à partir de zéro. Nous commencerons par explorer les concepts et composants de base, puis nous mettrons en place une architecture fonctionnelle comprenant un tickerplant, une base de données temps réel (RDB), une base de données historique (HDB) et une passerelle (gateway). Enfin, nous l’étendrons en construisant des services Java pour interroger kdb+, s’abonner aux données en direct et publier des transactions via la bibliothèque client javakdb.
Anatomie d’une architecture Tick standard (Vanilla)
Le diagramme ci-dessous illustre ce à quoi ressemble une architecture tick standard. Passons en revue chaque composant pour comprendre son rôle au sein de l’écosystème.
Source de données — Le point d’entrée de l’architecture
Il s’agit d’une source de données en temps réel : cotations financières et transactions provenant de fournisseurs comme Bloomberg ou Refinitiv, relevés de capteurs industriels ou tout flux de données à haute fréquence. Ces flux arrivent généralement dans un format propriétaire spécifique au fournisseur.
Feed Handler — L’interface entre la source et kdb+
Son rôle est de parser les données entrantes de leur format propriétaire vers une structure que kdb+ peut ingérer. En pratique, plusieurs feed handlers peuvent fonctionner en parallèle pour collecter des données de différentes sources. KX propose les interfaces Fusion pour connecter kdb+ à diverses technologies comme R, Apache Kafka, Java, Python et C.
Tickerplant (TP) — Le composant le plus critique
Un processus q agissant comme tickerplant capture le flux de données initial, écrit chaque enregistrement dans un fichier log et publie les messages à tous les abonnés enregistrés. L’objectif principal est un débit à latence zéro, et il supporte l’ingestion de données en mode batch pour plus d’efficacité.
Au-delà du relais de données, le tickerplant gère les abonnements (ajout/suppression d’abonnés, envoi des définitions de tables) et le traitement de fin de journée (EOD). Le script tick.q fournit une implémentation de référence servant de point de départ.
Un principe de conception clé : les tickerplants doivent rester légers. Ils ne doivent pas stocker de données et consommer un minimum de mémoire. Pour une meilleure résilience, ils doivent s’exécuter sur des cœurs dédiés.
TP Log — Le fichier journal du tickerplant
Il enregistre chaque message reçu par le tickerplant. Son but principal est la récupération (recovery) : si la RDB plante, le fichier log est rejoué pour reconstruire l’état actuel et éviter toute perte de données.
Pour des performances optimales, le fichier log doit être stocké sur un disque local rapide afin de minimiser les délais de publication et les attentes d’E/S (I/O).
Real-Time Database (RDB)
Un processus q qui s’abonne au tickerplant et stocke tous les messages entrants en mémoire, rendant les données du jour disponibles pour des requêtes intraday.
Au démarrage, la RDB contacte le tickerplant et reçoit le schéma des données, l’emplacement du fichier TP log et le nombre de lignes à rejouer, garantissant qu’elle rattrape les données reçues avant sa mise en ligne. Ensuite, elle reçoit les mises à jour en direct.
En fin de journée, la RDB écrit ses données dans la base historique, envoie un message EOD et vide sa mémoire pour le jour suivant. Le script r.q sert de base de référence.
Real-Time Subscriber (RTS) — Ou moteur complexe d’événements (CEP)
Ce processus q s’abonne au tickerplant comme la RDB, mais au lieu de simplement stocker les données brutes, il exécute une logique additionnelle (ex: calcul d’un carnet d’ordres, maintien du dernier prix par instrument ou analyses en streaming).
Historical Database (HDB)
Un processus q qui fournit un accès aux données historiques stockées sur disque par la RDB en fin de journée. Les cas d’utilisation incluent les rapports d’exécution ou les analyses de défaillance de capteurs.
Les grandes tables sont partitionnées par date, chaque colonne étant sauvegardée dans son propre fichier. Cette structure sur disque est la clé de la performance de kdb+ : seules les partitions et colonnes pertinentes sont lues en mémoire, minimisant la charge d’E/S (I/O).
Gateway (GW)
Le point d’entrée unique pour les utilisateurs et applications externes. Il reçoit les requêtes et les route vers les processus appropriés (RDB, HDB ou RTS). Il peut combiner les résultats de plusieurs processus en une seule réponse et gère les permissions et l’équilibrage de charge.
Au-delà du standard : Architectures alternatives
Tickerplants en cascade (Chained Tickerplants)
Si le tickerplant principal publie chaque mise à jour immédiatement, abonner un client qui n’a besoin d’une mise à jour que toutes les quelques secondes est inefficace. Un chained tickerplant s’abonne au principal et republie les données à une fréquence inférieure. Il ne génère généralement pas son propre fichier log.
Par exemple, un tableau de bord graphique n’a pas besoin de centaines de mises à jour par seconde ; un batch toutes les 1000 millisecondes suffit amplement.
RDB en cascade (Chained RDBs)
Une chained RDB s’abonne au tickerplant mais ne gère pas le processus de fin de journée. L’avantage est l’isolation : les utilisateurs interrogent la RDB en cascade, laissant la RDB principale se concentrer sur la capture de données. Elle peut également ne s’abonner qu’à un sous-ensemble de données pour économiser la mémoire.
RDB en mode écriture seule (Write-Only RDB)
Si la RDB n’est jamais interrogée durant la journée, stocker toutes les données en mémoire est inutilement coûteux. Une write-only RDB tamponne les enregistrements et les écrit sur disque par lots dès qu’un seuil est atteint. Cela réduit drastiquement l’empreinte mémoire, bien que le processus ne soit alors pas adapté aux requêtes en temps réel.
Maîtriser les données de séries temporelles avec kdb+
Le monde des données à haute fréquence nécessite plus qu’un simple stockage ; il exige précision, rapidité et une architecture robuste. Comme nous l’avons vu dans cette première partie, l’architecture kdb+ tick est la colonne vertébrale du trading électronique moderne et de l’analyse en temps réel.
Prêt à implémenter votre propre système de données de marché ou à optimiser votre stack kdb+ existante ? Nos experts chez MARGO sont spécialisés dans le calcul haute performance et la technologie financière.
Échanger avec un expert MARGOPourquoi kdb+ est-il préféré aux bases de données SQL traditionnelles pour les données de marché ?
Les RDBMS traditionnels peinent face au volume et à la vélocité massifs des données de séries temporelles. kdb+ utilise un modèle de stockage orienté colonnes et un langage de traitement vectoriel (q), lui permettant de traiter des millions d’enregistrements par seconde avec une latence inférieure à la milliseconde.
Quelle est la différence fondamentale entre une RDB et une HDB ?
La Real-Time Database (RDB) conserve les données de la journée en cours en RAM pour un accès instantané. La Historical Database (HDB) fournit un accès aux données des jours précédents stockées sur disque, généralement partitionnées par date.
Comment le Tickerplant (TP) empêche-t-il la perte de données en cas de crash ?
Le TP écrit chaque enregistrement entrant dans un fichier TP Log sur disque avant de le publier. Si un abonné comme la RDB échoue, il peut rejouer ce fichier log au redémarrage pour reconstruire entièrement son état jusqu’à la dernière milliseconde.
Quand faut-il utiliser un Chained Tickerplant plutôt qu’un principal ?
Utilisez un Chained Tickerplant pour les consommateurs qui n’ont pas besoin de mises à jour tick-par-tick (comme les interfaces graphiques). En regroupant les mises à jour chaque seconde, vous déchargez le Tickerplant principal et réduisez la charge réseau pour les abonnés non critiques.
Java est-il compatible avec une architecture kdb+ ?
Absolument. Via la bibliothèque javakdb, les services Java peuvent agir en tant que feed handlers, s’abonner au Tickerplant pour des mises à jour en temps réel ou interroger la HDB via une Gateway, combinant la logique métier Java avec la performance de kdb+.
