Confluent Platform : la plateforme Data Streaming tout-en-un

Confluent Platform est une plateforme de données spécialisée dans l'ingestion, la distribution et le traitement de données en temps réel. Basé sur la plateforme Apache Kafka et développée par les mêmes créateurs que cette dernière, elle est devenue incontournable pour beaucoup d'équipes et de Data Engineer, car elle vient compléter Apache Kafka avec de nombreuses fonctionnalités. Confluent Platform est aujourd'hui un incontournable pour les entreprises qui souhaitent déployer et exécuter des plateformes Data en temps réel dans des environnements de production.

Dans cet article, nous allons étudier les principales différences entre Apache Kafka et Confluent Platform, et décrire quels sont les améliorations de cette dernière.

C'est quoi Apache Kafka ?

Apache Kafka est une plateforme open source d'agents de messages (brokers) en temps réel. Cette plateforme permet à la fois de diffuser des données à grande échelle (event streaming) et d'effectuer des traitements sur ces données en temps réel (stream processing). Depuis plusieurs années, Kafka s'impose comme la référence pour diffuser et traiter des centaines de Go de données à grande échelle, tout en assurant une haute disponibilité de services.

Un sujet essentiel sous Kafka est la notion de topic. Un topic est une catégorie où des messages (appelés records ou enregistrements) sont produits, similaire à une messagerie où chaque mail arriverait par ordre d'envoi. Chaque message contient une donnée envoyée sur Kafka, et peut être vu comme une unité atomique par rapport à un contexte, comme

les événements utilisateurs sur un site Web (page visitée, clic sur un bouton, défilement de la page) ;
les transactions financières (un virement, un prélèvement, un ajout de bénéficiaire) ;
les événements d'un réseau social (une vue, un like, un commentaire, un clic) ;
les capteurs IoT (température, humidité, luminosité).

Les applications qui vont agir sur les topics sont les producers (produceurs) et les consumers (consommateurs), codés principalement en Java ou en Python. Cette représentation se base sur le modèle publish-subscribe : des applications vont envoyer des données sur des topics (publish), et d'autres vont consommer ces données depuis des topics (subscribe), sans avoir de couplage direct de part et d'autre.

L'histoire de Confluent Platform

Initialement, Apache Kafka avait été développé par LinkedIn qui avait des besoins spécifiques en terme d'agent de messages hautement scalable. L'équipe ayant développé Kafka a ouvert le code source en 2011, repris ensuite en 2012 par la fondation Apache.

À lire aussi : découvrez notre formation Data Engineer

De plus en plus d'entreprises utilisent Kafka, et connectent différents services avec. Les auteurs de Kafka ont alors crée, en 2014, Confluent, qui propose des services autour de Kafka, et notamment Confluent Platform, qui est une plateforme de streaming dont Kafka est le composant principal. Mais le gros atout de cette plateforme est qu'elle dispose également de nombreuses fonctionnalités supplémentaires qui viennent apporter une bien meilleure utilisation de Kafka dans les systèmes en production.

Le composant Kafka Connect permet de créer des connexions directes depuis ou vers des bases de données (SQL, BigQuery, MongoDB, etc) avec Kafka. Ainsi, plus besoin de créer des consumers pour faire de la migration de données, car les connecteurs vont prendre en charge cette tâche.
Le moteur ksqlDB qui permet de créer des tables relationnelles alimentées directement via Kafka.
Le Schema Registry permet de gérer et de versioner des schémas de données, que nous aborderons très bientôt.
Le proxy REST pour pouvoir surveiller et administrer le broker Kafka et ses composants à distance, sans être connecté sur la machine.

Confluent dispose d'une version gratuite (Community) et d'une version commerciale. La version gratuite dispose uniquement des fonctionnalités essentielles (fichiers binaires Apache Kafka et outils de développement et connectivité) et ne permet d'exécuter qu'une seule instance Confluent. Si l'on souhaite avoir à disposition plus de fonctionnalités ou exécuter Confluent dans un cluster (recommandé pour la production), alors on préférera utiliser la version commerciale.

Voyons quelles sont les fonctionnalités essentielles de Confluent, accessibles sous toutes les versions.

Kafka Connect

Sous Kafka, les connecteurs permettent d'effectuer des migrations entre des bases de données/systèmes de stockage de fichiers et Kafka. Cela est donc particulièrement utile lorsque l'on souhaite faire des migrations de données sans mobiliser des ressource supplémentaires en créant un consumer. Nous retrouvons principalement deux types de connecteurs.

