Bienvenue dans la deuxième partie de cette série sur la construction d’une architecture kdb+ tick. Dans la première partie, nous avons abordé les concepts de base et passé en revue chaque composant — du tickerplant et RDB/HDB/RTS à la passerelle et au-delà.
Il est maintenant temps de passer de la théorie à la pratique : dans cette partie, nous allons configurer et exécuter une architecture kdb+ tick complète à partir de zéro.
Configuration de l’environnement kdb+/q
Avant de pouvoir lancer notre architecture tick, nous devons installer et configurer kdb+ et q sur notre machine. Rendez-vous sur kx.com/kdb-personal-edition-download pour télécharger l’édition personnelle gratuite pour votre système d’exploitation.
Alternativement, si vous préférez ignorer totalement la configuration locale, vous pouvez utiliser le bac à sable gratuit (JupyterLab) fourni sur la KX Academy — aucun prérequis n’est nécessaire, tout s’exécute dans le navigateur.
Une fois téléchargé et décompressé (par exemple dans C:\q), vous devez configurer vos variables d’environnement :
Définir QHOME :
setx QHOME "C:\q"
Ajouter au PATH :
setx PATH "%PATH%;C:\q\w64"
Clonage du dépôt git KxSystems
Clonez le dépôt suivant pour obtenir les scripts d’architecture d’exemple :
git clone https://github.com/KxSystems/kdb-architecture-course.git
Démarrage du Tickerplant (TP)
Le tickerplant est le cœur de l’architecture. Lancez-le avec :
q tick.q sym . -p 5010
Le fichier sym.q définit notre table trade :
trade:([]time:`timespan$();sym:`g#`symbol$();price:`float$();side:`symbol$())
Démarrage de la Real-Time Database (RDB)
La RDB s’abonne au tickerplant et conserve les données intraday en mémoire. Lancez-la avec :
q tick/rdb.q -p 5011
Démarrage du Feed Handler
Le feed handler génère et envoie les données au tickerplant. Lancez-le avec :
q tick/feed.q
Il ouvre une connexion et génère des transactions aléatoires chaque seconde :
h_tp:hopen 5010;system"t 1000";
Démarrage de la Historical Database (HDB)
La HDB sert les données à partir du disque. Lancez-la avec :
q tick/hdb.q sym -p 5012
Pour simuler un événement de fin de journée (EOD), exécutez ceci sur le tickerplant :
q).u.endofday[]
Démarrage du Real-Time Subscriber (RTS)
Le RTS exécute une logique personnalisée sur les données entrantes. Lancez-le avec :
q tick/rts.q -p 5013
Il maintient le dernier prix par symbole :
latestSymPrice: `sym xkey 0#trade;`latestSymPrice upsert select by sym from d
Démarrage de la Gateway
La gateway est le point d’entrée unique pour les requêtes. Lancez-la avec :
q tick/gw.q -p 5014
Elle route les requêtes vers la HDB et la RDB :
h_hdb:hopen 5012; h_rdb:hopen 5011;hdb,rdb
De la théorie à la pratique avec kdb+
Construire une architecture tick entièrement opérationnelle est une étape cruciale dans la maîtrise de kdb+. En connectant le Tickerplant, la RDB, la HDB et la Gateway, vous disposez désormais d’un système capable de gérer l’intégralité du cycle de vie des données à haute fréquence.
Prêt à faire évoluer votre architecture ou à l’intégrer dans votre environnement Java d’entreprise ? Nos experts chez MARGO sont là pour vous aider à naviguer dans la complexité de l’ingénierie des données en temps réel.
Contacter nos expertsQu’est-ce que QHOME et pourquoi est-ce obligatoire pour la configuration ?
QHOME est une variable d’environnement qui indique au système kdb+ où trouver ses fichiers et bibliothèques de base. Sans elle, l’interpréteur q ne peut pas charger les fonctions ou scripts essentiels nécessaires au fonctionnement de l’architecture tick.
Comment vérifier si un abonné est correctement connecté au Tickerplant ?
Vous pouvez exécuter la commande .u.w dans le processus Tickerplant. Elle renverra un dictionnaire listant tous les abonnés actifs et les tables spécifiques qu’ils surveillent, comme la RDB ou l’RTS.
Qu’advient-il des données de la RDB lors d’un événement de fin de journée (EOD) ?
Lors de l’EOD, le Tickerplant avertit la RDB de sauvegarder toutes ses données en mémoire sur le disque sous forme de nouvelle partition de date. Une fois la sauvegarde terminée, la RDB vide ses tables locales pour recommencer à zéro le lendemain.
Pourquoi kdb+ utilise-t-il l’énumération de symboles dans la HDB ?
L’énumération des symboles mappe les chaînes de caractères à des entiers dans un fichier sym. Cette optimisation réduit considérablement l’utilisation de la mémoire et accélère les requêtes sur de grands ensembles de données historiques en évitant le stockage redondant de chaînes de caractères.
La Gateway peut-elle gérer simultanément des requêtes pour aujourd’hui et hier ?
Oui. La Gateway est conçue pour router une seule requête à la fois vers la RDB (données temps réel) et la HDB (données historiques), en fusionnant les résultats en une seule réponse transparente pour l’utilisateur final.
