Primärschlüssel- und Fremdschlüsselbeschränkungen sind allgemein verfügbar und ermöglichen jetzt schnellere Abfragen

Dataricks freut sich, die allgemeine Verfügbarkeit (General Availability, GA) von Primärschlüssel- (Primary Key, PK) und Fremdschlüssel-Constraints (Foreign Key, FK) ab Databricks Runtime 15.2 und Databricks SQL 2024.30 bekannt zu geben. Diese Version folgt auf eine sehr erfolgreiche öffentliche Vorschauversion, die von Hunderten von wöchentlich aktiven Kunden genutzt wurde, und stellt einen bedeutenden Meilenstein bei der Verbesserung der Datenintegrität und des relationalen Datenmanagements innerhalb des Lakehouse dar.

Darüber hinaus kann Databricks diese Constraints jetzt verwenden, um Abfragen zu optimieren und unnötige Operationen aus dem Abfrageplan zu entfernen, was zu einer deutlich schnelleren Leistung führt.

Primärschlüssel- und Fremdschlüssel-Constraints

Primärschlüssel (PKs) und Fremdschlüssel (FKs) sind wesentliche Elemente in relationalen Datenbanken und fungieren als grundlegende Bausteine für die Datenmodellierung. Sie liefern Informationen über die Datenbeziehungen im Schema für Benutzer, Tools und Anwendungen und ermöglichen Optimierungen, die Constraints nutzen, um Abfragen zu beschleunigen. Primär- und Fremdschlüssel sind jetzt allgemein für Ihre Delta Lake-Tabellen verfügbar, die in Unity Catalog gehostet werden.

SQL-Sprache

Sie können Constraints definieren, wenn Sie eine Tabelle erstellen:

Im obigen Beispiel definieren wir einen Primärschlüssel-Constraint für die Spalte UserID. Databricks unterstützt auch Constraints für Spaltengruppen.

Sie können auch vorhandene Delta-Tabellen ändern, um Constraints hinzuzufügen oder zu entfernen:

Hier erstellen wir den Primärschlüssel namens products_pk für die Spalte ProductID (die keine Nullwerte zulässt) in einer vorhandenen Tabelle. Um diesen Vorgang erfolgreich auszuführen, müssen Sie der Besitzer der Tabelle sein. Beachten Sie, dass Constraint-Namen innerhalb des Schemas eindeutig sein müssen.
Der nachfolgende Befehl entfernt den Primärschlüssel, indem der Name angegeben wird.

Der gleiche Prozess gilt für Fremdschlüssel. Die folgende Tabelle definiert zwei Fremdschlüssel zum Zeitpunkt der Tabellenerstellung:

Weitere Informationen zur Syntax und zu Operationen im Zusammenhang mit Constraints finden Sie in der Dokumentation zu CREATE TABLE- und ALTER TABLE-Anweisungen.

Primärschlüssel- und Fremdschlüssel-Constraints werden in der Databricks-Engine nicht erzwungen, können aber nützlich sein, um eine Datenintegritätsbeziehung anzugeben, die gelten soll. Databricks kann stattdessen Primärschlüssel-Constraints im Upstream als Teil der Erfassungspipeline erzwingen. Weitere Informationen zu erzwungenen Constraints finden Sie unter Verwaltete Datenqualität mit Delta Live Tables. Databricks unterstützt auch erzwungene NOT NULL- und CHECK-Constraints (weitere Informationen finden Sie in der Constraints-Dokumentation).

Partner-Ökosystem

Tools und Anwendungen wie die neueste Version von Tableau und PowerBI können Ihre Primärschlüssel- und Fremdschlüsselbeziehungen automatisch von Databricks über JDBC- und ODBC-Konnektoren importieren und nutzen.

Anzeigen der Constraints

