Was ist eine Data Pipeline? Einfach erklärt

Eine Data Pipeline ist ein automatisierter Prozess, der Daten von einer oder mehreren Quellen zu einem Zielsystem transportiert – und sie dabei bereinigt, transformiert oder anreichert. Statt manuell CSV-Dateien zu kopieren oder SQL-Abfragen von Hand auszuführen, übernimmt die Pipeline diesen Datenfluss zuverlässig, wiederholbar und skalierbar.

Klingt simpel. In der Praxis ist es das grösste Infrastrukturproblem datengetriebener Unternehmen: Daten liegen in ERP-Systemen, SPS-Steuerungen, Cloud-Diensten, Excel-Tabellen und IoT-Sensoren. Sie haben unterschiedliche Formate, Aktualisierungsrhythmen und Qualitätsniveaus. Ohne eine saubere Pipeline landet nichts davon in einem Data Warehouse oder Data Lake, wo es tatsächlich analysiert werden kann.

Was eine Data Pipeline konkret macht

Eine Data Pipeline durchläuft typischerweise drei bis fünf Schritte – je nach Architektur und Anwendungsfall:

Extraktion. Daten werden aus Quellsystemen abgeholt. Das kann eine Datenbank-Abfrage sein (z.B. alle neuen Aufträge seit dem letzten Lauf), ein API-Call an eine SaaS-Anwendung (Salesforce, HubSpot, Google Analytics), ein Datei-Import (CSV, JSON, Parquet) oder ein Echtzeit-Stream von Sensoren über MQTT oder Azure Event Hub.

Transformation. Die Rohdaten werden in eine nutzbare Form gebracht: Datentypen konvertieren, Duplikate entfernen, Spalten umbenennen, Werte normalisieren, Tabellen verknüpfen. Hier entscheidet sich die Datenqualität. Werkzeuge wie dbt machen diesen Schritt modular, testbar und dokumentiert – statt fragiler SQL-Skripte, die nur eine Person versteht.

Laden. Die transformierten Daten werden ins Zielsystem geschrieben – typischerweise ein Data Warehouse für analytische Abfragen (OLAP) oder ein Data Lake für flexible Speicherung.

Validierung. Gute Pipelines prüfen nach jedem Schritt: Sind alle Datensätze angekommen? Stimmen die Datentypen? Gibt es unerwartete Null-Werte? Das ist Data Governance auf technischer Ebene.

Orchestrierung. Der gesamte Ablauf wird gesteuert: Wann startet die Pipeline? Was passiert bei einem Fehler? Welche Schritte hängen voneinander ab? Tools wie Azure Data Factory, Fabric Pipelines oder Apache Airflow übernehmen diese Aufgabe.

ETL vs. ELT: Der entscheidende Unterschied

Die beiden häufigsten Pipeline-Architekturen unterscheiden sich in der Reihenfolge von Transformation und Laden:

ETL (Extract – Transform – Load). Daten werden erst transformiert, dann ins Zielsystem geladen. Der klassische Ansatz: Vor dem Laden wird bereinigt, aggregiert und validiert. Vorteil: Nur saubere Daten landen im Warehouse. Nachteil: Die Transformation muss vor dem Laden stattfinden – das erfordert zusätzliche Infrastruktur und macht Änderungen aufwändig.

ELT (Extract – Load – Transform). Daten werden erst roh geladen, dann im Zielsystem transformiert. Der moderne Ansatz, der mit leistungsfähigen Cloud-Plattformen wie Microsoft Fabric oder Snowflake möglich geworden ist. Vorteil: Rohdaten bleiben erhalten (nichts geht verloren), Transformationen können nachträglich angepasst werden. Nachteil: Das Zielsystem muss die Rechenleistung für die Transformation bereitstellen.

