Datenmodellierung

In diesem Artikel werden Überlegungen, Einschränkungen und Empfehlungen für die Datenmodellierung in Azure Databricks vorgestellt. Er richtet sich an Benutzerinnen und Benutzer, die neue Tabellen einrichten oder ETL-Workloads erstellen. Der Schwerpunkt liegt auf dem Verständnis von Azure Databricks-Verhaltensweisen, die Einfluss auf das Transformieren von Rohdaten in ein neues Datenmodell haben. Die Entscheidungen zur Datenmodellierung hängen davon ab, wie Tabellen in Ihrer Organisation und von Ihren Workloads verwendet werden. Das von Ihnen ausgewählte Datenmodell wirkt sich auf die Abfrageleistung und die Compute- und Speicherkosten aus. Dazu gehört eine Einführung in die grundlegenden Konzepte des Datenbankentwurfs mit Azure Databricks.

Wichtig

Dieser Artikel bezieht sich ausschließlich auf Tabellen auf Basis von Delta Lake, einschließlich aller verwalteten Tabellen in Unity Catalog.

Sie können Azure Databricks verwenden, um andere externe Datenquellen abzufragen, einschließlich Tabellen, die im Lakehouse-Verbund registriert sind. Jede externe Datenquelle weist spezifische Einschränkungen, eine eigene Semantik und gesonderte Transaktionsgarantien auf. Siehe Abfragedaten.

Konzepte der Datenverwaltung

Ein mit Azure Databricks erstelltes Lakehouse teilt viele Komponenten und Konzepte mit anderen Data Warehousing-Systemen des Unternehmens. Berücksichtigen Sie beim Entwerfen Ihres Datenmodells die folgenden Konzepte und Features.

Transaktionen in Azure Databricks

In Azure Databricks sind Transaktionen auf einzelne Tabellen beschränkt. Dies bedeutet, dass Azure Databricks keine Anweisungen für mehrere Tabellen unterstützt (auch als Transaktionen mit mehreren Anweisungen bezeichnet).

Für Workloads zur Datenmodellierung bedeutet dies, dass beim Erfassen eines Quelldatensatzes mehrere unabhängige Transaktionen ausgeführt werden müssen, um Zeilen in zwei oder mehr Tabellen einzufügen oder zu aktualisieren. Jede dieser Transaktionen kann unabhängig von anderen Transaktionen erfolgreich oder mit Fehlern abgeschlossen werden, und nachfolgende Abfragen müssen aufgrund fehlerhafter oder verzögerter Transaktionen tolerant gegenüber Zustandskonflikten sein.

Primär- und Fremdschlüssel in Azure Databricks

Primär- und Fremdschlüssel sind rein informativ und werden nicht erzwungen. Dieses Modell ist in vielen cloudbasierten Datenbanksystemen auf Unternehmensniveau üblich, unterscheidet sich jedoch von vielen herkömmlichen relationalen Datenbanksystemen. Weitere Informationen finden Sie unter Einschränkungen bei Azure Databricks.

Joins in Azure Databricks

Joins können in jedem Datenbankentwurf zu Verarbeitungsengpässen führen. Bei der Verarbeitung von Daten in Azure Databricks versucht der Abfrageoptimierer, den Plan für Joins zu optimieren. Dies kann jedoch schwierig sein, wenn eine einzelne Abfrage Ergebnisse aus vielen Tabellen verknüpfen muss. Der Optimierer kann auch daran scheitern, Datensätze in einer Tabelle zu überspringen, wenn sich Filterparameter in einem Feld in einer anderen Tabelle befinden, sodass eine vollständige Tabellenüberprüfung durchgeführt werden muss.

Weitere Informationen finden Sie unter Verwenden von Joins in Azure Databricks.

Hinweis

Sie können materialisierte Sichten verwenden, um die Ergebnisse für einige Joinvorgänge inkrementell zu berechnen. Einige Joins sind jedoch nicht mit materialisierten Sichten kompatibel. Siehe Materialisierte Ansichten.

Verwenden geschachtelter und komplexer Datentypen

Azure Databricks unterstützt die Verwendung teilweise strukturierter Datenquellen wie JSON, Avro und ProtoBuff sowie das Speichern komplexer Daten als Strukturen, JSON-Zeichenfolgen, Zuordnungen und Arrays. Weitere Informationen finden Sie unter Modellieren teilweise strukturierter Daten.

Normalisierte Datenmodelle

Azure Databricks funktioniert gut mit jedem Typ von Datenmodell. Wenn Sie ein vorhandenes Datenmodell abfragen oder zu Azure Databricks migrieren möchten, sollten Sie vor dem Ändern der Architektur Ihrer Daten die Leistung bewerten.

Wenn Sie ein neues Lakehouse entwerfen oder einer vorhandenen Umgebung Datasets hinzufügen, empfiehlt Azure Databricks, ein streng normalisiertes Modell wie 3NF (Third Normal Form) zu verwenden.

Modelle wie das Sternschema oder das Schneeflockenschema funktionieren in Azure Databricks gut, da in Standardabfragen weniger Joins enthalten sind und weniger Schlüssel synchronisiert werden müssen. Darüber hinaus ermöglicht das Verwenden einer höheren Anzahl von Datenfeldern in einer einzelnen Tabelle dem Abfrageoptimierer, große Datenmengen mithilfe von Statistiken auf Dateiebene zu überspringen. Weitere Informationen zum Überspringen von Daten finden Sie unter Überspringen von Daten für Delta Lake.