Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Puede usar la funcionalidad de clonación de Azure Databricks para convertir de manera incremental los datos de orígenes de datos de Parquet o Apache Iceberg a tablas Delta administradas o externas.
Azure Databricks clonar para Parquet y Iceberg combina la funcionalidad utilizada para clonar tablas Delta y convertir tablas a 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 emplear la clonación para la ingesta incremental de datos de Parquet o Iceberg
Azure Databricks proporciona una serie de opciones para ingestar datos en el lakehouse. 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.
- Está realizando una migración de Parquet o Iceberg a Delta Lake, pero necesita seguir usando las tablas de origen.
- Debe mantener una sincronización exclusivamente de ingesta entre una tabla de destino y una tabla de origen de producción que recibe nuevas inserciones, actualizaciones y eliminaciones.
- Quiere crear una instantánea compatible con ACID de los datos de origen para informes, aprendizaje automático o ETL por lotes.
¿Cuál es la sintaxis para la clonación?
La clonación para Parquet e Iceberg utiliza la misma sintaxis básica que se emplea para clonar tablas Delta y admite 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 una tabla Parquet o Iceberg en profundidad mediante una ruta de acceso de archivo, utilice 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 utilizando una ruta 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`;
Usted también puede crear clones profundos o superficiales para las tablas Parquet registradas en el metastore, tal como se muestra en los siguientes ejemplos:
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 e Iceberg, se aplican las siguientes limitaciones adicionales:
- Debe registrar tablas de Parquet con particiones en un catálogo como Unity Catalog o el metastore de Hive heredado antes de clonar la tabla y usar su nombre 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.
- 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,longoint. - Azure Databricks no admite el trabajo con columnas truncadas de tipo
decimal.
- En Databricks Runtime 12.2 LTS y versiones posteriores, el único tipo de columna truncado admitido es
- 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 Iceberg.
- 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.