Warum Datenpipelines immer wichtiger werdenInterview mit Helge Scheil, Executive VP Engineering bei Fivetran
13.12.2023
Lesedauer: 7 Minuten
|
Warum werden Datenpipelines als unsichtbare kritische Infrastrukturen angesehen?
Sie sind kritisch, weil ohne sie in vielen Unternehmen der Betrieb zum Erliegen käme. Sie sind unsichtbar, weil in den meisten Unternehmen auf die Endpunkte viel Wert gelegt wird, also die Informationssysteme, nicht aber auf die verbindenden Elemente dazwischen.
Bitte nennen Sie uns einige reale Beispiele zu deren Bedeutung.
Generell sehen wir zwei große Nutzungsbereiche, einmal für Analytics beziehungsweise den Business-Intelligence-Bereich, zum anderen im operativen Downstream. Dort ziehen wir Daten aus den Quellsystemen heraus, bearbeiten diese weiter und überführen sie dann in die Zielsysteme entweder für Business Intelligence oder auch für den operativen Bereich. Gerade bei letzterem gibt es kritische Businessprozesse. Als Beispiel kann ich die Lufthansa als einer unserer deutschen Kunden nennen, die für ihre Flugplanungssysteme letztendlich Daten aus verschiedenen Systemen herausholt, um für die Flugplanung relevante Informationen wirklich direkt bis ins Cockpit zu bringen.
Auf dem Weg dorthin wird mit denselben Mechanismen auch die Logistik, Terminierung, Beladung von Flugzeugen usw. koordiniert. Das ganze nutzt nicht nur die Lufthansa selbst, sondern wird auch Fluglinien angeboten, um ihnen Logistik, Flugplanung, Terminierung, Beladung usw. als Service zur Verfügung zu stellen. Diese Daten sind businesskritisch, weil sie pünktliches Abreisen ermöglichen oder teilweise verhindern können.
Diese Daten werden aus den verschiedensten Quellsystemen geladen. Dazu gehören Daten über Wetterlagen, über Beladung, über Gäste usw. und das für über 300 Fluglinien! Jetzt haben Sie einen Eindruck, wie komplex diese Datenflüsse letztendlich auch sein können und wie hoch die Anforderungen sind, das in Echtzeit zu tun.
Ihr Vorschlag, die Datenhaltung zu zentralisieren, zielt vor allem auf Punkt-zu-Punkt-Datenströme. Was hat Sie zu diesem Ansatz inspiriert und wo sehen Sie die Hauptvorteile für Ihre Kunden?
Um beispielsweise einen 360-Grad-Einblick in Kundendaten und Kundenszenarien zu bekommen, können Daten generell aus verschiedenen Datenquellen zentralisiert werden. Dazu werden sie in einem Data Warehouse oder auch einem Data Lake zusammengeführt. So kann man die Daten gesammelt analysieren und mögliche quellenübergreifende Wechselwirkungen feststellen. So werden relativ schnell Antworten auf betriebswirtschaftliche Fragestellungen gefunden.
Durch diesen Ansatz ergibt sich aber eine zeitliche Verzögerung, um die Fragen zu beantworten. Es gibt auch qualitative Probleme, die sich daraus ergeben. Kunde A heißt im ERP-System nicht unbedingt A, sondern vielleicht A 0.2, während er im CRM-System A heißt. Das nicht zentralisiert abzugleichen und zusammenzuführen, ist unheimlich schwierig. Systemübergreifend Abfragen und Prozesse zu steuern, kann man sicherlich ansatzweise mit Lösungen wie Kafka versuchen. Aber da wird es dann auch wieder kompliziert. Wie können denn normale Benutzer diese Informationen abfragen? Mit zugänglichen Tools, die den Zugriff auf die zentralisierten Daten auch einfacher machen?
Wir reden also nicht nur über eine Technologie und deren Prozesse, sondern auch über Verfügbarmachung für Nutzer, die diese Daten weiterverarbeiten oder analysieren müssen. Das ist einfacher auf einer zentralisierten Datenbank als in einer dezentralisierten Welt.
Was waren Ihre umfangreichsten Projekte bezüglich Datenmenge?
Wir bedienen heutzutage über 7.000 Kunden. Über diese Kunden lassen wir jeden Monat 200 Data Pipelines laufen, im Durchschnitt circa drei pro Kunden. Wir haben einen Kunden – eine Kombination von Uber und Delivery Hero bzw. Dash für den lateinamerikanischen Markt – der über 10.000 Data Pipelines hat! Dessen Datenvolumen liegt bei 130 Terabyte im Monat. Das heißt im Durchschnitt 3 bis 4 Terabyte pro Tag.
Wir haben auch Kunden, die in Echtzeit riesige Datenmengen aus ihren Online-Transaktionsdatenbanken herausfiltern und für die Weiterverarbeitung in Cloud Data Warehouses transportieren. Im Extrembereich haben wir innerhalb von zwei Stunden ein Terabyte abgearbeitet! Es ist eine Herausforderung die Geschwindigkeit zu halten, mit der das Datenvolumen bearbeitet wird. Es gelingt uns aber ganz gut.
Wie sollte der Übergang auf die Data-Pipeline-Verarbeitung erfolgen? Soll eine parallele lokale Infrastruktur aufrechterhalten werden?
Unbedingt, wenn es um alte Systeme geht und das Datenvolumen hoch ist. Das größte Risiko dieser Projekte ist aber, dass das Altsystem am Ende nicht abgeschaltet wird!
Bei der Umstellung muss man nicht nur einen Plan, sondern auch einen Terminplan haben. Wie werden diese Daten, der Datenabgleich, die Datenqualität und die Datentypen verifiziert, sodass in Ruhe das System abgeschaltet werden kann?
Zudem muss die Verlässlichkeit der neuen Pipeline gewährleistet sein. Das bedeutet nicht nur die Daten-qualität des Ablieferns, sondern auch der regelmäßigen erfolgreichen Überlieferung der Daten an das Zielsystem. Wir sind relativ stolz darauf, dass wir eine Verfügbarkeit von 99,95 Prozent haben.
Was würden Sie denn als den typischen Zeitrahmen für die Umstellung solcher Infrastruktur ansehen?
Wir sehen zum Teil sehr kurze Übergangszeiten. Bei kleineren Systemen guckt man sich das ein paar Tage an, dann kann man das alte abschalten. Bei sehr großen Systemen sollte man das im Minimum drei Monate laufen lassen, gerade bei Finanz- und Accounting-Systemen.
Wie würden Sie Snowflake in die Datenlandschaft einordnen?
In erster Linie treten wir zusammen mit Snowflake als Kooperationspartner auf. Die meisten unserer Kunden benutzen Snowflake als ihr Cloud Data Warehouse. Daneben werden auch BigQuery von Google oder Databricks genutzt. Mit Snowflake verbindet uns eine sehr enge Verbindung. Bob Mugler, einer unser Aufsichtsratsmitglieder, war CEO von Snowflake und hat uns eine sehr gute Starthilfe geleistet.
Allerdings gibt es einige Unique Selling Points, die uns unterscheiden. Wir haben eine größere Münchner Firma als Kunden, die haben Snowflake als zentrale Instanz in ihrem Vorhaben designed und wollen viele andere Systeme ablösen. Aber als große Firma kauft man auch viele andere Firmen auf. Nicht alles lässt sich bei einer 300.000 Mitarbeiter Firma zentral koordinieren. Es gibt da noch andere Data Lakes, Field Storage, Cloud Data Warehouses und operative Datenbanken, wo Daten ebenfalls hingeschoben werden.
Unser USP Nummer eins ist die Verfügbarkeit und Simplicity bzw. Nutzerfreundlichkeit ist das zweite Merkmal. Mit einigen Klicks oder per API kann alles konfiguriert werden. Vorgefertigte Modelle in unseren dbt Starterpaketen für die analytische Weiterverarbeitung ermöglichen es, die Daten im Zielsystem schon so aufzubereiten, dass nur das Business Intelligence System angeschlossen werden muss, um dann Berichte erzeugen zu können.
Ein weiteres Merkmal für uns ist, dass wir komplett Plattform-agnostisch sind. Unsere Infrastruktur läuft auf AWS, auf Microsoft Azure und der Google Cloud Plattform.
Warum ist das dann relevant?
Es sind kritische Infrastrukturen, wo die Daten fließen. Wer hat darauf Zugriff? Es gibt den Kunden immer ein sicheres Gefühl, wenn sie dort Kunde sind, wo sie ihre internen Cloud-Infrastrukturen ebenfalls betreiben. Aus europäischer Sicht laufen wir in Frankfurt, in Irland, in London und in Paris.
Was treibt Sie denn in dieser Branche an und wie würden Sie die zukünftige Entwicklung einschätzen?
Bei uns dreht sich alles um Data Movement und die angrenzenden Bereiche wie Data Governance und Data Trust. Man muss wissen, woher die Daten gekommen sind und wer wie die Datenveränderungen objektmäßig vorgenommen hat. Security ist auch ein ganz spannendes Thema. Wir haben als reine cloudbasierte Lösung angefangen. Verschiedene Unternehmen in der Finanzbranche oder auch in der Verteidigungsbranche wollen nicht, dass ihre Daten von ihren eigenen „Behind the Firewall“ Systemen über ein offenes Netzwerk im Internet in eine Cloud-Datenbank geschoben werden.
Daher investieren wir sehr intensiv in Hybridmodelle, lokale Data Pipelines, die Daten verarbeiten und Daten bewegen, die aber nie durch die ganzen Cloudaccounts durchlaufen. Das einzige, was bei uns registriert ist, sind die Metadaten: Quelle und Ziel, Häufigkeit, Datenvolumen. Die Daten selbst sehen wir nicht. Die bleiben Behind the Firewall im Rechenzentrum der Kunden. Wir nennen das Local Data Processing. Intern heißt das Ganze Remote Execution. Normal werden verschlüsselte Daten über die Cloud verarbeitet. Das ist hier nicht der Fall, auch verschlüsselte Daten verlassen zu keinem Zeitpunkt die internen Systeme.
Letzte Frage: Wie kam denn Ihr Firmenname zustande?
1954 wurde Fortran erfunden von dem Informatiker John Backus. Das war die erste Programmiersprache, die einen Zugang zum sehr simplen Umgang mit Computersystemen zur Verfügung gestellt hat. Wir haben den Zugang zu Daten so simpel dargestellt, dass wir uns daran orientiert haben, eine Zahl weitergezählt haben und bei Fivetran gelandet sind.
Vielen Dank für das Gespräch!
Das Interview führten Jana Lekscha und Norbert Gronau.
Helge Scheil
ist als Executive Vice President of Engineering bei Fivetran verantwortlich für die technische Weiterentwicklung der 450+ vollständig gemanagten Konnektoren für automatisiertes Data Movement.
Nach seinem Abschluss in BS, Computer Science und Business Administration an der Wirtschaftsakademie Kiel startete er seine Laufbahn bei Oracle, nach einigen Stationen in Softwareunternehmen ist er heute ein profunder Kenner der Branche und Engineeringexperte.
Branchen: branchenübergreifend
Das könnte Sie auch interessieren
