Data Flow

Ein Data Flow ist ein Baustein in SAP Datasphere, der Daten aus einer oder mehreren Tabellen liest, umformt und in eine Zieltabelle schreibt. Gebaut wird er im Data Builder, dem grafischen Modellierungs-Werkzeug in Datasphere. Ein Data Flow verarbeitet immer den kompletten Datenbestand statt nur neuer oder geänderter Zeilen (ohne sogenanntes Delta-Verfahren) und gilt seit Einführung der neueren Transformation Flows als Fallback-Werkzeug für Sonderfälle.

Was ist ein Data Flow?

Data Flow bezeichnet in SAP Datasphere einen konkreten Baustein-Typ im [Data Builder](/insights/glossar/data-builder/) und keinen allgemeinen Datenfluss-Begriff. Ein Data Flow beschreibt eine Umformung zwischen einer oder mehreren Quelltabellen und einer Zieltabelle innerhalb eines Datasphere-Space (ein abgegrenzter Arbeitsbereich in Datasphere). Gebaut wird die Umformung grafisch, indem einzelne Verarbeitungsschritte wie Verknüpfen (Join), Filtern, Spalten auswählen (Projection), Zusammenfassen (Aggregation) oder Zusammenführen (Union) zu einer Kette verbunden werden. Alternativ lässt sich ein Python-Script einbinden, wenn die Logik in klassischer Datenbank-Abfragesprache (SQL) schwer abbildbar ist.

Ein Data Flow läuft nicht als HANA-SQL-Pushdown, sondern in einem Kubernetes-Pod, der pro Ausführung neu initialisiert wird. Die Initialisierungszeit liegt typischerweise bei rund 20 Sekunden pro Lauf, unabhängig vom Datenvolumen. Python-Operatoren laufen laut SAP-Angaben um Faktor 40 bis 50 langsamer als äquivalente SQL-Logik. Diese Charakteristik macht Data Flows für große Volumen und hochfrequente Ausführungen ungeeignet und begrenzt den Anwendungsbereich auf kleinere Datenmengen oder Sonderlogik.

Data Flows arbeiten ohne Delta-Verarbeitung. Jede Ausführung liest die Quelltabellen vollständig oder mit datumsbasiertem Filter, transformiert und schreibt in die Zieltabelle. Es gibt kein Change-Data-Capture und kein Delta-Staging, mit dem sich nur veränderte Datensätze verarbeiten ließen. Wiederholte Läufe verarbeiten daher denselben Datenbestand mehrfach, was den Verbrauch von Data Integration Hours in die Höhe treibt.

Seit der Einführung der Transformation Flows mit Delta-Staging und der Weiterentwicklung der Replication Flows für Extract-and-Load-Szenarien ist der Data Flow in der SAP-Roadmap als Fallback-Werkzeug positioniert. Empfohlen wird er nur, wenn weder ein Transformation Flow noch ein Replication Flow den Anwendungsfall abdecken, etwa bei komplexer Python-Regel-Logik ohne SQL-Äquivalent oder bei Bestandsobjekten aus früheren Datasphere-Modellierungen.

Abgrenzung zu verwandten Datasphere-Objekten und zum generischen Begriff

Die wichtigste Abgrenzung ist die zu den beiden anderen Flow-Typen im Data Builder: Transformation Flow und Replication Flow. Zusätzlich lohnt sich die Trennung vom generischen Begriff „Data Flow" außerhalb des SAP-Stacks und die Einordnung gegenüber der Task Chain und der Open-SQL-Procedure als Nachbar-Bausteinen in Datasphere.

Die aktuelle SAP-Empfehlung ist ELT-First mit Replication Flow für den Extract-and-Load-Teil und Transformation Flow für die Transformation. Data Flows bleiben als Fallback-Objekttyp bestehen und werden weiter unterstützt, gelten aber nicht mehr als bevorzugter Weg für neu gebaute Transformationen.

Beispiel: Python-Regel-Logik in einem Data Flow

Ein Datasphere-Bestandsprojekt aus dem Jahr 2022 modelliert die konzernweite Provisions-Berechnung im Vertrieb. Die Verkaufsbelege liegen als Local Table im Datasphere-Space, aus S/4HANA per Replication Flow übertragen. Die Provisions-Logik selbst folgt einem mehrstufigen Regelwerk mit Verzweigungen über Produktgruppe, Region und Vertragstyp und greift auf einen externen Referenzkatalog zu, der bewusst außerhalb der HANA-Datenbank gepflegt wird.

Das Team modelliert die Berechnung als Data Flow im Data Builder. Ein Python-Operator implementiert die Verzweigungslogik und schreibt in eine Ziel-Local-Table „Provision je Beleg". Der Data Flow läuft nächtlich als Schritt einer Task Chain nach dem vorgelagerten Replication Flow und vor der abschließenden Aktualisierung der Analytic Models im [Business Builder](/insights/glossar/business-builder/). Die Laufzeit ist wegen des Python-Faktors überschaubar, weil die Datenmenge pro Nacht klein bleibt.

Beim Umbau der Datasphere-Landschaft prüft das Team, welche Data Flows sich in Transformation Flows mit grafischer oder SQL-Logik überführen lassen. Data Flows bleiben nur für die Provisions-Regel bestehen, weil die Verzweigungslogik im gegebenen Detailgrad in SQL nicht sauber abbildbar ist. Alle anderen Bestands-Data-Flows werden in Transformation Flows migriert und profitieren von Delta-Staging und geringeren Initialisierungskosten.