Rapprochement de Kafka et Flink : Confluent tente d’arrondir les angles

Confluent mise sur l’expérience développeur

Gérer les déploiements de Flink SQL en même temps que les ressources Kafka depuis un seul environnement, rédiger, valider et déployer les requêtes Flink SQL, utiliser des templates de configuration de projets pour des applications de streaming et de flux de données… voilà les promesses de Confluent en ce qui concerne ce module VS Code.

Des fonctions UDF sont également accessibles depuis Azure pour appeler à l’aide de requêtes SQL des logiques spécifiques écrites en Java. Elles étaient déjà disponibles sur AWS depuis le début de l’année.

En accès anticipé cette fois-ci, les « Snapshot Queries » sont des requêtes qui permet de lire des données d’une table à un moment T au lieu de traiter les données en continu.

« Elles vous permettent d’exécuter une requête que vous pourriez effectuer sur des données en temps réel, mais elles fournissent des résultats en mode batch en utilisant Tableflow », explique Shaun Clowes, Chief Product Officer chez Confluent, auprès du MagIT. Le fait d’avoir un intervalle temporel clairement délimité permettrait d’obtenir des résultats 50 à 100 fois plus rapidement que d’utiliser un job de streaming sur des données historiques.

Pour l’instant, ce point dans le temps correspond à l’enregistrement des données au moment où la requête est exécutée. Il sera toutefois possible d’obtenir une fonctionnalité proche de ce que propose Iceberg avec le mode « Time Travel ». C’est-à-dire la possibilité de requêter des données historiques et de rejouer des événements.

En réalité, ce système fonctionne avec et sans Tableflow.

Sans Tableflow, au moment d’exécuter une requête snapshot, Flink détermine les offsets Kafka correspondants au marquage temporel à travers les partitions. Il lit les données des topics sources liés à ces offsets, traite les enregistrements pour reconstruire les tables au moment T du début de l’exécution avant de retourner un résultat.

Avec Tableflow, Query Snapshot lit les topics Kafka et les fichiers Parquet, depuis Confluent Managed Storage ou depuis S3 pour effectuer cette reconstruction.

« On obtient en quelque sorte le meilleur des deux mondes depuis Flink. Vous bénéficiez d’une traçabilité parfaite et d’une performance très rapide pendant la relecture et d’un traitement instantané lors du streaming de données » vante Shaun Clowes.

Des clients à convaincre

Certains utilisateurs se sont toutefois montrés sceptiques quant à l’utilisation de Flink.

« Nous sommes très prudents parce que nous gérons beaucoup d’argent et si une chose fonctionne, c’est qu’elle a été bien testée et nous la gardons ainsi », explique Uwe Jugel, ingénieur de données principal chez Upvest. Upvest est une fintech d’origine allemande qui fournit des services technologiques d’investissement aux néobanques dont Revolut, n26 ou encore Plum.

Upvest est en train de rendre compatible l’ensemble des données de ses domaines avec Kafka, ce qui n’était pas le cas jusqu’à présent.

 « Nous sommes en train d’investir pour que tout soit disponible dans le Schema Registry ».

Flink n’est donc pas la priorité pour la fintech. « Comment développer une application Flink ? Tel est le défi. Je sais comment développer une application et la déployer dans Kubernetes », affirme Uwe Jugel. « Mes équipes le savent toutes. Et c’est un processus de déploiement très résilient. Ils ont des tonnes de choses à faire pour déployer une nouvelle version d’un nouveau service et tout le reste », poursuit-il. « Tout cela doit fonctionner parfaitement avec une bonne orientation. Je pense que [Confluent Cloud for Apache Flink] doit prouver sa valeur. Si c’est meilleur que ce que nous avons déjà, alors nous investirons probablement ».

« Je peux comprendre les hésitations des gens », commente Shaun Clowes auprès du MagIT. « Flink est plus jeune de quatre ans que Kafka. C’est un écart relativement important dans le monde des infrastructures de données. Kafka a 13 ans et Flink 9 ans. Les deux technologies sont donc matures. Nous pensons que Flink est un moteur puissant et nous essayons de le prouver avec ces différentes fonctionnalités. C’est exercice nécessaire, car les usagers sont habitués et aiment leurs outils ».

« Cela va prendre du temps, mais selon moi, le cap qui est d’unifier Kafka et Flink au sein d’une expérience simple est bien fixé », déclare Fred Cecilia, Senior Solutions Engineer chez Confluent. « Nous allons déployer des fonctionnalités étape par étape et ce sont des choses qui vont prendre sens pour certains dès maintenant, et pour d’autres dans un ou deux ans », anticipe-t-il.  

Confluent se veut rassurant.

Le filtrage IP afin de s’assurer que Flink n’est accès qu’à des machines « de confiance » et l’adaptation au Confluent Cloud Network, c’est-à-dire de la compatibilité du service avec les réseaux privés cloud, sont disponibles.

Les mêmes fonctionnalités seront bientôt disponibles pour Schema Registry, un espace pour centraliser la gestion des schémas de données utilisés lors des traitements. Schema Registry pourra également être connecté à un VPC à l’aide d’AWS Private Link. Ce système gagne en popularité chez les utilisateurs de Confluent Cloud.

Toujours dans Confluent Cloud, trois connecteurs managés font leur apparition. Il est désormais possible d’effectuer des jobs Reverse ETL lié à Snowflake, tandis qu’Azure Cosmos DB v2 dispose d’un connecteur source et sink (pour pousser les données Kafka dans le DbaaS de Microsoft Azure). Le troisième connecteur a été annoncé en mars. Il s’agit d’un connecteur nommé Oracle Xtream CDC. Il doit multiplier par deux ou trois le débit des traitements Change Data Capture entre Oracle RAC et Confluent Cloud ou Confluent Platform, afin par la suite de répartir les données dans différents systèmes, dont S3, MongoDB Atlas ou Google BigQuery.

Aussi, Enterprise Clusters est désormais disponible dans 12 régions Google Cloud. Oui, Confluent Cloud est enfin disponible sur les trois hyperscalers à un niveau de service attendu par les grands groupes, assure l’éditeur.

L’enjeu de la gouvernance des données de streaming

En revanche, une fonctionnalité n’est pas encore accessible depuis GCP : Cross-Cloud Cluster Linking.

En disponibilité limitée, mais prête pour les charges de travail en production, celle-ci permet de répliquer les données au sein des clusters Kafka Entreprise et Dedicated entre Azure et AWS en utilisant une architecture de réseau « privé » dépendante du VPC et d’AWS PrivateLink.  

Une annonce semble intéressante pour les entreprises ayant largement déployé Confluent Cloud et Confluent Platform. Unified Stream Manager est présenté comme un futur « metadata control plane » permettant de superviser les données présentes dans les clusters sur site et dans le cloud à partir de Confluent Cloud.

« Nous n’essayons pas de vous obliger à placer vos données quelque part en particulier », résume Shaun Clowes. « Nous voulons simplement que vous sachiez où se trouvent vos données et que vous puissiez les déplacer ».

« De nombreux clients ont à la fois des clusters on-prem et cloud », affirme Fred Cecilia. « Les clusters en eux-mêmes, ce n’est pas le plus difficile à gérer. C’est la notion de schéma et de gouvernance qui est compliquée », insiste-t-il. « Il faut lier l’arrivée de cette couche de supervision à la mise à jour de notre centre de contrôle et la disponibilité du chiffrement des données au niveau des champs dans Confluent Platform. Pourquoi ? Parce que les clients veulent pouvoir gérer les données privées peu, importe où elles sont déployées ».