Barbara
AMÉLIORATION D’UN PROJET DE STREAMING EN TEMPS RÉEL AVEC KSQLDB
Dans un précédent article, nous avons exploré les composants d’un projet de streaming en temps réel qui consomme et traite les données de capteurs de smartphones avec FastAPI, Kafka, QuestDB, et Docker. Ce projet était une première tentative d’implémenter une architecture capable de déplacer les données de streaming des smartphones, à travers un log de Kafka, et dans une base de données de séries temporelles où les données peuvent être facilement interrogées et traitées. Le produit final était un tableau de bord qui interrogeait la base de données et affichait les lectures des capteurs en temps quasi-réel.
UN OBJECTIF COMMUN
Un critique de ce projet était l’introduction d’une latence inutile due à l’écriture de données de Kafka dans la base de données, et à l’interrogation de la base de données pour afficher les lectures des capteurs les plus récentes. Lorsque notre objectif principal est d’analyser les données en temps quasi-réel, écrire dans et lire à partir d’une base de données devient inefficace.
C’est l’un des problèmes pour lesquels KSQLDB a été créé pour résoudre. Au lieu d’écrire des données dans la base de données et de les interroger pour l’analyse, KSQLDB permet un traitement et une analyse directs des flux de données, éliminant ainsi le besoin de persister les données dans une base de données avant d’y accéder.
Dans cet article, nous allons étendre le précédent en introduisant KSQLDB pour interroger et traiter des données de streaming. Contrairement à la surveillance traditionnelle de la base de données, la mise en œuvre des requêtes push dans KSQLDB réduit considérablement la latence sur le tableau de bord et simplifie l’infrastructure du backend. Tout le code utilisé pour créer ce projet est disponible sur GitHub.
REDUIRE LA LATENCE PERCEPTIBLE
L’objectif de ce projet est le même que précédemment: développer un tableau de bord en temps réel qui visualise les données de capteurs. Cependant, dans cette itération, notre objectif est de réduire au minimum la latence perceptible entre le téléphone et le tableau de bord en exploitant la puissance de KSQLDB.
L’architecture de ce projet est plus simple que précédemment car QuestDB, et son consommateur ne sont plus nécessaires pour déplacer les données vers le tableau de bord.
Trois applications FastAPI sont écrites pour faciliter le flux de données et la visualisation: le producteur, le frontend de tableau de bord, et le backend de tableau de bord. Ces applications, avec Kafka et KSQLDB, sont orchestrées via le docker-compose.
KSQLDB est un moteur de streaming open-source conçu pour traiter, analyser et transformer des flux de données en temps réel de Kafka en utilisant une syntaxe similaire à SQL. En somme, KSQLDB permet d’interagir avec des données dans des sujets Kafka en utilisant des concepts de base de données relationnelle familiers tels que les tables, les requêtes, les vues matérialisées, les jointures et les agrégats.
La commande KSQLDB est utilisée pour créer un flux à partir du sujet qui stocke les lectures de capteurs de smartphone (les données écrites par le producteur).
Une requête push est exécutée pour récupérer des lectures de capteurs à mesure qu’elles sont écrites sur le sujet. En substance, une requête push ouvre une connexion à longue durée qui envoie des mises à jour à un client chaque fois que de nouvelles données sont reçues sur le sujet. Cela fait des requêtes push un bon choix pour le streaming de données de smartphone.
