Tableflow : Confluent tient son pont entre Kafka et les plateformes analytiques
Avec la disponibilité générale de Tableflow, l’éditeur entend simplifier l’ingestion de données depuis Kakfka dans des tables au format ouvert. S’il a commencé par Apache Iceberg, Confluent prévoit de prendre en charge Delta Lake de Databricks.
À la fin du mois de mars, Confluent a annoncé la disponibilité générale de Tableflow sur AWS. Présentée lors du Kafka Summit 2024 à Londres, cette technologie doit permettre d’ingérer des données de streaming dans des tables au format ouvert puis les rendre interrogeables par des moteurs de traitement analytiques. « Le résumé en une ligne c’est exactement ça, mais si l’on s’arrête à cela, l’on rate le plus intéressant », affirme Fred Cecilia, Senior Solutions Engineer chez Confluent.
Plus précisément, Tableflow permet d’ingérer des données en provenance de topics Apache Kafka dans des tables Apache Iceberg et, en accès anticipé, des tables Delta Lake. « Dans le principe, ce n’est pas nouveau, mais c’est “galère”. Il faut mettre en place des connecteurs, les gérer, convertir les métadonnées, gérer le changement de schémas, etc. », indique l’ingénieur avant-vente. « Nos clients nous exprimaient cette souffrance ».
Les messages Kafka sont sérialisés au format Avro, JSON ou Protobuf alors que la plupart des entrepôts de données modernes utilisent Parquet. Tout comme l’évolution du schéma, cela réclame de mettre en place des flux de travail spécifiques pour gérer les conversions et les changements. « Il faut gérer également le compactage de données. Si l’on récupère des données au fil de l’eau et que l’on veut les mettre dans une table Iceberg, ça coince, car Iceberg n’aime pas les petits fichiers Parquet », ajoute Fred Cecilia.
Ce sont tous ces aspects que Tableflow doit automatiser en « quelques clics » (quatre étapes). Dans le détail, Tableflow gère automatiquement la conversion vers Parquet, l’évolution du schéma, applique les règles de compression, de qualité de données et gère le Change Data Capture avant de créer des vues matérialisées Iceberg ou Delta.
Compatibilité avec Iceberg et Delta Lake : Confluent joue la carte de la neutralité
Le schéma est géré à l’aide du Confluent Schema Registry, tandis que les métadonnées peuvent être synchronisées avec des catalogues externes. Confluent prend actuellement en charge Apache Polaris et sa version managée par Snowflake (Open Catalog), AWS Glue, l’API REST Catalog Iceberg et prévoit l’ajout d’Unity Catalog. Ces catalogues n’ont accès qu’en lecture seule aux métadonnées. Contrairement à celui de Confluent géré sous le capot, Iceberg REST qui peut les lire et les écrire.
Quant à savoir si Confluent offrira aux clients un moyen de gérer un catalogue capable d’écrire et de lire les métadonnées (la clé de la maîtrise des formats de tables ouverts), Fred Cecilia n’a pas la réponse. « Déjà, les clients peuvent utiliser d’autres catalogues en lecture. Et je pense que nous allons voir de plus en plus de catalogues de métadonnées qui parlent entre eux, car l’on ne peut pas serrer la vis pour un format ouvert », estime-t-il. « C’est techniquement faisable […]. Je pense que les utilisateurs auront le dernier mot, ils ont un vrai pouvoir de décision dans ce contexte ».
Les tables matérialisées Iceberg ou Delta sont stockées soit dans un espace de stockage objet géré par Confluent, soit dans un bucket S3 géré par l’entreprise cliente. Une fois que c’est le cas, les usagers peuvent requêter ces données à travers Snowflake, Databricks, Amazon SageMaker, AWS Athena, Dremio, Starburst, Onehouse, Imply, Apache Spark, Trino ou DuckDB. Dans ce contexte, les tables sont externes. Elles ne sont pas nativement stockées dans Snowflake, Databricks et autres.
Il s’agit là, comme l’avait promis Jay Kreps, cofondateur et CEO de Confluent, de simplifier l’ingestion de données opérationnelle dans les plateformes analytiques. « Dans un même temps, les données des mêmes topics peuvent être récupérées pour alimenter des systèmes de détection de fraudes », illustre Fred Cecilia. C’est là que l’éditeur recommande l’usage Confluent for Apache Flink, mais c’est un autre sujet.
« Bring your own Storage » : l’option la plus pertinente de cette disponibilité générale
« La stratégie de Confluent a toujours été d’éviter de proposer une fonctionnalité bancale sur les trois hyperscalers. »
Fred CeciliaSenior Solutions Engineer, Confluent
Certaines limitations sont encore de vigueur. Ce système n’est disponible que pour Confluent Cloud sur AWS. La prise en charge de Google Cloud, puis de Microsoft Azure est prévue plus tard. « La stratégie de Confluent a toujours été d’éviter de proposer une fonctionnalité bancale sur les trois hyperscalers », commente Fred Cecilia. « Nous la déployons d’abord sur le cloud le plus utilisé par nos clients, nous collectons les retours et à partir des retours, nous pouvons faire évoluer le service et le proposer sur les autres ». Pour l’instant, il n’est pas fait mention d’une prise en charge de Tableflow sur la version self-managed Confluent Platform.
Si les données sont chiffrées en transit, Tableflow ne prend pas en charge le chiffrement côté clients (BYOK). De même, le stockage managé de Confluent n’est pas compatible avec les clusters protégés par VPC, contrairement à la brique de stockage objet S3 que les clients peuvent utiliser. À condition qu’il soit dans la même région cloud que leur cluster Kafka.
Une seule intégration avec un catalogue de métadonnées par cluster est possible. Seuls les topics Kafka – Tableflow configurés avec un espace de stockage externe peuvent utiliser un catalogue tiers, quand celui lié à l’espace de stockage Confluent ne peut pas se synchroniser avec ces metadata catalogs. Si l’administrateur en change, il faut supprimer manuellement les métadonnées associées. En clair, l’usage d’un bucket S3 réceptacle des tables gérées par l’entreprise semble être la meilleure solution.
Cette option « bring your own storage » est de toute façon « la caractéristique la plus marquante de Tableflow en disponibilité générale », d’après Kevin Petrie, analyste chez BARC US, auprès de Searchdatamanagement, une publication sœur du MagIT. « Elle permet aux clients de contrôler totalement le stockage tout en garantissant la conformité avec les exigences uniques en matière de propriété des données ».
« Cela fait 20 ans que je suis dans l’IT et c’est l’une des rares fois où je vois des petits acteurs comme des grands s’entendre sur un format ouvert. »
Fred CeciliaSenior Solutions Engineer, Confluent
Enfin, les topics sans schéma ne sont pas pris en charge. Et l’éditeur de rappeler que les tables Iceberg ne peuvent pas être interrogées avec Confluent Cloud for Apache Flink.
« Nous constaterons réellement les limites avec les retours d’utilisateurs, il y en aura toujours », note Fred Cecilia. « Pour le moment, nous parlons beaucoup des avantages, car nos clients se concentrent sur ce qu’ils n’ont plus à faire. Ensuite, pour moi, ce ne sont pas vraiment des limites, mais plus des opportunités qui vont s’ouvrir à nous ». D’autant qu’Apache Iceberg est aussi bien plébiscité par les éditeurs que par leurs clients. « Cela fait 20 ans que je suis dans l’IT et c’est l’une des rares fois où je vois des petits acteurs comme des grands s’entendre sur un format ouvert », se réjouit-il.
Actuellement, Confluent se concentre sur l’arrivée de Tableflow dans Azure et GCP ainsi que sur la disponibilité générale avec Delta Lake et Unity Catalog. D’autres fonctionnalités, dont la prise en charge des tables Upsert, afin de « gérer les opérations de déduplication et de fusion par clé primaire », ainsi que l’envoi des enregistrements incompatibles vers des listes « mortes » et le partitionnement personnalisé sont au programme.
La tarification de Confluent Cloud for Tableflow est fonction d’indices de consommation. L’éditeur prend en compte le nombre de topics accédés par heure (0,10 dollar par topic par heure), le nombre de gigaoctets traités (0,04 dollar par Go). Le stockage managé revient à 0,029 dollar par Go par mois, tandis que les 1 000 requêtes de lecture coûtent 0,000 4 dollar.
Pour approfondir sur Middleware et intégration de données
