Data Processing: Definition, Batch, Stream, Abgrenzung

Data Processing (Datenverarbeitung) bezeichnet die systematische Umwandlung von Rohdaten (unverarbeitete Ausgangsdaten) in eine strukturierte, auswertbare Form. Der Vorgang umfasst vier Bausteine: Erfassung (Einlesen aus der Quelle), Bereinigung (Fehler und Lücken entfernen), Transformation (fachliche Umformung) und Ausgabe (Bereitstellung an ein Zielsystem). Der Begriff ist ein Oberbegriff über konkrete Verarbeitungsmodi wie Batch (geplante Sammelverarbeitung), Stream (fortlaufende Ereignisverarbeitung) und transaktionale Verarbeitung (Einzelvorgänge in operativen Systemen) und lässt offen, mit welcher Technologie und in welchem Rhythmus die Umwandlung erfolgt.

Was ist Data Processing?

Data Processing beschreibt jede Umwandlung von Rohdaten in eine für Menschen oder Systeme nutzbare Form. Der Begriff ist bewusst technologieneutral: Er umfasst sowohl eine nächtliche ETL-Strecke (Extract, Transform, Load: Auslesen aus Quellsystemen, Umformen, Laden in ein Zielsystem) in einem Data Warehouse (zentrale Datenbank für Auswertungen) als auch die Auswertung eines einzelnen Klick-Events im Millisekunden-Bereich. Er trennt das Was der Verarbeitung (aus Rohdaten wird nutzbare Information) vom Wie (Verarbeitungsmodus, Verarbeitungs-Engine, Werkzeug-Landschaft).

Konzeptionell besteht Datenverarbeitung aus vier Schritten: Erfassung der Rohdaten aus einer Quelle (Ingestion), Validierung und Bereinigung, fachliche Transformation durch Aggregation, Anreicherung und Formatierung sowie Speicherung und Bereitstellung des Ergebnisses an einen Konsumenten. Diese Schritte sind eine gedankliche Ordnung, kein Werkzeug-Modell; sie kommen in unterschiedlicher Reihenfolge und Granularität in konkreten Architekturen vor.

Der englische Begriff data processing stammt aus der Rechenzentrums-Ära der 1950er- und 1960er-Jahre, in der Lochkarten und Mainframe-Batch-Läufe die dominierende Form der computergestützten Verarbeitung waren. Die deutsche Entsprechung „Elektronische Datenverarbeitung" (EDV) hat sich in Verwaltungs- und Rechtstexten gehalten, im modernen Fach-Vokabular aber ausgedient. Heute ist Data Processing der neutrale Oberbegriff über die konkreten Muster der Datenverarbeitung.

Der Grund für die Begriffsbreite liegt in der Trennung von Anforderung und Umsetzung. In der Abstimmung zwischen Fachbereich und Plattform-Team hilft der Umbrella-Term, weil zuerst die Anforderung an Latenz, Vollständigkeit und Frequenz geklärt werden muss, bevor der passende Verarbeitungsmodus ausgewählt wird.

Verarbeitungsmodi: Batch, Stream, Transactional

Unter dem Dach Data Processing haben sich drei grundlegende Verarbeitungsmodi etabliert. Sie unterscheiden sich in der Struktur der Eingabedaten (endlich vs. unbegrenzt) und in der geforderten Latenz.

Modus	Eingabe	Latenz	Typischer Einsatz
Batch Processing	endliche Datenmenge, geplante Läufe	Minuten bis Stunden	nächtliche DWH-Aufbereitung, Reporting, Modell-Training
Stream Processing	fortlaufender Ereignisstrom, unbegrenzt	Millisekunden bis Sekunden	Betrugserkennung, Live-Dashboards, IoT-Telemetrie
Transactional Processing (OLTP)	Einzeltransaktion in operativem System	Millisekunden	Bestellung, Buchung, Zahlung

