Streamhouse è il nuovo buzzword. Ecco la parte che conta davvero.

Di Andrew Tan

La parola che nessuno ha definito

Ero in un panel il mese scorso quando qualcuno ha usato la parola "streamhouse" cinque volte in due minuti. Ne parlava con convinzione. Diceva che era «il più grande cambiamento nell’architettura dei dati dai tempi del lakehouse». Diceva che avrebbe «fatto collassare il confine tra streaming e analytics». Diceva che i team che non l’avessero adottato si sarebbero ritrovati a «mantenere infrastrutture batch legacy» entro diciotto mesi.

Dopo il panel gli ho chiesto cosa fosse in realtà uno streamhouse.

Ha esitato. Poi ha risposto: «È quando la tua piattaforma di streaming e il tuo data warehouse diventano la stessa cosa». Ho chiesto un esempio. Ha detto Kafka con Iceberg. Ho chiesto in cosa fosse diverso da quello che Flink fa già da anni. Ha risposto che lo streamhouse è «nativo». Ho chiesto cosa significasse «nativo» in questo contesto. Ha detto che significa che non serve un job separato per spostare i dati dallo stream al warehouse. Ho chiesto cosa succede quando lo stream deve essere riprodotto, backfilled o unito a una slowly changing dimension table. Ha risposto che quelli sono «dettagli di implementazione».

Era un vendor. Stava vendendo qualcosa. Ma la parola è ormai uscita allo scoperto, e l’ho sentita da architetti di dati, responsabili di piattaforma e persino da un CTO che mi ha detto che la sua strategia 2027 è di «streamhouse-izzare lo stack di analytics».

Quindi facciamo quello che il marketing non fa: definiamo la cosa, separiamo il cambiamento reale dal rebranding e capiamo se si tratta di una categoria di cui dovreste occuparvi o semplicemente di una nuova etichetta per la complessità che già gestite.

Cosa dovrebbe significare "streamhouse"

Il termine nasce da un gruppo di lavoro annunciato all’inizio di quest’anno da Confluent, Aiven, Redpanda, StreamNative e Ververica. La proposta è semplice: i dati di streaming e i dati analitici vivono in sistemi separati da troppo tempo. Kafka gestisce lo stream. Snowflake gestisce l’analytics. Si costruisce una pipeline tra i due. La pipeline si rompe. Tutti danno la colpa all’altro team.

La proposta dello streamhouse è di unificarli. I dati di streaming arrivano in formati di tabella aperti — Iceberg, Delta Lake, Paimon — nel momento stesso in cui arrivano. I motori di query leggono direttamente quelle tabelle. Niente job ETL. Niente sincronizzazione batch. Niente «landing zone» che diventa obsoleta tra un’esecuzione e l’altra. Lo stream è la tabella. La tabella è lo stream.

Confluent lo chiama Tableflow. Aiven lo chiama Aiven Streams. Il branding esatto cambia a seconda del vendor, ma l’architettura è coerente:

• Gli eventi arrivano in un layer di streaming (Kafka, Redpanda, Pulsar).
• Un motore di streaming (Flink, Spark Structured Streaming o un runtime specifico del vendor) li scrive in modo incrementale in un formato di tabella aperto.
• I motori di query (Trino, DuckDB, Snowflake, BigQuery) leggono la tabella come se fosse una normale tabella di warehouse.
• La tabella è «aggiornata continuamente» invece che «aggiornata periodicamente».

Non è una truffa. C’è un reale risultato tecnico. Riuscire a far produrre a una pipeline di streaming file di tabella interrogabili in near-real-time, con evoluzione dello schema, compaction e snapshot isolation, è davvero difficile. I team che stanno costruendo tutto questo meritano riconoscimento.

Ma l’architettura non è nuova. È un raffinamento di ciò che Flink, Kinesis Analytics e persino alcune pipeline personalizzate Kafka-to-S3 fanno da anni. Ciò che è nuovo è l’ombrello di marketing: la parola «streamhouse», il gruppo di lavoro, la promessa che questo pattern elimini la necessità di sistemi batch e streaming separati.

Quell’ultima parte è la forzatura.

Cosa cambia — e cosa non cambia

Separamo il reale dall’aspirazionale.