Les Sink Connectors qui vont s'abonner à un ou plusieurs topics et insérer de nouvelles données dans une base de données ou dans un système de stockage de fichier.
Les Sources Connectors qui à l'inverse, vont surveiller l'activité d'une base de données ou d'un système de stockage de fichiers, et alimenter un ou plusieurs topics lorsqu'un nouvelle donnée est insérée.

Le principale avantage des connecteur est d'éviter de développer soi-même un consumer qui irait transférer des données entre un système de stockage et Kafka. Ici, le connecteur va gérer toute cette complexité à notre place.

Pour cela, Confluent propose une panoplie de connecteurs déjà développés et prêts à l'emploi, mis à disposition sur Confluent Hub, une plateforme qui recense tous les connecteurs (officiels ou ceux développés par la communauté).

Schémas de données

En utilisant Kafka, on remarque rapidement qu'il n'y a aucune nomenclature sur la façon dont les messages sont envoyés et inscrits dans les topics. Pire, il pourrait y avoir plusieurs typologies de messages arrivant sur un même topic. Comment pouvons-nous faire en sorte que les messages sur les topics respectent certaines formes ?

Le registre de schémas (SchemaRegistry) est une application qui permet d'homogénéiser la communication de messages entre les producers/consumers et Kafka dans le but de structurer les messages entrants et sortants sur les topics. Confluent va justement embarquer un registre de schéma, permettant d'ajouter une certaine homogénéité aux topics.

Registre de schémas

Les formats de données évoluent constamment, surtout dans les infrastructures Big Data. Les schémas permettent de garder une cohérence sur la structure des données tout au long de l'utilisation du broker. Non seulement le format des données va évoluer, mais également la manière dont elles sont produites et qui va les utiliser.

Le registre de schéma défini un environnement de plusieurs versions de schémas comme étant un sujet. Dans un sujet, on retrouve alors plusieurs versions de schémas qui permet donc d'identifier le même topic par exemple, mais avec des versions de schémas différentes. Le nom d'un sujet va dépendre d'une stratégie qui défini la manière dont Kafka doit appréhender ces différents schémas.

Le stratégie par défaut TopicNameStrategy reprend le nom du topic pour le nom d'un schéma. Si l'on dispose d'un topic nommé mytopic, alors le sujet devra commencer par mytopic-....
La stratégie RecordNameStrategy permet de lier cette fois-ci un message (record) avec un sujet : c'est utilisé notamment lorsqu'au sein d'un même sujet, il y a plusieurs structures différentes.
La stratégie TopicRecordNameStrategy qui est similaire à la précédent, mais qui ne s'effectue qu'à l'échelle d'un seul topic, contraitement à RecordNameStrategy qui peut référencer des messages sur des topics différents.

Pour résumer, la stratégie TopicNameStrategy est utilisée lorsque tous les messages d'un topic possèdent la même structure. Dans le cas échéant, on s'orientera vers l'une des deux stratégies restantes, lorsque par exemple il y a plusieurs schémas possibles dans un seul topic ou qu'un schéma se retrouve dans des messages sur plusieurs topics.

À lire aussi : découvrez notre formation Data Engineer

Si l'on regarde de plus près la stratégie par défaut, nous devons adopter une certaine convention sur le nommage des sujets.

Lorsqu'un schéma porte le nom <topic>-value, alors les messages du topic topic pourront être sérialisés et désérialisés par le schéma correspondant.
De même, lorsqu'un schéma porte le nom <topic>-key, le principe s'opère mais pour les clés des messages.

Comment fonctionne un schéma ? En réalité, la définition d'un schéma est assez simple : il s'agit d'un format JSON dans lequel nous allons définir les différents champs avec leurs types associés, leur valeur par défaut et d'autres informations.

C'est au moment de la sérialisation (transformation au format binaire) ou de la désérialisation que le schéma est utilisé pour vérifier que les données respectent la structure imposée.

Nous avons alors besoin d'utiliser un système de sérialisation de données comme Apache Avro.

Apache Avro

Avro est un système de sérialisation de données, au même titre que Protobuf ou Thrift. Sous un format binaire, Avro permet de stocker les données ainsi que leurs schémas au même endroit : il s'intègre donc facilement sous la plupart des langages.

Pour définir un schéma, Avro utilise le format JSON pour ensuite sérialiser au format binaire. Nous retrouvons la plupart des types élémentaires (null, int, float, string, ...) mais également des types plus complexes (record, enum, array, ...).

Prenons le schéma suivant :

