Apache Fluss: Streaming-Speicher auf Apache Arrow zwischen Flink und Lakehouse

Fluss als Streaming-Speicher: die Lücke zwischen Strom und Lakehouse

Apache Fluss beschreibt sich im README als Streaming-Speicher für Echtzeitanalyse und KI, der als Echtzeit-Datenschicht für Lakehouse-Architekturen dienen soll. Die Lücke, die das Projekt schließen will, liegt zwischen zwei Welten: Ereignisströme auf der einen Seite, tabellarische Datenbestände im Lakehouse auf der anderen. Statt beide Welten mit getrennten Systemen zu bedienen, stellt Fluss eine Schicht dazwischen, die Daten mit geringer Verzögerung und hohem Durchsatz aufnimmt und verarbeitet.

Die Anbindung an Rechen-Engines ist konkret benannt. Apache Flink und Apache Spark werden als integrierte Engines geführt, StarRocks ist im README angekündigt, aber nach dem dortigen Wortlaut noch nicht verfügbar. Als einheitliche Abstraktion dient die Tabelle, die Echtzeitdaten und historische Daten über Engine-Grenzen hinweg zusammenführt.

Ein Detail erklärt den Namen: Fluss ist das deutsche Wort für Fluss, ausgesprochen /flus/. Das Bild dazu liefert das README selbst, Daten fließen wie Wasser in Seen hinein, sie werden gesammelt, verteilt und strömen weiter. Die Metadaten nennen Java als Sprache, die Apache-Lizenz 2.0 und rund 2.100 Sterne bei knapp 610 Forks.

Apache Arrow, Spaltenprojektion und Prädikatsweitergabe im Lesepfad von Fluss

Der dritte Funktionsblock betrifft die Frage, wie gelesen wird. Fluss setzt laut README auf Apache Arrow und nennt das Vorgehen spaltenorientiertes Streaming. Gemeint sind Datenbankprimitive auf Datenströmen, ausdrücklich genannt werden Spaltenprojektion und Prädikatsweitergabe.

Der praktische Wert dieser Konstruktion liegt auf der Hand. Eine Engine, die drei von zwanzig Spalten braucht, soll auch nur diese drei Spalten lesen, und Einschränkungen auf Zeilen sollen bereits im Speicher ausgewertet werden statt erst nach dem Transport. Das README formuliert die Folge als geringere Kosten für Ein- und Ausgabe sowie für Netzübertragung. Belegt wird die Aussage nicht. Messwerte, ein Vergleich mit zeilenweisem Lesen oder eine Angabe, bei welchen Datenprofilen der Gewinn besonders groß ausfällt, fehlen.

Was die Konstruktion voraussetzt, ist ebenso erwähnenswert. Spaltenorientiertes Lesen trägt nur, wenn die Engine die Projektion an Fluss weitergibt. Ob das für Apache Spark und Apache Flink im gleichen Umfang gilt, sagt das README nicht. Die verlinkte Schnellstartanleitung unter fluss.apache.org/docs/quickstart/flink/ behandelt nach ihrem Adresspfad den Flink-Weg, während die allgemeine Dokumentation unter fluss.apache.org/docs/ liegt.

Deduplizierung, Teilaktualisierung und Delta-Joins in der Fluss-Speicherschicht

Ein weiterer Block im README beschreibt die Trennung von Berechnung und Speicherung. Stromverarbeiter sollen sich auf reine Berechnung konzentrieren, während Fluss Zustand und Speicher verwaltet. In dieser Rolle führt das README vier Fähigkeiten auf: Deduplizierung, Teilaktualisierung, Delta-Joins und Aggregations-Merge-Engines.

Jede dieser Fähigkeiten verschiebt Arbeit aus der Engine in die Speicherschicht. Eine Teilaktualisierung erlaubt, nur geänderte Felder eines Datensatzes zu schreiben, statt die gesamte Zeile neu zu erzeugen. Bei Delta-Joins entfällt der Aufbau eines großen Zustands im Verarbeiter, weil die Speicherschicht die benötigten Stände bereithält. Für Aggregationen nennt das README Merge-Engines, ohne zu beschreiben, welche Aggregationen zusammengeführt werden können und wie widersprüchliche Zwischenstände aufgelöst werden.

Für den Betrieb folgt aus dieser Aufteilung, dass Fluss als zustandsbehaftete Komponente eigene Anforderungen an Speicherplatz und Sicherung stellt. Das README macht dazu keine Angaben, und es fehlt auch ein Hinweis darauf, wie sich die Speicherschicht bei Ausfall einer Komponente verhält.

Changelogs und Entscheidungsverfolgung in Fluss-Tabellen

Ein eigener Block trägt die Überschrift Changelogs und Entscheidungsverfolgung. Fluss erzeugt demnach von sich aus Änderungsprotokolle, also eine nur anhängbare Geschichte von Zuständen und Entscheidungen. Genannt werden drei Zwecke: Nachprüfbarkeit, Wiederholbarkeit und tiefe Beobachtbarkeit des Systems.

