Kapitel 1. Einführung in die Seehausarchitektur

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Alle Datenfachleute, unabhängig von ihrem Jobprofil, führen zwei gemeinsame und grundlegende Aktivitäten aus: Fragen stellen und Antworten finden! Jede Person, die mit Daten zu tun hat, sei es ein Dateningenieur, ein Datenarchitekt, ein Datenanalyst, ein Datenwissenschaftler oder sogar ein Datenverantwortlicher wie ein Chief Information Officer (CIO) oder Chief Data Officer (CDO), muss neugierig sein und Fragen stellen.

Es ist schwierig, Antworten auf komplexe Fragen zu finden. Aber die größere Herausforderung ist es, die richtigen Fragen zu stellen. Die "Kunst des Möglichen" kann nur erforscht werden, indem man: (1) die richtigen Fragen gestellt werden und (2) die Antworten durch die Nutzung der Daten aufgedeckt werden. So einfach das auch klingen mag, ein Unternehmen braucht eine komplette Datenplattform, damit die Nutzer diese Aufgaben erfüllen können. Diese Plattform muss die Datenaufnahme und -speicherung unterstützen und den Nutzern Werkzeuge zur Verfügung stellen, mit denen sie neue Fragen stellen und entdecken, erweiterte Analysen durchführen, Ergebnisse vorhersagen und prognostizieren und Erkenntnisse gewinnen können. Die Datenplattform ist die Infrastruktur, die es den Nutzern ermöglicht, die Daten zum Nutzen des Unternehmens einzusetzen.

Um solche Datenplattformen zu implementieren, brauchst du eine robuste Datenarchitektur - eine, die dir hilft, die Kernkomponenten der Datenplattform zu definieren und die Designprinzipien für die Umsetzung in die Praxis festzulegen. Traditionell nutzen Unternehmen Data Warehouse- oder Data Lake-Architekturen zur Umsetzung ihrer Datenplattformen. Diese beiden Architekturansätze haben sich in vielen Branchen durchgesetzt. Diese Architekturen haben sich auch weiterentwickelt, um die sich ständig verbessernden modernen Technologien und Muster zu nutzen. Die Lakehouse-Architektur ist ein solches modernes Architekturmuster, das sich in den letzten Jahren entwickelt hat und zu einer beliebten Wahl für Datenarchitekten geworden ist, die Datenplattformen entwerfen.

In diesem Kapitel führe ich dich in die grundlegenden Konzepte der Datenarchitektur, der Datenplattformen und ihrer Kernkomponenten ein und zeige dir, wie die Datenarchitektur beim Aufbau einer Datenplattform hilft. Dann erkläre ich dir, warum es einen Bedarf für neue Architekturmuster wie das Lakehouse gibt. Du lernst die Grundlagen und Merkmale der Lakehouse-Architektur kennen und erfährst, welche Vorteile die Implementierung einer Datenplattform mit der Lakehouse-Architektur hat. Am Ende des Kapitels fasse ich die wichtigsten Erkenntnisse zusammen, damit du dich an die wichtigsten Punkte erinnerst, wenn du die folgenden Kapitel in diesem Buch liest.

Beginnen wir mit den Grundlagen der Datenarchitektur.

Die Datenarchitektur verstehen

Die Datenplattform ist das Endergebnis der Implementierung einer Datenarchitektur unter Verwendung des gewählten Technologie-Stacks. Die Datenarchitektur ist die Blaupause, die das System definiert, das du aufbauen willst. Sie hilft dir, den Endzustand deines Zielsystems zu visualisieren und wie du ihn erreichen willst. Die Datenarchitektur definiert die Kernkomponenten, die Abhängigkeiten zwischen diesen Komponenten, die grundlegenden Designprinzipien und die Prozesse, die für die Umsetzung deiner Datenplattform erforderlich sind.

Was ist Datenarchitektur?

Um die Datenarchitektur zu verstehen, betrachte die folgende reale Analogie einer kommerziellen Baustelle, z. B. eines Einkaufszentrums oder einer großen Wohnsiedlung.

Der Bau einer Gewerbeimmobilie erfordert eine robuste Architektur, ein innovatives Design, einen erfahrenen Architekten und ein Heer von Bauarbeitern. Die Architektur spielt die wichtigste Rolle bei der Entwicklung - sie sorgt dafür, dass das Gebäude allen Wetterbedingungen standhält, dass Menschen leicht Zugang zu den verschiedenen Etagen haben und sich dort zurechtfinden, und dass Menschen im Notfall schnell evakuiert werden können. Solche Architekturen basieren auf bestimmten Leitprinzipien, die das Kerndesign und die Anordnung der Gebäudeblöcke festlegen. Egal, ob du ein Wohnhaus, einen Geschäftskomplex oder eine Sportarena baust, die Grundpfeiler und die zentralen Gestaltungsprinzipien für die Architektur bleiben dieselben. Die Gestaltungsmuster - die Innenausstattung, die Ästhetik und andere Merkmale für die Nutzer - unterscheiden sich jedoch.

Ähnlich wie beim Bau einer Gewerbeimmobilie spielt die Datenarchitektur die wichtigste Rolle bei der Entwicklung robuster Datenplattformen, die verschiedene Nutzer/innen und unterschiedliche Daten- und Analyseanwendungen unterstützen sollen. Um eine Plattform aufzubauen, die belastbar, skalierbar und für alle Nutzer/innen zugänglich ist, sollte die Datenarchitektur auf zentralen Leitprinzipien basieren. Unabhängig von der Branche oder dem Bereich bleiben die Grundlagen der Datenarchitektur gleich.

Die Datenarchitektur spielt, ähnlich wie die Designarchitektur einer Baustelle, eine wichtige Rolle dabei, wie sich die Nutzer an die Plattform anpassen. In diesem Abschnitt geht es um die Bedeutung der Datenarchitektur für den Gesamtprozess der Implementierung einer Datenplattform.

Wie hilft die Datenarchitektur beim Aufbau einer Datenplattform?

Die Architektur der Datenplattform ist wahrscheinlich die kritischste Phase eines Datenprojekts und wirkt sich oft auf wichtige Ergebnisse wie die Benutzerakzeptanz, Skalierbarkeit, Compliance und Sicherheit der Plattform aus. Die Datenarchitektur hilft dir, die folgenden grundlegenden Aktivitäten zu definieren, die du durchführen musst, um mit dem Aufbau deiner Plattform zu beginnen.

Definition der Kernkomponenten

Die Kernkomponenten deiner Datenplattform helfen bei den täglichen Aktivitäten wie Datenaufnahme, Speicherung, Umwandlung, Nutzung und anderen allgemeinen Diensten im Zusammenhang mit Verwaltung, Betrieb, Governance und Sicherheit. Die Datenarchitektur hilft dir, diese Kernkomponenten deiner Datenplattform zu definieren. Diese Kernkomponenten werden im nächsten Abschnitt ausführlich behandelt.

Definition der Abhängigkeiten zwischen den Komponenten und des Datenflusses

Nachdem du die Kernkomponenten deiner Plattform definiert hast, musst du festlegen, wie sie zusammenwirken sollen. Die Datenarchitektur definiert diese Abhängigkeiten und hilft dir, den Datenfluss zwischen Produzenten und Konsumenten zu visualisieren. Die Architektur hilft dir auch dabei, alle spezifischen Einschränkungen oder Integrationsprobleme zu ermitteln und zu lösen, die beim Austausch von Daten zwischen diesen Komponenten auftreten können.

Leitprinzipien festlegen

Im Rahmen des Entwurfsprozesses der Datenarchitektur legst du auch die Leitprinzipien für die Implementierung deiner Datenplattform fest. Diese Grundsätze helfen dabei, ein gemeinsames Verständnis zwischen den verschiedenen Datenteams zu schaffen, die die Plattform nutzen. Sie stellen sicher, dass alle dem gleichen Designansatz, gemeinsamen Standards und wiederverwendbaren Frameworks folgen. Die Festlegung gemeinsamer Leitprinzipien ermöglicht es dir, eine optimierte, effiziente und zuverlässige Datenplattformlösung zu implementieren. Die Leitprinzipien können auf verschiedene Komponenten angewendet werden und werden auf der Grundlage der Möglichkeiten und Grenzen der Datenarchitektur definiert. Wenn deine Plattform zum Beispiel mehrere Business Intelligence (BI)-Tools bereitstellt, sollte ein Leitprinzip festlegen, welches BI-Tool je nach Datenverwendungsmuster oder Anwendungsfall verwendet werden soll.

Definition des Technologie-Stacks

Der Architekturentwurf gibt auch Aufschluss über den technischen Aufbau der Kernkomponenten der Plattform. Bei der Architektur der Plattform kann es eine Herausforderung sein, alle zugrundeliegenden Technologien endgültig festzulegen - eine detaillierte Untersuchung der Einschränkungen und Vorteile sowie ein Proof of Concept (PoC) sind erforderlich, um sie endgültig festzulegen. Die Datenarchitektur hilft dabei, die wichtigsten Überlegungen für die Auswahl dieser Technologien und die gewünschten Erfolgsfaktoren für die Durchführung von PoC-Aktivitäten und die endgültige Festlegung des Tech-Stacks zu definieren.

