Apache Fluss Assess

data-platform open-source analytics-engineering streaming-storage streaming-lakehouse real-time-analytics apache-flink lakehouse-formats kafka-alternative change-data-capture

Sept. 2026

Überblick

Apache Fluss ist ein Streaming-Storage-System, das sich als die Real-Time-Datenschicht für ein Lakehouse positioniert. Statt ein Log und eine Tabelle als getrennte Systeme zu behandeln, stellt es eine gemeinsame Table-Abstraktion über Streaming-Daten, kontinuierlich aktualisierte Tabellen und historische Lakehouse-Daten bereit und integriert sich auf der Compute-Seite mit Apache Flink und Apache Spark sowie auf der Storage-Seite mit Apache Paimon, Apache Iceberg, Apache Hudi und Lance (BigDATAwire). Es wurde im Juli 2023 vom Flink-Team bei Alibaba Cloud initiiert, auf der Flink Forward Asia 2024 als Open Source veröffentlicht und ist inzwischen vom Apache Incubator zu einem Top Level Project aufgestiegen, mit einstimmiger IPMC-Zustimmung und Freigabe durch das ASF Board.

Der Grund, sich Fluss anzusehen, ist architektonisch, nicht inkrementell. Die wiederkehrende Geschichte in der Evidenz sind Teams, deren Kafka-plus-Wide-Table-Designs im großen Maßstab teuer und instabil wurden: Rednote migrierte Indexdaten von Kafka zu Fluss innerhalb einer Pipeline, die Suche, Recommendation und Advertising versorgt, und Taobao Instant Commerce baute Real-Time-Decisioning neu auf, das vorher auf Kafka, Flink, Paimon und StarRocks lief. Columnar Streaming Reads und Lakehouse-Tiering sind in beiden Fällen die Hebel.

Wir stufen Fluss als assess ein, weil das Konzept überzeugend ist und die Referenzfälle real sind, die Reifekurve aber steil und jung ist. Zero-Downtime-Schema-Evolution und Consumer-aware Snapshot-Lifecycle-Management kamen erst mit 0.9, veröffentlicht im März 2026 — genau die Lücken, die das Review Board angemerkt hat. Das ist ein Projekt, das sich schnell in die richtige Richtung bewegt, aber noch keine Komponente, die wir allein auf Basis der Dokumentation unter eine kritische Pipeline stellen würden.

Adoptionssignale

Aufstieg vom Apache Incubator zum Top Level Project, wobei der Graduation-Vorschlag einstimmige IPMC-Zustimmung und anschließende ASF-Board-Genehmigung erhielt (Graduation-Post).
Community-Metriken bei der Graduation: 157 Contributors, 2.000+ GitHub Stars und 1.700+ gemergte Pull Requests (Graduation-Post).
Berichtete Produktions-Deployments bei Alibaba, Xiaohongshu (Rednote), Fresha, JD.com, Ant Group und iQIYI.
Eine detaillierte öffentliche Produktions-Case-Study von Rednote zu Columnar Streaming, Cold-Data-Isolation und Lakehouse-Integration, vorgestellt auf der Flink Forward Asia 2026 (Case Study).
Die Release-Kadenz ist stetig und substanziell: 0.8 im November 2025 brachte Flink-2.1-Kompatibilität, Materialized-Table-Support und Helm Charts; 0.9 im März 2026 brachte Schema-Evolution, Storage-Level-Aggregationen, Change Data Feed, automatisches Rebalancing und Spark-Catalog-Integration.
Multi-Language-Zugriff entsteht gerade: Rust-, Python- und C++-Clients 0.1.0 teilen sich einen einzigen Rust-Core mit Arrow-basiertem Datenaustausch und decken Log-, Primary-Key- und Partitioned Tables ab.

Risiken

Kürzlich geschlossene Fähigkeitslücken. Sichere Schema-Evolution und Consumer-aware Snapshot-Lifecycle-Management waren 0.9-Features, sodass es wenig angesammelte operative Evidenz dafür gibt, dass sie unter lang laufenden Multi-Consumer-Workloads standhalten.
Pre-1.0-Storage-System. Das 0.9.1-Patch-Release behob einen Paimon-IOManager-Leak, der /tmp während des Tierings erschöpfte, sowie Korrektheitsfehler bei Partial Updates nach ADD COLUMN — die Art von Defektklasse, die man beim Einsatz junger Storage-Systeme erbt.
Konzentrierter Vendor- und geografischer Fußabdruck. Das Projekt wurde von Alibaba Cloud gespendet, und PMC-Führung sowie Produktionsreferenzen ballen sich um Alibaba und eine Handvoll großer chinesischer Plattformen, was die unabhängige Validierung einschränkt.
Unreifes Client-Ökosystem außerhalb der JVM. Die Rust-, Python- und C++-Clients liegen bei 0.1.0; alles jenseits von Flink- oder Spark-SQL-Zugriff ist im Frühstadium.
Architektonisches Lock-in durch die Table-Abstraktion. Kafka in einem zentralen Indexing- oder Feature-Pfad zu ersetzen, ist eine tiefgreifende Änderung an Datenverträgen und nachgelagerten Consumern und lässt sich schwer zurückdrehen, wenn sich die Projekttrajektorie ändert.

