Data Integration: Definition, Muster und Abgrenzung

Data Integration (deutsch: Datenintegration) ist der Oberbegriff für alle Verfahren, die Daten aus getrennten Quellsystemen zu einem gemeinsamen, auswertbaren Bestand zusammenführen. Dazu zählen Batch-Verfahren (Daten werden gesammelt und in Paketen übertragen), ereignisorientierte Verfahren (jede Änderung wird sofort weitergegeben) und virtuelle Verfahren (Zugriff auf mehrere Quellen ohne physische Kopie). Ziel ist ein konsistenter Datenbestand für Reporting, Analytik und KI-Modelle.

Was ist Data Integration?

Data Integration ist ein Sammelbegriff für die technischen und organisatorischen Muster, die verstreute Datenbestände zu einem auswertbaren Gesamtbild zusammenführen. Die Ausgangslage ist in fast jedem Unternehmen dieselbe: Die operativen Systeme (Warenwirtschaft, CRM für Kundendaten, Webshop, Finanz-Buchhaltung) halten ihre Daten jeweils in eigenen Formaten und Strukturen. Reporting-Werkzeuge, Analysen und KI-Modelle brauchen aber einen gemeinsamen Zugriff über diese System-Grenzen hinweg. Data Integration schließt diese Lücke.

Der Begriff bündelt sechs Muster-Familien, die sich in Latenz, Verantwortung und Datenbewegung unterscheiden: reine Data Ingestion (Extract und Load ohne Transformation), klassisches ETL (Transformation vor dem Load in ein Warehouse), ELT (Load in einen Lakehouse- oder Cloud-Warehouse-Store und Transformation dort), Change Data Capture (ereignisorientierte Übertragung von Row-Änderungen), Zero-ETL (Managed-Integration eines Cloud-Anbieters) und Data Virtualization (Query-Zeit-Föderation ohne physische Datenbewegung). iPaaS-Plattformen wie Mulesoft, Boomi oder Azure Logic Apps decken einen benachbarten Bereich ab: API- und Event-orientierte Integration zwischen SaaS-Anwendungen, oft prozess- statt reporting-getrieben.

Historisch wanderte der Schwerpunkt von der Enterprise Application Integration der 1990er (Message-Broker, Punkt-zu-Punkt-Konnektoren) über die Warehouse-getriebene ETL-Welle der 2000er zur Streaming- und CDC-Welle der 2010er. Heute prägen drei Verschiebungen den Begriff: ELT löst ETL im Lakehouse-Kontext ab, weil die Zielplattform genug Compute für die Transformation liefert; Managed-Angebote (Zero-ETL, Lakeflow Connect, Fivetran) verlagern die Pipeline-Verantwortung zum Anbieter; iPaaS-Plattformen zergliedern klassische Integrations-Portfolios in kleinteilige, event-orientierte Flows.

Data Integration operiert auf zwei Ebenen. Physische Integration bewegt Daten in ein Zielsystem und arbeitet mit Kopien, die aktualisiert werden müssen. Logische Integration nutzt Federation und liefert Query-Zeit-Zugriff auf mehrere Quellen ohne Datenbewegung. Die meisten Architekturen kombinieren beide Ebenen: Federation für seltene Ad-hoc-Zugriffe, Materialisierung für hochfrequente Reporting-Workloads.

Abgrenzung zu Ingestion, ETL/ELT, Zero-ETL, Virtualization und iPaaS

Data Integration wird häufig mit einem seiner Teil-Muster gleichgesetzt. Die folgende Tabelle sortiert die Begriffe entlang ihrer Rolle in der Familie.

Begriff	Verhältnis zu Data Integration	Kernunterschied
Data Ingestion	Teil-Muster	Deckt Extract und Load in ein Zielsystem ab; Transformation und Federation gehören definitionsgemäß nicht dazu. Data Integration umfasst zusätzlich Transformation, CDC, Virtualization und iPaaS.
ETL / ELT	Verfahren	Konkrete Ausprägung physischer Integration. ETL transformiert vor dem Load (Warehouse-Vorgehen), ELT lädt zuerst und transformiert im Zielsystem (Lakehouse-Vorgehen). Data Integration ist die Klammer über ETL, ELT und weitere Verfahren.
Change Data Capture	Verfahren	Ereignisorientierte Erfassung von Row-Änderungen aus dem Transaktions-Log der Quelle. Liefert einen der Bausteine für physische Data Integration mit niedriger Latenz.
Zero-ETL	Bereitstellungsform	Managed-Integration eines Cloud-Anbieters, die eine CDC- oder ETL-Strecke im Hintergrund betreibt. Verfahren steht in der Data-Integration-Familie, Betriebsverantwortung wandert zum Anbieter.
Data Virtualization	Logische Integration	Query-Zeit-Föderation ohne physische Datenbewegung. Ergänzt physische Integration und ersetzt sie in hochfrequenten Workloads selten vollständig.
iPaaS	Nachbar-Familie	Integration Platform as a Service für API- und Event-orientierte Integration zwischen SaaS-Anwendungen. Überschneidet sich mit klassischer Data Integration, adressiert primär Prozess-Integration statt Reporting-Konsolidierung.

Zwei Trennlinien sind für Architektur-Entscheidungen zentral. Erstens die Trennung zwischen physischer und logischer Integration: Sobald die Auswertungslast steigt, wird Materialisierung wirtschaftlicher als Federation. Zweitens die Trennung zwischen Reporting-Integration (Data Integration im engeren Sinn) und Prozess-Integration (iPaaS): Reporting-Integration bewegt Daten in einen analytischen Store, Prozess-Integration verbindet operative Anwendungen miteinander.

Beispiel: konsolidierter Datenbestand über drei Quellen

Ein Handelsunternehmen konsolidiert Datenbestände aus SAP S/4HANA (Finance und Auftragsabwicklung), Salesforce (CRM) und Shopify (Webshop) in einem Databricks Lakehouse. Die konsolidierte Datenschicht speist das Kunden-360-Reporting, ein Forecasting-Modell und die Marketing-Automation. Drei unterschiedliche Muster der Data-Integration-Familie kommen zum Einsatz.

Der S/4HANA-Bestand fließt über einen Replication Flow in SAP Datasphere und ein Zero-Copy-Sharing-Setup in das Lakehouse. Der Replication Flow arbeitet CDC-basiert; die Daten liegen anschließend als Delta-Tabellen im Bronze-Layer, ohne physisch kopiert zu werden. Salesforce liefert über einen Lakeflow-Connect-Konnektor einen kontinuierlichen CDC-Stream in das Bronze-Layer. Der Shopify-Bestand kommt über eine iPaaS-Plattform, die Bestell-Events als JSON auf einen Kafka-Topic legt; Structured Streaming verarbeitet den Topic und schreibt in eine Silver-Tabelle mit dedupliziertem Zustand.

Auf Silver-Ebene führt ein ELT-Verfahren mit Delta Live Tables die drei Quellen über einen gemeinsamen Kunden-Schlüssel zusammen und stellt eine konsolidierte Kundendimension bereit. Reporting- und Modell-Workloads greifen ausschließlich auf die Silver- und Gold-Schicht zu. Federation über Unity Catalog Lakehouse Federation bleibt für seltene Ad-hoc-Auswertungen auf die Original-Quellen reserviert. Die Auswahl der Muster richtet sich nach Latenz-Anforderung, Quell-Charakteristik und Betriebsverantwortung; eine generische Präferenz für ein einzelnes Verfahren führt in heterogenen Landschaften regelmäßig zu Fehlbewertungen.