Abstimmung mit der Gesamtvision und der Datenstrategie

Und schließlich, und das ist das Wichtigste, hilft dir die Datenarchitektur bei der Implementierung einer Datenplattform, die mit deiner Gesamtvision und der Datenstrategie deines Unternehmens zur Erreichung seiner Geschäftsziele übereinstimmt. Data Governance ist zum Beispiel ein wesentlicher Bestandteil der Datenstrategie eines Unternehmens. Die Datenarchitektur definiert die Komponenten, die sicherstellen, dass Data Governance im Mittelpunkt jedes Prozesses steht. Dazu gehören Komponenten wie Metadaten-Repositories, Datenkataloge, Zugriffskontrollen und Grundsätze für die gemeinsame Nutzung von Daten.

Hinweis

Data Governance ist ein Oberbegriff, der verschiedene Standards, Regeln und Richtlinien umfasst, die sicherstellen, dass alle Datenprozesse denselben formalen Richtlinien folgen. Diese Richtlinien helfen dabei, die Einhaltung geografischer oder branchenspezifischer Vorschriften zu gewährleisten und sicherzustellen, dass die Daten vertrauenswürdig und von hoher Qualität sind und einen Mehrwert bieten. Um das Vertrauen der Verbraucher in die Daten aufrechtzuerhalten und die Vorschriften einzuhalten, sollten Unternehmen bei allen Datenverwaltungsprozessen Data Governance-Richtlinien befolgen. Data Governance hilft Unternehmen dabei, ihre Daten besser zu kontrollieren, Daten leicht zu finden und sie sicher mit den Verbrauchern zu teilen.

Da du nun die Datenarchitektur und ihre Bedeutung für die Implementierung von Datenplattformen besser verstehst, lass uns die Kernkomponenten einer Datenplattform besprechen.

Kernkomponenten einer Datenplattform

In diesem Abschnitt werden wir uns die Kernkomponenten einer Datenplattform ansehen und wie ihre Funktionen zu einem robusten Datenökosystem beitragen. Abbildung 1-1 zeigt die Kernkomponenten für die Implementierung einer Datenplattform auf der Grundlage eines Datenarchitekturplans.

Abbildung 1-1. Kernkomponenten einer Datenplattform

Lass uns diese Kernkomponenten und die damit verbundenen Prozesse näher betrachten.

Quellensysteme

Quellsysteme liefern Daten an die Datenplattform, die für Analysen, Business Intelligence (BI) und maschinelles Lernen (ML) genutzt werden können. Zu diesen Quellen gehören Altsysteme, Backend-Systeme für die Online-Transaktionsverarbeitung (OLTP), IoT-Geräte, Clickstreams und soziale Medien. Die Quellen können anhand verschiedener Faktoren kategorisiert werden.

Interne und externe Quellensysteme

Interne Quellen sind die internen Anwendungen innerhalb einer Organisation, die Daten produzieren. Dazu gehören interne CRM-Systeme (Customer Relationship Management), Transaktionsdatenbanken und maschinell erstellte Protokolle. Interne Quellen können im Besitz interner bereichsspezifischer Teams sein, die für die Erzeugung der Daten verantwortlich sind.

Datenplattformen benötigen oft Daten aus externen Systemen, um ihre internen Daten zu verbessern und wettbewerbsfähige Erkenntnisse zu gewinnen. Beispiele für Daten, die aus externen Systemen stammen, sind Wechselkurse, Wetterinformationen und Marktforschungsdaten.

Batch-, echtzeitnahe und Streaming-Systeme

Bis vor ein paar Jahrzehnten konnten die meisten Quellensysteme nur Batch-Daten senden, d.h. sie haben die Daten in der Regel am Ende des Tages in einem täglichen Batch-Prozess gesendet. Mit der steigenden Nachfrage nach Einblicken und Analysen in Echtzeit begannen die Quellensysteme, Daten nahezu in Echtzeit zu senden. Diese Systeme können nun Daten in Form von mehreren, kleineren Mikro-Batches in einem festen Intervall von nur wenigen Minuten weitergeben. Quellen wie IoT-Geräte, Social Media Feeds und Clickstreams senden Daten als kontinuierlichen Strom, der in Echtzeit aufgenommen und verarbeitet werden sollte, um den maximalen Wert zu erhalten.

Strukturierte, halbstrukturierte und unstrukturierte Daten

Quellsysteme produzierten traditionell nur strukturierte Daten in Tabellen oder fest strukturierten Dateien. Mit den Fortschritten bei den Datenaustauschformaten wurden zunehmend halbstrukturierte Daten in Form von XML- und JSON-Dateien erzeugt. Und als Unternehmen begannen, Big Data-Lösungen zu implementieren, erzeugten sie große Mengen unstrukturierter Daten in Form von Bildern, Videos und Maschinenprotokollen. Deine Datenplattform sollte alle Arten von Quellsystemen unterstützen, die verschiedene Arten von Daten in unterschiedlichen Zeitintervallen senden.

Dateneingabe

Die Datenaufnahme ist der Prozess, bei dem Daten aus den Quellsystemen extrahiert und in deine Datenplattform geladen werden. Wie im vorangegangenen Abschnitt beschrieben, muss das Ingestion-Framework je nach der Fähigkeit des Quellsystems, Daten zu produzieren und zu senden, so implementiert werden, dass ein Batch-, Fast-Echtzeit- oder Streaming-System entsteht.

Batch-Ingestion

Daten, die einmal am Tag gesendet werden (entweder als End-of-Day- oder als Start-of-Day-Prozess), können als Batch-Prozess in die Datenplattform eingespeist werden. Dies ist das gängigste Einspeisungsmuster, das in traditionellen Data-Warehouse-Architekturen für die Erstellung täglicher Management-Informationssysteme (MIS) oder gesetzlicher Berichte verwendet wird.

Fast in Echtzeit

Für zeitkritischere Daten kann der Ingest in Form von Micro-Batches oder in Fast-Echtzeit erfolgen. Die Intervalle für die Aufnahme von Mikro-Batches können zwischen einigen Stunden und wenigen Minuten liegen, während Daten in Beinahe-Echtzeit in einem Abstand von einigen Minuten bis Sekunden aufgenommen werden können. Die Datenübernahme-Tools sollten die erforderlichen Service Level Agreements (SLAs) gemäß den geschäftlichen Anforderungen erfüllen.

Streaming

Streaming-Analytics-Anwendungsfälle sind extrem zeitkritisch und benötigen eine Architektur, die die Datenaufnahme in Echtzeit unterstützt, d.h. innerhalb weniger Millisekunden ab dem Zeitpunkt der Datengenerierung. Da diese Daten zeitkritisch sind, können sie schnell an Wert verlieren, wenn sie nicht sofort aufgenommen und verarbeitet werden. Die Ingestion-Komponenten deiner Datenplattform sollten niedrige Latenzzeiten unterstützen, damit die Daten zur Verfügung stehen, sobald sie von den Quellsystemen erzeugt werden.

Tipp

Eine gute Praxis für die Gestaltung des Ingestion-Prozesses ist die Entwicklung wiederverwendbarer, konfigurierbarer Frameworks, die Daten aus mehreren Quellen oder Entitäten aufnehmen können. Das hilft dabei, neue Entitäten schnell in die Datenplattform einzubinden. Bei der Entwicklung der Datenarchitektur kannst du in Betracht ziehen, wiederverwendbare Lösungen für diese Kernkomponenten zu entwickeln, um den Implementierungsaufwand zu verringern.

Speicherung von Daten

Sobald die Daten eingelesen sind, müssen sie gespeichert werden, damit sie haltbar sind, leicht gefunden und weiter analysiert werden können. Komponenten zur Datenspeicherung ermöglichen die effektive Speicherung verschiedener Datentypen. Diese Komponenten bewahren Daten auf, die bei Bedarf abgerufen werden können, und sollten eine hohe Verfügbarkeit und Haltbarkeit bieten.

Je nach Anwendungsfall kannst du die Speicherung von Daten in zwei große Kategorien einteilen: allgemeine Speicherung und zweckgebundene Speicherung.

Allgemeine Speicherung

Alle Datentypen in Objektspeichern wie Hadoop Distributed File System (HDFS), Amazon Simple Storage Service (S3), Azure Data Lake Storage (ADLS) oder Google Cloud Storage (GCS). Diese Objektspeicher unterstützen die Speicherung von strukturierten, halbstrukturierten oder unstrukturierten Daten. Sie bieten eine hohe Verfügbarkeit und Haltbarkeit und sind außerdem kosteneffizient, was sie zu einer der besten Entscheidungen für die Speicherung von Daten über längere Zeiträume macht.

Hinweis

ADLS Gen 2 ist ein Cloud-Objektspeicherdienst von Azure, der auf Azure Blob Storage aufbaut. Er bietet Hochverfügbarkeit, Funktionen für Disaster Recovery, verschiedene Speicherebenen, um Kosten zu sparen, und andere Big Data-Funktionen. Er wird häufig für die Implementierung von Data Lakes innerhalb des Azure-Ökosystems genutzt. Zuvor bot Azure auch ADLS Gen 1 (basierend auf HDFS) an, das inzwischen eingestellt wurde. Wenn wir uns in diesem Buch auf ADLS beziehen, meinen wir den ADLS Gen 2 Service.