In der Praxis setzen wir heute meist auf ELT in Kombination mit dem Medallion-Modell (Bronze → Silver → Gold): Rohdaten landen zuerst unverändert im Data Lake (Bronze), werden dann bereinigt und verknüpft (Silver) und schliesslich für konkrete Anwendungsfälle aggregiert (Gold). Genau so haben wir es bei der Datenplattform für die Basler Verkehrsbetriebe umgesetzt: Weichensensordaten fliessen über Azure Event Hub in Microsoft Fabric, werden mit dbt core transformiert und stehen dann in Power BI zur Verfügung.

Vergleich: ETL vs. ELT

Batch vs. Streaming: Wann brauche ich Echtzeit?

Nicht jede Pipeline muss in Echtzeit laufen. Die beiden Grundmuster:

Batch-Pipelines verarbeiten Daten in regelmässigen Intervallen – stündlich, täglich oder wöchentlich. Das reicht für die meisten analytischen Anwendungsfälle: Monatsreports, BI-Dashboards, Finanzauswertungen. Batch-Pipelines sind einfacher zu bauen, zu testen und zu debuggen.

Streaming-Pipelines verarbeiten Daten in Echtzeit oder Near-Realtime (Sekunden bis wenige Minuten Latenz). Sie sind nötig, wenn sofort auf Ereignisse reagiert werden muss: Anomalieerkennung an Maschinen, Live-Monitoring von Fahrzeugflotten, Alerting bei Grenzwertüberschreitungen. Typische Technologien: Apache Kafka, Azure Event Hub, MQTT-Broker.

In der Praxis kombinieren viele Unternehmen beide Ansätze: Sensordaten fliessen per Streaming in ein Echtzeit-Dashboard für das Betriebsteam, während dieselben Daten parallel per Batch in ein Data Warehouse für langfristige Analysen geladen werden. Dieses Muster setzen wir z.B. im Bereich Industrie & Logistik bei Kunden ein, die sowohl operatives Monitoring als auch strategische Auswertungen benötigen.

Praxisbeispiele: Data Pipelines bei Substring

Data Pipelines sind kein abstraktes Konzept – sie sind das Rückgrat jeder Datenplattform, die wir bauen. Hier drei Beispiele:

Weichensensordaten bei den Basler Verkehrsbetrieben. Tram-Weichen erzeugen kontinuierlich Sensordaten. Diese fliessen über Azure Event Hub in Microsoft Fabric, werden mit dbt nach dem Medallion-Modell transformiert und in Power BI visualisiert. Die Pipeline läuft automatisiert – von der Weiche bis zum Dashboard.

Predictive Maintenance bei der Schweizerischen Post. Die Kippschalensorter der Post erzeugen Betriebsdaten, die über eine Pipeline in eine Analyseplattform fliessen. Dort erkennt ein KI-Modell Muster, die auf bevorstehende Ausfälle hindeuten – bevor sie passieren.

Marketing-Datenplattform für Basel Tourismus. Daten aus Google Analytics, Social Media (Pinterest, Facebook, Instagram), ERP und Baselcard fliessen über Fivetran und Meltano in eine Snowflake-Plattform. Dort werden sie transformiert und in Tableau visualisiert. Mehrere Quellen, ein Ziel, ein automatisierter Prozess – das ist eine Data Pipeline.

Typische Fehler beim Aufbau von Data Pipelines

Aus unserer Erfahrung in Dutzenden Kundenprojekten sind das die häufigsten Stolpersteine:

Keine Fehlerbehandlung. Eine Pipeline, die bei einem Fehler einfach abbricht und nichts meldet, ist nutzlos. Gute Pipelines haben Retry-Logik, Alerting und Logging. Wenn ein API-Call scheitert, soll die Pipeline es nochmals versuchen, nicht das ganze Dashboard leer lassen.

Fehlende Datenvalidierung. Nur weil Daten ankommen, heisst das nicht, dass sie korrekt sind. Ohne Tests (z.B. «Sind alle Pflichtfelder gefüllt?», «Liegt der Umsatz im plausiblen Bereich?») schleichen sich Fehler ein, die erst Wochen später im Report auffallen.

