Techniken zur Modellierung von Data Warehousing und deren Implementierung auf der Databricks Lakehouse Platform

Das Lakehouse ist ein neues Paradigma für Datenplattformen, das die besten Funktionen von Data Lakes und Data Warehouses kombiniert. Es ist als skalierbare Datenplattform für Unternehmen konzipiert, die viele Anwendungsfälle und Datenprodukte beherbergen kann. Es kann als ein einziges, einheitliches Unternehmensdatenrepository für all Ihre Folgendes dienen:

• Datenbereiche,
• Echtzeit-Streaming-Anwendungsfälle,
• Data Marts,
• unterschiedliche Data Warehouses,
• Feature Stores und Sandboxes für Data Science und
• Self-Service-Analyse-Sandboxes für Abteilungen.

Angesichts der Vielfalt der Anwendungsfälle können für verschiedene Projekte auf einem Lakehouse unterschiedliche Datenorganisationsprinzipien und Modellierungstechniken gelten. Technisch gesehen kann die Databricks Lakehouse Platform viele verschiedene Datenmodellierungsstile unterstützen. In diesem Artikel möchten wir die Implementierung der Datenorganisationsprinzipien Bronze/Silver/Gold des Lakehouse erläutern und wie verschiedene Datenmodellierungstechniken in jede Schicht passen.

Was ist ein Data Vault?

Ein Data Vault ist ein neueres Datenmodellierungsdesignmuster, das zum Aufbau von Data Warehouses für unternehmensweite Analysen verwendet wird, verglichen mit den Kimball- und Inmon-Methoden.

Data Vaults organisieren Daten in drei verschiedene Typen: Hubs, Links und Satellites. Hubs repräsentieren Kerngeschäftsentitäten, Links repräsentieren Beziehungen zwischen Hubs und Satellites speichern Attribute über Hubs oder Links.

Data Vault konzentriert sich auf agile Data Warehouse-Entwicklung, bei der Skalierbarkeit, Datenintegration/ETL und Entwicklungsgeschwindigkeit wichtig sind. Die meisten Kunden haben eine Landing Zone, eine Vault Zone und eine Data Mart Zone, die den Databricks-Organisationsparadigmen der Bronze-, Silver- und Gold-Schichten entsprechen. Der Data Vault-Modellierungsstil mit Hub-, Link- und Satellite-Tabellen passt typischerweise gut in die Silver-Schicht des Databricks Lakehouse.

Erfahren Sie mehr über Data Vault-Modellierung bei der Data Vault Alliance.

Was ist Dimensional Modeling?

Dimensional Modeling ist ein Bottom-up-Ansatz zur Gestaltung von Data Warehouses, um sie für Analysen zu optimieren. Dimensionale Modelle werden verwendet, um Geschäftsdaten in Dimensionen (wie Zeit und Produkt) und Fakten (wie Transaktionen in Beträgen und Mengen) zu denormalisieren, und verschiedene Themenbereiche werden über konforme Dimensionen verbunden, um zu verschiedenen Faktentabellen zu navigieren.

Die gebräuchlichste Form des Dimensional Modeling ist das Sternschema. Ein Sternschema ist ein multidimensionales Datenmodell, das zur Organisation von Daten verwendet wird, damit es leicht zu verstehen und zu analysieren ist und sehr einfach und intuitiv Berichte darüber zu erstellen sind. Kimball-artige Sternschemata oder dimensionale Modelle sind so ziemlich der Goldstandard für die Präsentationsschicht in Data Warehouses und Data Marts sowie für semantische und Berichterstattungsschichten. Das Sternschema-Design ist für die Abfrage großer Datensätze optimiert.

Sowohl normalisierte Data Vault (schreiboptimierte) als auch denormalisierte dimensionale Modelle (leseoptimierte) Datenmodellierungsstile haben ihren Platz im Databricks Lakehouse. Die Hubs und Satellites des Data Vault in der Silver-Schicht werden verwendet, um die Dimensionen im Sternschema zu laden, und die Link-Tabellen des Data Vault werden zu den Schlüsseltreiber-Tabellen für das Laden der Faktentabellen im dimensionalen Modell. Erfahren Sie mehr über Dimensional Modeling von der Kimball Group.

Datenorganisationsprinzipien in jeder Schicht des Lakehouse