Es gibt verschiedene Möglichkeiten, die in der Tabelle definierten Primärschlüssel- und Fremdschlüssel-Constraints anzuzeigen. Sie können auch einfach SQL-Befehle verwenden, um Constraint-Informationen mit dem Befehl DESCRIBE TABLE EXTENDED anzuzeigen:

Catalog Explorer und Entity-Relationship-Diagramm

Sie können die Constraint-Informationen auch über den Catalog Explorer anzeigen:

Jede Primärschlüssel- und Fremdschlüsselspalte hat ein kleines Schlüsselsymbol neben ihrem Namen.

Und Sie können die Primär- und Fremdschlüsselinformationen und die Beziehungen zwischen Tabellen mit dem Entity-Relationship-Diagramm im Catalog Explorer visualisieren. Unten ist ein Beispiel für eine Tabelle purchases, die auf zwei Tabellen verweist, users und products:

INFORMATION SCHEMA

Die folgenden INFORMATION_SCHEMA-Tabellen enthalten ebenfalls Constraint-Informationen:

• TABLE_CONSTRAINTS: Beschreibt Metadaten für alle Primärschlüssel- und Fremdschlüssel-Constraints innerhalb des Katalogs.
• KEY_COLUMN_USAGE: Listet die Spalten der Primärschlüssel- oder Fremdschlüssel-Constraints innerhalb des Katalogs auf.
• CONSTRAINT_TABLE_USAGE: Beschreibt die Constraints, die auf Tabellen im Katalog verweisen.
• CONSTRAINT_COLUMN_USAGE: Beschreibt die Constraints, die auf Spalten im Katalog verweisen.
• REFERENTIAL_CONSTRAINTS: Beschreibt referenzielle (Fremdschlüssel-) Constraints, die im Katalog definiert sind.

Verwenden Sie die Option RELY, um Optimierungen zu aktivieren

Wenn Sie wissen, dass der Primärschlüssel-Constraint gültig ist (z. B. weil Ihre Datenpipeline oder Ihr ETL-Job ihn erzwingt), können Sie Optimierungen basierend auf dem Constraint aktivieren, indem Sie ihn mit der Option RELY angeben, wie folgt:

Die Verwendung der Option RELY ermöglicht es Databricks, Abfragen auf eine Weise zu optimieren, die von der Gültigkeit des Constraints abhängt, da Sie garantieren, dass die Datenintegrität gewahrt bleibt. Seien Sie hier vorsichtig, denn wenn ein Constraint als RELY gekennzeichnet ist, die Daten aber gegen den Constraint verstoßen, können Ihre Abfragen falsche Ergebnisse zurückgeben.

Wenn Sie die Option RELY für einen Constraint nicht angeben, ist der Standardwert NORELY. In diesem Fall können Constraints weiterhin für Informations- oder Statistikzwecke verwendet werden, aber Abfragen verlassen sich nicht darauf, um korrekt ausgeführt zu werden.

Die Option RELY und die Optimierungen, die sie nutzen, sind derzeit für Primärschlüssel verfügbar und werden in Kürze auch für Fremdschlüssel verfügbar sein.

Sie können den Primärschlüssel einer Tabelle ändern, um zu ändern, ob er RELY oder NORELY ist, indem Sie ALTER TABLE verwenden, zum Beispiel:

Beschleunigen Sie Ihre Abfragen, indem Sie unnötige Aggregationen eliminieren

Eine einfache Optimierung, die wir mit RELY-Primärschlüssel-Constraints durchführen können, ist die Eliminierung unnötiger Aggregationen. Zum Beispiel in einer Abfrage, die eine Distinct-Operation auf eine Tabelle mit einem Primärschlüssel anwendet, der RELY verwendet:

Wir können die unnötige DISTINCT-Operation entfernen:

Wie Sie sehen, stützt sich diese Abfrage auf die Gültigkeit des RELY-Primärschlüssel-Constraints - wenn es doppelte Kunden-IDs in der Kundentabelle gibt, gibt die transformierte Abfrage falsche doppelte Ergebnisse zurück. Sie sind für die Durchsetzung der Gültigkeit des Constraints verantwortlich, wenn Sie die Option RELY festlegen.

Wenn der Primärschlüssel NORELY ist (der Standardwert), entfernt der Optimierer die DISTINCT-Operation nicht aus der Abfrage. Dann läuft sie möglicherweise langsamer, gibt aber immer korrekte Ergebnisse zurück, auch wenn es Duplikate gibt. Wenn der Primärschlüssel RELY ist, kann Databricks die DISTINCT-Operation entfernen, was die Abfrage erheblich beschleunigen kann - um etwa das 2-fache für das obige Beispiel.

Beschleunigen Sie Ihre Abfragen, indem Sie unnötige Joins eliminieren

Eine weitere sehr nützliche Optimierung, die wir mit RELY-Primärschlüsseln durchführen können, ist die Eliminierung unnötiger Joins. Wenn eine Abfrage eine Tabelle joint, die nirgendwo referenziert wird, außer in der Join-Bedingung, kann der Optimierer feststellen, dass der Join unnötig ist, und den Join aus dem Abfrageplan entfernen.

Um ein Beispiel zu geben, nehmen wir an, wir haben eine Abfrage, die zwei Tabellen joint, store_sales und customer, gejoint auf dem Primärschlüssel der Kundentabelle PRIMARY KEY (c_customer_sk) RELY.

Wenn wir den Primärschlüssel nicht hätten, könnte jede Zeile von store_sales potenziell mit mehreren Zeilen in customer übereinstimmen, und wir müssten den Join ausführen, um den korrekten SUM-Wert zu berechnen. Da die Tabelle customer aber auf ihrem Primärschlüssel gejoint wird, wissen wir, dass der Join für jede Zeile von store_sales eine Zeile ausgibt.

Die Abfrage benötigt also eigentlich nur die Spalte ss_quantity aus der Faktentabelle store_sales. Daher kann der Abfrageoptimierer den Join vollständig aus der Abfrage eliminieren und sie in Folgendes umwandeln:

Dies läuft viel schneller, da der gesamte Join vermieden wird - in diesem Beispiel beobachten wir, dass die Optimierung die Abfrage von 1,5 Minuten auf 6 Sekunden beschleunigt!. Und die Vorteile können noch größer sein, wenn der Join viele Tabellen umfasst, die eliminiert werden können!

Sie fragen sich vielleicht, warum jemand eine solche Abfrage ausführen sollte? Das ist eigentlich viel häufiger, als Sie vielleicht denken! Ein häufiger Grund ist, dass Benutzer Sichten erstellen, die mehrere Tabellen miteinander verbinden, z. B. viele Fakten- und Dimensionstabellen. Sie schreiben Abfragen über diese Sichten, die oft Spalten aus nur einigen der Tabellen verwenden, nicht aus allen - und so kann der Optimierer die Joins gegen die Tabellen eliminieren, die in jeder Abfrage nicht benötigt werden. Dieses Muster ist auch in vielen Business Intelligence (BI)-Tools üblich, die oft Abfragen generieren, die viele Tabellen in einem Schema verbinden, selbst wenn eine Abfrage nur Spalten aus einigen der Tabellen verwendet.

Fazit

Seit der öffentlichen Vorschau haben über 2600 + Databricks-Kunden Primärschlüssel- und Fremdschlüssel-Constraints verwendet. Heute freuen wir uns, die allgemeine Verfügbarkeit dieser Funktion bekannt zu geben, die einen neuen Schritt in unserem Engagement zur Verbesserung des Datenmanagements und der Datenintegrität in Databricks darstellt.

Darüber hinaus nutzt Databricks jetzt Schlüssel-Constraints mit der Option RELY, um Abfragen zu optimieren, z. B. durch die Eliminierung unnötiger Aggregationen und Joins, was zu einer deutlich schnelleren Abfrageleistung führt.

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