Eine Data Pipeline ist ein automatisiertes System, das Daten zu Analysezwecken von Quellsystemen an ein Ziel verschiebt. Sie löst ein häufiges Problem für datengetriebene Unternehmen: wie nützliche Informationen, die über viele verschiedene Systeme verstreut sind, abgewickelt und analysiert werden können. Die Pipeline kann die Daten zuverlässig und wiederholt verschieben.

Im Folgenden erklären wir, was eine Data Pipeline ist, wie sie funktioniert, worin sich Batch- und Streaming-Ansätze unterscheiden und wie sich Zahlungsdaten in ein Data-Pipeline-Setup einfügen.

Das Wichtigste auf einen Blick

• Eine Data Pipeline ersetzt manuelle Exporte und Ad-hoc-Prozesse, die unter Belastung abbrechen.

• Die Wahl zwischen Batch- und Streaming-Pipelines hängt davon ab, wie aktuell Ihre Daten sein müssen. Finanz- und Analyse-Workloads lassen sich in der Regel problemlos im Batch-Betrieb ausführen.

• Zahlungsdaten erfordern in einem Pipeline-Setup besondere Sorgfalt. Eine native Synchronisation durch Ihren Zahlungsdienstleister verbessert die Sicherheit und Zuverlässigkeit.

Was ist eine Data Pipeline?

Eine Data Pipeline ist eine automatisierte Abfolge von Schritten, die Daten aus einer oder mehreren Quellen extrahiert, diese optional transformiert und in ein Ziel lädt, wo sie analysiert oder zur Ausführung von Vorgängen verwendet werden können. Das Ziel ist in der Regel ein Data Warehouse, ein Data Lake oder ein Cloud-Speicher.

Warum sind Data Pipelines für das Reporting und die Entscheidungsfindung wichtig?

Der Wert einer Data Pipeline liegt darin, was möglich wird, wenn sich Ihre Daten an einem Ort befinden, an dem Sie sie nutzen können. Data Pipelines bieten die folgenden Vorteile:

• Reduzierte Datensilos: Wenn Ihre Daten auf verschiedene Systeme verteilt sind – wenn beispielsweise Umsatzdaten bei Ihrem Zahlungsdienstleister, Daten von Endkundinnen und Endkunden in Ihrem Customer Relationship Management (CRM)-System und Support-Daten in Ihrem Helpdesk liegen –, können Sie systemübergreifende Fragen nicht einfach beantworten. Eine Pipeline, die diese Quellen zentralisiert, ermöglicht funktionsübergreifende Analysen.

• Konsistente Definitionen: Pipelines erzwingen Struktur. Wenn jedes Team Daten über die Pull-Methode aus denselben Data-Warehouse-Tabellen abruft, die auf dieselbe Weise berechnet werden, sind Metriken wie der monatlich wiederkehrende Umsatz (MRR) in allen Berichten konsistent definiert – und es gibt keine Diskussionen darüber, wessen Zahlen richtig sind.

• Wiederholbare, überprüfbare Prozesse: Pipelines liefern Tag für Tag vergleichbare Ergebnisse. Diese Wiederholbarkeit macht es möglich, Metriken im Laufe der Zeit zu verfolgen und Anomalien zu untersuchen, wenn sie auftreten.

• Schnellere Reporting-Zyklen: Finanzteams, die zuvor Tage mit dem Extrahieren und Abgleichen von Daten verbracht haben, können den Zyklus erheblich verkürzen, wenn sich die Daten bereits bereinigt und strukturiert im Data Warehouse befinden.

Was sind die Kernkomponenten einer Data Pipeline?

Viele Pipelines, unabhängig von ihrer Komplexität, bestehen aus denselben Bausteinen. Dies sind die wichtigsten Komponenten:

• Quellen: Wo die Daten herkommen, einschließlich Datenbanken, Software-as-a-Service (SaaS)-Application Programming Interfaces (APIs), Event-Streams und Flatfiles. Je mehr Quellen eine Pipeline über die Pull-Methode abruft, desto wichtiger wird es, das Schema und die Zuverlässigkeit jeder einzelnen Quelle zu verfolgen und wie oft sich die Quelle ändert.

• Aufnahme: Der Mechanismus zum Extrahieren von Daten aus Quellen in die Pipeline. Dies können geplante Datenbankabfragen, ein Abonnement für einen Webhook-Stream oder ein Drittanbieter-Konnektor sein. Die Aufnahme ist oft der Punkt, an dem Pipelines unterbrochen werden (z. B. APIs ändern sich, Anmeldeinformationen laufen ab, Quellen fallen aus), weshalb gute Aufnahmeebenen so konzipiert sind, dass sie Fehler erkennen und beheben.

• Transformationen: Der Schritt, der Rohdaten in eine Form umwandelt, die analytisch nützlich ist. Beispielsweise bereinigen Transformationen Datensätze und entfernen Duplikate, führen Daten aus mehreren Quellen zusammen, berechnen abgeleitete Felder oder erzwingen ein konsistentes Schema über Systeme hinweg, die von Haus aus keines teilen.

• Orchestrierung: Die Ebene, die Abhängigkeiten und Zeitpläne verwaltet. Wenn Tabelle B davon abhängt, dass Tabelle A vollständig geladen ist, muss die Orchestrierungsebene dies wissen und die Reihenfolge erzwingen. Tools wie Apache Airflow, Prefect und Data Build Tool (dbt) können diese Art der Abhängigkeitsverwaltung übernehmen.

• Ziele: Wo die verarbeiteten Daten landen. Dies ist normalerweise ein Cloud-Data-Warehouse wie Snowflake oder Redshift oder ein Cloud-Speicher wie S3 oder Google Cloud Storage (GCS). Die Wahl des Ziels bestimmt, welche Art von Analyse im weiteren Verlauf möglich ist.

