Entwicklung von Datenpipelines

Wenn in der Vergangenheit Daten aktualisiert werden mussten, trugen die Mitarbeiter sie manuell in eine Datentabelle ein. Dies führte zu manuellen Eingabefehlern und Zeitverzögerungen. Da dies hauptsächlich in Stapeln, meist täglich, geschah, gab es eine beträchtliche Vorlaufzeit zwischen dem Eintreten des Ereignisses und seiner Meldung. Die Entscheidungsträger mussten mit dieser Zeitspanne leben und trafen ihre Entscheidungen oft auf der Grundlage veralteter Daten.

In der heutigen Zeit sind Echtzeit-Updates und -Einblicke eine alltägliche Anforderung. Der Aufbau von Datenpipelines diente im Wesentlichen dazu, Daten aus einer Ebene (Transaktions- oder Ereignisquellen) in Data Warehouses oder Data Lakes zu verschieben, aus denen Erkenntnisse gewonnen werden.

Es stellt sich die Frage, ob wir angesichts dieser Fortschritte bei den Anforderungen zur Unterstützung von Echtzeiteinblicken und anderen Qualitätsanforderungen mit herkömmlichen Architekturen oder gängigen ETL-Ansätzen effizient arbeiten können. Lassen Sie es uns herausfinden!

Datenpipelines sind für jedes Programm zur Produktdigitalisierung wichtig. In der zweiten Hälfte dieses Jahrzehnts wurden wir Zeuge, wie ein immenser Fokus auf digitale Architekturen und Technologien gelegt wurde. Die Einführung von Microservices und Containerisierung zeigt eine starke Wachstumskurve, die diese Tatsache belegt. Wir sehen auch, dass technologische Fortschritte angewandt werden, aber auf traditionelle "OLTP" oder Kerndienste/Geschäftslogik beschränkt sind.

Anders sieht es aus, wenn man die Muster in den Datenpipelines oder auf der "OLAP"-Seite der Dinge betrachtet. Wir beobachten eine begrenzte Anpassung an die technologische Entwicklung im Bereich der Kerndienste. Die meisten gängigen Datenpipelines werden entweder mit traditionellen ETL- oder ELTL-Architekturen erstellt. Dies sind beliebte De-facto-Ansätze der Branche. Sie lösen zwar das eigentliche Problem, d. h. die Gewinnung verwertbarer Erkenntnisse, sind aber auch mit gewissen Einschränkungen verbunden. Lassen Sie uns einige dieser Herausforderungen untersuchen:

Abgeschottete Teams: Der ETL-Prozess erfordert Fachwissen oder Fähigkeiten bei der Datenextraktion oder -migration. Dies könnte bedeuten, dass das technische Team mehrstufig oder so strukturiert ist, dass es sich mit den technischen Nuancen des Prozesses befasst. Z.B.: Ein ETL-Ingenieur weiß oft nicht, welche Erkenntnisse abgeleitet werden und wie sie von den Endbenutzern genutzt werden.

Begrenzte Manifestation: Das Implementierungsteam versucht nun, jeden gewünschten Anwendungsfall in die vorgegebene Struktur oder das Muster einzupassen. Obwohl dies nicht immer ein Problem oder ein Fehler ist, kann es manchmal ineffizient sein. Z.B.: Wie extrahiert man aus einer unstrukturierten Quelle und wie geht man mit der Modellierung des dazwischenliegenden Persistenzschemas um?

Latenzzeit: Die Zeit, die für das Extrahieren, Transformieren und Laden der Daten benötigt wird, führt oft zu Verzögerungen. Diese Verzögerung könnte darauf zurückzuführen sein, dass die Daten in Stapeln verarbeitet werden, oder auf die notwendigen Zwischenladeschritte zur Persistenz von Zwischenergebnissen. In einigen Geschäftsszenarien ist dies nicht akzeptabel. Z.B.: Datenströme, die von einem IoT-Dienst stammen, werden gespeichert und zu einem späteren Zeitpunkt als Stapel verarbeitet. Dadurch entsteht eine Verzögerung zwischen der Datengenerierung und den aktualisierten Erkenntnissen auf Dashboards.