Zwischen Batch und Stream liegt der inkrementelle Batch: häufige, kleine Läufe, die nur die seit dem letzten Lauf neuen Daten verarbeiten, ohne echte Ereignis-für-Ereignis-Kontinuität. In modernen Lakehouse-Architekturen wird die Grenze zwischen inkrementellem Batch und Stream über Engines wie Apache Spark Structured Streaming oder Apache Flink weiter unscharf, weil beide Modi über dieselbe API bedient werden können.

Abgrenzung: Data Pipeline, ETL, Data Ingestion, OLTP

Data Processing wird häufig mit benachbarten Begriffen verwechselt. Die folgende Übersicht klärt die üblichen Verwechslungen.

Begriff	Verhältnis zu Data Processing
Data Pipeline	konkrete, gerichtete Kette von Verarbeitungsschritten mit definiertem Start, Ziel und Zeitplan. Eine Pipeline ist die technische Umsetzung eines Verarbeitungsfalls; Processing ist das Konzept dahinter.
ETL / ELT	spezifische Muster für Extraktion, Transformation und Laden von Daten in ein Zielsystem. ETL/ELT ist eine Ausprägung von Batch- oder inkrementeller Datenverarbeitung; Data Processing ist der breitere Oberbegriff.
Data Ingestion	ausschließlich der Aufnahme-Schritt (Rohdaten aus der Quelle in ein Ziel). Data Processing umfasst zusätzlich Transformation und Ausgabe.
Data Analytics	die Auswertung bereits verarbeiteter Daten mit dem Ziel Erkenntnis oder Entscheidung. Analytics nutzt das Ergebnis von Data Processing als Eingabe.
OLTP (Transactional Processing)	einzeltransaktionale Verarbeitung in operativen Datenbanken. Sitzt konzeptionell unter Data Processing, wird in Datenplattform-Kontexten aber gesondert benannt, weil OLTP-Systeme (Postgres, MySQL, SAP HANA) andere Engine-Anforderungen haben als analytische Verarbeitung (OLAP).

Die Abgrenzung zwischen Data Processing und Data Pipeline ist besonders relevant. Eine Pipeline führt Processing aus, benötigt einen Orchestrator (etwa [Apache Airflow](https://airflow.apache.org/docs/) oder Databricks Lakeflow Jobs) und hat einen deklarierten Zeitplan. Data Processing beschreibt dagegen den logischen Vorgang und existiert auch ohne Pipeline: eine Ad-hoc-SQL-Query gegen eine Silver-Tabelle verarbeitet Daten, ohne Teil einer Pipeline zu sein.

Beispiel: Verkaufsdaten in zwei parallelen Modi

Eine Handelsplattform verarbeitet ihre Verkaufsdaten in zwei parallelen Modi. Ein nächtlicher Batch-Lauf aggregiert die abgeschlossenen Transaktionen des Vortags über [Apache Spark](https://spark.apache.org/docs/latest/) zu Umsatz-Kennzahlen pro Filiale und Warengruppe und schreibt das Ergebnis in eine Gold-Tabelle für das BI-Dashboard des Managements. Latenz und Frequenz sind hier unkritisch; entscheidend sind Durchsatz und Rechen-Effizienz.

Parallel liest ein Stream-Processing-Job die Klick-Events aus dem Webshop kontinuierlich aus einem [Apache Kafka](https://kafka.apache.org/documentation/)-Topic, berechnet in gleitenden Fenstern die aktiven Nutzer pro Minute und speist ein Live-Dashboard für den Betrieb. Latenz im Sekundenbereich ist die harte Anforderung; Durchsatz und Kosten treten dahinter zurück.

Beide Verarbeitungen erfüllen denselben Zweck (Rohdaten in nutzbare Kennzahlen umwandeln) in unterschiedlichen Modi. Die Entscheidung, welcher Modus für welche Fragestellung passt, ist keine Werkzeug- sondern eine Anforderungsentscheidung: Wie schnell muss das Ergebnis vorliegen, wie vollständig muss der Datenbestand sein, welche Kosten sind tragbar?