Dieser Ansatz geht über reine Datenspeicherung hinaus. Wer bei einer automatisierten Entscheidung rekonstruieren will, auf welcher Datengrundlage sie gefallen ist, braucht genau diese Historie. Das README schreibt nicht, wie lange Changelogs aufbewahrt werden, ob sich alte Abschnitte abtrennen lassen und wie viel zusätzlichen Speicher sie beanspruchen. Auch die Frage, ob die Historie pro Tabelle aktiviert oder abgeschaltet werden kann, bleibt offen.

Ergänzend führt das README einen Block für maschinelles Lernen auf. Als einheitliche Speicherschicht sollen zeilenbasierte, spaltenorientierte, vektor-basierte und multimodale Daten zusammenlaufen, mit dem Ziel eines Echtzeit-Merkmalsspeichers. Welche Vektor-Formate unterstützt werden und ob sich Merkmale direkt abfragen lassen, steht nicht im README.

git clone, ./mvnw clean package -DskipTests und das Verzeichnis build-target

Der Bau aus den Quellen ist klar beschrieben, und die Voraussetzungen sind ungewöhnlich präzise angegeben. Gefordert werden eine Unix-artige Umgebung, wobei Linux, Mac OS X, Cygwin und WSL als verwendete Umgebungen stehen, dazu Git, Maven in Version 3.8.6 oder neuer sowie Java 11.

Der Ablauf besteht aus drei Schritten. Mit git clone https://github.com/apache/fluss.git wird der Quellstand geholt, mit cd fluss in das Verzeichnis gewechselt, und ./mvnw clean package -DskipTests erzeugt das Ergebnis. Es landet im Verzeichnis build-target. Der Umweg über den Maven-Wrapper ./mvnw hat einen guten Grund, den das README nennt: Er stellt die richtige Maven-Version bereit, womit die Untergrenze 3.8.6 auch auf Maschinen mit älterer Installation eingehalten wird.

Zwei Punkte verdienen Beachtung. Tests werden mit dem Schalter -DskipTests übersprungen, ein erfolgreicher Durchlauf sagt also nichts über das Verhalten in der eigenen Umgebung. Und Java 11 ist als feste Version angegeben statt als Untergrenze, ob neuere Laufzeitumgebungen funktionieren, bleibt unerwähnt.

v0.9.1-incubating: Reifegrad, Issue-Last und die Alternative Apache Kafka

Der Versionsstand ist das deutlichste Signal zur Reife. Die drei jüngsten Veröffentlichungen tragen die Bezeichnungen v0.9.1-incubating vom Mai 2026, v0.9.0-incubating vom März 2026 und v0.8.0-incubating vom November 2025. Der Zusatz incubating weist auf ein Projekt in der Inkubation der Apache-Stiftung hin, und Nummern unterhalb von 1.0 bedeuten, dass Brüche an den Schnittstellen zwischen Nebenversionen zu erwarten sind. Wer Fluss einsetzt, sollte deshalb nicht mit der Verlässlichkeit einer ausgereiften Datenschicht rechnen.

Auffällig ist das Verhältnis der Gemeinschaftskennzahlen. Rund 2.100 Sterne stehen knapp 970 offenen Issues gegenüber. Ein solches Verhältnis spricht für regen Zulauf und zugleich für einen Berg offener Punkte, den das README nicht einordnet und für den keine Aussage zur Bearbeitungsdauer vorliegt.

Als Alternative kommt Apache Kafka infrage, wenn lediglich ein Ereignisstrom mit wiederholbarem Lesen gebraucht wird. Kafka stellt die Transport- und Speicherschicht für Ereignisse bereit, kennt aber keine Tabellenabstraktion über historische Daten, wie Fluss sie über dem Lakehouse anbietet. Die Kehrseite dieser Abstraktion ist zusätzlicher Betriebsaufwand. Die Apache-Lizenz 2.0 erlaubt bei beiden Projekten kommerzielle Nutzung und angepasste Varianten, sofern die Hinweispflichten beachtet werden; eine Gewährleistung ist ausgeschlossen.

Redaktionelles Fazit

Fluss passt zu Vorhaben, bei denen Analysen Sekundenbruchteile nach dem Eintreffen der Daten ansetzen müssen und Apache Flink oder Apache Spark bereits als Engine feststeht. Wer nur Ereignisse transportieren will, ist mit Apache Kafka besser bedient, und für Berichte mit Stundenverzug ist der Betrieb einer eigenen Speicherschicht schwer zu begründen. Vor dem Einsatz sollte der Bau mit Java 11 und Maven ab 3.8.6 in build-target durchlaufen und geprüft werden, ob die eigenen Engines Spaltenprojektion und Prädikatsweitergabe tatsächlich an Fluss weiterreichen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes