Clonación superficial para tablas de Unity Catalog

Importante

El soporte de clonación superficial con las tablas administradas del Unity Catalog está en versión preliminar pública en Databricks Runtime 13.3 y versiones posteriores. La compatibilidad con clonación superficial para tablas externas de Unity Catalog se encuentra en versión preliminar pública en Databricks Runtime 14.2 y versiones posteriores.

Puede usar la clonación superficial para crear nuevas tablas de Unity Catalog a partir de tablas existentes de Unity Catalog. La compatibilidad superficial con clones para Unity Catalog permite crear tablas con privilegios de control de acceso independientes de sus tablas primarias sin necesidad de copiar archivos de datos subyacentes.

Importante

Solo puede clonar tablas administradas de Unity Catalog en tablas administradas de Unity Catalog y tablas externas de Unity Catalog en tablas externas de Unity Catalog. El comportamiento de VACUUM difiere entre las tablas administradas y externas. Clones superficiales de Vacuum y Unity Catalog.

Para más información sobre el clon delta, consulte Clonación de una tabla en Azure Databricks.

Para obtener más información sobre las tablas del catálogo de Unity, consulte ¿Qué son las tablas y vistas?.

Crear un clon superficial en Unity Catalog

Puede crear un clon superficial en Unity Catalog con la misma sintaxis disponible para clones poco profundos en todo el producto, como se muestra en el ejemplo de sintaxis siguiente:

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name> SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>

Para crear un clon superficial en Unity Catalog, debe tener privilegios suficientes en los recursos de origen y de destino, como se detalla en la tabla siguiente:

Recurso	Permisos requeridos
Tabla de origen	SELECT
Esquema de origen	USE SCHEMA
Catálogo de origen	USE CATALOG
Esquema de destino	USE SCHEMA, CREATE TABLE
Catálogo de destino	USE CATALOG
Ubicación externa de destino (solo tablas externas)	CREATE EXTERNAL TABLE

Al igual que otras sentencias de crear tabla, el usuario que crea un clon superficial es el propietario de la tabla de destino. El propietario de una tabla clonada de destino puede controlar los derechos de acceso de esa tabla independientemente de la tabla de origen.

Nota:

El propietario de una tabla clonada podría ser diferente del propietario de una tabla de origen.

Consulta o modificación de una tabla clonada superficial en Unity Catalog

Importante

En las instrucciones de esta sección se describen los privilegios necesarios para el proceso configurado con el modo de acceso compartido. Para el modo de acceso de usuario único, consulte Trabajar con tablas clonadas poco profundas en modo de acceso de usuario único.

Para consultar un clon superficial en Unity Catalog, debe tener suficientes privilegios en la tabla y contener recursos, como se detalla en la tabla siguiente:

Recurso	Permisos requeridos
Catálogo	USE CATALOG
Esquema	USE SCHEMA
Tabla	SELECT

También debe tener permisos en el destino MODIFY de la operación de clonación para completar las siguientes acciones:

• Insertar registros
• Eliminar registros
• Registros de actualización
• MERGE
• CREATE OR REPLACE TABLE
• DROP TABLE

Clones superficiales de Vacuum y Unity Catalog

Importante

Este comportamiento se encuentra en versión preliminar pública en Databricks Runtime 13.3 LTS y versiones posteriores para tablas administradas y Databricks Runtime 14.2 y versiones posteriores para tablas externas.

Cuando se usan tablas de Unity Catalog para el origen y el destino de una operación de clonación superficial, Unity Catalog administra los archivos de datos subyacentes para mejorar la confiabilidad para el origen y el destino de la operación de clonación. La ejecución VACUUM en el origen de un clon superficial no interrumpe la tabla clonada.

Normalmente, cuando VACUUM identifica archivos válidos para un umbral de retención determinado, solo se tienen en cuenta los metadatos de la tabla actual. La compatibilidad superficial con clones para Unity Catalog realiza un seguimiento de las relaciones entre todas las tablas clonadas y los archivos de datos de origen, por lo que los archivos válidos se expanden para incluir los archivos de datos necesarios para devolver consultas para cualquier tabla clonada superficial, así como la tabla de origen.

Esto quiere decir que para la semántica de clonación VACUUM superficial de Unity Catalog, un archivo de datos válido es cualquier archivo dentro del umbral de retención especificado para la tabla de origen o cualquier tabla clonada. Las tablas administradas y externas tienen una semántica ligeramente diferente.

Este seguimiento mejorado de los metadatos cambia cómo VACUUM afectan las operaciones a los archivos de datos que respaldan las tablas Delta, con la semántica siguiente:

• En el caso de las tablas administradas, las operaciones VACUUM en el origen o el destino de una operación de clonación superficial pueden eliminar archivos de datos de la tabla de origen.
• En el caso de las tablas externas, las operaciones VACUUM solo quitan archivos de datos de la tabla de origen cuando se ejecutan en la tabla de origen.
• Solo se quitan los archivos de datos no considerados válidos para la tabla de origen o cualquier clon superficial en el origen.
• Si se definen varios clones superficiales en una sola tabla de origen, la ejecución VACUUM en cualquiera de las tablas clonadas no quita archivos de datos válidos para otras tablas clonadas.

Nota:

Databricks recomienda nunca ejecutar VACUUM con una configuración de retención de menos de 7 días para evitar dañar las transacciones de larga duración en curso. Si necesita ejecutar VACUUM con un umbral de retención inferior, asegúrese de comprender cómo VACUUM en clones poco profundos de Unity Catalog difiere de cómo VACUUM interactúa con otras tablas clonadas en Azure Databricks. Consulte Clonación de una tabla en Azure Databricks.

Trabajar con tablas clonadas de poca profundidad en modo de acceso de usuario único

Al trabajar con clones superficiales de Unity Catalog en modo de acceso de usuario único, debe tener permisos en los recursos para el origen de la tabla clonada, así como en la tabla de destino.

Esto significa que para consultas sencillas además de los permisos necesarios en la tabla de destino, debe tener USE permisos en el catálogo de origen y el esquema y los SELECT permisos en la tabla de origen. Para cualquier consulta que pueda actualizar o insertar registros en la tabla de destino, también debe tener permisos en MODIFY la tabla de origen.

Databricks recomienda trabajar con clones de Unity Catalog en proceso con modo de acceso compartido, ya que esto permite una evolución independiente de los permisos para los destinos de clonación superficial de Unity Catalog y sus tablas de origen.

Limitaciones

• Los clones superficiales en tablas externas deben ser tablas externas. Los clones superficiales en tablas administradas deben ser tablas administradas.
• No se pueden compartir clones poco profundos mediante el uso compartido de Delta.
• No se pueden anidar clones poco profundos, lo que significa que no se puede hacer un clon superficial a partir de un clon superficial.
• En el caso de las tablas administradas, al quitar la tabla de origen se interrumpe la tabla de destino para clones superficiales. Las operaciones DROP TABLE no quitan los archivos de datos que respaldan tablas externas, por lo que los clones superficiales de tablas externas no se ven afectados al quitar el origen.
• El Unity Catalog permite a los usuarios tablas administradas UNDROP durante unos 7 días después de un comando DROP TABLE. En Databricks Runtime 13.3 LTS y superiores, los clones superficiales administrados basados en una tabla administrada anulada siguen funcionando durante este periodo de 7 días. Si no UNDROP la tabla de origen de esta ventana, el clon superficial deja de funcionar una vez que se recopilan los archivos de datos de la tabla de origen.