Клонирование таблицы в Azure Databricks

Вы можете создать копию существующей таблицы Delta Lake в Azure Databricks в определенной версии с помощью команды clone. Клоны могут быть либо глубокими, либо поверхностными.

Azure Databricks также поддерживает клонирование таблиц Parquet и Iceberg. См . добавочное клонирование таблиц Parquet и Iceberg в Delta Lake.

Дополнительные сведения об использовании клона с каталогом Unity см. в разделе "Мелкий клон" для таблиц каталога Unity.

Типы клонирования

• Глубокий клон — это клон, который копирует данные исходной таблицы в целевой объект клонирования в дополнение к метаданным существующей таблицы. Кроме того, клонируются метаданные потока таким образом, что поток, записывающий данные в таблицу Delta, может быть остановлен в исходной таблице и продолжаться на целевом объекте клонирования без перебоя.
• Поверхностный клон — это клон, который не копирует файлы данных в целевой объект клонирования. Метаданные таблицы эквивалентны исходным. Создание этих клонов менее затратно.

Клонируемые метаданные включают в себя: схему, сведения о секционировании, инварианты, допустимость значений NULL. Для глубоких клонов также клонируется поток и метаданные COPY INTO. Метаданные, которые не клонируются — описание таблицы и определяемые пользователем метаданные фиксации.

Что такое семантика операций клонирования Delta?

Если вы работаете с таблицей Delta, зарегистрированной в хранилище метаданных Hive или коллекцией файлов, не зарегистрированных в качестве таблицы, клон имеет следующую семантику:

• Любые изменения, вносимые в глубокие или поверхностные клоны, влияют только на сами клоны, а не исходную таблицу.
• Поверхностные клоны ссылаются на файлы данных в исходном каталоге. Если вы запускаете vacuum исходную таблицу, клиенты больше не смогут считывать файлы данных, на которые ссылается ссылка, и FileNotFoundException возникает исключение. В этом случае выполнение клона с заменой на неглубокое клон восстанавливает клон. Если это происходит часто, попробуйте использовать глубокий клон, который не зависит от исходной таблицы.
• Глубокие клоны не зависят от источника, из которого они были клонированы, но требуют больших затрат, так как при глубоком клонировании копируются и данные, и метаданные.
• При клонировании с replace в целевой объект, в котором уже есть таблица в этом пути, создается журнал Delta (если он не существует по этому пути). Существующие данные можно очистить, выполнив vacuum.
• Для существующих таблиц Delta создается новая фиксация, содержащая новые метаданные и новые данные из исходной таблицы. Эта новая фиксация является добавочной, то есть в ней фиксируются только изменения с момента последнего клонирования.
• Клонирование таблицы отличается от Create Table As Select и CTAS. В дополнение к данным исходной таблицы при клонировании копируются и ее метаданные. Кроме того, клонирование имеет более простой синтаксис: вам не нужно указывать секционирование, формат, инварианты, допустимость значений NULL и другие параметры, так как они берутся из исходной таблицы.
• Клонированная таблица имеет журнал, независимый от исходной таблицы. Запросы на поездки по времени в клонированную таблицу не работают с теми же входными данными, что и в исходной таблице.

Пример синтаксиса клонирования

В следующих примерах кода демонстрируется синтаксис для создания глубоких и мелких клонов:

SQL

CREATE TABLE target_table CLONE source_table; -- Create a deep clone of source_table as target_table

CREATE OR REPLACE TABLE target_table CLONE source_table; -- Replace the target

CREATE TABLE IF NOT EXISTS target_table CLONE source_table; -- No-op if the target table exists

CREATE TABLE target_table SHALLOW CLONE source_table;

CREATE TABLE target_table SHALLOW CLONE source_table VERSION AS OF version;

CREATE TABLE target_table SHALLOW CLONE source_table TIMESTAMP AS OF timestamp_expression; -- timestamp can be like “2019-01-01” or like date_sub(current_date(), 1)

Python

from delta.tables import *

deltaTable = DeltaTable.forName(spark, "source_table")

deltaTable.clone(target="target_table", isShallow=True, replace=False) # clone the source at latest version

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=True, replace=False) # clone the source at a specific version

# clone the source at a specific timestamp such as timestamp="2019-01-01"
deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=True, replace=False)

Scala

import io.delta.tables._

val deltaTable = DeltaTable.forName(spark, "source_table")

deltaTable.clone(target="target_table", isShallow=true, replace=false) // clone the source at latest version

deltaTable.cloneAtVersion(version=1, target="target_table", isShallow=true, replace=false) // clone the source at a specific version

deltaTable.cloneAtTimestamp(timestamp="2019-01-01", target="target_table", isShallow=true, replace=false) // clone the source at a specific timestamp

Сведения о синтаксисе см. в статье CREATE TABLE CLONE.

Метрики клонирования

CLONE передает следующие метрики в виде DataFrame из одной строки после завершения операции:

• source_table_size — размер в байтах исходной таблицы, которая клонируется;
• source_num_of_files — число файлов в исходной таблице;
• num_removed_files — если выполняется замена таблицы, количество файлов, удаляемых из текущей таблицы;
• num_copied_files — количество файлов, скопированных из источника (0 в случае поверхностных клонов);
• removed_files_size — размер в байтах файлов, удаляемых из текущей таблицы;
• copied_files_size — размер в байтах файлов, скопированных в таблицу.

Разрешения

Необходимо настроить разрешения для управления доступом к таблицам Azure Databricks и поставщика облачных служб.

Управление доступом к таблицам

Для глубоких и поверхностных клонов требуются следующие разрешения:

• разрешение SELECT для исходной таблицы.
• Если вы используете CLONE для создания новой таблицы, разрешение CREATE для базы данных, в которой создается таблица.
• Если вы используете CLONE для замены таблицы, вам необходимо иметь разрешение MODIFY для таблицы.

Разрешения поставщика облачных служб

Если вы создали глубокий клон, любой пользователь, который считывает его, должен иметь доступ на чтение к каталогу клона. Чтобы внести изменения в клон, пользователи должны иметь доступ на запись к каталогу клона.

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

Использование клона для архивации данных

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

-- Every month run
CREATE OR REPLACE TABLE archive_table CLONE my_prod_table

Использование клона для воспроизведения моделей машинного обучения

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

-- Trained model on version 15 of Delta table
CREATE TABLE model_dataset CLONE entire_dataset VERSION AS OF 15

Использование клона для краткосрочных экспериментов в рабочей таблице

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

-- Perform shallow clone
CREATE OR REPLACE TABLE my_test SHALLOW CLONE my_prod_table;

UPDATE my_test WHERE user_id is null SET invalid=true;
-- Run a bunch of validations. Once happy:

-- This should leverage the update information in the clone to prune to only
-- changed files in the clone if possible
MERGE INTO my_prod_table
USING my_test
ON my_test.user_id <=> my_prod_table.user_id
WHEN MATCHED AND my_test.user_id is null THEN UPDATE *;

DROP TABLE my_test;

Использование клона для переопределения свойств таблицы

Переопределения свойств таблицы особенно полезны для:

• добавления заметок к таблицам с данными о владельце или пользователе при совместном использовании данных разными подразделениями;
• Требуется архивация разностных таблиц и журнала таблиц или времени. Вы можете указать сроки хранения данных и журналов независимо для архивной таблицы. Например:

SQL

CREATE OR REPLACE TABLE archive_table CLONE prod.my_table
TBLPROPERTIES (
delta.logRetentionDuration = '3650 days',
delta.deletedFileRetentionDuration = '3650 days'
)

Python

dt = DeltaTable.forName(spark, "prod.my_table")
tblProps = {
"delta.logRetentionDuration": "3650 days",
"delta.deletedFileRetentionDuration": "3650 days"
}
dt.clone(target="archive_table", isShallow=False, replace=True, tblProps)

Scala

val dt = DeltaTable.forName(spark, "prod.my_table")
val tblProps = Map(
"delta.logRetentionDuration" -> "3650 days",
"delta.deletedFileRetentionDuration" -> "3650 days"
)
dt.clone(target="archive_table", isShallow = false, replace = true, properties = tblProps)