Ein agiler Ansatz zum Aufbau von Datenpipelines

Als Teamleiter bin ich ein großer Fan des Einsatzes von Workflow-Management-Methoden wie Kanban oder Agile zur Planung und Überwachung der Arbeit, die mein Team und ich zu erledigen haben.

Im Datenbereich ist es jedoch nicht immer eindeutig, welche Aufgaben zu erstellen sind und wie der erforderliche Aufwand abzuschätzen ist, da die Datensätze, mit denen Sie arbeiten müssen, unsicher und komplex sind.

In diesem Blog gebe ich Ihnen konkrete Tipps, wie Sie Ihre Data-Engineering-Projekte bei der Verwendung der agilen Methodik strukturieren können. Insbesondere hoffe ich, Ihnen dabei zu helfen, Ihren Data-Engineering-Workflow besser zu verwalten, indem ich einen Standardansatz für die Erstellung neuer Datenpipelines skizziere, der unabhängig von den verwendeten Datensätzen oder Technologien funktioniert.

Der Standard-Engineering-Ansatz, den wir in diesem Blog beschreiben, sieht folgendermaßen aus:

1. Beginnen Sie mit einem sogenannten 'Spike', um einen detaillierten Entwurf der neuen Datenpipeline zu erstellen.
2. Teilen Sie die Implementierung der Pipeline in drei Geschichten auf, die klare Ergebnisse haben.
3. Schätzen Sie den Arbeitsaufwand für jede Geschichte mithilfe von Story Points.

Die Einhaltung des vorgeschlagenen Arbeitsablaufs sollte Ihnen helfen, Datenpipelines zuverlässig und ohne Überraschungen für Sie und Ihre Stakeholder zu liefern.

Das Problem: Unbekanntes rund um die Quelldaten

Wenn Sie für Ihre Stakeholder eine neue Datenpipeline aufbauen, möchten Sie ihnen eine Vorstellung davon vermitteln, wie lange dies dauern wird und welche Ressourcen dafür erforderlich sind. Bei Daten ist dies aus zwei Gründen nicht immer einfach abzuschätzen: Unsicherheit und Komplexität.

Ungewissheit, denn bei der Integration einer neuen Datenquelle wissen Sie oft nicht im Voraus, wie die Daten aussehen. Außerdem haben Sie möglicherweise noch keine Erfahrung mit dem Quellsystem, aus dem Sie die Daten abrufen müssen. Das bedeutet, dass Sie wahrscheinlich noch nicht wissen, ob es Standardkonnektoren gibt oder ob Sie etwas Eigenes entwickeln müssen.

Abgesehen von technischen Unsicherheiten kann es auch bei den Interessengruppen zu Unklarheiten kommen. Sind die Anforderungen Ihrer Stakeholder für Sie glasklar? Wissen Sie, welche Spalten sie benötigen? Wie häufig Sie die Daten abrufen sollen und ob sie einen ersten Ladevorgang benötigen? Wir stellen oft fest, dass es einiger Kommunikation bedarf, um vollständig zu verstehen, wann die Anforderungen erfüllt sein sollten.

Die Komplexität ergibt sich daraus, dass Ihre Quelldaten alle möglichen unterschiedlichen Formate haben können (CSV, JSON, XML, ...). Wenn Sie Pech haben, können Sie sogar mehrere ineinander verschachtelte Arrays finden. Angenommen, Ihr Ziel als Ingenieur ist es, eine "saubere" Datenschicht zu erstellen, dann müssen Sie sorgfältig darüber nachdenken, wie Sie Ihre Daten so bereinigen, dass sie von Ihren Datenanalysten oder Data Scientists in der sauberen Datenschicht leicht konsumiert werden können (die sich dann auf Knien dafür bedanken sollten, dass Sie das richtig gemacht haben!).

Ungewissheit und Komplexität machen es schwierig, sich vorzustellen, wie Ihre Lösung aussehen soll. Daher ist es fast unmöglich, im Voraus abzuschätzen, wie viel Arbeit für die Ausführung der Aufgabe erforderlich ist.

Beginnen Sie mit einem Spike, um die Verwirrung zu beseitigen

Unsere Lösung für diese beiden Probleme besteht darin, jede neue Datenpipeline mit einem sogenannten Spike zu beginnen. Das Ziel des Spikes ist es, ein Pipeline-Design zu dokumentieren, das die Fragen in der folgenden Tabelle beantwortet:

Frage	Ergebnis
Welche Datensätze benötigen wir genau aus dem Quellsystem?	Übersicht über die genauen Tabellen, die abgerufen werden sollen
Welches Datenformat haben diese Datensätze und wie werden wir sie analysieren?	Mapping, wie Sie das Quellformat in das gewünschte bereinigte Datenformat konvertieren. Zum Beispiel, wie Sie von verschachtelten JSON-Tabellen zu unverschachtelten Delta-Tabellen kommen.
Wie werden wir mit dem Quellsystem verbunden?	Planen Sie, ob Sie eine API, Middleware oder z.B. einen SFTP-Server zum Abrufen der Daten verwenden möchten.
Mit welcher Häufigkeit werden wir die Daten abrufen?	Zum Beispiel: wöchentlich, täglich, stündlich, in Echtzeit.
Benötigen wir eine Anfangsbelastung? Wenn ja, wie viele Jahre historischer Daten?	Bekannte Größe der Anfangsladung und wie man sie erhält.
Haben wir es mit datenschutz- oder sicherheitsrelevanten Daten (PII) zu tun?	Eine Übersicht über die Attribute sensibler Daten und deren Behandlung, die von den Rechts- und Sicherheitsgremien genehmigt wurde.

Die Antworten auf die obigen Fragen werden alle Unsicherheiten im Zusammenhang mit der neuen Datenpipeline, die Sie implementieren möchten, ausräumen. Wenn Sie den Entwurf haben, können Sie die User Stories und Teilaufgaben klar identifizieren UND deren Aufwand abschätzen.

Wir verwenden oft einen Sprint (von 2 Wochen), um den Spike (neben anderen Aufgaben) zu bewältigen. Wir schätzen den für den Spike erforderlichen Aufwand nicht, da wir uns mit den eingeführten Unbekannten beschäftigen.

Bevor der Spike beginnt, sollten Sie Ihre Stakeholder darüber informieren, dass Sie von ihnen Input benötigen. Auf diese Weise können Sie lange Vorlaufzeiten vermeiden, in denen Sie und Ihr Team auf Inputs oder Zugriffsrechte von verschiedenen Interessengruppen wie den Geschäftsanwendern, dem Source Owner und/oder dem Enterprise Architect warten müssen. Planen Sie Meetings im Voraus, um den Schwung während des Sprints aufrechtzuerhalten.

Die Implementierung der Pipeline aufschlüsseln

Wenn Sie wissen, wie Sie Ihre Pipeline aufbauen wollen, können Sie die User Stories für den nächsten Sprint, in dem Sie die Pipeline tatsächlich aufbauen, verfeinern.

Die Schwierigkeit besteht darin, dass Sie keine zu großen Stories erstellen möchten, da diese im Sprint nicht fertiggestellt werden können. Unfertige Stories in den nächsten Sprint zu verschieben, ist sowohl für Ihr Team als auch für Ihre Stakeholder ärgerlich, da Sie keinen Mehrwert liefern.

Im Gegenteil, Sie wollen auch nicht, dass Ihre Geschichten zu klein sind, da der Aufwand für die Verwaltung Sie ausbremsen wird.

Eine Story sollte ein Stück Arbeit darstellen, das einen bestimmten Wert liefert. Daher unterteilen wir unsere Pipeline-Implementierung immer in die folgenden 3 Stories:

1. Implementieren Sie eine Pipeline zum inkrementellen Laden von Daten.
2. Implementieren Sie eine Datenpipeline mit voller Auslastung.
3. Implementieren Sie die Umwandlung von Rohdaten in saubere Daten.

Für jede dieser Geschichten gibt es ein klares Ergebnis. Wenn zum Beispiel die inkrementelle Ladepipeline fertig ist, werden Sie neue und aktualisierte Datensätze in der gewünschten Häufigkeit (täglich, stündlich, in Echtzeit) einlesen. Mit der Full Load Data Pipeline hingegen können Sie den gesamten Datenbestand aus dem Quellsystem abrufen. Dies ist nützlich, um historische Daten in Ihrem Zielspeicher zu erhalten. Wenn Sie den dritten Schritt abgeschlossen haben, verfügen Sie über eine Pipeline, die eingehende Rohdaten in ein ordentliches Format umwandelt und in Ihrer "sauberen" Datenschicht speichert.