Cosa migliora davvero:

• La latenza verso i dati interrogabili si riduce. Se esegui una sincronizzazione batch ogni ora, passare a micro-batching continuo o a vero streaming la porta a secondi o minuti. Per i casi d’uso in cui la freschezza è importante — rilevamento frodi, dashboard operative, pricing in tempo reale — si tratta di un miglioramento concreto.
• L’evoluzione dello schema è più pulita. I formati di tabella aperti gestiscono i cambiamenti di schema meglio della maggior parte delle pipeline personalizzate streaming-to-warehouse. Aggiungere una colonna non richiede uno script di migrazione. La rinomina di un campo viene tracciata nei metadati. Questo riduce gli incidenti «chi ha rotto la dashboard».
• Un unico layer di storage, meno copie. Se il team di analytics può interrogare gli stessi file Iceberg prodotti dalla pipeline di streaming, non serve un’estrazione separata verso il warehouse. Meno copie significano meno job di sincronizzazione, meno finestre di consistenza e meno punti in cui i dati possono divergere.

Cosa rimane esattamente uguale:

• Orchestrazione. Uno streamhouse non elimina la necessità di coordinare job, dipendenze e retry. Se la tua pipeline di streaming alimenta un modello dbt che alimenta una dashboard, quel DAG deve comunque essere gestito. Lo streamhouse sostituisce il passo di estrazione batch. Non sostituisce il layer di orchestrazione.
• Backfill e replay. Quando un bug corrompe tre giorni di dati in streaming, devi riavvolgere il log e rielaborarli. Il formato di tabella dello streamhouse lo rende possibile. Non lo rende facile. Devi comunque gestire gli offset dei consumer, gestire i cambiamenti di schema avvenuti a metà stream e verificare che i dati riprodotti corrispondano a ciò che i sistemi downstream avevano già visto.
• Workflow cross-system. La maggior parte delle pipeline reali tocca più di un sistema. Uno stream può attivare una chiamata API, aggiornare una cache, scrivere su un database e produrre una notifica. Lo streamhouse gestisce il percorso analitico. Non gestisce il percorso operativo. Serve comunque un runtime in grado di coordinare sistemi con diversi modelli di consistenza e modalità di fallimento.
• Struttura dei costi. L’infrastruttura di streaming è sempre accesa. Un job batch che gira dieci minuti ogni ora costa dieci minuti di compute all’ora. Un job di streaming che gira continuamente costa sessanta. Lo streamhouse sposta il costo dai job di sincronizzazione al compute di streaming. Se sia più economico dipende dal volume, dai pattern di query e da quanto bene si ottimizza la compaction.

Lo streamhouse migliora lo storage e l’interrogabilità dei dati di streaming. Non elimina la necessità di un runtime che gestisca il lavoro operativo complesso attorno a quei dati.

L’illusione della tabella continua

L’idea più seducente della proposta streamhouse è la «tabella continua». È una tabella che non diventa mai obsoleta. La interroghi e ottieni i dati più recenti. Niente job batch. Niente attesa. La tabella è viva.

È un modello mentale potente. È anche leggermente fuorviante.

Una tabella continua non è un singolo oggetto che si aggiorna sul posto. È una sequenza di snapshot, ciascuno rappresentante la tabella in un determinato momento. Quando la interroghi, stai leggendo uno di quegli snapshot. Il motore di query sceglie l’ultimo di cui è a conoscenza. Il motore di streaming sta continuamente aggiungendo nuovi file e committando nuovi snapshot.

Questo è importante perché lo scarto tra «l’ultimo evento è arrivato» e «l’ultimo snapshot è interrogabile» non è zero. Dipende da:

• Frequenza di commit. Quanto spesso il motore di streaming scrive un nuovo snapshot? Ogni secondo? Ogni minuto? Più è frequente, maggiore è l’overhead sui metadati.
• Compaction lag. La tabella accumula file piccoli. Le query rallentano. Qualcuno — o qualche job schedulato — deve compattare quei file in file più grandi. Durante la compaction il comportamento delle query può cambiare.
• Consistenza del catalog. Il motore di query viene a conoscenza dei nuovi snapshot tramite un catalog. Se il catalog è eventually consistent — e la maggior parte lo è — una query potrebbe leggere uno snapshot che è trenta secondi indietro rispetto allo stream reale. Trenta secondi non sono real-time. Sono near-real-time travestito da real-time.

