Das semantische Lakehouse erklärt

Datenseen und semantische Schichten gibt es schon seit langer Zeit – jeder lebt in seinem eigenen ummauerten Garten, eng gekoppelt an ziemlich enge Anwendungsfälle. Da die Daten- und Analyseinfrastruktur in die Cloud migriert wird, stellen sich viele die Frage, wie diese grundlegenden Technologiekomponenten in den modernen Daten- und Analyse-Stack passen. In diesem Artikel werden wir untersuchen, wie ein Data Lakehouse und eine semantische Schicht zusammen die traditionelle Beziehung zwischen Data Lakes und Analyseinfrastruktur auf den Kopf stellen. Wir werden lernen, wie ein semantisches Seehaus dramatisch vereinfachen kann Cloud-Datenarchitekturen, eliminieren Sie unnötige Datenbewegungen und reduzieren Sie die Time-to-Value und die Cloud-Kosten.

Die traditionelle Daten- und Analysearchitektur

Im Jahr 2006 führte Amazon Amazon Web Services (AWS) als neue Möglichkeit ein, das Rechenzentrum vor Ort in die Cloud auszulagern. Ein zentraler AWS-Service war sein Dateidatenspeicher, und damit war der erste Cloud Data Lake, Amazon S3, geboren. Andere Cloud-Anbieter würden danach ihre eigenen Versionen der Cloud-Data-Lake-Infrastruktur einführen.

Die meiste Zeit seines Lebens wurde der Cloud Data Lake in die Rolle des Dummen und Billigen verbannt Datenspeichervorrichtung - Ein Aufführung Bereich für Rohdaten, bis die Daten zu etwas Brauchbarem verarbeitet werden konnten. Für Analysen diente der Data Lake als Aufbewahrungsort für Daten, bis sie kopiert und in eine optimierte Analyseplattform geladen werden konnten, typischerweise ein relationales Cloud-Data Warehouse, das entweder OLAP-Cubes, proprietäre Business Intelligence (BI)-Tool-Datenextrakte wie Tableau Hyper oder Power BI Premium oder alle oben genannten. Als Ergebnis dieses Verarbeitungsmusters mussten Daten mindestens zweimal gespeichert werden, einmal in ihrer Rohform und einmal in ihrer „analytikoptimierten“ Form. 

Es überrascht nicht, dass die meisten traditionellen Cloud-Analytics-Architekturen wie im folgenden Diagramm aussehen:

Wie Sie sehen können, ist das „Analytics Warehouse“ für einen Großteil der Funktionen verantwortlich, die den Verbrauchern Analysen liefern. Das Problem mit dieser Architektur ist wie folgt:

1. Daten werden doppelt gespeichert, was die Kosten erhöht und betriebliche Komplexität schafft.
2. Daten im Analytics Warehouse sind eine Momentaufnahme, was bedeutet, dass Daten sofort veraltet sind.
3. Daten im Analytics Warehouse sind in der Regel eine Teilmenge der Daten im Data Lake, was die Fragen, die Verbraucher stellen können, einschränkt.
4. Das Analytics Warehouse wird separat und anders als die Cloud-Datenplattform skaliert, was zusätzliche Kosten, Sicherheitsbedenken und betriebliche Komplexität mit sich bringt.

Angesichts dieser Nachteile könnten Sie fragen: „Warum sollten Cloud-Datenarchitekten dieses Entwurfsmuster wählen?“ Die Antwort liegt in den Anforderungen der Analytics-Verbraucher. Während der Data Lake theoretisch analytische Abfragen direkt an Verbraucher liefern könnte, ist der Data Lake in der Praxis zu langsam und mit gängigen Analysetools nicht kompatibel. 

Wenn nur der Data Lake die Vorteile eines Analytics Warehouse bieten könnte und wir die doppelte Speicherung von Daten vermeiden könnten!

Die Geburt des Data Lakehouse

