Compartir a través de


Clonación de una tabla en Azure Databricks

Puede crear una copia de una tabla de Delta Lake existente en Azure Databricks con una versión específica mediante el comando clone. Los clones pueden ser profundos o superficiales.

Azure Databricks también admite la clonación de tablas de Parquet e Iceberg. Consulte Clonación incremental de tablas de Parquet e Iceberg en Delta Lake.

Para más detalles sobre el uso de clones con Unity Catalog, consulte Clonación superficial para tablas de Unity Catalog.

Nota:

Databricks recomienda usar Delta Sharing para proporcionar acceso de solo lectura a las tablas de distintas organizaciones. Consulte Uso seguro de recursos de uso compartido de datos e inteligencia artificial mediante Delta Sharing.

Tipos de clon

  • Un clon profundo es un clon que copia los datos de la tabla de origen en el destino de clonación además de los metadatos de la tabla existente. Además, los metadatos del flujo también se clonan de manera que un flujo que escribe en la tabla Delta se puede detener en una tabla de origen y continuar en el destino de un clon desde donde se dejó.
  • Un clon superficial es un clon que no copia los archivos de datos en el destino de clonación. Los metadatos de la tabla son equivalentes al origen. Estos clones son más baratos de crear.

Los metadatos que se clonan incluyen: esquema, información de creación de particiones, invariantes y nulabilidad. Solo para clones profundos, también se clonan los metadatos del flujo y COPY INTO. Los metadatos no clonados son la descripción de la tabla y los metadatos de confirmación definidos por el usuario.

¿Cuál es la semántica de las operaciones de clonación Delta?

Si tiene el trabajo con una tabla Delta registrado en la metastore de Hive o a una colección de archivos no registrada como tabla, la clonación tiene la siguiente semántica:

Importante

En Databricks Runtime 13.3 LTS y versiones posteriores, las tablas administradas de Unity Catalog admiten clones superficiales. La semántica de clonación para las tablas de Unity Catalog difiere significativamente de la semántica de clonación de Delta Lake en otros entornos. Consulte Clonación superficial para tablas de Unity Catalog.

  • Los cambios realizados en clones profundos o superficiales solo afectan a los propios clones y no a la tabla de origen.
  • Los clones superficiales hacen referencia a archivos de datos en el directorio de origen. Si se ejecuta vacuum en la tabla de origen, los clientes ya no podrán leer los archivos de datos a los que se hace referencia y se produce una excepción FileNotFoundException. En este caso, la ejecución de una clonación con reemplazo sobre el clon superficial reparará el clon. Si esto ocurre con frecuencia, considere la posibilidad de usar en su lugar un clon profundo que no dependa de la tabla de origen.
  • Los clones profundos no dependen del origen desde el que se clonaron, pero son costosos de crear porque un clon profundo copia los datos y los metadatos.
  • La clonación con replace en un destino que ya tiene una tabla en esa ruta de acceso crea un registro Delta si no existe uno en esa ruta de acceso. Puede limpiar los datos existentes mediante la ejecución de vacuum.
  • Para una tabla Delta existente, se crea una nueva confirmación que incluye los nuevos metadatos y los nuevos datos de la tabla de origen. Esta nueva confirmación es incremental, lo que significa que solo los cambios nuevos desde el último clon se confirman en la tabla.
  • Clonar una tabla no es lo mismo que Create Table As Select o CTAS. Un clon copia los metadatos de la tabla de origen además de los datos. La clonación también tiene una sintaxis más sencilla: no es necesario especificar particiones, formato, invariantes ni nulabilidad, ya que se toman de la tabla de origen.
  • Una tabla clonada tiene un historial independiente de su tabla de origen. Las consultas de viaje en el tiempo en una tabla clonada no funcionan con las mismas entradas que funcionan en su tabla de origen.

Ejemplo de sintaxis de clonación

En los ejemplos de código siguientes se muestra la sintaxis para crear clones profundos y superficiales:

SQL

CREATE TABLE delta.`/data/target/` CLONE delta.`/data/source/` -- Create a deep clone of /data/source at /data/target

CREATE OR REPLACE TABLE db.target_table CLONE db.source_table -- Replace the target

CREATE TABLE IF NOT EXISTS delta.`/data/target/` CLONE db.source_table -- No-op if the target table exists

CREATE TABLE db.target_table SHALLOW CLONE delta.`/data/source`

CREATE TABLE db.target_table SHALLOW CLONE delta.`/data/source` VERSION AS OF version

CREATE TABLE db.target_table SHALLOW CLONE delta.`/data/source` 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.forPath(spark, "/path/to/table")  # path-based tables, or
deltaTable = DeltaTable.forName(spark, "source_table")    # Hive metastore-based tables

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.forPath(spark, "/path/to/table")
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

Para más información sobre la sintaxis, consulte CREATE TABLE CLONE.

Métricas de clonación

CLONE informa de las métricas siguientes como un dataframe de una sola fila una vez completada la operación:

  • source_table_size: tamaño de la tabla de origen que se ha clonado en bytes.
  • source_num_of_files: número de archivos de la tabla de origen.
  • num_removed_files: si se va a reemplazar la tabla, cuántos archivos se han quitado de la tabla actual.
  • num_copied_files: número de archivos que se copiaron del origen (0 para clones superficiales).
  • removed_files_size: tamaño en bytes de los archivos que se van a quitar de la tabla actual.
  • copied_files_size: tamaño en bytes de los archivos copiados en la tabla.

Ejemplo de métricas de clonación

Permisos

Debe configurar permisos para el control de acceso de la tabla de Azure Databricks y el proveedor de nube.

Control de acceso a tabla

Los siguientes permisos son necesarios para clones profundos y superficiales:

  • Permiso SELECT en la tabla de origen.
  • Si usa CLONE para crear una tabla, permiso CREATE en la base de datos en la que va a crear la tabla.
  • Si usa CLONE para reemplazar una tabla, debe tener permiso MODIFY en la tabla.

Permisos del proveedor de nube

Si ha creado un clon profundo, cualquier usuario que lea el clon profundo debe tener acceso de lectura al directorio del clon. Para realizar cambios en el clon, los usuarios deben tener acceso de escritura al directorio del clon.

Si ha creado un clon superficial, cualquier usuario que lea el clon superficial necesita permiso para leer los archivos de la tabla original, ya que los archivos de datos permanecen en la tabla de origen con los clones superficiales, así como el directorio del clon. Para realizar cambios en el clon, los usuarios deben tener acceso de escritura al directorio del clon.

Uso de la clonación para el archivado de datos

Puede crear un clon profundo para conservar el estado de una tabla en un momento dado a fin de archivarla. Puede sincronizar clones profundos de forma incremental para mantener un estado actualizado de una tabla de origen para la recuperación ante desastres.

-- Every month run
CREATE OR REPLACE TABLE delta.`/some/archive/path` CLONE my_prod_table

Uso de la clonación para la reproducción de modelos de ML

Al realizar el aprendizaje automático, es posible que desee archivar una versión determinada de una tabla en la que entrenó un modelo de ML. Los modelos futuros se pueden probar con este conjunto de datos archivado.

-- Trained model on version 15 of Delta table
CREATE TABLE delta.`/model/dataset` CLONE entire_dataset VERSION AS OF 15

Uso de la clonación para experimentos a corto plazo en una tabla de producción

Para probar un flujo de trabajo en una tabla de producción sin dañar la tabla, puede crear fácilmente un clon superficial. Esto le permite ejecutar flujos de trabajo arbitrarios en la tabla clonada que contiene todos los datos de producción, pero no afecta a ninguna carga de trabajo de producción.

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

Uso de la clonación para invalidar las propiedades de una tabla

Nota:

Disponible en Databricks Runtime 7.5 y versiones posteriores.

Las invalidaciones de propiedades de tabla son especialmente útiles para:

  • Anotar tablas con información de propietario o usuario al compartir datos con diferentes unidades de negocio.
  • Se requiere archivar tablas Delta y el historial de tablas o el viaje en el tiempo. Puede especificar el periodo de retención de datos y de registros de forma independiente para la tabla de archivo. Por ejemplo:

SQL

CREATE OR REPLACE TABLE archive.my_table CLONE prod.my_table
TBLPROPERTIES (
delta.logRetentionDuration = '3650 days',
delta.deletedFileRetentionDuration = '3650 days'
)
LOCATION 'xx://archive/my_table'

Python

dt = DeltaTable.forName(spark, "prod.my_table")
tblProps = {
"delta.logRetentionDuration": "3650 days",
"delta.deletedFileRetentionDuration": "3650 days"
}
dt.clone('xx://archive/my_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("xx://archive/my_table", isShallow = false, replace = true, properties = tblProps)