Speziell angefertigte Speicherung

Objektspeicher sind zwar gut für eine kostengünstige, langfristige Speicherung, aber du brauchst vielleicht ein speziell entwickeltes Speichersystem, das Funktionen wie schnellen Zugriff, schnellere Abfrage, schlüsselbasierte Suche, spaltenbasierte Speicherung und hohe Gleichzeitigkeit bietet.

Es gibt verschiedene Technologien und Architekturmuster, um diese speziell entwickelten Speicher zu implementieren:

Data Warehouses

Biete Unterstützung für Online Analytical Processing (OLAP) Workloads

Relationale Datenbankmanagementsysteme (RDBMS)

Unterstützung von Online Transaction Processing (OLTP) Systemen für Anwendungs-Backends

In-Memory-Datenbanken

Schnelleres Abrufen von Daten

Graph-Datenbanken

Verbindungen speichern und Beziehungen

Die Komponenten zur Speicherung von Daten sind die am häufigsten verwendeten Komponenten einer Datenplattform. Von der Speicherung langfristiger Daten bis hin zu ihrer schnellen Bereitstellung laufen alle wichtigen Aktivitäten über diese Komponenten mit Hilfe einer Compute Engine ab.

Datenverarbeitung und -umwandlung

Die von den Quellsystemen erfassten Rohdaten müssen validiert, bereinigt, integriert und entsprechend den Geschäftsanforderungen umgewandelt werden. Im Rahmen der Datenverarbeitung werden die folgenden Schritte durchgeführt, um die Rohdaten in ein konsumierbares Endprodukt umzuwandeln.

Datenvalidierung und -bereinigung

Wenn die Daten aus den Quellsystemen übernommen werden, liegen sie in Rohform vor und müssen validiert und bereinigt werden, bevor sie den Endnutzern zur Verfügung gestellt werden können. Beide Schritte sind wichtig, um sicherzustellen, dass die Genauigkeit der Daten bei der Übertragung in die höheren Zonen der Speicherung im Lakehouse-Ökosystem nicht beeinträchtigt wird. Die Hierarchie der Zonen für die Speicherung von Daten - Rohdaten, bereinigte Daten, kuratierte Daten und semantische Daten - wird in Kapitel 7 näher erläutert.

Eingabedaten werden in einem ersten Schritt nach der Eingabe validiert. Diese Validierung gilt für strukturierte Daten und bis zu einem gewissen Grad auch für halbstrukturierte Daten, die für Berichte und die Gewinnung von Erkenntnissen verwendet werden. In diesem Schritt durchlaufen die Daten verschiedene Validierungsstufen, darunter die folgenden technischen und geschäftlichen Validierungen:

Technische Validierungen

Hauptsächlich bezogen auf die Datentypen, Datenformate und andere Prüfungen, die technischer Natur sind und in jedem Bereich oder jeder Branche angewendet werden können

Business-Validierungen

Bereichs- oder funktionsspezifisch und in Bezug auf bestimmte Werte in Attributen und deren Genauigkeit oder Vollständigkeit

Schema-Validierungen

Wie die Eingabedaten gemäß dem in den Spezifikationen oder Datenverträgen festgelegten Schema eingespeist werden sollten

Hinweis

Datenvertrag ist ein relativ neuer Begriff, der die Vereinbarung zwischen dem Datenproduzenten und seinen Kunden beschreibt. Er legt verschiedene Parameter für die produzierten Daten fest, z. B. den Eigentümer, die Häufigkeit, den Datentyp und das Format. Datenverträge stellen sicher, dass es ein gemeinsames Verständnis zwischen Datenproduzenten und -konsumenten gibt.

Datenumwandlung

Der Prozess der Umwandlung von Rohdaten in nützliche Informationen wird als Datentransformation bezeichnet. Sie kann aus einer Reihe von Transformationen bestehen, die zunächst die aus verschiedenen Quellsystemen erhaltenen Daten integrieren und sie dann in eine konsumierbare Form umwandeln, die nachgelagerte Anwendungen, Geschäftsanwender und andere Datenkonsumenten entsprechend ihren Anforderungen nutzen können.

Es gibt mehrere Datentransformationen, die du je nach Anwendungsfall und Anforderungen anwenden kannst. Die häufigsten Datenumwandlungen sind:

Datenintegration

Wenn Daten aus verschiedenen Quellsystemen aufgenommen werden, musst du sie kombinieren, um eine integrierte Ansicht zu erhalten. Ein Beispiel ist die Integration von Kundenprofildaten aus externen Quellsystemen, internen Systemen oder Marketinganwendungen. Verschiedene Quellsysteme können Daten in unterschiedlichen Formaten liefern, die wir in ein gemeinsames, standardisiertes Format bringen müssen, damit sie von nachgelagerten Anwendungen genutzt werden können. Nehmen wir zum Beispiel das Attribut "Geburtsdatum", das in verschiedenen Quellsystemen unterschiedliche Formate haben kann (wie MM/TT/JJJJ oder TT-MM-JJJ). Es ist wichtig, alle Datensätze in den verschiedenen Quellsystemen in ein Standardformat (wie TT/MM/JJJJ) umzuwandeln, bevor du sie in deiner zentralen Datenplattform speicherst. Als Teil des Transformationsprozesses wird diese Integration vor der Speicherung der Daten in den höheren Speicherzonen durchgeführt.

Datenerweiterung

Um Daten aussagekräftiger zu machen, müssen sie angereichert oder mit externen Daten ergänzt werden. Beispiele für Datenanreicherung sind:

  • Ergänze deine internen Daten mit externen Wechselkursen aus Drittanbieteranwendungen, um den globalen Tagesumsatz zu berechnen

  • Ergänzung deiner internen Daten mit externen Daten von Ratingagenturen zur Berechnung der Kreditwürdigkeit deiner Kunden

Datenaggregation

Die Daten müssen entsprechend den geschäftlichen Anforderungen zusammengefasst werden, damit sie schneller abgefragt und abgerufen werden können. Ein Beispiel wäre die Zusammenfassung von Daten nach Datum, Produkt und Standort, um eine Übersicht über die Verkäufe zu erhalten.

Datenkuratierung und -bereitstellung

Im letzten Schritt der Datenverarbeitung werden die Daten entsprechend den Geschäftsprozessen und Anforderungen aufbereitet und bereitgestellt. Die Daten werden auf der Grundlage eines branchenüblichen Datenmodells in die kuratierte Speicherung geladen, wobei Modellierungsansätze wie die Dimensionsmodellierung verwendet werden. Diese Anordnung der Daten anhand von branchenspezifischen Datenmodellen ermöglicht eine schnellere und einfachere Gewinnung von Erkenntnissen und Berichten. Die kuratierten Daten können dann zur Erstellung von Datenprodukten verwendet werden, die die Verbraucher direkt zur Erfüllung ihrer Geschäftsanforderungen nutzen können.

Hinweis

Datenprodukt ist ein neuer Begriff, mit dem ein konsumierbares Endprodukt bezeichnet wird, das speziell für seine Konsumenten kuratiert wurde. Datenprodukte werden in der Regel von den für die Daten zuständigen Teams erstellt. Diese Produkte können mit anderen Fachteams und nachgelagerten Anwendungen geteilt werden. Ein Datenprodukt kann eine Tabelle, eine Ansicht, ein Bericht, ein Dashboard oder sogar ein Modell für maschinelles Lernen (ML) sein, das von den Endnutzern leicht entdeckt und genutzt werden kann.

Datenverbrauch und -lieferung

Die Datenverwendungskomponenten in deiner Plattform ermöglichen es den Nutzern, auf die Daten zuzugreifen, sie zu analysieren, abzufragen und zu verwenden. Das können deine BI-Berichtstools oder sogar ML-Modelle sein, die für Vorhersagen und Prognosen verwendet werden. Die verschiedenen Workloads, die von diesen Komponenten unterstützt werden, sind:

BI-Workloads

BI-Tools helfen bei der Erstellung von Berichten und Dashboards für Anwendungsfälle wie MIS, regulatorische Berichte, Verkaufsanalysen oder tägliche Trends. BI war einer der ersten Anwendungsfälle, der von traditionellen Technologien wie RDBMS und Data Warehouse-Architekturen unterstützt wurde.

Ad-hoc-/Interaktive Analyse

Geschäftsanwender, Datenanalysten und Datenverantwortliche müssen oft Analysen durchführen, um Ad-hoc-Anforderungen zu erfüllen oder Antworten auf spontane Fragen zu finden, die in Meetings auftauchen. Die Komponenten, die solche interaktiven Ad-hoc-Analysen ermöglichen, bieten eine einfache SQL-Schnittstelle.

Nachgelagerte Anwendungen und APIs

Nachgelagerte Anwendungen brauchen einen universellen Weg, um mit deiner Datenplattform zu interagieren. APIs bieten Flexibilität und können von nachgelagerten Systemen genutzt werden, um die Daten einfach abzurufen.

KI- und ML-Workloads

