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!

91Ô­´´

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.

91Ô­´´

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

91Ô­´´

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.