Share via


Löschen oder Ersetzen einer Delta-Tabelle

Azure Databricks unterstützt SQL-Standard-DDL-Befehle zum Löschen und Ersetzen von Tabellen, die entweder in Unity Catalog oder im Hive-Metastore registriert sind. In diesem Artikel finden Sie Beispiele für das Löschen und Ersetzen von Delta-Tabellen und Empfehlungen für die Syntax je nach konfigurierter Umgebung und gewünschtem Ergebnis.

Wann eine Tabelle gelöscht werden sollte

Sie sollten DROP TABLE verwenden, um eine Tabelle aus dem Metastore zu entfernen, wenn Sie die Tabelle endgültig löschen möchten und keine Absicht haben, eine neue Tabelle an demselben Speicherort zu erstellen. Beispiel:

DROP TABLE table_name

DROP TABLE weist je nach Tabellentyp unterschiedliche Semantik auf und gibt an, ob die Tabelle in Unity Catalog oder im älteren Hive-Metastore registriert ist.

Tabellentyp Metastore Verhalten
Verwaltet Unity Catalog Die Tabelle wird aus dem Metastore entfernt, und die zugrunde liegenden Daten werden zum Löschen markiert. Sie können Daten in verwalteten Unity Catalog-Tabellen 7 Tage lang UNDROP.
Verwaltet Hive Die Tabelle wird aus dem Metastore entfernt, und die zugrunde liegenden Daten werden gelöscht.
Extern Unity Catalog Die Tabelle wird aus dem Metastore entfernt, die zugrunde liegenden Daten bleiben jedoch erhalten. URI-Zugriffsberechtigungen unterliegen nun dem externen Speicherort, der die Daten enthält.
Extern Hive Die Tabelle wird aus dem Metastore entfernt, die zugrunde liegenden Daten bleiben jedoch erhalten. Alle URI-Zugriffsberechtigungen bleiben unverändert.

Die DROP TABLE-Semantik unterscheidet sich von Tabellentypen, und Unity Catalog verwaltet einen Verlauf von Delta-Tabellen mithilfe einer internen Tabellen-ID. Allen Tabellen ist jedoch gemein, dass nach Abschluss des Vorgangs der zuvor registrierte Tabellenname keine aktive Verknüpfung zum Verlauf der Daten und Tabellen aus dem Metastore mehr hat.

Siehe DROP TABLE.

Hinweis

Databricks empfiehlt für Produktionspipelines oder -systeme nicht das Muster, eine Tabelle zu löschen und dann unter demselben Namen erneut zu erstellen, da dieses Muster zu unerwarteten Ergebnissen bei gleichzeitigen Vorgängen führen kann. Siehe Ersetzen von Daten durch gleichzeitige Vorgänge.

Wann eine Tabelle ersetzt werden sollte

Databricks empfiehlt die Verwendung von CREATE OR REPLACE TABLE-Anweisungen für Anwendungsfälle, in denen Sie die Zieltabelle vollständig mit neuen Daten überschreiben möchten. Um beispielsweise eine Delta-Tabelle mit allen Daten aus einem Parkettverzeichnis zu überschreiben, können Sie den folgenden Befehl ausführen:

CREATE OR REPLACE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`

CREATE OR REPLACE TABLE hat die gleiche Semantik unabhängig vom verwendeten Tabellentyp oder Metastore. CREATE OR REPLACE TABLE hat die folgenden wichtigen Vorteile:

  • Tabelleninhalte werden ersetzt, die Tabellenidentität wird jedoch beibehalten.
  • Der Tabellenverlauf wird beibehalten, und Sie können die Tabelle mit dem RESTORE-Befehl auf eine frühere Version zurücksetzen.
  • Der Vorgang ist eine einzelne Transaktion, sodass die Tabelle zu keiner Zeit nicht vorhanden ist.
  • Das gleichzeitige Lesen von Abfragen aus der Tabelle kann ohne Unterbrechung fortgesetzt werden. Da die Version vor und nach dem Ersetzen weiterhin im Tabellenverlauf vorhanden ist, können gleichzeitige Abfragen bei Bedarf auf eine der beiden Versionen der Tabelle verweisen.

Weitere Informationen finden Sie unter CREATE TABLE [USING].

Ersetzen von Daten durch gleichzeitige Vorgänge

Wann immer Sie einen vollständigen Ersatz von Daten in einer Tabelle, die in gleichzeitigen Vorgängen verwendet werden kann, ausführen möchten, müssen Sie CREATE OR REPLACE TABLE verwenden.

Das folgende Antimuster sollte nicht verwendet werden:

-- This is an anti-pattern. Avoid doing this!
DROP TABLE IF EXISTS table_name;

CREATE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`;

Die Gründe für diese Empfehlung variieren je nachdem, ob Sie verwaltete oder externe Tabellen verwenden und ob Sie Unity Catalog verwenden oder nicht; aber in allen Delta-Tabellentypen, kann das Verwenden dieses Musters zu einem Fehler, verworfenen Datensätzen oder beschädigten Ergebnissen führen.

Stattdessen empfiehlt Databricks, immer CREATE OR REPLACE TABLE zu verwenden, wie im folgenden Beispiel:

CREATE OR REPLACE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`

Da der Tabellenverlauf während der atomischen Datenersetzung beibehalten wird, können gleichzeitige Transaktionen die Version der Quelltabelle, auf die verwiesen wird, überprüfen und daher fehlschlagen oder gleichzeitige Transaktionen bei Bedarf abgleichen, ohne dass es zu unerwartetem Verhalten oder unerwarteten Ergebnissen kommt.