KI und ML können bei verschiedenen Anwendungsfällen wie Vorhersagen, Prognosen und Empfehlungen helfen. Wenn es diese Arten von Anwendungsfällen in deinem Unternehmen gibt, sollte deine Datenplattform in der Lage sein, Werkzeuge für den ML-Lebenszyklus bereitzustellen, einschließlich Training, Einsatz und Inferenz der Modelle.

Alle diese Komponenten - BI-Berichtstools und ML-Modelle - ermöglichen die Nutzung und Bereitstellung von Daten für die Verbraucher und spielen eine wichtige Rolle bei der Akzeptanz der Plattform durch die Nutzer. Diese Komponenten bieten den Nutzern auch eine Schnittstelle für die Interaktion mit den Daten, die sich auf der Plattform befinden, weshalb die Nutzererfahrung bei der Entwicklung der Plattform berücksichtigt werden sollte.

Gemeinsame Dienste

Es gibt gängige Dienste, die Funktionalitäten über eine Datenplattform hinweg bereitstellen und eine wichtige Rolle dabei spielen, dass Daten leicht auffindbar, verfügbar und für die Nutzer sicher zugänglich sind. Diese gemeinsamen Dienste werden im Folgenden zusammengefasst.

Metadaten-Management

Diese bestehen aus Tools und Technologien, die dir helfen, Metadaten in deinem Ökosystem aufzunehmen, zu verwalten und zu pflegen. Metadaten erleichtern den Nutzern die Auffindbarkeit und den Zugriff auf die Daten. Du kannst Datenkataloge erstellen, um die Metadaten mit Details zu verschiedenen Tabellen, Attributen, Datentypen, Längen, Schlüsseln und anderen Informationen zu organisieren. Datenkataloge helfen den Nutzern, Daten schneller und effektiver zu finden und zu nutzen.

Data Governance und Datensicherheit

Die Umsetzung von starken Data Governance und Daten Sicherheitsrichtlinien ist unerlässlich, um:

  • Sicherstellung einer guten Datenqualität, um das Vertrauen der Verbraucher in die Daten zu stärken

  • Erfülle alle relevanten regulatorischen Anforderungen

  • Anzeige der Datenreihenfolge, um den Datenfluss zwischen den Systemen zu verfolgen

  • Implementiere die richtigen Zugriffskontrollen für alle Nutzer der Plattform

  • Daten mit internen und externen Datenkonsumenten teilen

  • Verwalte sensible Daten, indem du sie von nicht berechtigten Nutzern fernhältst

  • Daten zu schützen, wenn sie innerhalb oder außerhalb der Datenplattform gespeichert oder bewegt werden

Diese Themen werden in Kapitel 6 ausführlich behandelt.

Datenoperationen

Diese Dienste helfen bei der Verwaltung verschiedener Vorgänge in den verschiedenen Phasen des Datenlebenszyklus. Datenoperationen ermöglichen die folgenden Aktivitäten:

  • Orchestrierung von Datenpipelines und Festlegung von Zeitplänen zur Ausführung von Prozessen

  • Automatisierung von Tests, Integration und Bereitstellung von Datenpipelines

  • Verwaltung und Beobachtung des Zustands des gesamten Datenökosystems

Moderne Datenplattformen nutzen die Datenbeobachtungsfunktionen zur Überwachung des Zustands der Daten insgesamt.

Hinweis

Datenbeobachtung ist ein neuer Begriff für das Verständnis des Zustands von Daten innerhalb des Ökosystems. Dabei handelt es sich um einen Prozess zur proaktiven Erkennung von Problemen in Bezug auf Qualität, Genauigkeit, Frische und Vollständigkeit der Daten, um Datenausfälle zu vermeiden. Moderne Datenplattformen sollten Funktionen für die Datenbeobachtung bieten, vor allem in Anbetracht der großen Datenmengen und der schnellen Datenaufnahme und -verarbeitung, bei der jede Ausfallzeit das System schwer beeinträchtigen kann.

All diese Kernkomponenten bilden die Datenplattform und ermöglichen ihren Nutzern, verschiedene Aktivitäten durchzuführen. Datenarchitekturen liefern die Blaupause und die Leitprinzipien für den Aufbau dieser Datenplattformen. Mit diesem grundlegenden Verständnis von Datenarchitekturen und Datenplattformen und ihrer Bedeutung wollen wir nun ein neues Architekturmuster - das Lakehouse - besprechen, das das Hauptthema dieses Buches ist.

Warum brauchen wir eine neue Datenarchitektur?

Data Warehouses und Data Lakes sind nach wie vor die beliebtesten Architekturen für die Implementierung von Datenplattformen. In den letzten Jahren haben sich einige Unternehmen jedoch bemüht, Datenplattformen zu implementieren, indem sie andere Architekturansätze nutzten.

Ihre Motivation , nach neuen Ansätzen zu suchen, anstatt die bekannten traditionellen Datenarchitekturen zu implementieren, ist hauptsächlich zweigeteilt:

  • Traditionelle Architekturen haben mehrere Einschränkungen, wenn sie als eigenständige Systeme implementiert werden. Auf diese traditionellen Architekturen und ihre Einschränkungen gehe ich in Kapitel 2 ein.

  • In den letzten Jahren hat es zahlreiche technologische Fortschritte gegeben. Innovationen im Bereich der Cloud und die Reife von Open-Source-Technologien waren die Haupttreiber für diese Fortschritte.

Unternehmen haben immer wieder versucht, die Grenzen traditioneller Architekturen zu überwinden und neue Technologien zu nutzen, um skalierbare, sichere und zuverlässige Plattformen aufzubauen. Unternehmen, unabhängige Dienstleistungsanbieter (ISVs) und Systemintegratoren (SIs) haben verschiedene und innovative Ansätze ausprobiert, um modernere Datenplattformen zu implementieren. Einige dieser Ansätze sind:

  • Eine zweistufige Architektur kombiniert einen Data Lake und ein Data Warehouse zur Unterstützung von BI-, Datenanalyse- und ML-Anwendungsfällen

  • Nutzung von HTAP-Technologien (Hybrid Transactional/Analytical Processing), die eine einzige Speicherschicht verwenden, um transaktionale (OLTP) und analytische (OLAP) Workloads zu vereinheitlichen

  • Aufbau moderner Cloud Data Warehouses, die neben strukturierten und halbstrukturierten Daten auch unstrukturierte Daten verarbeiten können

  • Implementierung von proprietären Speicherformaten auf Cloud-Objektspeichern, die eine warehouse-ähnliche Leistung bieten können

  • Aufbau von Compute Engines zur Durchführung von BI direkt auf Data Lakes

All diese Bemühungen deuten darauf hin, dass ein neues architektonisches Muster benötigt wird, das:

  • Unterstützung der Implementierung einer einfachen, einheitlichen Plattform, die mit allen Datenformaten und einer Vielzahl von Anwendungsfällen umgehen kann, um den Nutzern eine einfache Nutzung der Daten zu ermöglichen

  • Bietet die ACID-Unterstützung, die hervorragende BI-Leistung und die Zugriffskontrollmechanismen eines Data Warehouse

  • Bieten die Skalierbarkeit, Kosteneffizienz und Flexibilität eines Data Lake

So hat sich in den letzten Jahren ein neues Muster herausgebildet - die Seehaus-Architektur. Wir werden im nächsten Abschnitt mehr darüber erzählen.

Architektur für Seehäuser: Ein neues Muster

Neue Tools, Produkte und Open-Source-Technologien haben die Art und Weise verändert, wie Unternehmen Datenökosysteme implementieren. Diese neuen Technologien haben dazu beigetragen, komplexe Datenarchitekturen zu vereinfachen. Das Ergebnis sind Datenplattformen, die zuverlässiger, offener und flexibler sind und eine Vielzahl von Daten- und Analyseaufgaben unterstützen.

Das Data Lakehouse (in diesem Buch auch als Lakehouse oder Lakehouse-Architektur bezeichnet) ist ein neues Architekturmuster, das neue Technologien für den Aufbau einfacher und offener Datenplattformen nutzt. Wie in Abbildung 1-2 dargestellt, handelt es sich bei einem Lakehouse im Kern um einen Data Lake mit einer zusätzlichen Transaktionsschicht und einer leistungsfähigen Berechnungsschicht. Die zusätzliche Transaktionsschicht verleiht ihm Data-Warehouse-ähnliche ACID-Eigenschaften und andere Funktionen.

Hinweis

Die zusätzliche Transaktionsschicht wird manchmal auch als "Metadatenschicht" bezeichnet, da sie Metadaten über die Transaktion bereitstellt. Um die Konsistenz zu wahren, werden wir sie im gesamten Buch als Transaktionsschicht bezeichnen.

Abbildung 1-2. Schichten der Architektur des Seehauses

Wir werden diese Ebenen bald ausführlicher besprechen. Doch zunächst wollen wir das Lakehouse-Konzept und die Kombination von Data Warehouse- und Data Lake-Funktionen besser verstehen.

Das Lakehouse: Das Beste aus beiden Welten

Datenplattformen, die mit der Lakehouse -Architektur aufgebaut sind, weisen Merkmale eines Data Warehouse und eines Data Lake auf, daher der Name Lakehouse. Abbildung 1-3 zeigt die wichtigsten Merkmale der Lakehouse-Architektur, die eine Kombination aus den besten Eigenschaften eines Data Lakes und eines Data Warehouses ist. Auf die Merkmale eines Data Lakes und eines Data Warehouses werde ich in Kapitel 2 näher eingehen, wo ich diese traditionellen Architekturen, ihre Merkmale und ihre Vorteile erläutern werde.

