Streamhouse ist das neue Buzzword. Hier ist der Teil, der wirklich zählt.

Von Andrew Tan

Das Wort, das niemand definiert hat

Ich saß letzten Monat auf einem Panel, als jemand das Wort „streamhouse“ fünfmal in zwei Minuten benutzte. Er meinte es vollkommen ernst. Er sagte, es sei „die größte Veränderung in der Datenarchitektur seit dem Lakehouse“. Er sagte, es würde „die Grenze zwischen Streaming und Analytics zum Einsturz bringen“. Und er sagte, Teams, die es nicht adoptieren, würden in achtzehn Monaten „Legacy-Batch-Infrastruktur betreiben“.

Nach dem Panel fragte ich ihn, was ein Streamhouse eigentlich sei.

Er zögerte. Dann sagte er: „Es ist, wenn deine Streaming-Plattform und dein Warehouse ein und dasselbe werden.“ Ich bat um ein Beispiel. Er sagte Kafka mit Iceberg. Ich fragte, wie sich das von dem unterscheidet, was Flink schon seit Jahren macht. Er sagte, das Streamhouse sei „native“. Ich fragte, was „native“ in diesem Zusammenhang bedeute. Er antwortete, das bedeute, man brauche keinen separaten Job, um Daten vom Stream ins Warehouse zu bewegen. Ich fragte, was passiert, wenn der Stream replayed, backfilled oder mit einer Slowly-Changing-Dimension-Tabelle gejoined werden muss. Er sagte, das seien „Implementierungsdetails“.

Er war ein Vendor. Er wollte etwas verkaufen. Aber das Wort ist jetzt in der Welt, und ich habe es von Data Architects, Platform Leads und sogar einem CTO gehört, der mir erzählte, seine Strategie für 2027 sei, „den Analytics-Stack zu streamhousen“.

Also machen wir das, was das Marketing nicht tut: Definieren wir das Ding, trennen den echten Wandel von der Neuverpackung und klären, ob dies eine Kategorie ist, um die man sich kümmern sollte – oder nur ein neues Etikett für Komplexität, die man bereits besitzt.

Was „streamhouse“ bedeuten soll

Der Begriff stammt aus einer Arbeitsgruppe, die Anfang dieses Jahres von Confluent, Aiven, Redpanda, StreamNative und Ververica angekündigt wurde. Die Botschaft ist einfach: Streaming-Daten und analytische Daten leben schon viel zu lange in getrennten Systemen. Kafka kümmert sich um den Stream. Snowflake kümmert sich um die Analytics. Dazwischen baut man eine Pipeline. Die Pipeline geht kaputt. Jeder gibt dem anderen Team die Schuld.

Der Streamhouse-Vorschlag lautet, diese Systeme zu vereinen. Streaming-Daten landen direkt bei ihrer Ankunft in offenen Tabellenformaten – Iceberg, Delta Lake, Paimon. Query-Engines lesen diese Tabellen direkt. Kein ETL-Job. Keine Batch-Synchronisation. Keine „Landing Zone“, die zwischen den Läufen veraltet. Der Stream ist die Tabelle. Die Tabelle ist der Stream.

Confluent nennt das Tableflow. Aiven nennt es Aiven Streams. Die genaue Markenbezeichnung ändert sich je nach Vendor, die Architektur bleibt jedoch konsistent:

• Ereignisse treffen in einer Streaming-Schicht ein (Kafka, Redpanda, Pulsar).
• Eine Streaming-Engine (Flink, Spark Structured Streaming oder eine herstellerspezifische Runtime) schreibt sie inkrementell in ein offenes Tabellenformat.
• Query-Engines (Trino, DuckDB, Snowflake, BigQuery) lesen die Tabelle wie eine normale Warehouse-Tabelle.
• Die Tabelle wird „kontinuierlich aktualisiert“ statt „periodisch aufgefrischt“.

Das ist kein Betrug. Es gibt hier eine echte technische Errungenschaft. Eine Streaming-Pipeline so zu bauen, dass sie in nahezu Echtzeit abfragbare Tabellendateien mit Schema-Evolution, Compaction und Snapshot-Isolation erzeugt, ist wirklich schwierig. Die Teams, die das bauen, verdienen Anerkennung.