Zu viel Komplexität am Anfang. Manche Teams versuchen, sofort eine Enterprise-Pipeline mit Echtzeit-Streaming, Schema Registry und Multi-Tenant-Architektur zu bauen. Besser: Mit einer einfachen Batch-Pipeline starten, die funktioniert – und dann iterativ erweitern.

Keine Dokumentation. Wer hat diese Pipeline gebaut? Was macht sie genau? Welche Quellen sind angebunden? Ohne Dokumentation wird jede Pipeline nach sechs Monaten zur Blackbox. Tools wie dbt lösen dieses Problem, weil Dokumentation Teil des Codes ist.

Excel als Zwischenschritt. Sobald jemand Daten aus der Pipeline exportiert, in Excel bearbeitet und wieder importiert, ist die Automatisierung gebrochen. Jede manuelle Intervention ist ein potenzieller Fehler.

Welche Tools setzen wir ein?

Die Auswahl des richtigen Tools hängt vom Kontext ab. Hier die Technologien, die wir in der Praxis einsetzen:

Ingestion (Daten laden): Azure Event Hub (Streaming), Fivetran und Meltano (SaaS-Konnektoren), Fabric Pipelines (Batch), custom Python-Skripte für Spezialfälle.

Transformation: dbt core (SQL-basiert, modular, testbar), PySpark in Fabric Notebooks (für komplexe Verarbeitungen), SQL Stored Procedures (Legacy).

Speicherung: Microsoft Fabric (OneLake, Warehouse, Lakehouse), Snowflake, Azure Synapse.

Orchestrierung: Fabric Pipelines, Azure Data Factory, GitHub Actions.

Visualisierung: Power BI, Tableau.

Einen Überblick über alle Technologien finden Sie auf unserer Technologie-Seite.

Wann brauchen Sie eine Data Pipeline?

Nicht jedes Unternehmen braucht sofort eine komplexe Pipeline. Aber sobald Sie eines dieser Muster erkennen, wird es Zeit:

• Sie kopieren regelmässig manuell Daten zwischen Systemen (Export → Excel → Import).
• Ihre Reports sind veraltet, weil die Datenaufbereitung Tage dauert.
• Sie haben mehr als drei Datenquellen, die zusammengeführt werden müssen.
• Ihr Team verbringt mehr Zeit mit Datenaufbereitung als mit Analyse.
• Sie planen eine Datenplattform auf Microsoft Fabric, Snowflake oder Azure.

Ein guter erster Schritt: Mit einer Datenlandkarte erfassen, welche Daten wo liegen. Danach eine Datenstrategie definieren, die klärt, welche Daten wohin fliessen sollen. Und dann die Pipeline bauen – iterativ, mit einem konkreten Use Case.

Wie wir Sie unterstützen

Unser BI- und Data-Platform-Team baut Data Pipelines für Unternehmen aus Industrie, öffentlichem Verkehr und öffentlicher Verwaltung. Von der ersten Datenlandkarte bis zur produktiven Pipeline in Power BI – alles aus einer Hand.

Sie wollen Ihre Datenflüsse automatisieren? Kontaktieren Sie uns – wir zeigen Ihnen den schnellsten Weg.

Weiterführende Glossar-Einträge

• dbt + Microsoft Fabric – Modernes Data Engineering mit SQL
• Was ist ein Data Warehouse? – Das typische Ziel einer Pipeline
• Was ist ein Data Lake? – Rohdatenspeicher für heterogene Quellen
• OLAP und OLTP – Operative vs. analytische Verarbeitung
• Data Governance – Datenqualität organisatorisch sicherstellen
• Excel ablösen – Warum manuelle Tabellen zum Problem werden
• Big Data – Wenn Datenmengen explodieren
• Vom Shopfloor zum Insight – Produktionsdaten analysierbar machen
• Unified Namespace – Echtzeitdaten nach ISA-95 strukturiert bereitstellen
• Kreislaufwirtschaft & Daten (BePro-CEND) – Warum Circular Economy Daten braucht

‍