Släpp eller ersätt en tabell

Azure Databricks har stöd för SQL-standard-DDL-kommandon för att släppa och ersätta tabeller som registrerats med antingen Unity Catalog eller Hive-metaarkivet. Beteendet släpp och ersätt skiljer sig åt beroende på tabelltyp och metaarkiv. Välj rätt kommando för att undvika dataförlust eller samtidiga åtgärdsfel.

När du ska ta bort en tabell

Databricks rekommenderar att du använder DROP TABLE för att ta bort en tabell från metaarkivet när du vill ta bort tabellen permanent och inte har för avsikt att skapa en ny tabell på samma plats. Ett exempel:

DROP TABLE table_name

DROP TABLE har olika beteenden beroende på typen av tabell och om tabellen är registrerad i Unity Catalog eller det äldre Hive-metaarkivet.

Tabelltyp	Metabutik	Behavior
Managed	Unity-katalog	Tabellen tas bort från metaarkivet och underliggande data markeras för borttagning. Du kan UNDROP en hanterad tabell inom den konfigurerade återställningsperioden (standardvärdet är 7 dagar). Se Ta bort en hanterad tabell.
Managed	Hive	Tabellen tas bort från metaarkivet och underliggande data tas bort.
Externt	Unity-katalog	Tabellen tas bort från metaarkivet men underliggande data finns kvar. URI-åtkomstbehörigheter styrs nu av den externa plats som innehåller data.
Externt	Hive	Tabellen tas bort från metaarkivet men underliggande data finns kvar. Alla URI-åtkomstbehörigheter är oförändrade.

Unity Catalog har en historik över tabeller med hjälp av ett internt tabell-ID. För alla tabelltyper har det tidigare registrerade tabellnamnet inte längre en aktiv länk till data- och tabellhistoriken från metaarkivet när släppåtgärden har slutförts.

Se även DROP TABLE.

Note

Databricks rekommenderar inte att du släpper och sedan återskapar en tabell med samma namn för produktionspipelines eller system eftersom detta kan resultera i oväntade resultat för samtidiga åtgärder. Se Ersätt data med samtidiga åtgärder.

När du ska ersätta en tabell

Databricks rekommenderar att du använder CREATE OR REPLACE TABLE instruktioner för användningsfall där du helt vill skriva över måltabellen med nya data. Om du till exempel vill skriva över en tabell med alla data från en Parquet-katalog kör du följande kommando:

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

CREATE OR REPLACE TABLE har samma semantik oavsett tabelltyp eller metaarkiv som används. Följande är viktiga fördelar med CREATE OR REPLACE TABLE:

• Tabellinnehåll ersätts, men tabellidentiteten behålls.
• Tabellhistoriken behålls och du kan återställa tabellen till en tidigare version med RESTORE kommandot .
• Åtgärden är en enskild transaktion, så det finns aldrig en tid när tabellen inte finns.
• Samtidiga förfrågningar som läser från tabellen kan fortsätta utan avbrott. Eftersom versionen före och efter ersättningen fortfarande finns i tabellhistoriken kan samtidiga frågor referera till någon av tabellernas version efter behov.
• Om den ursprungliga tabellen innehåller kolumnmasker behålls dessa masker för alla kolumner som fortfarande finns i den nya tabellen. Detta säkerställer att dataåtkomstprinciper bevaras.

Se CREATE TABLE [ANVÄNDA].

Ersätt data med samtidiga åtgärder

När du vill utföra en fullständig ersättning av data i en tabell som kan användas i samtidiga åtgärder måste du använda CREATE OR REPLACE TABLE.

Du bör inte använda följande antimönster:

DROP TABLE IF EXISTS table_name;

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

För alla tabelltyper, oavsett om du använder Unity Catalog eller inte, kan det här mönstret resultera i ett fel, borttagna poster eller skadade resultat.

I stället rekommenderar Databricks att alltid använda CREATE OR REPLACE TABLE, som i följande exempel:

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

Eftersom atomisk ersättning bevarar tabellhistoriken kan samtidiga transaktioner verifiera den version av källtabellen som de refererar till och misslyckas eller stämma av samtidiga transaktioner utan oväntat beteende.