Il problema è noto a chiunque abbia un data stack in produzione: i dati operativi vivono in Apache Kafka, mentre analisti e strumenti di BI se li aspettano nel data lake o nel warehouse. Il ponte tradizionale sono connettori custom, job ETL schedulati e gestione manuale degli schemi: un approccio fragile sotto schema evolution e costoso da gestire su larga scala. Confluent Tableflow, una feature managed di Confluent Cloud, punta a eliminare quel ponte materializzando i topic Kafka come tabelle Apache Iceberg o Delta Lake, così i motori analitici possono interrogare i dati di streaming come tabelle senza scrivere né mantenere pipeline.
Come funziona
Tableflow usa il Kora storage layer di Confluent per trasformare i dati dei topic (in Avro, JSON Schema o Protobuf) in file Parquet strutturati, poi genera i metadati Iceberg o Delta Lake e li espone tramite l’Iceberg REST Catalog integrato o cataloghi esterni supportati. Lo Schema Registry è la fonte di verità per il mapping e la schema evolution. Il flusso end-to-end passa per: ingestion dei segmenti Kafka committati, staging nel Kora storage, conversione in Parquet, generazione dei metadati di tabella (Iceberg e Delta Lake sono entrambi in GA), pubblicazione nel catalogo e governance degli schemi.
Le tabelle risultanti sono interrogabili con i motori più diffusi (Snowflake, Databricks, AWS Athena, Amazon Redshift, Trino, BigQuery), mentre per il catalogo si può usare il REST catalog Iceberg gestito, AWS Glue o Unity Catalog.
Attivazione e schema evolution
L’articolo include un tutorial passo-passo con Amazon S3 come storage layer: si crea un cluster e un topic in Confluent Cloud, si registra uno schema, si configura una Provider Integration verso S3 tramite un ruolo IAM con policy di permessi e trust policy, e infine si abilita Tableflow sul topic scegliendo il formato tabella. I dati compaiono nel bucket S3 in formato Parquet con i relativi metadati Iceberg.
Sul fronte governance, Tableflow segue le regole di compatibilità dello Schema Registry e applica in automatico i cambiamenti compatibili: aggiunta di colonne nullable con default null, rimozione di colonne dove le regole lo consentono, ampliamento di tipi (int verso long, float verso double, aumento della precisione decimale). Se un cambiamento non è compatibile con la modalità configurata, serve intervento manuale e Tableflow può sospendere la materializzazione per il topic interessato.
In sintesi
- Kafka resta il system of record in tempo reale, mentre le tabelle Iceberg su object storage diventano la base analytics, tenuta continuamente in sync.
- Zero-ETL qui significa nessuna pipeline custom: Tableflow gestisce ingestion, conversione, metadati e cataloging.
- La schema evolution è governata dallo Schema Registry, con propagazione automatica dei cambiamenti compatibili e sospensione controllata di quelli che non lo sono.
Fonte: Tableflow: Turn Kafka Topics into Iceberg Tables — https://www.confluent.io/blog/tableflow-kafka-iceberg/
Hai qualcosa da aggiungere? Unisciti alla discussione.