Für die meisten produktiven Umgebungen in der Schweiz empfiehlt sich ein hybrides Medallion-Design (Bronze/Silber/Gold-Schichten) mit Batch-Verarbeitung für periodische Reports und Streaming über Apache Kafka oder Apache Flink für echte Echtzeit-Anforderungen. Wer noch kein klares Latenz-SLA definiert hat, fährt mit Micro-Batching besser als mit vollem Streaming. Weiterhin empfiehlt es sich, ein entsprechendes Anfrage Formular | My Website zur Klärung der Anforderungen zu nutzen. Drei Faktoren bestimmen die Wahl:
- Latenzbedarf: Brauchen Sie Daten in Sekunden oder reichen Stunden? Echtes Streaming (Kafka + Flink) lohnt sich erst unter einer Minute Latenz.
- Datenvolumen und Kosten: Batch auf Apache Spark ist günstiger pro verarbeitetes Gigabyte; Streaming-Cluster laufen rund um die Uhr und erzeugen Fixkosten.
- Betriebsreife: Lambda-Architekturen verlangen zwei parallele Codepfade. Kappa oder Medallion sind für die meisten Teams wartbarer.
Technologien, die Sie kennen sollten: Apache Kafka (Ereignis-Streaming), Apache Flink (zustandsbehaftete Stream-Verarbeitung), Apache Spark (Batch und Micro-Batch), Apache Airflow oder Dagster (Ablaufsteuerung), dbt (Transformation als Code), Delta Lake (transaktionale Speicherschicht), Parquet und Avro (Spalten- bzw. zeilenorientierte Formate mit Schema-Unterstützung).
Inhaltsverzeichnis
- Welche Schichten bilden eine Datenpipeline?
- Wie unterscheiden sich 3-, 4- und 5-Phasen-Modelle?
- Batch, Streaming, Lambda, Kappa oder Medallion: Was passt wann?
- ETL oder ELT: Wo findet die Transformation statt?
- Wie betreibt man Pipelines zuverlässig?
- Wo scheitern Pipelines und was kostet Skalierung?
- Schritt-für-Schritt-Plan für Schweizer Unternehmen
- Von Datenverträgen bis Sicherheit: Was Entwicklungsteams konkret tun
- Wichtige Erkenntnisse
- Was wir in Schweizer Datenprojekten immer wieder sehen
- Outwork begleitet Ihr Datenpipeline-Projekt von Anfang an
- Nützliche Quellen und weiterführende Lektüre
Welche Schichten bilden eine Datenpipeline?
Jede produktionsreife Datenpipeline besteht aus vier Kernschichten, die jeweils klar abgegrenzte Aufgaben übernehmen. Kernkomponenten sind Ingestion, Verarbeitung/Transformation, Speicherung und Bereitstellung.
Ingestion
Die Aufnahmeschicht liest Daten aus Quellsystemen: Dateisysteme, REST-APIs, relationale Datenbanken (MS SQL, Oracle, PostgreSQL), Ereignisströme über Apache Kafka oder Webhooks. Hier werden Authentifizierung, Paginierung und Verbindungswiederholung gehandhabt. Ein häufig unterschätzter Punkt: Die Staging-Area direkt nach der Aufnahme ist keine Kür, sondern Pflicht. Ohne sie können Sie keine historischen Daten neu verarbeiten, wenn eine Transformation fehlerhaft war.
Verarbeitung und Transformation
Spark übernimmt schwere Batch-Transformationen; Flink oder Apache Beam eignen sich für Echtzeit-Pipelines mit Zustandsverwaltung. In ELT-Setups (dazu mehr in Abschnitt 5) findet ein Großteil der Transformation erst im Zielsystem statt, gesteuert durch dbt-Modelle.
Speicherung
Rohdaten landen im Data Lake (z. B. Azure Data Lake Storage, AWS S3). Kuratierte Daten liegen im Lakehouse-Format, typischerweise auf Delta Lake mit ACID-Transaktionen. Parquet ist das bevorzugte Spaltenformat für analytische Abfragen; Avro eignet sich für Schema-Evolution in Streaming-Szenarien, weil es Vorwärts- und Rückwärtskompatibilität unterstützt.
Bereitstellung (Serving)
Der Serving-Layer stellt Daten für Konsumenten bereit: Data Warehouses für BI-Tools, Feature Stores für maschinelles Lernen, APIs oder Message Queues für operative Anwendungen. Bestätigungen und Wiederholungslogik gehören ebenfalls in diese Schicht.
Profi-Tipp: Im Minimal-PoC können Sie Staging und Serving vereinfachen. Aber spätestens in der Produktion brauchen Sie eine explizite Staging-Area mit konfigurierbarer Aufbewahrungsdauer, sonst ist ein vollständiger Replay nach einem Fehler nicht möglich.
Wie unterscheiden sich 3-, 4- und 5-Phasen-Modelle?
Phasenmodelle beschreiben, wie Daten durch die Architektur fließen und welche Artefakte in jeder Stufe entstehen. Die Wahl des Modells beeinflusst direkt, wie viel Speicher Sie vorhalten müssen und wie gut Sie auf Fehler reagieren können.
| Modell | Phasen | Typische Artefakte | Wann sinnvoll |
|---|---|---|---|
| 3-Phasen | Aufnahme → Verarbeitung → Bereitstellung | Rohdaten, transformierte Tabellen, Serving-Views | Einfache Pipelines, wenige Quellen, kurze Compliance-Anforderungen |
| 4-Phasen | Aufnahme → Roh → Bereinigt → Konsum | Raw Lake, Staging-Zone, Curated Zone, Serving-Layer | Mittlere Komplexität, mehrere Quellsysteme, Replay-Bedarf |
| 5-Phasen | Aufnahme → Roh → Bereinigt → Angereichert → Konsum | Raw Lake, Staging, Curated, Enriched/Feature Layer, Serving | Analytische und operative Nutzung kombiniert, ML-Feature-Pipelines |
Für Schweizer Unternehmen mit Datenschutzanforderungen nach dem revidierten Datenschutzgesetz (revDSG) empfiehlt sich das 4- oder 5-Phasen-Modell: Rohdaten bleiben in einer dedizierten Raw-Zone mit klarer Zugangskontrolle und konfigurierbarer Aufbewahrung. Eine Faustregel für die Aufbewahrung von Rohdaten: 30 bis 90 Tage für operative Pipelines, länger nur wenn Compliance oder Audit-Anforderungen es verlangen. Längere Aufbewahrung erhöht die Speicherkosten, ermöglicht aber vollständige Replays bei Transformationsfehlern.
Batch, Streaming, Lambda, Kappa oder Medallion: Was passt wann?
Die Wahl des Architekturmusters ist die folgenreichste Designentscheidung. Falsch gewählt, zahlen Sie das mit Jahren erhöhtem Betriebsaufwand.
Batch-Verarbeitung ist das einfachste Muster. Apache Spark verarbeitet große Datenmengen periodisch, typischerweise stündlich oder täglich. Latenz liegt im Bereich von Minuten bis länger. Kosten pro verarbeitetem Gigabyte sind gering, weil Cluster nur während der Verarbeitung laufen. Replay ist trivial: Eingabedaten neu einlesen, Job erneut starten.
Streaming mit Kafka und Flink liefert Daten in Sekunden oder weniger. Der Preis: Cluster laufen dauerhaft, Exactly-once-Semantik erfordert sorgfältiges Checkpoint-Design, und Schema-Drift ist schwieriger abzufangen als im Batch. Echter Streaming-Bedarf besteht bei Betrugserkennung, Echtzeit-Dashboards oder IoT-Datenverarbeitung.
Lambda-Architektur kombiniert einen Batch-Pfad (für historische Korrektheit) mit einem Speed-Layer (für niedrige Latenz). Das klingt elegant, ist in der Praxis aber wartungsintensiv: Transformationslogik muss in zwei Codepfaden synchron gehalten werden. Jede Änderung an der Geschäftslogik erfordert doppelte Arbeit.
Kappa-Architektur löst dieses Problem durch einen einzigen Stream-First-Pfad. Historische Daten werden durch Replay aus einem unveränderlichen Ereignisprotokoll (insert-only Event Log) neu verarbeitet. Kappa ist einfacher zu betreiben, setzt aber voraus, dass alle Verarbeitungslogik als Stream-Job formulierbar ist.
Medallion-Architektur (Lakehouse) ist heute das meistgewählte Muster für kombinierte analytische und operative Anforderungen. Bronze-Schicht enthält Rohdaten, Silber bereinigte und validierte Daten, Gold aggregierte oder domänenspezifische Daten für Konsumenten. Delta Lake auf Databricks oder Azure Synapse ist die typische Implementierungsbasis.
- Batch: Niedrige Komplexität, hohe Replay-Fähigkeit, höhere Latenz, günstig im Betrieb.
- Streaming: Niedrige Latenz, hohe Komplexität, Exactly-once erfordert Sorgfalt, Dauerbetriebskosten.
- Lambda: Kombination beider Pfade, doppelter Wartungsaufwand, selten gerechtfertigt.
- Kappa: Einheitlicher Stream-Pfad, einfacher als Lambda, Replay über Event Log.
- Medallion: Schichtenmodell für gemischte Anforderungen, gut für Governance und Lineage.
Profi-Tipp: Micro-Batching mit Spark Structured Streaming oder Flink in Batch-Modus reicht für die meisten Anwendungsfälle aus, die keine Sub-Minuten-Latenz benötigen. Echtes Streaming lohnt sich erst, wenn Sie ein konkretes SLA unter 60 Sekunden haben und dieses SLA geschäftlich begründbar ist.
ETL oder ELT: Wo findet die Transformation statt?
ETL (Extrahieren, Transformieren, Laden) transformiert Daten vor dem Laden ins Zielsystem. ELT lädt Rohdaten zuerst und transformiert sie im Zielsystem. Der Unterschied klingt technisch, hat aber direkte Auswirkungen auf Architektur, Kosten und Werkzeugwahl.
ELT mit dbt hat sich als Standard für moderne Lakehouse- und Warehouse-Umgebungen etabliert. SQL-zentrierte Transformationsmodelle sind versionierbar, testbar und für Data Analysts zugänglich, ohne dass sie Spark-Code schreiben müssen.
- ELT bevorzugen, wenn: Das Zielsystem (Snowflake, BigQuery, Databricks) genug Rechenleistung hat, Transformationen häufig iteriert werden, und dbt-Modelle den Entwicklungszyklus beschleunigen sollen.
- ETL bevorzugen, wenn: Das Zielsystem ressourcenbeschränkt ist (On-Premises-Warehouse mit fixer Kapazität), Datenschutzanforderungen verlangen, dass sensible Felder vor dem Laden maskiert werden, oder schwere Transformationen (z. B. ML-Feature-Engineering) Spark-Cluster benötigen.
- Pushdown-Strategien: Spark kann Transformationslogik an das Zielsystem delegieren. Das reduziert Netzwerkverkehr, setzt aber voraus, dass der Connector Pushdown unterstützt.
- Reproduzierbarkeit: dbt-Modelle sind idempotent per Design. Jeder Run produziert dasselbe Ergebnis, solange die Eingabedaten gleich sind. Das vereinfacht Debugging und Reprocessing erheblich.
ETL als etabliertes Muster bleibt relevant, wo Compliance oder Systemgrenzen ELT ausschließen. Die Entscheidung ist keine Glaubensfrage, sondern eine Frage der Systemgrenzen und des Team-Know-hows.
Wie betreibt man Pipelines zuverlässig?
Orchestrierung, Beobachtbarkeit und Datenherkunft sind keine optionalen Ergänzungen. Sie sind der Unterschied zwischen einer Pipeline, die läuft, und einer, die man versteht und reparieren kann.
Apache Airflow ist der etablierte Standard für komplexe Abhängigkeitsgraphen (DAGs). Dagster bietet eine modernere Abstraktion mit eingebautem Asset-Katalog und besserer Testbarkeit. Cloud-verwaltete Varianten (Cloud Composer für Airflow, Astronomer) reduzieren den Infrastrukturaufwand.
Checkliste für produktiven Betrieb:
- Scheduling und Abhängigkeiten: Alle Jobs als DAG modelliert, Upstream-Abhängigkeiten explizit deklariert, keine impliziten Zeitkopplungen.
- Wiederholungslogik: Exponentielles Backoff für transiente Fehler, maximale Wiederholungsanzahl konfiguriert, Dead-Letter-Queue für nicht verarbeitbare Nachrichten.
- SLI/SLO-Beispiele: Verfügbarkeit der Pipeline > 99,5 %, Verarbeitungslatenz p95 < 15 Minuten für Batch, Fehlerrate < 0,1 % pro Run.
- Datenqualitäts-Metriken: Vollständigkeit (Null-Rate), Aktualität (Freshness), Eindeutigkeit, referenzielle Integrität zwischen Tabellen.
- Anomalieerkennung: Observability-Architekturen nach dem Monte-Carlo-Ansatz erkennen Abweichungen automatisch und lösen Alarme aus, bevor Konsumenten fehlerhafte Daten sehen.
- Lineage: Jede Transformation dokumentiert, welche Quelltabellen sie liest und welche Zieltabellen sie schreibt. Unverzichtbar für Impact-Analysen bei Schema-Änderungen und für Compliance-Nachweise.
Runbook bei Schema-Drift: Alarm auslösen, betroffene Downstream-Jobs pausieren, Schema-Änderung im Schema-Registry dokumentieren, Transformationen anpassen, Reprocessing aus Staging starten, Downstream-Jobs freigeben.
Wo scheitern Pipelines und was kostet Skalierung?
Die häufigsten Fehlerursachen sind nicht technischer Natur, sondern organisatorisch: fehlende Eigenverantwortung für Datenqualität und keine definierten Datenverträge zwischen Produzenten und Konsumenten.
- Fehlende Idempotenz: Ein Job, der bei Wiederholung doppelte Datensätze erzeugt, ist ein Produktionsproblem. Jede Transformation muss idempotent sein, d. h. mehrfaches Ausführen mit denselben Eingaben liefert dasselbe Ergebnis.
- Schema-Drift: Quellsysteme ändern Feldnamen oder Typen ohne Vorankündigung. Avro mit Schema Registry fängt das ab; ohne Registry merken Sie es erst, wenn Downstream-Jobs abstürzen.
- Backpressure: Streaming-Pipelines ohne Backpressure-Strategie überschwemmen Zielsysteme bei Lastspitzen. Kafka-Consumer-Groups mit konfigurierten Lag-Schwellwerten und Flink-Checkpoint-Intervallen sind die Standardlösung.
- Hot Keys: Ungleichmäßige Partitionierung in Kafka oder Spark führt zu einzelnen überlasteten Partitionen. Partitionsschlüssel sorgfältig wählen, Cardinality prüfen.
- Kostenhebel: Parquet mit Snappy-Kompression reduziert Speicherbedarf gegenüber unkomprimiertem JSON um den Faktor 5 bis 10. Storage-Tiering (heiß/warm/kalt) senkt Kosten für selten abgefragte Rohdaten. Cluster-Autoscaling in Spark verhindert Leerlaufkosten außerhalb der Verarbeitungsfenster.
- Rollback und Reprocessing: Delta Lake unterstützt Time Travel: Sie können zu einem früheren Tabellenstand zurückspringen und Daten ab einem definierten Zeitpunkt neu verarbeiten, ohne die gesamte Pipeline neu aufzusetzen.
Schritt-für-Schritt-Plan für Schweizer Unternehmen
Ein strukturierter Migrationsplan verhindert, dass ein PoC zur Dauerbaustelle wird. Typische Meilensteine:
- Ist-Analyse (Woche 1–3): Quellsysteme inventarisieren, Datenvolumen und Latenzanforderungen messen, bestehende Datenflüsse dokumentieren. Rollen klären: Data Owner, Data Engineer, Platform Engineer.
- Datenverträge und Schema-Design (Woche 3–6): Für jede Datenquelle einen Vertrag definieren: Felder, Typen, Nullable-Regeln, Aktualisierungsfrequenz, SLA. Avro- oder Parquet-Schemas im Schema-Registry hinterlegen.
- PoC (Monat 1–3): Einen repräsentativen Use Case implementieren. Metriken von Anfang an messen: Verarbeitungslatenz, Fehlerrate, Kosten pro Run. Staging-Area und Replay-Fähigkeit von Beginn an einplanen.
- Erweitertes Rollout (Monat 3–6): Weitere Quellsysteme anbinden, Orchestrierung mit Airflow oder Dagster einführen, SLI/SLO-Baseline festlegen, Alerting konfigurieren.
- Konsolidierung (Monat 6–12): Lineage-Tracking aktivieren, Datenqualitäts-Framework einführen, Kostenoptimierung (Tiering, Kompression), Governance-Dokumentation für revDSG-Compliance abschließen.
Governance und Compliance in der Schweiz: Das revidierte Datenschutzgesetz (revDSG) verlangt Transparenz über Datenverarbeitung, Zweckbindung und Auskunftsfähigkeit. Für Datenpipelines bedeutet das: Datenspeicherort (Data Residency) in der Schweiz oder im EWR dokumentieren, Zugangskontrolle (RBAC) auf Schicht-Ebene, Lineage für Auskunftsanfragen nutzbar machen. Ohne MDM entsteht ein Flickenteppich an Zuordnungsregeln; ein Golden-Record-Ansatz schafft eine einheitliche Datenbasis über Quellsysteme hinweg.
Von Datenverträgen bis Sicherheit: Was Entwicklungsteams konkret tun
Datenverträge und Schema-Verwaltung
Datenverträge zwischen Produzenten und Konsumenten sind das wirksamste Mittel gegen Schema-Drift. Ein Vertrag legt fest: Felder, Typen, Nullable-Regeln, Aktualisierungsfrequenz und Kompatibilitätsmodus (vorwärts, rückwärts, vollständig). Avro im Confluent Schema Registry oder Parquet mit eigenem Metastore sind die gängigen Implementierungen. Versionierung ist Pflicht: Breaking Changes erfordern eine neue Hauptversion, nicht eine stille Änderung.
Testing und Bereitstellung
dbt-Tests (not_null, unique, accepted_values, relationships) laufen bei jedem Commit. Integrationstests prüfen, ob Transformationen auf realen Stichprobendaten das erwartete Ergebnis liefern. Canary-Deployments für Streaming-Jobs: neue Version parallel zur alten starten, Ausgaben vergleichen, erst dann umschalten.
Sicherheit auf Architekturebene
Verschlüsselung im Ruhezustand (AES-256) und in der Übertragung (TLS 1.2+) sind Mindeststandard. Zugriffskontrolle über RBAC auf Tabellen- und Spaltenebene, nicht nur auf Datenbankebene. Secrets-Management über HashiCorp Vault oder den nativen Secret Manager des Cloud-Anbieters, nie hartcodiert in Pipeline-Code. Audit-Trails für alle Datenzugriffe, exportierbar für Compliance-Prüfungen.
Hybrid- und Cloud-Integration
On-Premises-Quellen an Cloud-Pipelines anbinden: VPN-Tunnel oder Private Link für verschlüsselte Verbindungen, JDBC-Konnektoren für relationale Datenbanken, SFTP für Dateibasierte Übertragungen. Netzwerkkosten bei Cloud-Transfers einkalkulieren: Egress-Gebühren zwischen Regionen oder Anbietern können bei großen Datenmengen erheblich sein. Best Practices für skalierbare Pipelines auf Databricks empfehlen VPC-Peering für niedrige Latenz zwischen On-Premises und Cloud.
Wichtige Erkenntnisse
Die richtige Datenpipeline-Architektur entscheidet über Latenz, Kosten und Wartbarkeit: Medallion mit Batch ist für die meisten Schweizer Produktivumgebungen der pragmatischste Ausgangspunkt.
| Thema | Details |
|---|---|
| Architekturwahl | Medallion/Lakehouse für gemischte Anforderungen; echtes Streaming nur bei nachgewiesenem Sub-Minuten-SLA. |
| PoC-Metriken | Verarbeitungslatenz, Fehlerrate und Kosten pro Run von Tag 1 an messen, nicht erst in der Produktion. |
| Governance Schweiz | revDSG verlangt Datenspeicherort-Dokumentation, RBAC und Lineage für Auskunftsfähigkeit. |
| Observability | SLI/SLO-Baseline vor dem Produktionsstart festlegen; Anomalieerkennung automatisiert, nicht manuell. |
| Kostenkontrolle | Parquet mit Kompression, Storage-Tiering und Cluster-Autoscaling sind die drei wirksamsten Kostenhebel. |
| Outwork als Partner | Outwork begleitet Schweizer Unternehmen von der Ist-Analyse über den PoC bis zum produktiven Betrieb. |
Was wir in Schweizer Datenprojekten immer wieder sehen
Das häufigste Muster bei Projekten, die ins Stocken geraten: Der PoC war erfolgreich, aber niemand hat Datenverträge definiert. Sechs Monate später kämpft das Team mit Schema-Drift aus drei Quellsystemen gleichzeitig, und die Staging-Area fehlt, also ist kein Replay möglich.
Was den Unterschied macht, ist nicht die Technologiewahl. Spark oder Flink, Airflow oder Dagster: Diese Entscheidungen sind reversibel. Was kaum reversibel ist: fehlende Eigenverantwortung für Daten (kein Data Owner), kein Budget für Monitoring und kein Testkonzept für Transformationen. Organisationen, die von Anfang an einen Data Owner pro Domäne benennen und Datenverträge als Artefakt behandeln, kommen schneller in die Produktion und haben weniger Betriebsprobleme.
Ein weiteres Muster: Schweizer KMU unterschätzen den Aufwand für Compliance-Dokumentation. Das revDSG ist kein einmaliges Projekt, sondern ein laufender Betriebsprozess. Lineage und Audit-Trails, die von Anfang an in die Architektur eingebaut sind, kosten wenig extra. Nachträglich eingebaut, kosten sie viel.
Outwork begleitet Ihr Datenpipeline-Projekt von Anfang an
Viele Schweizer Unternehmen wissen, was sie brauchen: eine saubere, wartbare Datenpipeline-Architektur mit klarer Governance. Der Engpass ist selten das Konzept, sondern die Umsetzungskapazität und das Know-how für die ersten kritischen Schritte.
Outwork übernimmt genau diese Schritte: Ist-Analyse, Datenvertrags-Design, PoC-Implementierung und Produktionsrollout. Unsere Softwareentwicklung deckt den gesamten Stack ab, von der Ingestion-Schicht bis zum Serving-Layer. Für Teams, die schnell skalieren müssen, bieten wir Developer-Outsourcing mit erfahrenen Data Engineers, die sofort einsatzbereit sind. Alle Deliverables sind auf Schweizer Datenschutzanforderungen ausgerichtet: Datenspeicherort, RBAC und Lineage-Dokumentation inklusive.
Nehmen Sie jetzt Kontakt auf und vereinbaren Sie ein kostenloses Erstgespräch. Wir klären gemeinsam, welches Architekturmuster zu Ihren Anforderungen passt und wie ein realistischer PoC-Plan aussieht. Alle Leistungen im Überblick finden Sie auf unserer Website.
Nützliche Quellen und weiterführende Lektüre
Für den Einstieg und den PoC:
- Datenpipeline-Architektur: Komponenten, Typen und Aufbau (AtroCore): Solide Übersicht über Kernkomponenten, Staging und Replay-Strategien. Gut als Referenz für die Ist-Analyse.
- Data Pipelines in der Praxis (IT-Schulungen): Praxisnahe Erklärungen zu Orchestrierung mit Airflow und ELT-Patterns mit dbt.
- ETL-Pipeline vs. Datenpipeline (Qlik): Klare Abgrenzung zwischen ETL und allgemeinen Pipeline-Konzepten, nützlich für Architekturentscheidungen.
Für den Produktionsbetrieb:
- Lambda vs. Kappa: Griechische Architekturen (inside-it.ch): Schweizer Perspektive auf Architekturmuster, mit konkreten Argumenten gegen unnötige Lambda-Komplexität.
- Monte-Carlo-Observability-Architektur (Orchestra): Technische Erklärung, wie automatisierte Anomalieerkennung in Pipelines integriert wird.
- Best Practices für skalierbare Datenpipelines (Microsoft/Databricks): Empfehlungen für Produktionsarchitekturen auf Databricks, inklusive Hybrid-Cloud-Integration.
- Was ist eine Datenpipeline? (IBM): Konzeptioneller Einstieg, nützlich für die Kommunikation mit nicht-technischen Stakeholdern.