Aber die Architektur ist nicht neu. Es ist eine Verfeinerung dessen, was Flink, Kinesis Analytics und sogar einige maßgeschneiderte Kafka-to-S3-Pipelines seit Jahren tun. Neu ist der Marketing-Schirm: das Wort „streamhouse“, die Arbeitsgruppe und das Versprechen, dieses Muster mache separate Batch- und Streaming-Systeme überflüssig.

Genau dieser letzte Teil ist weit hergeholt.

Was sich ändert – und was nicht

Trennen wir das Reale vom Wunschdenken.

Was tatsächlich besser wird:

• Die Latenz bis zu abfragbaren Daten sinkt. Wenn du bisher jede Stunde einen Batch-Sync ausgeführt hast, reduziert der Wechsel zu kontinuierlichem Micro-Batching oder echtem Streaming diese Latenz auf Sekunden oder Minuten. Für Anwendungsfälle, bei denen Frische entscheidend ist – Betrugserkennung, operative Dashboards, Real-time Pricing – ist das eine echte Verbesserung.
• Schema-Evolution wird sauberer. Offene Tabellenformate gehen mit Schema-Änderungen besser um als die meisten selbstgebauten Streaming-to-Warehouse-Pipelines. Das Hinzufügen einer Spalte erfordert kein Migrationsskript. Das Umbenennen eines Feldes wird im Metadaten-Tracking erfasst. Das reduziert „Wer hat das Dashboard kaputt gemacht“-Vorfälle.
• Eine Speicherschicht, weniger Kopien. Wenn dein Analytics-Team dieselben Iceberg-Dateien abfragen kann, die deine Streaming-Pipeline erzeugt, brauchst du keinen separaten Warehouse-Extrakt mehr. Weniger Kopien bedeuten weniger Sync-Jobs, weniger Konsistenzfenster und weniger Stellen, an denen Daten auseinanderdriften können.

Was exakt gleich bleibt:

• Orchestrierung. Ein Streamhouse entfernt nicht die Notwendigkeit, Jobs, Abhängigkeiten und Retries zu koordinieren. Wenn deine Streaming-Pipeline ein dbt-Modell füttert, das ein Dashboard füttert, muss dieser DAG weiterhin verwaltet werden. Das Streamhouse ersetzt den Batch-Extraktionsschritt. Es ersetzt nicht die Orchestrierungsschicht.
• Backfills und Replays. Wenn ein Bug drei Tage gestreamter Daten korrumpiert, musst du den Log zurückspulen und neu verarbeiten. Das Streamhouse-Tabellenformat macht das möglich. Es macht es nicht einfach. Du musst weiterhin Consumer-Offsets verwalten, Schema-Änderungen mitten im Stream handhaben und sicherstellen, dass die replayten Daten mit dem übereinstimmen, was nachgelagerte Systeme bereits gesehen haben.
• Workflows über Systemgrenzen hinweg. Die meisten realen Pipelines berühren mehr als ein System. Ein Stream kann einen API-Aufruf auslösen, einen Cache aktualisieren, in eine Datenbank schreiben und eine Benachrichtigung erzeugen. Das Streamhouse kümmert sich um den Analytics-Pfad. Es kümmert sich nicht um den operativen Pfad. Du brauchst weiterhin eine Runtime, die über Systeme mit unterschiedlichen Konsistenzmodellen und Fehlermodi hinweg koordinieren kann.
• Kostenstruktur. Streaming-Infrastruktur ist Always-on-Infrastruktur. Ein Batch-Job, der zehn Minuten pro Stunde läuft, kostet zehn Minuten Rechenzeit pro Stunde. Ein Streaming-Job, der kontinuierlich läuft, kostet sechzig. Das Streamhouse verlagert Kosten von Sync-Jobs auf Streaming-Compute. Ob das günstiger ist, hängt von deinem Volumen, deinen Query-Patterns und der Qualität deines Compaction-Tunings ab.

