Clonación superficial de tablas en Unity Catalog

Importante

Esta característica está en versión preliminar pública.

Importante

La compatibilidad de la clonación superficial difiere para las tablas gestionadas por Unity Catalog y las tablas externas. En el caso de las tablas administradas, use Databricks Runtime 13.3 y versiones posteriores, y para tablas externas, use Databricks Runtime 14.2 y versiones posteriores.

Solo puede clonar tablas administradas de Unity Catalog a tablas administradas de Unity Catalog y tablas externas de Unity Catalog a tablas externas de Unity Catalog. El comportamiento de VACUUM difiere entre las tablas administradas y externas. Consulte Usar VACUUM con clones superficiales del Unity Catalog.

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.

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.

Recurso	Permisos requeridos
Esquema de origen	USE SCHEMA
Catálogo de origen	USE CATALOG
Esquema de destino	USE SCHEMA, CREATE TABLE
Catálogo objetivo	USE CATALOG

Al igual que otras instrucciones `CREATE TABLE`, el usuario que crea un clon superficial posee 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. Esto significa que el propietario de una tabla clonada podría 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.

Recurso	Permisos requeridos
Esquema de origen	USE SCHEMA
Catálogo de origen	USE CATALOG
Esquema de destino	USE SCHEMA, CREATE TABLE
Catálogo objetivo	USE CATALOG
Ubicación externa de destino	CREATE EXTERNAL TABLE

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

Para consultar un clon superficial en modo de acceso estándar (anteriormente modo de acceso compartido), debe tener los siguientes privilegios en la tabla y contener recursos.

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

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

• Insertar registros
• Eliminar registros
• Actualizar registros
• MERGE
• CREATE TABLE
• DROP TABLE

Trabajar con tablas clonadas poco profundas en modo de acceso dedicado

Al trabajar con clones superficiales del catálogo de Unity en modo de acceso dedicado (anteriormente modo de acceso de usuario único), debe tener permisos en los recursos del 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 SELECT los permisos en la tabla de origen. Para cualquier consulta que actualice o inserte registros en la tabla de destino, también debe tener permisos MODIFY en la tabla de origen.

Databricks recomienda trabajar con clones de Unity Catalog en cómputo con el modo de acceso estándar, ya que esto permite la evolución independiente de los permisos para los objetivos de clonación superficial de Unity Catalog y 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. 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. Sin embargo, la compatibilidad superficial con clones de 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 metadatos cambia la forma en que VACUUM las operaciones afectan a los archivos de datos subyacentes de 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 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.

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. Para más información, consulte Clonación de una tabla en Azure Databricks.

Además, incluso si se elimina una tabla clonada superficial, es posible que necesite SELECT acceso a esta tabla 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 vínculo durante 7 días después de que una tabla de copia superficial sea eliminada 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 se vuelve 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:
  • Error en las operaciones que requieren leer datos o metadatos (por ejemplo, SELECT, INSERT, UPDATE, DESCRIBE HISTORY, CLONE).
  • Siguen siendo visibles a través de operaciones de nivel de metadatos (por ejemplo, SHOW TABLES, DROP TABLE) para permitir la limpieza.

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

Limitaciones

• Los clones superficiales en tablas externas deben ser tablas externas. Los clones superficiales en tablas administradas deben ser tablas administradas.
• No puede usar REPLACE ni CREATE OR REPLACE para sobrescribir un clon superficial existente. En su lugar, DROP el clon superficial y ejecute una nueva instrucción CREATE.
• No se pueden compartir clones poco profundos mediante Delta Sharing.
• 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.