Ein modernes Lakehouse ist eine allumfassende Datenplattform für Unternehmen. Es ist hochgradig skalierbar und leistungsfähig für alle Arten von verschiedenen Anwendungsfällen wie ETL, BI, Data Science und Streaming, die unterschiedliche Datenmodellierungsansätze erfordern können. Sehen wir uns an, wie ein typisches Lakehouse organisiert ist:

Bronze-Schicht — die Landing Zone

In der Bronze-Schicht landen wir alle Daten aus Quellsystemen. Die Tabellenstrukturen in dieser Schicht entsprechen den Tabellenstrukturen des Quellsystems "as-is", abgesehen von optionalen Metadatenspalten, die hinzugefügt werden können, um das Ladedatum/-zeit, die Prozess-ID usw. zu erfassen. Der Fokus in dieser Schicht liegt auf Change Data Capture (CDC) und der Fähigkeit, ein historisches Archiv von Quelldaten (Cold Storage), Datenherkunft, Auditierbarkeit und Wiederverarbeitung bei Bedarf bereitzustellen – ohne die Daten erneut aus dem Quellsystem lesen zu müssen.

In den meisten Fällen ist es eine gute Idee, die Daten in der Bronze-Schicht im Delta-Format zu belassen, damit nachfolgende Lesevorgänge aus der Bronze-Schicht für ETL performant sind – und damit Sie Updates in Bronze durchführen können, um CDC-Änderungen zu schreiben. Manchmal, wenn Daten im JSON- oder XML-Format ankommen, sehen wir Kunden, die sie im ursprünglichen Datenformat des Quellsystems landen und sie dann durch Umwandlung in das Delta-Format stagen. Manchmal sehen wir also Kunden, die die logische Bronze-Schicht in eine physische Landing- und Staging-Zone manifestieren.

Das Speichern von Rohdaten im ursprünglichen Datenformat des Quellsystems in einer Landing Zone hilft auch bei der Konsistenz, wenn Sie Daten über Ingestion-Tools aufnehmen, die Delta nicht als native Senke unterstützen oder wenn Quellsysteme Daten direkt auf Objektspeicher schreiben. Dieses Muster passt auch gut zum AutoLoader-Ingestion-Framework, bei dem Quellen die Daten in der Landing Zone für Rohdateien landen und dann Databricks AutoLoader die Daten in die Staging-Schicht im Delta-Format konvertiert.

Silver-Schicht — das zentrale Unternehmensrepository

In der Silver-Schicht des Lakehouse werden die Daten aus der Bronze-Schicht abgeglichen, zusammengeführt, konsolidiert und bereinigt ("gerade genug"), sodass die Silver-Schicht eine "Unternehmensansicht" aller wichtigen Geschäftsentitäten, Konzepte und Transaktionen bereitstellen kann. Dies ähnelt einem Enterprise Operational Data Store (ODS) oder einem zentralen Repository oder Datenbereichen eines Data Mesh (z. B. Stammdaten für Kunden, Produkte, nicht duplizierte Transaktionen und Referenztabellen). Diese Unternehmensansicht bringt die Daten aus verschiedenen Quellen zusammen und ermöglicht Self-Service-Analysen für Ad-hoc-Berichte, fortgeschrittene Analysen und ML. Sie dient auch als Quelle für Abteilungsanalysten, Data Engineers und Data Scientists, um weitere Datenprojekte und Analysen zu erstellen, um Geschäftsprobleme über unternehmensweite und abteilungsweite Datenprojekte in der Gold-Schicht zu lösen.

Im Lakehouse Data Engineering-Paradigma wird typischerweise die ELT-Methodik (Extract-Load-Transform) im Gegensatz zum traditionellen Extract-Transform-Load (ETL) verfolgt. Der ELT-Ansatz bedeutet, dass nur minimale oder "gerade genug" Transformationen und Datenbereinigungsregeln beim Laden der Silver-Schicht angewendet werden. Alle "unternehmensweiten" Regeln werden in der Silver-Schicht angewendet, im Gegensatz zu projektspezifischen Transformationsregeln, die in der Gold-Schicht angewendet werden. Geschwindigkeit und Agilität bei der Aufnahme und Bereitstellung der Daten im Lakehouse werden hier priorisiert.

Aus Sicht des Datenmodellings hat die Silver-Schicht eher 3rd-Normal-Form-ähnliche Datenmodelle. Schreiboptimierte Datenarchitekturen und Datenmodelle im Data Vault-Stil können in dieser Schicht verwendet werden. Wenn eine Data Vault-Methodik verwendet wird, passen sowohl der rohe Data Vault als auch der Business Vault in die logische Silver-Schicht des Lakehouse – und die Point-In-Time (PIT) Präsentationsansichten oder Materialized Views werden in der Gold-Schicht präsentiert.

