Si vous êtes ici, alors les notions de Apache Kafka ne vous sont pas totalement inconnues : c’est une plateforme de “Streaming événementiel”, basée sur l'architecture événementielle, qui permet de produire et consommer des flux d’événements (event streams) immuables et non bornés - oui le mot événement est redondant je le sais.
Apache Kafka vient avec son lot d’API de développement pratique et avec cela, quasiment n’importe quelle compagnie qui manipule de grandes quantités de données est déjà comblée.
Mais si je vous dis qu’il existe encore mieux ? Quelque chose qui est directement bâtie sur ces API et qui tend à se rapprocher des bases de données relationnelles pour une plus grande aisance de compréhension, de manipulation et qui ne nécessite pas de déploiement, pas (ou peu) de code ? C’est un mirage, un avion ou Superman ? Non ! Je parle de ksqlDB !
KSQL : littéralement, la cerise sur le sundae 🍒
StreamsAPI de Apache Kafka fournit un ensemble de fonctionnalités qui permet entre autres choses, de pouvoir transformer, agréger ou fusionner des données provenant de Kafka. Cependant, les KStreams restent des applications à part entière qui ont besoin d’un développement, de tests, de déploiements.
Or quand nous parlons de données, la question de que fait-on de ces données, quelles sont les règles métiers, comment faire est souvent répondu par des analystes ou des personnes du métier, pas forcément des équipes de DEV/OPS.
De plus, il arrive en général que les analystes n'aient pas un bagage en TIs, en conception logicielle et ne connaissent pas les impacts de certaines fonctionnalités qui leur paraissent mineures. Vous savez, ces fonctionnalités qui remettent en cause tout ce qui a été fait précédemment…
Dans le domaine de la gestion des données, que ce soit des données “small data” ou Big Data - jeu de mots pas génial, je sais - les analystes ne savent pas d’avance ce qu’ils peuvent ou veulent faire et ils ont ce besoin exploratoire de fouiller dans les données.
Et tel un héros de l’ombre, ksqlDB vient à la rescousse : en effet, plutôt que de partir sur le développement de KStreams, ksqlDB offre la possibilité de faire de l’exploration de données.
Voici une liste non exhaustive de ce qui est à la portée de mains des analystes et des équipes (avec comme prérequis de connaître SQL et d'avoir des bases en Kafka et en ksqlDB, notamment grâce une petite formation avec moi 😉 ) :
Voir la liste des topics d’événements
Afficher en temps réel les données
Faire des requêtes en SQL (non AINSI compliant) sur les données
Créer des Streams et des KTables
Mais je vous vois venir : “on peut déjà faire cela avec les outils en ligne de commande de Kafka (Kafka CLI)”. Ma réponse est oui.
Cependant, est-ce possible de faire de l’analyse en temps réel sur des données ?
Analyse en temps réel : un point fort pour les analystes
Qui dit Big Data, dit souvent analyses de données sur de forts volumes, avec des moyens pour surveiller les données, les suivre ou encore faire des alertes (monitoring, tracking, alerting). Pour la modélisation, la Big Data s’appuie des cubes de données multidimensionnels, appelés OLAP (Online analytical processing) dont un des axes majeurs est le temps.
SQLDB permet notamment de créer des streams avec des fenêtres de temps. Par exemple pour compter le nombre de transactions avec une carte crédit effectuée dans un laps de temps court, afin de détecter une fraude ; ou encore le nombre de fois que le message “ERROR” apparaît dans les journaux applicatifs dans la dernière minute. Tout cela est rendu aussi simple qu’une requête SQL avec l’ajout d’un mot clé : WINDOW. Il existe 4 types de façons de créer une fenêtre de temps : Tumbling, Hopping, Sliding, Session.
CREATE TABLE nombre_derreurs
SELECT code_derreur, count(*)
FROM journaux_app1
WINDOWS HOPPING (SIZE 60 SECOND)
WHERE type = ‘ERROR’
GROUP BY code_derreur; Autre force majeure : les transformations de données
Basée sur StreamsAPI, ksqlDB est aussi utile pour faire des transformations de données et de formats de données.
Commençons par un exemple, pour faire du filtrage : vous êtes une compagnie de support avec plusieurs niveaux de services. Toutes les requêtes de support sont centralisées vers un seul et unique topic d’événements. Par contre, vous souhaitez que les demandes pour les clients Diamant soient acheminées différemment. Pour s’éviter le développement et la maintenance d’une micro application que ne ferait juste que du filtrage, ksqlDB offre la possibilité de créer un nouveau flux d’événements avec une clause WHERE.
CREATE STREAM demande_clients_diamant A
SELECT client_id, demande, FROM demande_topic_central main
LEFT JOIN client c ON c.client_id = main.client_id
WHERE c.niveau = ‘Diamant’;Bien évidemment, d’autres types de transformations sont de la partie comme les agrégations, les fusions, la création de vue matérialisées, joindre des données depuis des sources et des destinations de données externes (grâce aux connecteurs Kafka)...
Et donc ksqlDB c’est…
Un outil incroyable si vous avez besoin de jouer avec vos données, et que vous n’avez pas envie de faire une myriade d’applications microservices.
Cela vous permet d’avoir un véritable ETL intégré dans votre écosystème Kafka et de pouvoir manipuler des énormes quantités de données, d’événements avec un langage "SQL-like" aux possibilités grandes.
Donc si Kafka est intégré dans votre environnement, et que vous souhaitez économiser vos efforts - et votre argent - pensez KSQLDB avant de partir sur le développement tête baissée. D'autant plus qu'en terme de découplage de responsabilités applicatives ksqlDB peut s'inscrire dans le patron CQRS. Et encore mieux amis développeurs, cela peut aussi laisser le temps et la possibilité aux analystes de chercher exactement ce qu'ils veulent et le faire par eux-mêmes - bonne nouvelle pour le découplage de responsabilités humaines sur un projet n'est-ce pas ?
Pour en revenir et comme je le conseille souvent : bien réfléchir avant évite de se casser la tête après.
Pour finir, voici une vue macro de Apache Kafka avec ses parties clients "terminales" (Producer, Consumer, Connect Source, Connect Sink), ses parties clients de manipulation de flux d'événements (KStreams et ksqlDB) et la partie centrale : le cluster de broker (ainsi que Zookeeper, Schema Registry et autre qui ne sont pas représenté ici).
Comentarii