Clonación superficial de tablas en 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 CREATE TABLE, 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

Si se elimina la tabla base de un clon superficial, el clon queda inutilizable. De forma predeterminada, Databricks impide quitar una tabla base si todavía tiene clones poco profundos que hacen referencia a ella.

Para invalidar esta protección, use la DROP TABLE ... FORCE sintaxis . Si usa FORCE:

• La tabla base se elimina inmediatamente.
• Todas las referencias a clones poco profundos se rompen y:
  • Los clones poco profundos producen errores en las operaciones que requieren lectura de datos o metadatos (por ejemplo, SELECT, INSERT, UPDATE, DESCRIBE HISTORY). CLONE
  • Para permitir la limpieza, los clones poco profundos siguen siendo visibles a través de operaciones de nivel de metadatos (por ejemplo, SHOW TABLES, DROP TABLE).

Este comportamiento solo se aplica a las tablas administradas del catálogo de Unity. Para obtener más información, consulte DROP TABLE.

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.
• 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.
• En el caso de las tablas administradas, al quitar la tabla de origen se interrumpe la tabla de destino para clones superficiales. Las operaciones no eliminan los archivos de datos subyacentes para las tablas externas y, por lo tanto, los clones poco profundos de las tablas externas no se ven afectados al eliminar el origen.
• Unity Catalog permite a los usuarios gestionar tablas UNDROP durante aproximadamente 7 días después de un comando DROP TABLE. En Databricks Runtime 13.3 LTS y versiones posteriores, los clones superficiales gestionados de una tabla de origen eliminada continúan funcionando durante los 7 días en que Unity Catalog admite UNDROP. Si la tabla de origen no se restaura dentro de esa ventana, el clon superficial se inutiliza cuando los archivos de datos de origen se eliminan durante la recolección de basura.