Abbildung 1-3. Merkmale des Seehauses

Aber wie können Lakehouses die besten Eigenschaften von Data Warehouses und Data Lakes in einer einzigen Speicherung vereinen? Welche Technologien ermöglichen diese Funktionen?

Wie bekommt ein Seehaus Data-Lake-Funktionen?

Wie ein Data Lake nutzt ein Lakehouse die Cloud Object Storage wie Amazon S3, ADLS oder GCS und speichert die Daten in offenen Dateiformaten wie Apache Parquet, Apache Avro oder Apache ORC. Dank dieser Speicherung in der Cloud verfügen Lakehouses über die besten Eigenschaften von Data Lakes, wie hohe Verfügbarkeit, Langlebigkeit, Kosteneffizienz, Skalierbarkeit, Unterstützung für alle Datentypen (strukturiert, halbstrukturiert, unstrukturiert) und Unterstützung für KI- und ML-Anwendungsfälle.

Wie bekommt ein Seehaus Data Warehouse-Funktionen?

Im Vergleich zu einem Data Lake hat ein Lakehouse eine zusätzliche Komponente: die Transaktionsschicht, die eine zusätzliche Schicht über den Dateiformaten ist. Diese zusätzliche Schicht trennt ein Lakehouse von einem Data Lake. Sie ermöglicht es Lakehouses, Data Warehouse-Funktionen wie ACID-Konformität, Unterstützung für Aktualisierungen und Löschungen, bessere BI-Leistung und eine feinkörnige Zugriffskontrolle zu erhalten. Die Technologie, mit der diese Transaktionsschicht implementiert wird, ist als "offene Tabellenformate" bekannt, auf die wir im nächsten Abschnitt näher eingehen werden.

Die Lakehouse-Architektur ist in der Daten-Community auf Interesse gestoßen, und verschiedene Unternehmen haben begonnen, Plattformen zur Unterstützung verschiedener Anwendungsfälle wie ETL-Verarbeitung, BI, ML, Data Science und Streaming-Analytics aufzubauen. Neben den führenden Cloud-Providern bieten mehrere kommerzielle Produktanbieter SaaS- oder PaaS-Angebote an, um die Implementierung einer auf Datenplattformen basierenden Lakehouse-Architektur zu unterstützen. Dazu gehören Produkte von Databricks, Snowflake, Dremio und Onehouse.

Wir wollen die Lakehouse-Architektur und die ihr zugrunde liegenden Technologien genauer unter die Lupe nehmen.

Die Architektur des Seehauses verstehen

Abbildung 1-4 zeigt eine einfache Ansicht der Lakehouse-Architektur, die aus den Schichten Speicherung und Berechnung sowie den zugrunde liegenden Technologieoptionen besteht. Es handelt sich dabei um eine granulare Ansicht von Abbildung 1-2, die wir weiter oben in diesem Kapitel gesehen haben.

Abbildung 1-4. Detailliertere Ansicht der Architektur von Seehäusern

Wie wir bereits besprochen haben, besteht die Lakehouse-Architektur aus einer Speicher- und einer Berechnungsschicht. Datenplattformen, die mit der Lakehouse-Architektur aufgebaut sind, ermöglichen es Daten- und Analyse-Workloads, Daten aus der Speicherung zu nutzen, während die Compute Engine zum Einsatz kommt.

Ebene der Speicherung

Verstehen wir zunächst die technologischen Optionen in der Ebene der Speicherung. Diese Ebene besteht aus drei Komponenten: Cloud-Speicherung, offenes Dateiformat und offenes Tabellenformat.

Speicherung in der Cloud

Die Cloud Speicherung ist ein Service, der die hohe Verfügbarkeit, Haltbarkeit und Skalierbarkeit bietet, die für die Implementierung von Data-Lake- und Lakehouse-Plattformen erforderlich sind. Führende Cloud-Provider bieten die folgenden Dienste für die Implementierung von Lakehouse-Plattformen an:

  • Amazon S3 von Amazon Web Services (AWS)

  • ADLS von Microsoft Azure

  • GCS von Google Cloud Plattform (GCP)

Hinweis

Unternehmen können ein Lakehouse auch mit lokaler HDFS Speicherung implementieren. Die ausschließliche Verwendung von Cloud Object Storage für die Implementierung eines Lakehouses ist nicht notwendig. Angesichts der niedrigen Kosten, der Trennung von Rechenleistung und Speicherung und der einfachen Skalierbarkeit ist es jedoch ratsam, die Cloud-Objektspeicherung als Basisinfrastruktur für die Implementierung eines Lakehouse zu nutzen.

In diesem Buch werden nur moderne Plattformen besprochen, die Unternehmen mit Hilfe von Cloud-Technologien implementieren. Wir werden in Kapitel 2 mehr über moderne Plattformen erfahren.

Offene Dateiformate

Datenplattformen können Daten in verschiedenen Dateiformaten in der Cloud Speicherung speichern. Dateiformate wie CSV, JSON und XML sind die beliebtesten. Die drei am weitesten verbreiteten Dateiformate für Analyseplattformen sind Parquet, ORC und Avro ( ).

Alle diese Formate sind offene Dateiformate, das heißt, sie sind Teil eines Open-Source-Ökosystems. Sie sind nicht proprietär, sondern können von jedem für die Speicherung von Daten verwendet werden. Jede kompatible Verarbeitungsmaschine kann mit solchen offenen Dateiformaten arbeiten. Viele andere Eigenschaften machen diese drei Formate für analytische Arbeitslasten geeignet. Wir werden diese Dateiformate in Kapitel 3 ausführlicher besprechen.

Offene Tabellenformate

Wie bereits erwähnt, bringen die offenen Tabellenformate Transaktionsmöglichkeiten in einen Data Lake und machen ihn so zu einem Lakehouse. Diese offenen Tabellenformate sind das Herzstück des Lakehouses. Es gibt drei solcher Formate, die in der Datengemeinschaft immer beliebter werden: Apache Iceberg, Apache Hudi und das Delta Lake der Linux Foundation.

Werfen wir einen kurzen Blick auf diese drei offenen Tabellenformate:

Apache Eisberg

Apache Iceberg ist ein offenes Tabellenformat, das mit Cloud Object Stores und offenen Dateiformaten wie Parquet, Avro und ORC für die Implementierung von Lakehouse-Architekturen verwendet werden kann. Es unterstützt Funktionen wie Zeitreisen, Schema-Evolution und SQL-Unterstützung und macht die Implementierung von Lakehouse schneller und einfacher.

Apache Hudi

Apache Hudi hilft bei der Implementierung eines transaktionalen Data Lakes und kann verwendet werden, um Data Warehouse-ähnliche Fähigkeiten in den Data Lake zu bringen. Es bietet ACID-Transaktionsgarantien, inkrementelle Verarbeitung, Zeitreisefunktionen, Schemaentwicklung und Durchsetzungsfunktionen.

Der Delta Lake der Linux Foundation

Delta Lake wurde von Databricks als internes Projekt ins Leben gerufen und ist gemeinhin als Open-Source-Framework für die Speicherung von Daten in Lakes bekannt. Delta Lake liefert die Metadatenschicht und ACID-Funktionen für Data Lakes. Außerdem bietet es Funktionen wie Zeitreisen, Schemaerzwingung und -entwicklung sowie Audit Trail Logging.

Hinweis

Es gibt jetzt zwei verschiedene Distributionen von Delta Lake. Die kommerzielle Version wird zusammen mit der Databricks-Plattform geliefert. Die Open-Source-Version ist auf der Website der Linux Foundation erhältlich und kann auch in anderen Umgebungen als der von Databricks verwendet werden. Obwohl Databricks alle Delta Lake-Funktionen als Open Source zur Verfügung stellt, kann es sein, dass die neueste Open Source-Version nicht sofort mit verwalteten Apache Spark-Diensten wie Amazon EMR oder Azure Synapse Analytics verfügbar ist. Du wirst warten müssen, bis diese verwalteten Cloud-Dienste die neuesten Spark- und Delta Lake-Versionen anbieten, um alle aktuellen Delta Lake-Funktionen nutzen zu können.

Alle diese offenen Tabellenformate werden in Kapitel 3 ausführlicher behandelt.

Compute-Schicht

Einer der wichtigsten Vorteile der Lakehouse-Architektur ist ihre Offenheit und die Möglichkeit, von jeder kompatiblen Verarbeitungsmaschine direkt angesprochen oder abgefragt zu werden. Für die Ausführung von BI-Workloads oder interaktiven Analysen ist keine spezielle, proprietäre Engine erforderlich. Bei diesen Compute Engines kann es sich um Open-Source- oder kommerzielle Query Engines handeln, die speziell für Lakehouse-Architekturen entwickelt wurden.

Open-Source-Engines

Du kannst Open-Source-Engines verwenden, um auf Daten aus einem Seehaus zuzugreifen. Diese sind nicht herstellerspezifisch und du musst keine Lizenz erwerben, um sie zu nutzen. Beispiele für Open-Source-Computing-Engines sind Spark, Presto, Trino und Hive.