Mit den Fortschritten in der allgemeinen Softwarearchitektur, wie Microservice, Service Mesh usw., besteht ein Bedarf an einer ähnlichen Modernisierung. Ein wichtiger Ansatz ist die Verteilung der Datenpipeline für die Domänen anstelle einer zentralisierten Datenpipeline, die zum Aufbau mehrerer solcher Objekte beiträgt, was zu Data Mesh führt. Data Mesh zielt darauf ab, diese Herausforderungen zu bewältigen, indem ein anderer Ansatz gewählt wird:

• Teams oder Pods, die auf die Bereitstellung funktionaler Merkmale ausgerichtet sind
• Behandlung von Daten als Produkt (auffindbar, in sich geschlossen und sicher)
• Polyglotte Speicherung und Kommunikation über Mesh erleichtern

Einen ersten Überblick über Data Mesh finden Sie hier.

Data Mesh kann auf verschiedene Weise implementiert werden. Ein effektives Muster ist die Verwendung eines ereignisgesteuerten Ansatzes und Event Storming zur Bildung von Datenprodukten. Ein Bereich kann aus einem oder mehreren Datenprodukten bestehen. Dies würde auch bedeuten, dass Daten redundant sein können und in einem oder mehreren Speichern persistiert werden. Dies wird als polyglotte Speicherung bezeichnet. Schließlich werden diese Datenprodukte über die Mesh-APIs konsumiert, die entsprechend den Anforderungen der jeweiligen Domäne entwickelt wurden.

Andere Architekturen sind Data Lake, Data Hub und Data Virtualization. Eine kurze Gegenüberstellung dieser Stile finden Sie hier.

Einige weitere Überlegungen, die man anstellen sollte:

• Erleichterung des einfachen Datenzugriffs zu jeder Zeit durch Verwendung von Standardschnittstellen wie SQL. Technologien wie Snowflake, DBT, Materialize ermöglichen solche Echtzeit-Joins, die nicht nur BI ermöglichen, sondern auch beim Low-Level-Plotting der Pipeline helfen
• Entwerfen Sie Datenpipelines so, dass sie robust und fehlertolerant sind, z. B. durch Checkpoints für Zwischenergebnisse, die für weitere Analysen benötigt werden
• Nutzung verteilter, lose gekoppelter Verarbeitungseinheiten, skalierbar für den Einsatz polyglotter Technologien, z. B. Spark-Jobs oder Python-Modelle
• Einsatz von Datenvirtualisierung zur Abmilderung von Engpässen, z. B. Verkürzung der Vorlaufzeit für die Datenverfügbarkeit
• Effizienter Einsatz von DataOps zur Verfolgung und Bewertung der Leistung Ihrer Datenpipeline

Abschließend möchte ich mit einem Disclaimer schließen. Dieser Artikel soll nicht dazu dienen, die aktuellen ETL-Architekturen zu verwerfen. In der Tat ist ETL für bestimmte Anwendungsfälle wie Batch-Jobs immer noch eine sehr gute Option, die es zu übernehmen gilt. Vielmehr geht es hier um eine Erkenntnis, die man auf der Grundlage der verschiedenen Anforderungen gewinnen muss, und um die Erkundung weiterer Architekturen, die für den jeweiligen Bedarf gut geeignet sind. In diesem Artikel haben wir uns einige solcher Architekturen wie Data Mesh und die damit verbundenen Bereiche angesehen, die es zu berücksichtigen gilt.

Sie können gerne Ihre Kommentare, Ihr Feedback und Ihre Fragen zu diesem Artikel loswerden. Ich werde versuchen, jede dieser Fragen so schnell wie möglich zu beantworten.