La tabella continua è un’astrazione utile. Ma resta un’astrazione sopra un processo di batch-di-micro-batch. I file sono discreti. Gli snapshot sono discreti. La freschezza è limitata dagli intervalli di commit, dalle schedulazioni di compaction e dalla latenza del catalog. Chiamarla «continua» oscura la realtà ingegneristica, che è: batch più piccoli, commit più veloci, stessi problemi di coordinamento.

Dove i team finiscono comunque a cucire runtime diversi

Ecco lo scenario che il marketing dello streamhouse non ti mostra:

Hai una pipeline di streaming che scrive eventi in una tabella Iceberg. Il team di analytics la interroga con Trino. Il team di ML la legge con Spark. Il team operativo deve attivare un alert quando si verifica un determinato pattern di eventi — non dopo che l’evento è atterrato nella tabella, ma quando arriva nello stream.

Lo streamhouse gestisce i percorsi analytics e ML. Ma l’alert operativo deve essere eseguito contro lo stream stesso, prima che l’evento sia committato in uno snapshot di tabella. Quindi metti in piedi un job Flink separato per elaborare lo stream grezzo. Ora hai due runtime: uno per il percorso tabella, uno per il percorso operativo.

Poi l’azienda chiede un report settimanale che riconcilia i dati di streaming con i dati batch provenienti dal sistema ERP. I dati ERP non arrivano in streaming. Arrivano come un dump CSV giornaliero. Quindi costruisci un job batch che legge il CSV, lo unisce alla tabella Iceberg e produce il report. Ora hai tre runtime.

Poi qualcuno scopre che la pipeline di streaming ha prodotto dati errati per sei ore lo scorso martedì a causa di uno schema drift. Devi riavvolgere lo stream, correggere la logica e fare il replay. Ma il replay deve produrre esattamente gli stessi snapshot di tabella che le query downstream avevano già visto, altrimenti l’addestramento del team ML sarà inconsistente. Quindi coordini il replay con la pipeline del team ML. Ora stai orchestrando runtime tra quattro sistemi.

Lo streamhouse ha risolto il problema «come interrogo il mio stream». Non ha risolto il problema «come coordino più runtime con semantiche diverse». Quel problema rimane tuo.

Un framework decisionale onesto

Se stai valutando se il pattern streamhouse ha senso per il tuo team, non iniziare dal diagramma di architettura. Inizia da ciò che stai realmente cercando di fare.

Usa uno streamhouse quando:

• Il tuo caso d’uso principale è analytics o ML su dati che arrivano continuamente e la tua sincronizzazione batch attuale è il collo di bottiglia.
• Stai già usando Kafka (o Redpanda, o Pulsar) e sei stanco di mantenere pipeline separate per spostare quei dati in un warehouse.
• I tuoi pattern di query sono compatibili con i formati di tabella aperti — letture colonnari, predicate pushdown, snapshot isolation — e non stai cercando di fare trigger operativi a sotto-secondo.
• Hai il team necessario per gestire compaction, consistenza del catalog e evoluzione dello schema a velocità di streaming.

Non usare uno streamhouse quando:

• Il tuo caso d’uso di «streaming» è in realtà un job batch che gira ogni quindici minuti. Lo streamhouse non è gratis. Se nessuno ha bisogno dei dati più velocemente di quindici minuti, stai pagando compute continuo per un valore intermittente.
• Hai bisogno di trigger operativi — chiamate API, aggiornamenti di cache, notifiche — che devono scattare all’arrivo dell’evento, non al commit della tabella. Lo streamhouse è un pattern analitico, non operativo.
• Il tuo team sta già faticando con le operazioni sui formati di tabella aperti. Lo streamhouse aggiunge velocità di streaming a quelle operazioni. Se compaction e gestione del catalog sono già dolorose, renderle più veloci non le rende più semplici.
• Speravi che sostituisse il tuo layer di orchestrazione. Non lo farà. Avrai comunque bisogno di qualcosa che gestisca dipendenze, retry, backfill e workflow cross-system.