Kommerzielle Motoren

Das sind Abfrage-Engines, die speziell für eine bessere Leistung bei der Ausführung von Workloads auf Seehäusern entwickelt wurden. Kommerzielle Engines werden in der Regel von Grund auf neu entwickelt und berücksichtigen dabei die zugrunde liegenden offenen Datenformate und wie effektiv sie die beste Leistung erzielen können. Beispiele für kommerzielle Compute Engine-Anbieter sind Databricks, Dremio, Snowflake und Starburst.

Sowohl die Speicher- als auch die Berechnungsebene arbeiten zusammen, um Lakehouse-Architekturen mit den besten Eigenschaften von Data Lakes und Data Warehouses zu betreiben. Dadurch überwindet die Lakehouse-Architektur die Grenzen traditioneller Datenarchitekturen und unterstützt verschiedene Arbeitslasten, von BI bis KI, sowie verschiedene nachgelagerte Anwendungen, die die Daten einer Datenplattform nutzen.

Eine Datenplattform, die auf der Lakehouse-Architektur basiert, weist wichtige Merkmale auf, die dazu beitragen, die Einschränkungen herkömmlicher Architekturen zu überwinden. Im folgenden Abschnitt werden diese Merkmale näher erläutert.

Merkmale der Seehausarchitektur

Die folgenden Merkmale unterscheiden die Lakehouse-Architektur von anderen traditionellen Datenarchitekturen.

Eine Ebene der Speicherung ohne eigenes Lager

Wie in den vorangegangenen Abschnitten beschrieben, ist ein Lakehouse im Kern ein Data Lake, der auf einer Cloud-Objektspeicherung mit einer zusätzlichen Transaktionsschicht basiert. Es gibt keine separate Speicherung wie bei einem speziellen Data Warehouse zur Unterstützung von BI-Workloads. Alle Verbraucher lesen, greifen auf Daten zu oder fragen sie direkt aus dem Data Lake ab. Dieselbe Cloud Object Speicherung unterstützt alle Anwendungsfälle, einschließlich BI- und KI/ML-Workloads.

Warehouse-ähnliche Leistung im Data Lake

Die Speicherung in der Cloud ist für BI-Workloads nicht geeignet und bietet nicht die Leistung, die die speziell entwickelte proprietäre Speicherung von Cloud Data Warehouses bietet. Datenplattformen, die auf der Lakehouse-Architektur basieren, bieten eine hervorragende Leistung für BI-Anwendungsfälle, da sie Optimierungshebel auf der Speicher- und Rechenebene bieten. Mit der richtigen Kombination aus offenen Datenformaten (Dateien und Tabellen) und Compute-Engines, die speziell für die Lakehouse-Architektur entwickelt wurden, kannst du eine hervorragende Leistung erzielen.

Entkoppelte Architektur mit getrennter Speicherung und Rechenskalierung

Die Lakehouse-Architektur basiert auf einem entkoppelten Ansatz mit getrennten Speicher- und Recheneinheiten. Die vorherigen Generationen von Datenplattformen verwendeten Architekturen mit integrierten Speicher- und Verarbeitungsschichten. Beispiele dafür sind Datenbanken, traditionelle On-Premises-Warehouses und Hadoop-Ökosysteme. Eine Skalierung der Speicherung oder der Rechenleistung war mit solchen integrierten Architekturen nicht möglich.

Die entkoppelte Lakehouse-Architektur ermöglicht eine individuelle Skalierung der Speicher- und Rechenkapazitäten. Du kannst einfach mehr Speicherung hinzufügen, ohne die Rechnerkapazität zu erhöhen und andersherum. Abbildung 1-5 zeigt Plattformen, die die Lakehouse-Architektur mit entkoppelter Speicherung und Rechenleistung implementieren.

Abbildung 1-5. Entkoppelte Speicherung und Rechenleistung in der Lakehouse-Architektur

Offene Architektur

Die Lakehouse-Architektur verwendet einen "offenen" Ansatz für die Implementierung von Datenplattformen. Das bedeutet, dass du die Freiheit hast, Open-Source-Datenformate und Open-Source-Rechenmaschinen für deine Datenplattformen zu verwenden. Im Gegensatz zu proprietären Warehouses, bei denen du die in der Warehouse-Software enthaltene native Verarbeitungs-Engine verwenden musst, kannst du bei Lakehouses jede verteilte Verarbeitungs-Engine einsetzen, die mit den zugrunde liegenden Speicherformaten kompatibel ist. Dank dieser offenen Architektur können Datenkonsumenten direkt von der Speicherung in der Cloud auf die Daten zugreifen, ohne dass sie eine herstellerspezifische Software benötigen.

Unterstützung für verschiedene Datentypen

Traditionell unterstützten On-Premises-Warehouse-Architekturen nur strukturierte Daten. Semistrukturierte und unstrukturierte Daten konnten sie nicht speichern, verwalten oder pflegen. Einige moderne Cloud-Warehouses können jetzt auch halbstrukturierte Daten wie JSON- und XML-Dateien unterstützen.

Datenplattformen, die nach dem Lakehouse-Ansatz aufgebaut sind, unterstützen alle Datenformate - strukturierte, halbstrukturierte und unstrukturierte Bilder, Audio- und Videodaten - auf einer einzigen Speicherebene.

Unterstützung für verschiedene Workloads

Da lakehouse alle Datenformate verarbeiten kann, unterstützt es alle Arten von Workloads, einschließlich BI, AI/ML, ETL und Streaming. Du brauchst keine separaten Speicherebenen oder eine speziell entwickelte Speicherung, um diese Arbeitslasten zu unterstützen. Die Lakehouse-Architektur kann alle diese Workloads in einer einzigen Speicherschicht unterstützen.

Als Nächstes wollen wir die wichtigsten Vorteile der Lakehouse-Architektur erörtern und wie sie dazu beitragen kann, eine einfache, einheitliche und offene Datenplattform aufzubauen.

Vorteile der Seehausarchitektur

Eine Datenplattform, die nach dem Lakehouse-Ansatz implementiert, bietet viele bedeutende Vorteile, insbesondere in einer Welt, in der der Aufbau von Datenplattformen nicht nur skalierbar und flexibel, sondern auch sicher und zuverlässig sein muss.

Im Folgenden findest du eine Liste der Vorteile, die du durch die Implementierung einer Datenplattform auf Basis der Lakehouse-Architektur erhältst.

Vereinfachte Architektur

Bei der Lakehouse-Architektur befinden sich alle Daten in einer einzigen Speicherschicht. Die Datenarchitektur wird vereinfacht, weil es kein separates Warehouse gibt und die zusätzliche ETL-Pipeline, die erforderlich ist, um Daten aus Data Lakes in Data Warehouses zu übertragen, reduziert wird. Die Lakehouse-Architektur vermeidet auch Verzögerungen, Ausfälle oder Datenqualitätsprobleme, die mit der Integration von Data Lakes und Data Warehouses verbunden sind.

Diese Architektur mit einer einzigen Speicherung hat mehrere Vorteile:

  • Es ist kein zusätzlicher Aufwand erforderlich, um Daten zwischen dem Data Lake und dem Warehouse zu synchronisieren. Die Synchronisierung von Daten zwischen zwei verschiedenen Arten von Speichern ist immer eine Herausforderung.

  • Du musst dir keine Sorgen machen, dass du die Datentypen zwischen Data Lakes und Warehouses ändern musst. Die Schemata in diesen beiden stimmen oft nicht überein, da sich die Datentypen unterscheiden können.

  • Die Datenverwaltung wird im Lakehouse viel einfacher, da du die Zugriffskontrollen nur an einer Stelle implementieren musst. Bei einer zweistufigen Speicherung musst du getrennte Zugriffskontrollmechanismen für den Zugriff auf Daten aus dem Data Lake und dem Warehouse einrichten und sicherstellen, dass diese immer synchronisiert sind.

  • ML-Workloads können Daten aus dem Lakehouse lesen und direkt auf die zugrunde liegenden Parquet-, Avro- oder ORC-Speicherungsdateien zugreifen. Damit entfällt die Notwendigkeit, aggregierte Daten aus dem Warehouse in den Lake zu kopieren, wenn sie von ML-Workloads benötigt werden.

Unterstützung für unstrukturierte Daten und ML-Anwendungsfälle

Ein großer Teil der Daten, die in der heutigen Welt produziert werden, ist unstrukturiert. Ein Lakehouse unterstützt unstrukturierte Daten ebenso wie strukturierte und halbstrukturierte Daten. Dies eröffnet unendliche Möglichkeiten für die Implementierung von KI- und ML-Anwendungsfällen, um riesige Mengen unstrukturierter Daten für Vorhersagen, Prognosen, Empfehlungen und neue Erkenntnisse aus Daten zu nutzen.

Keine Anbieterbindung