{
  "type": "record",
  "name": "schema",
  "namespace": "org.blent.data_engineer.schema",
  "fields": [
    { "name": "fname", "type": "string" },
    { "name": "lname", "type": "string" },
    { "name": "age", "type": ["int", "null"] }
  ]
}

En regardant le champ fields, il y a trois champs enregistrés par le schéma.

Le champ fname, de type string.
Le champ lname, de type string.
Le champ name, de type int mais qui peut être manquant.

Tout message qui se conforme aux exigences précédentes pourra être envoyé sur le topic Kafka associé avec ce schéma. Dans le cas échéant, ce dernier sera refusé.

Producer avec Avro

Si l'on souhaite sérialiser au format binaire tout en s'assurant que la structure des données respecte un schéma, il nous faut utiliser un producer qui supporte Avro. Il y a alors deux cas de figures.

Le producer peut envoyer sa propre version de schéma sur un sujet correspondant au registre de schéma. Attention toutefois, pour que le registre de schéma accepte ce nouveau schéma, il faut que ce dernier soit compatible avec les anciennes versions (il est possible de désactiver la vérification de la compatibilité, mais c'est déconseillé).
Le producer récupère la version la plus à jour depuis le registre de schéma. Cette option est utile notamment si l'on ne souhaite pas donner la possibilité aux producers d'utiliser leur propre schéma : il faudra en revanche gérer les schémas pour s'assurer qu'il y en a un sur les topics où cela est nécessaire.

Sous une configuration classique, l'utilisation d'un schéma avec une sérialisation Avro s'effectue en plusieurs étapes.

Le producer envoie un schéma vers le registre de schéma.
Le registre de schéma ajoute le nouveau schéma ou le rejette en cas d'incompatibilité.
Le registre de schéma retourne un identifiant unique au producer. Si le schéma que le producer a envoyé existe déjà, le registre de schéma retournera l'identifiant existant du schéma correspondant.
Le producer garde en mémoire le schéma qu'il va charger avec Avro.
Le producer utilise le schéma pour vérifier que les données respectent bien le schéma et sérialise le message au format binaire pour l'envoyer à Kafka.

Cette structure permet de faire en sorte que les producers enregistrent eux-mêmes les schémas (bien qu'ils peuvent également les récupérer directement depuis le registre) si besoin, puisqu'ils sont les créateurs de ces données.

Base SQL temps réel avec ksqlDB

De manière générale, nous pouvons mettre en place deux actions en tant que consumer sur ce topic : faire de la migration de données (transfert vers BigQuery, S3, PostgreSQL, etc) et de l'analyse de données. Cette dernière action est intéressante car elle permettrait de connaître sur des fenêtres temporelles de plusieurs secondes/minutes la situation en temps réel des trajets. Avec une source de données comme Kafka, nous avons plusieurs possibilités.

Kafka Streams permet de développer des applications Java ou Scala pour consommer des données depuis un topic. Cela nécessite de gérer soi-même le support d'exécution de la JVM (sur un serveur que l'on provisionne).
Un moteur temps réel (Spark Streaming, Flink, etc) qui permet de développer des applications dans plus de langages et qui seront exécutables dans un cluster de plusieurs serveurs (utile lorsque le débit depuis Kafka est très important).
Une exécution légère avec ksqlDB qui permet d'exécuter des requêtes SQL pour construire des tables qui s'auto-alimentent.

À lire aussi : découvrez notre formation Data Engineer

Cette dernière possibilité est la plus simple à mettre en place dans notre situation, car d'une part ksqlDB est déjà installé avec Confluent, mais d'autre part car l'utilisation de tables SQL est beaucoup plus facile à utiliser.

Quand utiliser Confluent Platform ?

De manière générale, Confluent Platform peut être un bon choix dès lors qu'Apache Kafka pourrait être utilisée, c'est-à-dire dans les situations où il faut gérer et/ou traiter des données en temps réel. Cependant, pour certains cas, il serait préférable d'utiliser la version commerciale de Confluent Platform.

Pour des raisons de sécurité et de gouvernance, car Confluent dispose de modules RBAC (accès conditionné par des rôles) et de mécanismes d'authentification.
Lorsque l'on souhaite avoir de nombreux outils de suivi, de monitoring et d'intégration avec d'autres applications existantes.
Lorsque l'on ne souhaite pas gérer soi-même tout la partie infrastructure et exécution avec l'offre Confluent Cloud.

En bref, utiliser Confluent se révèle très pratique pour satisfaire un niveau d'exigence et de disponibilité d'application élevée, tout en bénéficiant d'un large éventail d'outils et de fonctionnalités très pratiques.