Das Streamhouse verbessert die Speicherung und Abfragbarkeit von Streaming-Daten. Es entfernt nicht die Notwendigkeit einer Runtime, die die unordentliche operative Arbeit um diese Daten herum erledigt.

Die Illusion der kontinuierlichen Tabelle

Die verführerischste Idee im Streamhouse-Pitch ist die „continuous table“. Eine Tabelle, die nie veraltet. Du fragst sie ab und erhältst die neuesten Daten. Kein Batch-Job. Kein Warten. Die Tabelle lebt.

Das ist ein starkes mentales Modell. Es ist auch etwas irreführend.

Eine kontinuierliche Tabelle ist kein einzelnes Objekt, das sich an Ort und Stelle aktualisiert. Es ist eine Folge von Snapshots, von denen jeder den Zustand der Tabelle zu einem bestimmten Zeitpunkt darstellt. Wenn du sie abfragst, liest du einen dieser Snapshots. Die Query-Engine wählt den neuesten, den sie kennt. Die Streaming-Engine hängt ständig neue Dateien an und committet neue Snapshots.

Das ist wichtig, weil die Lücke zwischen „das letzte Ereignis ist angekommen“ und „der neueste Snapshot ist abfragbar“ nicht null ist. Sie hängt ab von:

• Commit-Frequenz. Wie oft schreibt die Streaming-Engine einen neuen Snapshot? Jede Sekunde? Jede Minute? Je schneller, desto höher der Metadaten-Overhead.
• Compaction-Verzögerung. Die Tabelle sammelt kleine Dateien an. Abfragen werden langsamer. Jemand – oder ein geplanter Job – muss diese Dateien zu größeren komprimieren. Während der Compaction kann sich das Abfrageverhalten ändern.
• Catalog-Konsistenz. Die Query-Engine erfährt über einen Catalog von neuen Snapshots. Wenn der Catalog eventual consistent ist – und die meisten sind es –, kann eine Abfrage einen Snapshot lesen, der dreißig Sekunden hinter dem tatsächlichen Stream liegt. Dreißig Sekunden sind kein Real-time. Es ist Near-real-time im Real-time-Kostüm.

Die kontinuierliche Tabelle ist eine nützliche Abstraktion. Aber sie bleibt eine Abstraktion über einen Batch-of-Micro-Batches-Prozess. Die Dateien sind diskret. Die Snapshots sind diskret. Die Frische wird durch Commit-Intervalle, Compaction-Pläne und Catalog-Latenz begrenzt. Sie „continuous“ zu nennen, verschleiert die technische Realität: kleinere Batches, schnellere Commits, dieselben Koordinationsprobleme.

Wo Teams weiterhin Runtimes zusammenflicken müssen

Hier ist das Szenario, das das Streamhouse-Marketing dir nicht zeigt:

Du hast eine Streaming-Pipeline, die Ereignisse in eine Iceberg-Tabelle schreibt. Dein Analytics-Team fragt sie mit Trino ab. Dein ML-Team liest sie mit Spark. Dein operatives Team muss eine Warnung auslösen, sobald ein bestimmtes Ereignismuster auftritt – nicht nachdem das Ereignis in der Tabelle gelandet ist, sondern sobald es im Stream ankommt.

Das Streamhouse kümmert sich um die Analytics- und ML-Pfade. Die operative Warnung muss jedoch gegen den Stream selbst laufen, bevor das Ereignis in einen Tabellen-Snapshot committet wird. Also stellst du einen separaten Flink-Job auf, der den rohen Stream verarbeitet. Jetzt hast du zwei Runtimes: eine für den Tabellenpfad, eine für den operativen Pfad.

Dann möchte das Business einen wöchentlichen Bericht, der die gestreamten Daten mit den Batch-Daten aus deinem ERP-System abgleicht. Die ERP-Daten kommen nicht als Stream. Sie kommen als täglicher CSV-Dump. Also baust du einen Batch-Job, der die CSV liest, sie mit der Iceberg-Tabelle joint und den Bericht erzeugt. Jetzt hast du drei Runtimes.