Worin unterscheiden sich Batch- und Streaming-Pipelines?

Für die Datenverschiebung haben sowohl Streaming als auch Batching ihre Daseinsberechtigung. Die richtige Wahl hängt davon ab, wie alt Ihre Daten sein dürfen, bevor sie ein echtes Problem verursachen.

Batch-Pipelines

Diese verschieben Daten nach einem Zeitplan (z. B. stündlich, nachts, wöchentlich). Sie eignen sich gut für Workloads, bei denen Latenz keine Rolle spielt, wie zum Beispiel monatliche Finanzberichte, wöchentliche Kohortenanalysen von Endkundinnen und Endkunden und nächtliche Synchronisationen mit einem Data Warehouse. Die Batch-Verarbeitung ist in der Regel einfacher aufzubauen und zu betreiben. Für viele Analyse-Anwendungsfälle ist es genau das, was Sie brauchen.

Streaming-Pipelines

Diese verarbeiten Daten kontinuierlich bei Eintritt von Ereignissen, mit einer Latenz, die in Sekunden oder Millisekunden statt in Stunden gemessen wird. Sie wurden für Anwendungsfälle entwickelt, bei denen das Reagieren auf veraltete Daten tatsächliche Kosten verursacht, wie z. B. Betrugserkennung, Bestandsverfolgung in Echtzeit und Echtzeit-Dashboards.

Bevor Sie diesen Weg der Datenverschiebung wählen, sollten Sie die Kapazitäten Ihres Teams ermitteln. Die Streaming-Infrastruktur ist teurer und schwerer zu debuggen. Wenn Ihr Datenteam klein ist, überwiegt der Aufwand einer Streaming-Pipeline möglicherweise die Latenzvorteile.

In welcher Beziehung stehen Data Pipelines, ETL und ELT zueinander?

Während eine Data Pipeline jedes automatisierte System ist, das Daten von einer Quelle zu einem Ziel verschiebt, sind Extract, Transform, and Load (ETL) und Extract, Load, and Transform (ELT) zwei Muster, die diese Bewegung strukturieren. So funktionieren sie.

ETL

ETL bedeutet, dass Daten transformiert werden, bevor sie in das Ziel geladen werden. Die Transformation erfolgt in einer Zwischenschicht, sodass nur die bereinigte, geformte Ausgabe das Data Warehouse erreicht. Dies war das vorherrschende Muster, als Speicher teuer war und Data Warehouses nicht gut für die massenhafte Verarbeitung von Rohdaten geeignet waren.

ELT

Bei ELT werden die letzten Schritte umgekehrt. Rohdaten werden extrahiert und in das Data Warehouse geladen, und die Transformation erfolgt dort mittels Structured Query Language (SQL) oder einem Tool wie dbt. Moderne Cloud-Data-Warehouses sind günstig genug, um Rohdaten zu speichern, und leistungsstark genug, um sie zum Zeitpunkt der Abfrage oder als geplanten Job zu transformieren. ELT hat sich zum gängigeren Muster für Analyse-Workloads entwickelt, teils weil es Rohdaten für die erneute Verarbeitung bewahrt und Transformationen einfacher zu überprüfen, zu versionieren und zu ändern macht.

Nicht jede Pipeline passt exakt in eine der beiden Kategorien. Einige verschieben Daten fast ohne Transformation; sie synchronisieren rohe Event-Logs von einer API in einen Cloud-Speicher zur späteren Verarbeitung. Die Terminologie ist als Kurzform für die architektonische Absicht nützlich und nicht als präzise Taxonomie.

Wie fügt sich ein Zahlungsdienstleister in ein Data-Pipeline-Setup ein?

Zahlungsdaten gehören in der Regel zu den wertvollsten und kompliziertesten Daten im Data Warehouse eines Unternehmens. Teams durchlaufen meist dieselbe Entwicklung, wenn sie versuchen, diese zu verwalten.

Exporte von kommagetrennten Werten (CSV)

Viele Teams beginnen mit CSV-Exporten. Sie laden Berichte herunter, bereinigen sie und laden sie in das Data Warehouse hoch. Aber Exporte brechen ab, Schemata ändern sich oder jemand vergisst, den Prozess auszuführen. Als Folge fehlen historische Daten oft oder sind inkonsistent.

ETL-Konnektoren von Drittanbietern

Als Nächstes wenden sie sich Tools zu, die Daten über die Pull-Methode aus einer Zahlungs-API abrufen und nach einem Zeitplan in ein Data Warehouse laden. Diese sind einigermaßen zuverlässig, aber sie führen einen Anbieter in einen sensiblen Datenfluss ein. Wenn ein Team über Finanzdaten verfügt, die ein zusätzliches Drittanbietersystem durchlaufen, vergrößert dies die Angriffsfläche, führt zu Compliance-Überlegungen und generiert Daten, die sich möglicherweise geringfügig von denen des Zahlungsdienstleisters unterscheiden.

Native Synchronisation über Stripe Data Pipeline

Stripe Data Pipeline ermöglicht eine direkte Synchronisation mit Stripe, die Daten ohne einen Drittanbieter-Konnektor in ein Data Warehouse oder einen Cloud-Speicher verschiebt. Die Einrichtung erfordert nur wenige Klicks, es ist kein Code (No-Code) erforderlich und die Pipeline enthält historische Daten aus dem Stripe-Konto einer Nutzerin oder eines Nutzers. Sie enthält außerdem ausgewählte synthetisierte Berichte und kuratierte Datensätze wie strukturierte Finanzübersichten und analysierbare Tabellen zur Analyse von MRR, Betrug und mehr. Diese werden von Stripes eigenen Systemen generiert und können von einem generischen Konnektor nicht repliziert werden.