Gold-Schicht — die Präsentationsschicht

In der Gold-Schicht können mehrere Data Marts oder Data Warehouses gemäß der Dimensional Modeling/Kimball-Methodik erstellt werden. Wie bereits erwähnt, ist die Gold-Schicht für die Berichterstattung und verwendet eher denormalisierte und leseoptimierte Datenmodelle mit weniger Joins im Vergleich zur Silver-Schicht. Manchmal können Tabellen in der Gold-Schicht vollständig denormalisiert sein, typischerweise wenn die Data Scientists dies für das Feature Engineering ihrer Algorithmen wünschen.

ETL- und Data-Quality-Regeln, die „projektspezifisch“ sind, werden bei der Transformation von Daten aus der Silver-Schicht in die Gold-Schicht angewendet. Finale Präsentationsschichten wie Data Warehouses, Data Marts oder Datenprodukte wie Kundenanalysen, Produkt-/Qualitätsanalysen, Bestandsanalysen, Kundensegmentierung, Produktempfehlungen, Marketing-/Vertriebsanalysen usw. werden in dieser Schicht bereitgestellt. Kimball-Style-Star-Schema-basierte Datenmodelle oder Inmon-Style-Data-Marts passen in diese Gold-Schicht des Lakehouse. Data Science Laboratories und Departmental Sandboxes für Self-Service-Analysen gehören ebenfalls zur Gold-Schicht.

Das Lakehouse Data Organization Paradigm

Zusammenfassend lässt sich sagen, dass Daten kuratiert werden, während sie sich durch die verschiedenen Schichten eines Lakehouse bewegen.

• Die Bronze-Schicht verwendet die Datenmodelle der Quellsysteme. Wenn Daten in Rohformaten landen, werden sie in dieser Schicht in das Delta Lake-Format konvertiert.
• Die Silver-Schicht bringt die Daten aus verschiedenen Quellen zum ersten Mal zusammen und gleicht sie ab, um eine Enterprise-Sicht auf die Daten zu erstellen – typischerweise unter Verwendung von stärker normalisierten, schreiboptimierten Datenmodellen, die typischerweise 3rd-Normalform-ähnlich oder Data-Vault-ähnlich sind.
• Die Gold-Schicht ist die Präsentationsschicht mit stärker denormalisierten oder abgeflachten Datenmodellen als die Silver-Schicht, typischerweise unter Verwendung von Kimball-Style-Dimensional-Modellen oder Sternschemata. Die Gold-Schicht beherbergt auch Abteilungs- und Data-Science-Sandboxes, um Self-Service-Analysen und Data Science im gesamten Unternehmen zu ermöglichen. Die Bereitstellung dieser Sandboxes und ihrer eigenen separaten Compute-Cluster verhindert, dass die Business-Teams ihre eigenen Datenkopien außerhalb des Lakehouse erstellen.

Dieser Lakehouse-Datenorganisationsansatz soll Datensilos aufbrechen, Teams zusammenbringen und sie befähigen, ETL, Streaming und BI und AI auf einer Plattform mit entsprechender Governance durchzuführen. Zentrale Datenteams sollten die Wegbereiter für Innovationen im Unternehmen sein, die Einarbeitung neuer Self-Service-Benutzer beschleunigen und die Entwicklung vieler Datenprojekte parallel vorantreiben – anstatt dass der Datenmodellierungsprozess zum Engpass wird. Das Databricks Unity Catalog bietet Suche & Discovery, Governance und Lineage auf dem Lakehouse, um eine gute Data-Governance-Kadenz sicherzustellen.

Erstellen Sie noch heute Ihre Data Vaults und Star-Schema-Data-Warehouses mit Databricks SQL.

Weiterführende Lektüre:

• Fünf einfache Schritte zur Implementierung eines Sternschemas in Databricks mit Delta Lake
• Bewährte Vorgehensweisen zur Implementierung eines Data-Vault-Modells auf der Databricks Lakehouse-Plattform
• Best Practices für Dimensional Modeling & Implementierung auf Modern Lakehouse
• Identity Columns zur Generierung von Surrogat-Schlüsseln sind jetzt in einem Lakehouse in Ihrer Nähe verfügbar!
• Laden Sie ein EDW-Dimensional-Modell in Echtzeit mit Databricks Lakehouse

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag