Delen via

Een Delta-tabel verwijderen of vervangen

  • Artikel

Azure Databricks ondersteunt SQL-standaard DDL-opdrachten voor het verwijderen en vervangen van tabellen die zijn geregistreerd met Unity Catalog of de Hive-metastore. Dit artikel bevat voorbeelden van het verwijderen en vervangen van Delta-tabellen en aanbevelingen voor syntaxis, afhankelijk van uw geconfigureerde omgeving en het gewenste resultaat.

Wanneer een tabel neer te zetten

U moet DROP TABLE een tabel verwijderen uit de metastore wanneer u de tabel permanent wilt verwijderen en geen intentie hebt om een nieuwe tabel op dezelfde locatie te maken. Voorbeeld:

DROP TABLE table_name

DROP TABLE heeft verschillende semantiek, afhankelijk van het type tabel en of de tabel is geregistreerd bij Unity Catalog of de verouderde Hive-metastore.

Tabeltype Metastore Gedrag
Beheerd Unity-catalogus De tabel wordt verwijderd uit de metastore en onderliggende gegevens worden gemarkeerd voor verwijdering. U kunt UNDROP gedurende 7 dagen gegevens in beheerde tabellen in Unity Catalog gebruiken.
Beheerd Hive De tabel wordt verwijderd uit de metastore en de onderliggende gegevens worden verwijderd.
External Unity-catalogus De tabel wordt verwijderd uit de metastore, maar de onderliggende gegevens blijven behouden. URI-toegangsbevoegdheden worden nu beheerd door de externe locatie die de gegevens bevat.
External Hive De tabel wordt verwijderd uit de metastore, maar de onderliggende gegevens blijven behouden. Alle URI-toegangsbevoegdheden zijn ongewijzigd.

DROP TABLE semantiek verschilt tussen tabeltypen en Unity Catalog onderhoudt een geschiedenis van Delta-tabellen met behulp van een interne tabel-id. Alle tabellen delen echter het algemene resultaat dat nadat de bewerking is voltooid, de eerder geregistreerde tabelnaam geen actieve koppeling meer heeft naar gegevens en tabelgeschiedenis uit de metastore.

Zie DROP TABLE.

Notitie

Databricks raadt het verwijderen van een tabel niet aan en maakt vervolgens een tabel opnieuw met dezelfde naam voor productiepijplijnen of -systemen, omdat dit patroon onverwachte resultaten kan opleveren voor gelijktijdige bewerkingen. Zie Gegevens vervangen door gelijktijdige bewerkingen.

Wanneer een tabel moet worden vervangen

Databricks raadt het gebruik van CREATE OR REPLACE TABLE instructies aan voor use cases waarin u de doeltabel volledig wilt overschrijven met nieuwe gegevens. Als u bijvoorbeeld een Delta-tabel wilt overschrijven met alle gegevens uit een Parquet-map, kunt u de volgende opdracht uitvoeren:

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

CREATE OR REPLACE TABLE heeft dezelfde semantiek, ongeacht het tabeltype of metastore dat wordt gebruikt. Het volgende zijn belangrijke voordelen van CREATE OR REPLACE TABLE:

  • De inhoud van de tabel wordt vervangen, maar de tabelidentiteit blijft behouden.
  • De tabelgeschiedenis wordt bewaard en u kunt de tabel terugzetten naar een eerdere versie met de RESTORE opdracht.
  • De bewerking is één transactie, dus er is nooit een tijdstip waarop de tabel niet bestaat.
  • Gelijktijdige query's die uit de tabel worden gelezen, kunnen zonder onderbreking worden voortgezet. Omdat de versie vóór en na vervanging nog steeds bestaat in de tabelgeschiedenis, kunnen gelijktijdige query's zo nodig verwijzen naar een van beide versies van de tabel.

Zie CREATE TABLE [USING].

Gegevens vervangen door gelijktijdige bewerkingen

Wanneer u een volledige vervanging wilt uitvoeren van gegevens in een tabel die kan worden gebruikt in gelijktijdige bewerkingen, moet u gebruiken CREATE OR REPLACE TABLE.

Het volgende antipatroon mag niet worden gebruikt:

-- 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`;

De redenen voor deze aanbeveling variëren, afhankelijk van of u beheerde of externe tabellen gebruikt en of u Unity Catalog gebruikt, maar voor alle Delta-tabeltypen die dit patroon gebruiken, kan dit leiden tot een fout, verwijderde records of beschadigde resultaten.

In plaats daarvan raadt Databricks aan altijd gebruik te maken CREATE OR REPLACE TABLE, zoals in het volgende voorbeeld:

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

Omdat de tabelgeschiedenis wordt bijgehouden tijdens de vervanging van atomische gegevens, kunnen gelijktijdige transacties de versie van de brontabel valideren waarnaar wordt verwezen en daarom indien nodig mislukken of gelijktijdige transacties afstemmen zonder onverwacht gedrag of resultaten te introduceren.