Tableflow : Confluent travaille au rapprochement de Kafka et d’Iceberg

Apache Flink est disponible dans Confluent Cloud

Mais l’annonce phare du Kafka Summit n’est autre que la disponibilité générale de la version managée de Flink dans Confluent Cloud sur AWS, Azure et GCP. Pour rappel, l’éditeur avait annoncé une préversion en septembre dernier. Confluent a décidé d’intégrer ce moteur de traitement de flux de données quand il a remarqué qu’il devenait de plus en plus répandu dans l’architecture de ses clients. L’éditeur mise sur le fait que la technologie prend en charge le standard SQL (ANSI). Ces requêtes peuvent être écrites depuis le CLI de Confluent ou depuis des espaces de travail (SQL Workspacces) permettant de « d’exécuter plusieurs requêtes SQL complexes et concurrentes ». Pour les connaisseurs, l’interface ressemble à celle de Snowflake ou Starburst.

L’éditeur a aussi développé des « Flink Actions », un ensemble de transformations de données préconfigurées accessibles depuis un « portail de données ». Confluent donne deux exemples pour dédupliquer des topics Kafka et pour masquer des champs dans un topic en entrée. En accès anticipé, il rend disponible des UDFs (User Defined Fonction) afin « d’étendre la portée des requêtes SQL ». Pour l’heure, ces UDFs sont compatibles avec Java, mais la prise en charge de Python est déjà prévue. Par ailleurs, la prise en charge d’APIs Flink pour accéder aux données gérées par le moteur a été améliorée. Pour le reste, l’éditeur entend apporter le même type de fonctionnalités censées assurer la robustesse et la sécurité des charges de travail Kafka à celles dédiées à Flink, dont le data lineage.

« Traditionnellement, une quantité importante de données sont dupliquées entre un flux de stream et un lakehouse. Donc au lieu de forcer la lecture et la copie des données au format Iceberg dans un autre bucket S3 pourquoi ne pas unifier les deux ? ».

Outre le rapprochement progressif de Kafka et de Flink, Confluent s’attaque à un autre projet d’envergure : la simplification de l’ingestion de données depuis Kafka dans des tables Apache Iceberg. L’éditeur décrit un processus fastidieux pour équilibrer l’infrastructure, convertir les données au format Parquet, gérer l’actualisation et la compatibilité des schémas Kafka, optimiser les fichiers et s’assurer que les changements de données sont bien pris en compte.

Or, dans Confluent Cloud, les données sont déjà représentées dans un espace de stockage objet, le plus souvent dans un bucket Amazon S3 ou Azure Blob Storage. « Cela veut dire que, traditionnellement, une quantité importante de données sont dupliquées entre un flux de stream et un lakehouse », résume Marc Selwan, Staff Product Manager chez Confluent, dans un post de blog. « Donc au lieu de forcer la lecture et la copie des données au format Iceberg dans un autre bucket S3 pourquoi ne pas unifier les deux ? ». Selon Confluent, il y a double intérêt à cela : réduire le volume de stockage et rapprocher les données opérationnelles des données analytiques. De même les données ingérées en batch et en streaming existeraient sous un même statut.

Confluent veut simplifier la fusion des données opérationnelles et analytiques

Tableflow permet de représenter les topics Kafka et les schémas associés dans des tables Iceberg. L’outil s’appuie sur les briques de la couche de stockage Kora pour prendre les segments de données Kafka et les écrire au format Parquet. Mais une table Iceberg n’existe pas sans son lot de métadonnées, souvent (systématiquement ?) gérées par le métastore Apache Hive. « Sous le capot, un matérialiseur crée les métadonnées Iceberg tout en gérant le mapping du schéma, son évolution, et les conversions de type », indique Marc Selwan.

Sur la scène du Kafka Summit, la démonstration sur un petit jeu de données fut si rapide que votre serviteur n’a pas pu la voir parce qu’il avait baissé la tête pour prendre des notes. Le temps de la relever deux secondes plus tard, c’était fini.

Tableflow est pour l’heure un concept très intéressant, mais quelle est sa réelle utilité ?

« Le principal cas d’usage est le suivant : “comment puis-je introduire l’état actuel de l’entreprise dans mes systèmes analytiques, dans mon entrepôt de données pour les rapports ?” », avance Jay Kreps, cofondateur et CEO de Confluent à la question du MagIT.

« C’est un cas d’usage courant pour Confluent aujourd’hui, mais en l’absence de source unique de vérité, cela demande beaucoup plus de travail ».

Entre l’ingestion des données et leur stockage dans un data warehouse, Confluent met l’accent sur le rôle d’Apache Flink, qui peut alors être utilisé pour gérer à la volée des transformations de données : joindre des topics, masquer des données, les dédupliquer, etc.

« Les données peuvent être traitées et mises en forme dès leur arrivée. Ainsi, même un entrepôt de données normal sans modifications spéciales, s’il prend en charge Iceberg en tant que format de requête, vous pouvez avoir accès à des données prêtes à l’emploi, non pas en quelques millisecondes comme vous pouvez le faire avec le flux [Kakfa], mais en quelques minutes. Pour les entrepôts de données, c’est du temps réel. », poursuit Jay Kreps. 

Tableflow doit encore faire ses preuves

Tableflow sent encore la peinture fraîche. Pour le moment, Confluent stocke les tables Iceberg dans les buckets S3 de sa plateforme. Pour y accéder, il faut utiliser l’API REST catalog d’Iceberg et une clé API Confluent Cloud avant de connecter les tables à un moteur capable de lire les tables. L’éditeur travaille à la compatibilité des tables avec des services de cataloging, dont AWS Glue. Il est d’ores et déjà prévu que les tables Tableflow puissent être directement stockées sur le stockage objet du client ou de sa plateforme de données. L’éditeur a déjà « partagé sa vision » à ses partenaires, dont Snowflake, Starburst, Imply, Dremio, AWS (Athena) et Onehouse. Ils se seraient montrés enthousiastes, selon Jay Kreps.

Dans un premier temps, Tableflow doit permettre l’ingestion de données dans des tables Iceberg depuis l’architecture Kora. Dans une deuxième phase, le lien entre Confluent Cloud et un Data Warehouse compatible sera bidirectionnel. Dans une troisième phase, Confluent veut rendre toutes les tables Iceberg consommables à travers Kafka.

Kafka et Flink sont deux technologies réputées pour leur complexité, surtout au moment de les déployer en production. Pour autant, Confluent, qui avance son expertise dans la gestion des déploiements dans le cloud, n’est pas le seul à s’intéresser au rapprochement des topics Kafka et des tables Iceberg. L’année dernière, Tabular a partagé sur le Hub de Confluent, un répertoire consacré aux connecteurs Kafka, un moyen d’ingérer des données depuis des topics dans des tables Iceberg à la manière de Tableflow. La startup rappelle que Flink peut déjà écrire dans plusieurs tables Iceberg simultanément, sans toutefois bénéficier des avantages de Kafka.