Удаление или замена разностной таблицы

Azure Databricks поддерживает стандартные команды DDL SQL для удаления и замены таблиц, зарегистрированных в каталоге Unity или в хранилище метаданных Hive. В этой статье приведены примеры удаления и замены таблиц Delta и рекомендаций по синтаксису в зависимости от настроенной среды и требуемого результата.

Когда нужно удалить таблицу

Необходимо удалить DROP TABLE таблицу из хранилища метаданных, если вы хотите окончательно удалить таблицу и не намерены создавать новую таблицу в том же расположении. Например:

DROP TABLE table_name

DROP TABLE имеет разные семантики в зависимости от типа таблицы и того, зарегистрирована ли таблица в каталоге Unity или устаревшее хранилище метаданных Hive.

Тип таблицы	Хранилище мета-данных	Поведение
Управляется	Каталог Unity	Таблица удаляется из хранилища метаданных, а базовые данные помечены для удаления. Данные в управляемых таблицах каталога Unity можно использовать UNDROP в течение 7 дней.
Управляется	Куст	Таблица удаляется из хранилища метаданных, а базовые данные удаляются.
Внешняя.	Каталог Unity	Таблица удаляется из хранилища метаданных, но базовые данные остаются. Права доступа к URI теперь управляются внешним расположением, содержащими данные.
Внешняя.	Куст	Таблица удаляется из хранилища метаданных, но базовые данные остаются. Все привилегии доступа к URI не изменяются.

DROP TABLE семантика отличается между типами таблиц, а каталог Unity поддерживает журнал таблиц Delta с помощью внутреннего идентификатора таблицы. Однако все таблицы имеют общий результат, который после завершения операции ранее зарегистрированное имя таблицы больше не имеет активной связи с данными и журналом таблиц из хранилища метаданных.

См. раздел DROP TABLE.

Примечание.

Databricks не рекомендует шаблон удаления и последующего воссоздания таблицы с использованием того же имени для рабочих конвейеров или систем, так как этот шаблон может привести к непредвиденным результатам для параллельных операций. См. раздел "Замена данных параллельными операциями".

При замене таблицы

Databricks рекомендует использовать CREATE OR REPLACE TABLE инструкции для вариантов использования, в которых необходимо полностью перезаписать целевую таблицу новыми данными. Например, чтобы перезаписать таблицу Delta со всеми данными из каталога Parquet, можно выполнить следующую команду:

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

CREATE OR REPLACE TABLE имеет одинаковую семантику независимо от используемого типа таблицы или хранилища метаданных. Ниже приведены важные CREATE OR REPLACE TABLEпреимущества:

• Содержимое таблицы заменено, но сохраняется удостоверение таблицы.
• Журнал таблиц сохраняется, и вы можете вернуть таблицу в более раннюю версию с RESTORE помощью команды.
• Операция является одной транзакцией, поэтому никогда не существует времени, когда таблица не существует.
• Одновременные запросы, считывающие из таблицы, могут продолжаться без прерывания. Так как версия до и после замены по-прежнему существует в журнале таблиц, одновременные запросы могут ссылаться на любую версию таблицы по мере необходимости.

См. CREATE TABLE [USING].

Замена данных параллельными операциями

Всякий раз, когда вы хотите выполнить полную замену данных в таблице, которая может использоваться в параллельных операциях, необходимо использовать CREATE OR REPLACE TABLE.

Не следует использовать следующие антишаблоны:

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

Причины этой рекомендации зависят от того, используете ли вы управляемые или внешние таблицы и используете ли вы каталог Unity, но во всех типах таблиц Delta, использующих этот шаблон, может привести к ошибке, удаленным записям или поврежденным результатам.

Вместо этого Databricks рекомендует всегда использовать CREATE OR REPLACE TABLE, как показано в следующем примере:

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

Так как журнал таблиц сохраняется во время замены атомарных данных, параллельные транзакции могут проверять версию исходной таблицы, на которые ссылается ссылка, и, следовательно, завершаются сбоем или согласовывают одновременные транзакции при необходимости, не вводя непредвиденное поведение или результаты.