Wie wir bereits besprochen haben, verwenden Seehäuser offene Formate für die Implementierung von Datenplattformen. Offene Formate ermöglichen es den Verbrauchern, Daten mit jeder kompatiblen Verarbeitungsmaschine abzufragen und zu verarbeiten, die sich gut in die zugrunde liegenden Formate der Speicherung integrieren lässt. Lakehouses verwenden kein proprietäres Speicherformat, das eine bestimmte Verarbeitungsmaschine eines Anbieters erfordert. So können nachgelagerte Anwendungen direkt auf die Daten zugreifen und sie nutzen.

Wenn du zum Beispiel eine zweistufige Datenplattform mit einem Data Lake und einem dedizierten Warehouse implementierst, musst du die Daten zunächst in das Warehouse laden, um BI-Workloads durchführen zu können. Um diese Daten abzufragen oder auf sie zuzugreifen, musst du die proprietäre Compute Engine desselben Warehouse-Anbieters nutzen. Du musst die vom Anbieter zur Verfügung gestellten Verarbeitungskapazitäten nutzen und dafür bezahlen. Das führt zu einer Anbieterbindung und die Migration zu anderen Engines ist mit erheblichem Aufwand verbunden.

Warnung

Nicht alle offenen Tabellenformate sind mit allen Open-Source- oder kommerziellen Abfrageprogrammen kompatibel. Dieser Bereich wächst, und mehrere unabhängige Softwareanbieter (ISVs) arbeiten an der Entwicklung von Konnektoren für die Interaktion mit verschiedenen Datenformaten. Bei der Entscheidung für dein technisches Paket solltest du die Kompatibilität der Engine mit den zugrunde liegenden offenen Tabellenformaten berücksichtigen.

Datenaustausch

Da das Lakehouse offene Datenformate verwendet, wird der Austausch von Daten mit nachgelagerten Verbrauchern viel einfacher. Du musst die Verbraucher nicht auf deinen Plattformen einbinden oder Dateiextrakte mit ihnen teilen. Sie können direkt auf die Daten aus der Speicherung in der Cloud zugreifen, basierend auf den Zugriffsrechten für die gemeinsame Datennutzung.

Ein Beispiel für die gemeinsame Nutzung von Daten ist das Delta Sharing-Protokoll, ein offener Standard für die sichere gemeinsame Nutzung von Daten, der von Delta Lake eingeführt wurde. Abbildung 1-6 zeigt eine vereinfachte Version des Delta-Sharing-Protokolls. Bitte beachte, dass die tatsächlichen Implementierungen zusätzliche Komponenten haben, um die Berechtigungen zu verwalten und die Leistung zu optimieren, damit nur die benötigten Daten bereitgestellt werden.

Abbildung 1-6. Deltaaufteilung im Deltasee

Der Hauptvorteil der gemeinsamen Nutzung offener Daten ist die Freiheit der Datenkonsumenten, jede beliebige Open-Source-Verarbeitungsmaschine oder kommerzielle Produkte zur Abfrage und Analyse der Daten zu verwenden. Sie müssen nicht dasselbe Produkt wie der Datenproduzent verwenden, um auf die gemeinsam genutzten Daten zuzugreifen. Auf der anderen Seite muss der Datenproduzent nur die Daten freigeben und sich keine Gedanken darüber machen, welche Verarbeitungsprogramme die Verbraucher für den Zugriff auf die Daten verwenden. Diese Funktion eröffnet zahlreiche Möglichkeiten für die sichere gemeinsame Nutzung von Daten und die Einrichtung eines Marktplatzes für die gemeinsame Nutzung und den Austausch von Daten.

Dies ist ein wachsender Bereich, und in Zukunft könnten mehrere Anbieter und Gemeinden neue Konnektoren einführen, um direkt auf die in einem Seehaus gespeicherten Daten zuzugreifen.

Skalierbar und kosteneffizient

Seehäuser nutzen Cloud-Speicherung, die skalierbar und viel billiger ist als herkömmliche Datenlager. Die Speicherkosten für Lakehouses werden von den Cloud-Providern festgelegt. Du kannst auch die Richtlinien für das Lebenszyklusmanagement und die kalten oder archivierten Ebenen nutzen, die Cloud-Anbieter anbieten, um die langfristigen Kosten für die Speicherung zu optimieren.

Keine Datensümpfe

Viele Unternehmen verfügen über große Datenmengen in ihren Data Lakes. Meistens nutzen sie diese Daten jedoch nicht effektiv, weil es ihnen an Datentransparenz mangelt.

Die Entdeckung dieser großen Datenmengen ist ohne eine angemessene Metadatenverwaltung, Governance, Nachverfolgung der Herkunft und Zugriffskontrolle schwierig. Ohne diese Dinge werden Data Lakes zu Datensümpfen und die Nutzung dieser Daten wird zur Herausforderung. Lakehouses helfen dabei, die Daten für die Nutzer der Plattform leicht auffindbar zu machen, indem sie Funktionen wie ein einheitliches Metadatenmanagement (für alle Daten und KI-Assets), die Nachverfolgung der Herkunft und vieles mehr bieten.

Hinweis

Datensümpfe sind Datenseen mit großen Datenmengen ohne angemessene Organisation oder Struktur. Die in solchen Data Lakes gespeicherten Daten werden nicht gut verwaltet und verfügen nicht über gut organisierte Metadaten in Form von Katalogen, was das Auffinden von Daten extrem schwierig macht und die allgemeine Sichtbarkeit der Daten für die Verbraucher verringert. Kurz gesagt: Datensümpfe sind Datenseen mit Daten, die aufgrund fehlender robuster Metadaten und Governance-Prozesse nicht für die Geschäftsanforderungen genutzt werden.

Durchsetzung und Entwicklung von Schemata

Die in der Lakehouse-Architektur verwendeten Technologien unterstützen die Durchsetzung von Schemavalidierungen, um Schemafehlanpassungen bei der Datenspeicherung zu vermeiden. Diese Technologien unterstützen auch die Schema-Evolution, indem sie verschiedene Ansätze verwenden, um Änderungen am Quellschema zu akzeptieren. Diese Funktionen ermöglichen ein flexibles System mit besserer Datenqualität und -integrität. Lassen Sie uns kurz die Vorteile dieser beiden Funktionen besprechen.

Schema-Durchsetzung

Die Schemaerzwingung stellt sicher, dass die im Lakehouse gespeicherten Daten dem in den Metadaten der Tabelle definierten Schema entsprechen. Der ETL-Prozess lehnt alle zusätzlichen Attribute oder nicht übereinstimmenden Datentypen ab. Diese Validierungen helfen dabei, korrekte Daten zu speichern und so die Datenqualität insgesamt zu verbessern. Wenn zum Beispiel ein String-Wert in einem Attribut auftaucht, das im Schema als Ganzzahl definiert ist, wird er abgelehnt.

Schema-Entwicklung

Während die Schemaerzwingung die Datenqualität durch die Implementierung strenger Validierungen verbessert, unterstützt die Schemaevolution die Lockerung dieser Validierungen, indem sie mehr Flexibilität bei der Speicherung der Daten in einem Lakehouse bietet. Jedes zusätzliche Attribut, das nicht in den Metadaten der Tabelle definiert ist, kann mit Schema Evolution gespeichert werden. Je nach offenem Tabellenformat gibt es verschiedene Ansätze, um das zusätzliche Attribut zu speichern. Diese Funktion hilft dabei, neue Attribute oder Datentypabweichungen zu speichern, ohne sie abzulehnen. Der Hauptvorteil dieses Ansatzes ist, dass du keine Daten verlierst und Änderungen während der Laufzeit berücksichtigen kannst.

Während die Schemaerzwingung zur Verbesserung der Datenqualität beiträgt, indem sie strenge Regeln für bestimmte Attribute durchsetzt, bietet die Schemaevolution Flexibilität, um Metadatenänderungen in den Quellsystemen zu berücksichtigen. Bei der Implementierung deines Lakehouse kannst du beides nutzen, um die Datenqualität zu erhalten und Änderungen an den Metadaten der Quelle zu berücksichtigen.

Einheitliche Plattform für ETL/ELT, BI, AI/ML und Echtzeit-Workloads

Wie wir bereits erwähnt haben, ermöglicht die Lakehouse-Architektur die Implementierung einer einheitlichen Datenplattform zur Unterstützung verschiedener Arbeitslasten. Wir wollen diese Arbeitslasten und die Vorteile einer Lakehouse-Architektur für ihre Umsetzung genauer besprechen.

ETL/ELT-Arbeitsbelastungen

Um ETL-Workloads zu implementieren, kannst du gängige Verarbeitungs-Engines wie Spark verwenden, um Transformationen durchzuführen , bevor du die Daten in den höheren Zonen der Speicherhierarchie des Lakehouse speicherst. Du kannst auch eine ELT-Workload implementieren, um Transformationen mit SQL-Abfragen über eine beliebige Compute Engine durchzuführen. Datenexperten, die sich mit SQL besser auskennen, bevorzugen SQL-basierte ELT-Operationen zur Datenumwandlung.

BI-Workloads

Mit einer Leistung, die mit Data Warehouses vergleichbar ist, kannst du deine BI-Workloads mit einem Lakehouse umsetzen. Da ein Lakehouse eine Transaktionsschicht für den Data Lake bietet, sind Vorgänge wie Aktualisierungen und Löschungen möglich und schneller als in Data Lakes.

KI/ML-Workloads

