Clonación superficial para tablas de Unity Catalog

Use un clon superficial para crear tablas de Catálogo de Unity con privilegios de control de acceso independientes de sus tablas de origen, sin copiar los archivos de datos subyacentes. La clonación superficial en Unity Catalog solo es compatible con las tablas de Delta Lake. No se puede crear un clon superficial de una tabla Iceberg ni de ninguna otra tabla que no sea Delta.

Para más información sobre la clonación de una tabla, consulte Clonación de una tabla en Azure Databricks.

Cree un clon superficial gestionado por Unity Catalog

Cree un clon superficial de una tabla administrada en el catálogo de Unity.

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

Para crear un clon superficial administrado en el catálogo de Unity, debe tener los siguientes privilegios en los recursos de origen y de destino.

Al igual que con otras instrucciones de tabla, cuando ejecuta SHALLOW CLONE, es el propietario de la tabla de destino. El propietario de una tabla de destino clonada controla los derechos de acceso de esa tabla independientemente de la tabla de origen. El propietario de una tabla clonada puede ser diferente del propietario de una tabla de origen.

Crear un clon externo superficial del Unity Catalog

Cree un clon externo superficial de Unity Catalog especificando una ubicación externa.

CREATE TABLE <catalog-name>.<schema-name>.<target-table-name>
SHALLOW CLONE <catalog-name>.<schema-name>.<source-table-name>
LOCATION 's3://<bucket-name>/<path-name>/<target-table-name>'

Para crear un clon superficial externo en Unity Catalog, necesitará los siguientes privilegios en los recursos de origen y destino.

Trabajar con tablas clonadas superficialmente en modo de acceso estándar

Para consultar un clon superficial en el modo de acceso estándar (anteriormente, modo de acceso compartido), debe tener los siguientes privilegios sobre la tabla y los recursos que la contienen:

Debe tener también MODIFY permisos sobre el destino de la operación de clonación para ejecutar las siguientes operaciones:

• INSERT
• DELETE
• UPDATE
• MERGE
• CREATE TABLE
• DROP TABLE

Trabajar con tablas clonadas poco profundas en modo de acceso dedicado

Al trabajar con clones superficiales de Unity Catalog en modo de acceso dedicado (anteriormente, modo de acceso de usuario único), debe contar con permisos sobre los recursos tanto de la tabla de origen del clon como de la tabla de destino.

Para consultas simples, además de los permisos necesarios sobre la tabla de destino, debe tener USE permisos sobre el catálogo y el esquema de origen, y SELECT permisos sobre la tabla de origen. Para cualquier consulta que actualice o inserte registros en la tabla de destino, también debe contar con permisos MODIFY en la tabla de origen.

Databricks recomienda usar clones de Unity Catalog en compute con modo de acceso estándar, ya que esto permite realizar modificaciones independientes en los permisos de los destinos de clon superficial de Unity Catalog y de sus tablas de origen.

Utiliza VACUUM con clones superficiales del catálogo de Unity

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. Ejecutar VACUUM en el origen de una clonación superficial no rompe 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. Sin embargo, la compatibilidad con clones superficiales de Unity Catalog rastrea las relaciones entre todas las tablas clonadas y los archivos de datos fuente, por lo que el conjunto de archivos válidos se amplía para incluir los archivos de datos necesarios para responder a las consultas tanto de las tablas clonadas superficialmente como de la tabla de origen.

Para VACUUM en un clon superficial del catálogo de Unity, 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 las tablas externas tienen comportamientos ligeramente diferentes.

Este seguimiento mejorado de los metadatos cambia la forma en que VACUUM las operaciones afectan a los archivos de datos subyacentes para las tablas de Delta Lake, con el siguiente comportamiento:

• En el caso de las tablas administradas, VACUUM las operaciones en el origen o el destino de una operación de clonación superficial podrían 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 eliminan los archivos de datos no considerados válidos para la tabla de origen o cualquier clon superficial respecto a la fuente.
• Si se definen varios clones superficiales en una sola tabla de origen, la ejecución de VACUUM en cualquiera de las tablas clonadas no elimina los archivos de datos válidos para otras tablas clonadas.

Incluso si elimina un clon superficial de una tabla, es posible que necesite tener acceso SELECT a ese clon superficial para ejecutar VACUUM en la tabla base. Databricks lee el registro de Delta del clon superficial para comprobar qué archivos de datos de la tabla base sigue referenciando el clon antes de eliminarlos. Databricks mantiene este enlace durante 7 días después de eliminar una tabla clonada de forma superficial para admitir la operación UNDROP. Sin embargo, en el modo de acceso estándar, este permiso no es necesario.

Eliminar la tabla base de un clon somero

Puedes eliminar la tabla base de una tabla gestionada por Unity Catalog incluso cuando clones superficiales activos aún siguen haciendo referencia a ella. Los clones siguen leyendo hasta que se eliminan los archivos de datos de la tabla base, lo que los hace inutilizables. Puedes restaurar la tabla base con UNDROP durante su periodo de recuperación, cuyo valor predeterminado es de 7 días y se puede configurar en el nivel de catálogo o de esquema en 0 (para desactivar la recuperación) o de 7 a 30 días. La configuración del periodo de recuperación está en Vista previa Pública. Si no restauras la tabla, un proceso de purga asíncrono elimina sus archivos de datos tras finalizar el periodo de recuperación, de modo que los clones pueden seguir leyendo un tiempo después de que la tabla base ya no sea recuperable. Para recuperar una tabla base caída, usa UNDROP.

Limitaciones

• El clon superficial solo se admite para las tablas de Delta Lake. No se puede crear un clon superficial de una tabla Iceberg ni de ninguna otra tabla que no sea Delta.
• No puede utilizar CREATE OR REPLACE para sobrescribir un clon superficial existente. Use DROP TABLE seguido de CREATE TABLEo use un nuevo nombre de tabla.
• 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 OpenSharing.
• No se pueden anidar clones poco profundos, lo que significa que no se puede hacer un clon superficial a partir de un clon superficial.
• Para tablas externas, DROP TABLE no elimina los archivos de datos subyacentes, por lo que los clones superficiales no se ven afectados cuando se elimina la tabla fuente.
• Para tablas gestionadas en Databricks Runtime 13.3 LTS y superiores, clones superficiales de una tabla fuente eliminada siguen funcionando hasta que se eliminan los archivos de datos fuente. Consulte Eliminar la tabla base de un clon superficial.