Lo streamhouse è un pattern di storage e query. Non è un pattern di runtime. Se i tuoi problemi sono di storage e query — dati obsoleti, lag di sincronizzazione, troppe copie — vale la pena valutarlo. Se i tuoi problemi sono di runtime — coordinamento, recupero da fallimenti, semantiche cross-system — lo streamhouse non aiuta e può aggiungere complessità.

Cosa i vendor stanno davvero vendendo

Non credo che il gruppo di lavoro sullo streamhouse sia disonesto. Credo che sia selettivo. Sta mostrando i casi d’uso in cui il pattern brilla — analytics in tempo reale, feature store ML continui, dashboard operative — e omettendo silenziosamente quelli in cui non funziona.

Ciò che stanno davvero vendendo è uno spostamento del centro di gravità. Nell’ultimo decennio il data warehouse è stato il centro dell’universo dei dati. Tutto vi convergeva. La proposta dello streamhouse dice che lo stream è il centro e il warehouse è solo uno dei tanti consumer.

Per alcune organizzazioni questo è un cambiamento significativo. Se la tua azienda è event-driven — rilevamento frodi, IoT, trading in tempo reale — il modello stream-first ha senso. Ma la maggior parte delle organizzazioni non è event-driven. È schedule-driven. Esegue report. Aggiorna dashboard. Ritrena modelli durante la notte. Per questi team, spostare il centro di gravità sullo stream è una soluzione in cerca di un problema.

I vendor lo sanno. Ecco perché il marketing insiste su «future-proofing» e «modern data architecture» invece che su miglioramenti operativi concreti. Lo streamhouse viene posizionato come un’evoluzione inevitabile, come il cloud o il lakehouse prima di esso. Il sottotesto è: se non lo stai facendo, stai rimanendo indietro.

Forse. Ma rimanendo indietro rispetto a cosa? Se le tue pipeline batch sono affidabili, gli stakeholder sono soddisfatti e i costi sono prevedibili, adottare uno streamhouse solo perché un vendor dice che è inevitabile non è modernizzazione. È architettura per FOMO.

Dove ci inseriamo noi

In layline.io non vendiamo uno streamhouse. Vendiamo un runtime che gestisce sia batch che streaming nella stessa pipeline, sull’infrastruttura che già possiedi.

Il motivo per cui questo conta: molti team stanno valutando lo streamhouse perché vogliono far coesistere batch e streaming senza mantenere due stack separati. È un problema reale. Ma lo streamhouse lo risolve unificando lo storage attorno allo stream. Noi lo risolviamo unificando il runtime attorno al Workflow.

Se il tuo team di analytics ha bisogno di una tabella di warehouse e il team operativo ha bisogno di un trigger sullo stream, entrambi i percorsi possono passare attraverso la stessa logica di Workflow, la stessa osservabilità e lo stesso meccanismo di recovery. Il formato di storage diventa una scelta di configurazione — Iceberg quando aiuta, Parquet quando non serve, un message bus quando serve latenza operativa — invece che un impegno architettonico.

Lo streamhouse è un pattern utile per un insieme specifico di problemi. Non è un’architettura universale e non è un sostituto del runtime operativo che tiene in funzione le tue pipeline alle 2 di notte. I team che hanno successo con esso sono quelli che lo adottano per i motivi giusti — latenza di query, riduzione dell’overhead di sincronizzazione, evoluzione dello schema più pulita — e non si aspettano che risolva problemi che non è stato progettato per affrontare.

Il buzzword svanirà. La tecnologia sottostante — ingestione continua in formati di tabella aperti — resterà e migliorerà. La domanda è se il tuo team ne avesse davvero bisogno prima che il marketing ti dicesse che ne avevi bisogno.

Se il tuo team sta cercando di separare il segnale dello streamhouse dal rumore — o se stai cercando un runtime che gestisca batch e streaming senza obbligarti a scegliere una religione di storage — contattaci. Abbiamo aiutato team a valutare esattamente questo trade-off, e la risposta è di solito più semplice di quanto suggeriscano i diagrammi di architettura.

Andrew Tan è un imprenditore seriale e fondatore di layline.io, che costruisce infrastrutture enterprise di elaborazione dati in grado di gestire workload sia batch che real-time a scala.