Da ein Lakehouse neben strukturierten und halbstrukturierten Daten auch unstrukturierte Daten unterstützt, kannst du KI/ML-Anwendungsfälle durchführen, indem du direkt auf die Daten im Lakehouse zugreifst.

Echtzeit-Workloads

Eine einheitliche Lakehouse-Architektur unterstützt verschiedene Workloads, einschließlich Echtzeitverarbeitung. In den letzten Jahren haben Unternehmen aufgrund der Zunahme von Echtzeitdaten, die von IoT-Geräten, Wearables und Clickstreams generiert werden, versucht, Plattformen zu implementieren, die Echtzeit-Workloads unterstützen können. Frühere Datenarchitekturen, wie z. B. die Lambda-Architektur, unterstützten Echtzeit-Workloads mit verschiedenen Verarbeitungsströmen. Lakehouses unterstützen Echtzeit-Workloads durch eine einheitliche Architektur, die die Ausführung von Batch- und Echtzeitaufträgen mit derselben Codebasis ermöglicht.

Hinweis

DieLambda-Architektur ist ein traditioneller Ansatz zur Verarbeitung großer Datenmengen, die mit unterschiedlicher Häufigkeit eingehen. Die Lambda-Architektur hat zwei verschiedene Schichten für die Verarbeitung von Stapel- und Streaming-Daten. Die Batch- und Streaming-Datenkomponenten für diese Schichten sind ebenfalls getrennt, basierend auf Faktoren wie Latenz und damit verbundenen SLAs. Daraus ergibt sich eine komplexe Datenarchitektur mit zusätzlichem Aufwand für die Pflege unterschiedlicher Codebasen für die verschiedenen Schichten.

Zeitreise

Die Transaktionsschicht in einem Lakehouse ermöglicht es, verschiedene Versionen von Daten zu verwalten. So kann sie Zeitreisen durchführen, um ältere Daten, die aktualisiert oder gelöscht wurden, abzufragen und zu holen. Schauen wir uns ein Beispiel an, um die Zeitreisefunktion zu verstehen. Tabelle 1-1 zeigt eine Produkttabelle mit drei Spalten.

Tabelle 1-1. Eine Seehaustabelle mit Beispielsätzen
produkt_id produkt_name Produkt_Kategorie
22 Tastatur Computerzubehör
12 Maus Computerzubehör
71 Kopfhörer Computerzubehör
11 Handytasche mobiles Accessoire

Nehmen wir an, die dritte Zeile mit der product_id 71 wird aktualisiert, um die Kategorie von "Computerzubehör" in "Handyzubehör" zu ändern. Tabelle 1-2 zeigt die aktualisierte Tabelle.

Tabelle 1-2. Eine Seehaustabelle mit aktualisierten Datensätzen
produkt_id produkt_name Produkt_Kategorie
22 Tastatur Computerzubehör
12 Maus Computerzubehör
71 Kopfhörer mobiles Accessoire
11 Handytasche mobiles Accessoire

Wenn du jetzt die Produkttabelle abfragst, kannst du die aktualisierten Daten sehen, aber der ältere Wert von product_category für den aktualisierten Datensatz wird nicht angezeigt.

Wenn du offene Tabellenformate wie Iceberg, Hudi oder Delta Lake verwendest, kannst du die vorherigen Datensätze auch sehen, indem du die Tabelle einfach mit einer früheren Versionsnummer oder einem älteren Zeitstempel abfragst, wie im Folgenden gezeigt.

Ältere Daten basierend auf der Version abrufen

Du kannst den älteren Status der Datensätze abrufen, indem du die Versionsnummer verwendest:

select * from product as of version <older version number>

Ältere Daten anhand des Zeitstempels abrufen

Du kannst den älteren Status der Datensätze abrufen, indem du den früheren Zeitstempel verwendest:

select * from product as of <older timestamp>
Hinweis

Die genauen SQL-Befehle unterscheiden sich je nach dem offenen Tabellenformat und der Rechenmaschine, die für die Implementierung des Seehauses verwendet wird.

Diese Zeitreisefunktion ist in traditionellen Data Warehouses oder Data Lakes nicht möglich. Einige NoSQL-Datenbanken (wie HBase) und moderne Cloud-Warehouses speichern alle Versionen von Daten, aber in traditionellen Warehouses fehlte diese Funktion.

Diese Vorteile ermöglichen es allen Datenpersonen, im Vergleich zu früheren Datenarchitekturen schnell und effizient auf Daten zuzugreifen, sie zu verwalten, zu kontrollieren, zu analysieren und zu nutzen.

In Anbetracht der Vorteile kann die Lakehouse-Architektur schon bald zur Standardwahl für die Implementierung von Datenplattformen werden und könnte eine ähnlich breite Akzeptanz wie Data Warehouses und Data Lakes erfahren. Fortschrittliche Technologien, wachsende Communities und mehrere ISVs, die an Lakehouse-basierten Produkten arbeiten, deuten auf eine wachsende Nachfrage und Beliebtheit der Lakehouse-Architektur hin.

Die wichtigsten Erkenntnisse

Wenn du dich zum ersten Mal mit der Architektur von Seehäusern beschäftigst, verstehe ich, dass das eine Menge Informationen sind, die du auf Anhieb verdauen musst. Ich fasse die wichtigsten Punkte zusammen, die ich in diesem Kapitel besprochen habe, damit du dich an die wichtigsten Konzepte erinnerst, wenn du die folgenden Kapitel in diesem Buch liest.

Verständnis der Datenarchitektur

  • Die Datenarchitektur ist das Fundament einer jeden Datenplattform. Sie definiert die Kernkomponenten und ihre Abhängigkeiten untereinander. Sie liefert die Blaupause für den Aufbau der Datenplattform und hilft dabei, die Leitprinzipien für die Gestaltung des Systems festzulegen.

  • Die Kernkomponenten der Datenplattform sind Quellsysteme, Datenaufnahme, Speicherung, Datenverarbeitung und -transformation, Datenkonsum und -bereitstellung sowie gemeinsame Dienste wie Metadatenmanagement, Data Governance und Datensicherheit und Datenbetrieb.

  • Der Entwurf der Datenarchitektur ist einer der wichtigsten Schritte beim Aufbau der Dateninfrastruktur. Du solltest alles daran setzen, eine skalierbare, flexible, zuverlässige und vor allem einfache Plattform zu entwickeln. Dadurch wird die Akzeptanz bei den Nutzern beschleunigt.

Merkmale der Seehausarchitektur

  • Die Lakehouse-Architektur ist ein neues Architekturmuster, das in den letzten Jahren entstanden ist. Sie vereint die besten Eigenschaften von Data Warehouses und Data Lakes.

  • Die Lakehouse-Architektur speichert die Daten in einem Cloud-Speicher mit einer zusätzlichen Transaktionsschicht, die warehouseähnliche Funktionen ermöglicht.

  • Du erhältst die Skalierbarkeit, Flexibilität und Kosteneffizienz eines Data Lake sowie die Leistung, ACID-Konformität und bessere Governance von Data Warehouses.

  • Die Lakehouse-Architektur hat nur eine einzige Speicherebene und keine separate Speicherung im Lager. Sie verwendet eine entkoppelte Architektur, bei der die Rechen- und Speicherebenen getrennt sind und unabhängig voneinander skalieren.

  • Sie unterstützt die Speicherung und Verwaltung aller Datentypen, einschließlich strukturierter, halbstrukturierter und unstrukturierter Daten. Außerdem unterstützt sie verschiedene Workloads wie ETL, Streaming, BI und KI/ML.

Vorteile der Seehausarchitektur

  • Die Lakehouse-Architektur hilft dir, eine einfache, einheitliche Datenplattform zu implementieren, um eine Vielzahl von Daten- und Analyseanwendungen zu realisieren.

  • Lakehouses nutzen offene Technologien für die Speicherung; du musst dir keine Gedanken über die Bindung an einen bestimmten Anbieter machen. Du kannst jede kompatible Compute Engine verwenden, um die Daten abzufragen, indem du direkt auf die in der Cloud Speicherung gespeicherten Daten zugreifst.

  • Der Datenaustausch mit Datenkonsumenten, unabhängig von der Technologie oder dem Produkt, das sie verwenden, wird einfacher, ohne dass die Daten repliziert oder Dateiextrakte verschickt werden müssen.

  • Lakehouses hilft dir dabei, deine Daten effizienter zu verwalten und zu kontrollieren, z. B. mit Funktionen wie Schemaerzwingung, Schemaentwicklung und Zeitreisen.

Bei der weiteren Lektüre dieses Buches wirst du tief in fortgeschrittenere Themen eintauchen, um zu verstehen, wie man praktische Lakehouse-Architekturen entwirft und implementiert und um ihre Vorteile gegenüber traditionellen Architekturen wie Data Warehouses und Data Lakes oder den kombinierten zweistufigen Systemen zu erkennen. Aber für Leser, die neu in der Datenwelt sind, müssen wir zunächst diese traditionellen Architekturen, ihre Vorteile und ihre Grenzen besser verstehen, um die Vorteile der Lakehouse-Architektur zu erkennen. Darauf werde ich im nächsten Kapitel eingehen.

Get Praktische Seehaus-Architektur now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial