Clonación incremental de tablas de Parquet e Iceberg en Delta Lake

Puede usar la funcionalidad de clonación de Azure Databricks para convertir incrementalmente los datos de orígenes de datos de Parquet o Iceberg en tablas Delta administradas o externas.

El clon de Azure Databricks para Parquet e Iceberg combina la funcionalidad que se usa para clonar tablas Delta y convertir tablas en Delta Lake. En este artículo se describen los casos de uso y las limitaciones de esta característica y se proporcionan ejemplos.

Importante

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

Nota:

Para esta característica se necesita Databricks Runtime 11.3 LTS o superior.

Cuándo usar la clonación para la ingesta incremental de datos de Parquet o Iceberg

Azure Databricks proporciona una serie de opciones para ingerir datos en el lago. Databricks recomienda el uso de la clonación para ingerir datos de Parquet o Iceberg en las situaciones siguientes:

Nota:

El término tabla de origen hace referencia a los archivos de tabla y datos que se van a clonar, mientras que la tabla de destino hace referencia a la tabla Delta creada o actualizada por la operación.

• Va a realizar una migración de Parquet o Iceberg a Delta Lake, pero debe seguir usando tablas de origen.
• Debe mantener una sincronización de solo ingesta entre una tabla de destino y una tabla de origen de producción que recibe anexos, actualizaciones y eliminaciones.
• Quiere crear una instantánea compatible con ACID de los datos de origen para la creación de informes, el aprendizaje automático o el ETL por lotes.

¿Cuál es la sintaxis para la clonación?

En la clonación para Parquet e Iceberg se usa la misma sintaxis básica que se emplea para clonar tablas Delta, existiendo compatibilidad con clones superficiales y profundos. Para más información, consulte Tipos de clon.

Databricks recomienda usar la clonación de manera incremental para la mayoría de las cargas de trabajo. Para la compatibilidad con la clonación en Parquet e Iceberg se usa la sintaxis SQL.

Nota:

Los requisitos y garantías en la clonación de Parquet e Iceberg son diferentes a los de la clonación o conversión en Delta. Vea Requisitos y limitaciones para clonar tablas de Parquet e Iceberg.

Para clonar en profundidad una tabla Parquet o Iceberg mediante una ruta de acceso de archivo, use la siguiente sintaxis:

CREATE OR REPLACE TABLE <target-table-name> CLONE parquet.`/path/to/data`;

CREATE OR REPLACE TABLE <target-table-name> CLONE iceberg.`/path/to/data`;

Para clonar superficialmente una tabla Parquet o Iceberg mediante una ruta de acceso de archivo, use la siguiente sintaxis:

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE parquet.`/path/to/data`;

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE iceberg.`/path/to/data`;

También puede crear clones profundos o superficiales para las tablas Parquet registradas en el metastore, como se muestra en los ejemplos siguientes:

CREATE OR REPLACE TABLE <target-table-name> CLONE <source-table-name>;

CREATE OR REPLACE TABLE <target-table-name> SHALLOW CLONE <source-table-name>;

Requisitos y limitaciones para clonar tablas de Parquet e Iceberg.

Tanto si se usan clones profundos como superficiales, los cambios aplicados a la tabla de destino después de que se produzca el clon no se pueden volver a sincronizar con la tabla de origen. La sincronización incremental con el clon es unidireccional, lo que permite que los cambios en las tablas de origen se apliquen automáticamente a las tablas Delta de destino.

Al usar clones con tablas Parquet y Clone, se aplican las siguientes limitaciones adicionales:

• Debe registrar las tablas Parquet con particiones en un catálogo, como Unity Catalog o el metastore de Hive heredado, antes de clonar y usar el nombre de tabla para identificar la tabla de origen. No se puede usar la sintaxis de clonación basada en rutas de acceso para tablas Parquet con particiones.
• No se pueden clonar tablas Iceberg que hayan experimentado evolución de particiones.
• No se pueden clonar tablas Iceberg merge-on-read que hayan experimentado actualizaciones, eliminaciones o fusiones.
• A continuación se muestran las limitaciones para clonar tablas de Iceberg con particiones definidas en columnas truncadas:
  • En Databricks Runtime 12.2 LTS y versiones posteriores, el único tipo de columna truncado admitido es string.
  • En Databricks Runtime 13.3 LTS y versiones posteriores, puede trabajar con columnas truncadas de tipos string, long o int.
  • Azure Databricks no admite el trabajo con columnas truncadas de tipo decimal.
• El clon incremental sincroniza los cambios de esquema y las propiedades de la tabla de origen. Los cambios de esquema y los archivos de datos escritos directamente en la tabla clonada se invalidan.
• El catálogo de Unity no admite clones poco profundos para tablas Parquet o Docker.
• No se pueden usar patrones globales al definir una ruta de acceso.

Nota:

En Databricks Runtime 11.3 LTS, esta operación no recopila estadísticas de nivel de archivo. Por lo tanto, las tablas de destino no se benefician de la omisión de datos de Delta Lake. Las estadísticas de nivel de archivo se recopilan en Databricks Runtime 12.2 LTS y versiones posteriores.