Dann stellt jemand fest, dass die Streaming-Pipeline letzten Dienstag sechs Stunden lang fehlerhafte Daten produziert hat, weil es einen Schema-Drift gab. Du musst den Stream zurückspulen, die Logik korrigieren und replayen. Das Replay muss jedoch exakt dieselben Tabellen-Snapshots erzeugen, die nachgelagerte Abfragen bereits gesehen haben, sonst wird der Trainingslauf des ML-Teams inkonsistent. Also koordinierst du das Replay mit der Pipeline des ML-Teams. Jetzt orchestrierst du Runtimes über vier Systeme hinweg.

Das Streamhouse hat das „Wie frage ich meinen Stream ab“-Problem gelöst. Es hat nicht das „Wie koordiniere ich mehrere Runtimes mit unterschiedlicher Semantik“-Problem gelöst. Dieses Problem bleibt deins.

Der ehrliche Entscheidungsrahmen

Wenn du prüfst, ob das Streamhouse-Muster für dein Team sinnvoll ist, beginne nicht mit dem Architekturdiagramm. Beginne damit, was du tatsächlich erreichen willst.

Ein Streamhouse einsetzen, wenn:

• Dein primärer Anwendungsfall Analytics oder ML auf kontinuierlich eintreffenden Daten ist und dein aktueller Batch-Sync der Engpass ist.
• Du bereits Kafka (oder Redpanda oder Pulsar) betreibst und es leid bist, separate Pipelines zu pflegen, um diese Daten in ein Warehouse zu bringen.
• Deine Query-Patterns mit offenen Tabellenformaten kompatibel sind – columnare Reads, Predicate Pushdown, Snapshot Isolation – und du keine subsekündigen operativen Trigger brauchst.
• Du das Team hast, um Compaction, Catalog-Konsistenz und Schema-Evolution mit Streaming-Geschwindigkeit zu betreiben.

Kein Streamhouse einsetzen, wenn:

• Dein „Streaming“-Anwendungsfall eigentlich ein Batch-Job ist, der alle fünfzehn Minuten läuft. Das Streamhouse ist nicht kostenlos. Wenn niemand Daten schneller als alle fünfzehn Minuten braucht, bezahlst du kontinuierliche Rechenzeit für intermittierenden Nutzen.
• Du operative Trigger brauchst – API-Aufrufe, Cache-Updates, Benachrichtigungen –, die beim Eintreffen des Ereignisses feuern müssen, nicht beim Commit in die Tabelle. Das Streamhouse ist ein Analytics-Muster, kein operatives Muster.
• Dein Team bereits mit den Operationen offener Tabellenformate kämpft. Das Streamhouse fügt diesen Operationen Streaming-Geschwindigkeit hinzu. Wenn Compaction und Catalog-Management schon jetzt schmerzhaft sind, macht es sie nicht leichter, nur schneller.
• Du hoffst, es werde deine Orchestrierungsschicht ersetzen. Das wird es nicht. Du brauchst weiterhin etwas, das Abhängigkeiten, Retries, Backfills und Workflow-übergreifende Abläufe verwaltet.

Das Streamhouse ist ein Speicher- und Query-Muster. Es ist kein Runtime-Muster. Wenn deine Probleme Speicher- und Query-Probleme sind – veraltete Daten, Sync-Latenz, zu viele Kopien –, lohnt sich eine Evaluierung. Wenn deine Probleme Runtime-Probleme sind – Koordination, Fehlerbehebung, Semantik über Systemgrenzen hinweg –, hilft das Streamhouse nicht und kann sogar Komplexität hinzufügen.

Was die Vendoren wirklich verkaufen

Ich glaube nicht, dass die Streamhouse-Arbeitsgruppe unehrlich ist. Ich glaube, sie ist selektiv. Sie zeigen die Anwendungsfälle, in denen das Muster glänzt – Real-time Analytics, kontinuierliche ML-Feature-Stores, operative Dashboards – und lassen die Fälle, in denen es nicht glänzt, stillschweigend weg.