Ihre Definition von "fertig" bestimmt, wann eine Story vollständig abgeschlossen ist. In unserem Fall bedeutet dies, dass der Code für die Pipeline versionskontrolliert, von Kollegen geprüft, dokumentiert und getestet ist. Wenn die Story in der Entwicklungsumgebung genehmigt ist, wird sie anschließend über einen CI/CD-Prozess in die Abnahme und Produktion gebracht.

Wenn wir das Gefühl haben, dass eine Story immer noch ziemlich umfangreich ist, erstellen wir manchmal Unteraufgaben, um sie zu unterteilen. Die Unteraufgaben müssen nicht so detailliert dokumentiert werden wie die Story. Sie dienen hauptsächlich dazu, dass Sie als Entwickler den Überblick behalten, woran Sie gerade arbeiten. Wenn eine Integration zum Beispiel Verbindungen zu mehreren API-Endpunkten erfordert, sollten Sie für jeden dieser Endpunkte eine Unteraufgabe erstellen.

Kostenvoranschlag für die Arbeit

Um Ihre Stories in einem zukünftigen Sprint zu planen, müssen Sie abschließend den Schwierigkeitsgrad jeder Story abschätzen. Story Points sind eine gute Methode im agilen Projektmanagement, die ein abstraktes Maß für die Zeit liefert, die für die Fertigstellung einer Story benötigt wird. Mit Hilfe von Story Points wird es für Sie als Team einfacher, Aufgaben miteinander zu vergleichen und Sie erhalten eine Vorstellung davon, wie viele Punkte Sie als Team in einem einzigen Sprint bewältigen können.

Gemeinsam mit Ihrem Team legen Sie für jede Story eine Zahl aus der Fibonacci-Reihe (1, 2, 3, 5, 8, 13, 21...) als geschätzte Schwierigkeit fest. Wenn eine Story mit 13 oder mehr Punkten bewertet wird, ist sie zu umfangreich für einen 2-wöchigen Sprint und Sie sollten versuchen, die Story aufzuteilen.

Wir sehen zwei Hauptvariablen, die die Anzahl der Story-Punkte für eine Story beeinflussen: die Komplexität der zu implementierenden Pipeline und einfach die Zeit, die für die Aufgabe benötigt wird. So wird es mehr Zeit in Anspruch nehmen, ein Quellsystem mit nur wenigen strukturierten Tabellen aufzunehmen, als ein Quellsystem mit mehreren unstrukturierten Datenformaten.

Wir verwenden daher die folgende Tabelle, um unsere Story Points zu bestimmen:

Komplexität	Erforderliche Zeit	Story-Punkte
Niedrig	Niedrig	2
Niedrig	Mittel	3
Mittel	Niedrig	3
Medium	Mittel	5
Niedrig	Hoch	8
Hoch	Niedrig	8
Mittel	Hoch	13
Hoch	Mittel	13
Hoch	Hoch	21

Wir haben festgestellt, dass, wenn wir uns an die in diesem Blog beschriebene Vorgehensweise halten, unsere Geschichten maximal 8 Punkte umfassen und wir in der Lage sind, sie konsistent und zuverlässig zu liefern.

Einpacken

Dieser Blog beschreibt einen Ansatz zur Planung, Verfeinerung und Schätzung von Data Engineering-Arbeiten, die sich auf das Hinzufügen neuer Datenpipelines konzentrieren.

Wir schlagen vor, immer mit einem Spike zu beginnen, in dem Sie Unsicherheiten ausräumen, die darauf zurückzuführen sind, dass Sie noch keine Erfahrung mit dem Quellsystem oder dem Datensatz und seinem Format haben. Das Ziel dieses Spikes ist es, ein Pipeline-Design zu entwickeln, das kritische Fragen beantwortet, z.B. wie Sie eine Verbindung zur Quelle herstellen, wie oft Sie Daten abrufen möchten und ob ein erstes Laden erforderlich ist.

Mit diesen Informationen können Sie die Pipeline-Implementierung in die vorgeschlagenen Stories aufteilen, die nicht zu umfangreich sind und einen klaren Mehrwert liefern. Wenn Sie sich an diesen Arbeitsablauf halten, können Sie Datenpipelines zuverlässig und ohne Überraschungen für Sie und Ihre Stakeholder bereitstellen.

Wenn Sie möchten, dass wir Ihnen helfen, Ihre Data Engineering-Praxis zu beschleunigen, können Sie sich gerne an uns wenden. Wir können Ihnen sowohl bei der praktischen technischen Arbeit als auch beim Aufbau von Fähigkeiten und der Schulung Ihrer Data Engineering-Experten helfen.