Клонирование таблицы в Azure Databricks
Вы можете создать копию существующей таблицы Delta Lake в Azure Databricks в определенной версии с помощью команды clone
. Клоны могут быть либо глубокими, либо поверхностными.
Azure Databricks также поддерживает клонирование таблиц Parquet и Iceberg. См . добавочное клонирование таблиц Parquet и Iceberg в Delta Lake.
Дополнительные сведения об использовании клона с каталогом Unity см. в разделе "Мелкий клон" для таблиц каталога Unity.
Примечание.
Databricks рекомендует использовать разностный общий доступ для предоставления доступа только для чтения к таблицам в разных организациях. См. раздел "Что такое разностный общий доступ?".
Типы клонирования
- Глубокий клон — это клон, который копирует данные исходной таблицы в целевой объект клонирования в дополнение к метаданным существующей таблицы. Кроме того, клонируются метаданные потока таким образом, что поток, записывающий данные в таблицу Delta, может быть остановлен в исходной таблице и продолжаться на целевом объекте клонирования без перебоя.
- Поверхностный клон — это клон, который не копирует файлы данных в целевой объект клонирования. Метаданные таблицы эквивалентны исходным. Создание этих клонов менее затратно.
Клонируемые метаданные включают в себя: схему, сведения о секционировании, инварианты, допустимость значений NULL. Для глубоких клонов также клонируется поток и метаданные COPY INTO. Метаданные, которые не клонируются — описание таблицы и определяемые пользователем метаданные фиксации.
Что такое семантика операций клонирования Delta?
Если вы работаете с таблицей Delta, зарегистрированной в хранилище метаданных Hive или коллекцией файлов, не зарегистрированных в качестве таблицы, клон имеет следующую семантику:
Внимание
В Databricks Runtime 13.3 LTS и более поздних версиях управляемые таблицы каталога Unity поддерживают неглубокие клоны. Семантика клонирования для таблиц каталога Unity значительно отличается от семантики клона Delta Lake в других средах. См . раздел "Мелкий клон" для таблиц каталога Unity.
- Любые изменения, вносимые в глубокие или поверхностные клоны, влияют только на сами клоны, а не исходную таблицу.
- Поверхностные клоны ссылаются на файлы данных в исходном каталоге. Если вы запускаете
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)