Vorteile & Nachteile

Vorteile

Fluss bietet eine gemeinsame Table-Abstraktion, die Streaming-Daten, kontinuierlich aktualisierte Tabellen und historische Lakehouse-Daten vereint, wodurch eine ganze Klasse von Glue-Code zwischen einer Message Queue und einem Table-Format entfällt.
Es integriert sich sowohl mit Apache Flink als auch mit Apache Spark als Compute-Engines und mit Apache Paimon, Apache Iceberg, Apache Hudi und Lance als Lakehouse-Formate, sodass es sich in einen bestehenden Open-Format-Stack einfügen kann, statt ihn zu ersetzen.
Es gibt großskalige Produktionsreferenzen für genau den Schmerzpunkt, den es adressiert: Rednote hat eine zentrale Real-Time-Indexing-Pipeline von einer Kafka-basierten Wide-Table-Architektur weg migriert, die an Kosten- und Stabilitätsgrenzen gestoßen war, und Taobao Instant Commerce betreibt darauf Real-Time-Decisioning.

Nachteile

Fähigkeiten, die reife Platform-Teams als selbstverständlich voraussetzen, sind erst kürzlich hinzugekommen — Zero-Downtime-Schema-Evolution und Consumer-aware Lifecycle-Management kamen erst mit dem 0.9-Release im März 2026 —, sodass die operative Erfahrung damit noch dünn ist.
Das Projekt ist noch pre-1.0, und das 0.9.1-Patch-Release behob produktionsrelevante Defekte wie einen Paimon-IOManager-Leak, der während des Tierings zur Erschöpfung des /tmp-Disks führte, sowie Out-of-Bounds-Fehler bei Partial Updates nach ADD COLUMN.
Fast die gesamte öffentlich dokumentierte Produktionsadoption stammt von Alibaba und einer kleinen Gruppe großer chinesischer Plattformunternehmen, und das Projekt wurde von Alibaba Cloud initiiert und gespendet, sodass unabhängige Operational Playbooks und Hiring-Pools begrenzt sind.

Empfehlung

Führen Sie eine abgegrenzte, zeitlich begrenzte Evaluierung durch, keine Migration. Der am besten passende Kandidat ist eine Pipeline, die bereits das Fehlermuster zeigt, für das Fluss entwickelt wurde: eine Kafka-gestützte Wide Table mit vielen nachgelagerten Consumern, die jeweils eine andere Teilmenge von Spalten lesen, wobei Kosten und Stabilität die Einschränkung sind und nicht purer Durchsatz. Reproduzieren Sie diese Form auf 0.9 oder später mit Ihren eigenen Flink- oder Spark-Jobs und messen Sie Read Amplification, Tiering-Verhalten in Ihre bestehenden Paimon- oder Iceberg-Tabellen und Recovery-Zeit — extrapolieren Sie nicht aus den Rednote- oder Taobao-Zahlen, deren Skala und interne Infrastruktur sich von den meisten Umgebungen unterscheiden.

Betonen Sie die beiden vom Review Board genannten Bereiche. Testen Sie Schema-Evolution gegen laufende Consumer, einschließlich Add-Column gefolgt von Partial Updates und Deletes, da dieser Pfad noch bis 0.9.1 Fixes hervorbrachte. Testen Sie danach Snapshot-Lifecycle und Retention mit einem nachhinkenden Consumer und stellen Sie sicher, dass Sie grundlegende operative Fragen beantworten können: wie Sie rebalancieren, wie Sie einen Broker für Wartungsarbeiten herausnehmen und wie sich Tiering verhält, wenn die lokale Disk voll ist. Halten Sie die JVM-Clients vorerst auf dem kritischen Pfad und behandeln Sie die Rust-, Python- und C++-Bindings als experimentell.

Wenn die Evaluierung erfolgreich ist, halten Sie Fluss für mindestens einen weiteren Release-Zyklus in einer nicht-kritischen oder Shadow-Position, bevor Sie es befördern, und überprüfen Sie seinen Ring im nächsten Quartal anhand zweier Signale: Produktions-Erfahrungsberichte von Organisationen außerhalb des Alibaba-Umfelds und ein Release der 1.0-Klasse mit stabilen Kompatibilitätsgarantien.