Удаление или замена таблицы Delta

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

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

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

DROP TABLE table_name

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

Тип таблицы	Хранилище мета-данных	Поведение
Управляется	Каталог Unity	Таблица удаляется из хранилища метаданных, а базовые данные помечены для удаления. Данные можно UNDROP в управляемых таблицах каталога Unity в течение 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 [ИСПОЛЬЗОВАНИЕ].

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

Всякий раз, когда вы хотите выполнить полную замену данных в таблице, которая может использоваться в параллельных операциях, необходимо использовать 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`

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