Was sie wirklich verkaufen, ist eine Verschiebung des Gravitationszentrums. Im letzten Jahrzehnt war das Warehouse das Zentrum des Datenuniversums. Alles floss hinein. Der Streamhouse-Vorschlag sagt: Der Stream ist das Zentrum, und das Warehouse ist nur einer von vielen Konsumenten.

Das ist für manche Organisationen eine bedeutsame Verschiebung. Wenn dein Geschäft ereignisgetrieben ist – Betrugserkennung, IoT, Real-time-Trading –, ergibt das Stream-first-Modell Sinn. Die meisten Organisationen sind jedoch nicht ereignisgetrieben, sondern plangetrieben. Sie erstellen Berichte. Sie aktualisieren Dashboards. Sie trainieren Modelle über Nacht. Für diese Teams ist die Verlagerung des Gravitationszentrums zum Stream eine Lösung auf der Suche nach einem Problem.

Die Vendoren wissen das. Deshalb betont das Marketing „Zukunftssicherheit“ und „moderne Datenarchitektur“ statt konkreter operativer Verbesserungen. Das Streamhouse wird als unausweichliche Evolution positioniert, ähnlich wie früher die Cloud oder das Lakehouse. Der Subtext lautet: Wenn du das nicht machst, fällst du zurück.

Vielleicht. Aber hinter was zurück? Wenn deine Batch-Pipelines zuverlässig sind, deine Stakeholder zufrieden und deine Kosten vorhersehbar, dann ist die Einführung eines Streamhouse nur weil ein Vendor sagt, es sei unausweichlich, keine Modernisierung. Es ist Architektur aus FOMO.

Wo wir hineinpassen

Bei layline.io verkaufen wir kein Streamhouse. Wir verkaufen eine Runtime, die Batch und Streaming im selben Pipeline auf der Infrastruktur betreibt, die du bereits hast.

Warum das wichtig ist: Viele Teams evaluieren das Streamhouse, weil sie wollen, dass Batch und Streaming nebeneinander existieren, ohne zwei separate Stacks zu betreiben. Das ist ein echtes Problem. Das Streamhouse löst es, indem es den Speicher um den Stream herum vereinheitlicht. Wir lösen es, indem wir die Runtime um den Workflow herum vereinheitlichen.

Wenn dein Analytics-Team eine Warehouse-Tabelle braucht und dein operatives Team einen Stream-Trigger, können beide Pfade durch dieselbe Pipeline-Logik, dieselbe Observability und dieselbe Fehlerbehebung laufen. Das Speicherformat wird zu einer Konfigurationsentscheidung – Iceberg, wo es hilft, Parquet, wo es nicht hilft, ein Message Bus, wenn du operative Latenz brauchst –, statt zu einer architektonischen Verpflichtung.

Das Streamhouse ist ein nützliches Muster für eine bestimmte Gruppe von Problemen. Es ist keine universelle Architektur und kein Ersatz für die operative Runtime, die deine Pipelines um zwei Uhr nachts am Laufen hält. Die Teams, die damit erfolgreich sind, adoptieren es aus den richtigen Gründen – Query-Latenz, reduzierter Sync-Overhead, sauberere Schema-Evolution – und erwarten nicht, dass es Probleme löst, für die es nie gedacht war.

Das Buzzword wird verblassen. Die zugrundeliegende Technologie – kontinuierliche Aufnahme in offene Tabellenformate – wird bleiben und sich verbessern. Die Frage ist, ob dein Team es schon brauchte, bevor das Marketing dir gesagt hat, dass du es brauchst.

Wenn dein Team versucht, das Streamhouse-Signal vom Rauschen zu trennen – oder wenn du eine Runtime suchst, die Batch und Streaming verarbeitet, ohne dich zu einer Speicher-Religion zu zwingen – melde dich bei uns. Wir haben Teams bei genau dieser Abwägung geholfen, und die Antwort ist meist einfacher, als die Architekturdiagramme vermuten lassen.

Andrew Tan ist Serienunternehmer und Gründer von layline.io. Er baut Enterprise-Dateninfrastruktur, die sowohl Batch- als auch Echtzeit-Workloads in großem Maßstab verarbeitet.