Der Begriff „Lakehouse“ wurde 2020 mit dem wegweisenden Whitepaper von Databricks eingeführt „Was ist ein Lakehouse?“ von Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia und Ali Ghodsi. Die Autoren stellten die Idee vor, dass der Data Lake als Engine für die Bereitstellung von Analysen dienen könnte, nicht nur als statischer Dateispeicher.

Data Lakehouse-Anbieter haben ihre Vision umgesetzt, indem sie skalierbare Hochgeschwindigkeits-Abfrage-Engines eingeführt haben, die mit Rohdatendateien im Data Lake arbeiten und eine ANSI-Standard-SQL-Schnittstelle bereitstellen. Mit dieser Schlüsselinnovation argumentieren Befürworter dieser Architektur, dass sich Data Lakes wie ein Analyselager verhalten können, ohne dass Daten dupliziert werden müssen.

Es stellt sich jedoch heraus, dass das Analytics Warehouse andere wichtige Funktionen erfüllt, die von der Data Lakehouse-Architektur allein nicht erfüllt werden, darunter:

1. Konsistente Bereitstellung von „Gedankenschnell“-Abfragen (Abfragen in weniger als 2 Sekunden) über ein breites Spektrum von Abfragen hinweg.
2. Präsentieren einer geschäftsfreundlichen semantischen Schicht, die es Verbrauchern ermöglicht, Fragen zu stellen, ohne SQL schreiben zu müssen.
3. Anwenden von Data Governance und Sicherheit zum Zeitpunkt der Abfrage.

Damit ein Data Lakehouse das Analytics Warehouse wirklich ersetzen kann, brauchen wir also etwas anderes.

Die Rolle der semantischen Schicht

Ich habe viel über die Rolle der geschrieben semantische Schicht im modernen Datenstack. Zusammenfassend lässt sich sagen, dass eine semantische Ebene eine logische Ansicht von Geschäftsdaten ist, die Datenvirtualisierungstechnologie nutzt, um physische Daten zum Zeitpunkt der Abfrage in geschäftsfreundliche Daten zu übersetzen. 

Durch Hinzufügen einer Semantic-Layer-Plattform auf einem Data Lakehouse können wir die Analytics-Warehouse-Funktionen vollständig eliminieren, da die Semantic-Layer-Plattform:

1. Liefert „Gedankenschnellabfragen“ im Data Lakehouse mithilfe von Datenvirtualisierung und automatischer Optimierung der Abfrageleistung.
2. Bietet eine geschäftsfreundliche semantische Ebene, die die proprietären semantischen Ansichten ersetzt, die in jedes BI-Tool eingebettet sind, und ermöglicht es Geschäftsanwendern, Fragen zu stellen, ohne SQL-Abfragen schreiben zu müssen.
3. Bietet Data Governance und Sicherheit zum Zeitpunkt der Abfrage.

Eine Semantic-Layer-Plattform liefert die fehlenden Teile, die dem Data Lakehouse fehlen. Durch die Kombination einer semantischen Schicht mit einem Data Lakehouse können Organisationen:

1. Beseitigen Sie Datenkopien und vereinfachen Sie Datenpipelines.
2. Konsolidieren Sie Data Governance und Sicherheit.
3. Stellen Sie eine „Single Source of Truth“ für Geschäftskennzahlen bereit.
4. Reduzieren Sie die betriebliche Komplexität, indem Sie die Daten im Data Lake aufbewahren.
5. Bieten Sie Analytics-Kunden Zugriff auf mehr Daten und aktuellere Daten.

Das semantische Lakehouse: Jeder gewinnt

Mit dieser Architektur gewinnen alle. Verbraucher erhalten Zugriff auf detailliertere Daten ohne Latenz. IT- und Data-Engineering-Teams müssen weniger Daten verschieben und transformieren. Die Finanzabteilung gibt weniger Geld für die Kosten der Cloud-Infrastruktur aus. 

Wie Sie sehen, können Unternehmen durch die Kombination einer semantischen Ebene mit einem Data Lakehouse ihre Daten- und Analysevorgänge vereinfachen und mehr Daten schneller an mehr Verbraucher zu geringeren Kosten liefern.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://www.dataversity.net/the-semantic-lakehouse-explained/