Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Migración de tablas existentes a Iceberg Esta sección se centra en la migración de las tablas de estilo Hive existentes al formato Iceberg. [https://parquet.apache.org/](https://parquet.apache.org/) Esta información no se aplica a las tablas que ya utilizan formatos de tabla modernos, como Linux Foundation, Delta Lake o Apache Hudi. Para migrar sus tablas actuales de estilo Hive al formato Iceberg, puede utilizar la migración de datos local o completa:  + La [migración in situ](table-migration-inplace.md) es el proceso de generar los archivos de metadatos de Iceberg sobre los archivos de datos existentes. + La [migración completa de datos](table-migration-full.md) crea la capa de metadatos de Iceberg y también reescribe los archivos de datos existentes de la tabla original a la nueva tabla de Iceberg. En las siguientes secciones se proporciona una descripción detallada de cada método de migración, incluidas step-by-step las instrucciones y consideraciones para su implementación. Para obtener más información sobre estas estrategias de migración, consulte la sección sobre [migración de tablas](https://iceberg.apache.org/docs/latest/table-migration/) de la documentación de Iceberg. Tras revisar los detalles de los métodos de migración de datos internos y completos, consulta las dos secciones clave siguientes para ayudarte en el proceso de toma de decisiones: + [La elección de una estrategia de migración](migration-strategy.md) proporciona orientación a través de una serie de preguntas y escenarios que le ayudarán a determinar el enfoque de migración más adecuado en función de sus requisitos y casos de uso específicos. + El [resumen de las opciones de migración](migration-options.md) proporciona una tabla completa en la que se comparan las características y consideraciones clave de las diferentes opciones de migración. Esta tabla sirve como guía de referencia rápida y ofrece una comparación de características para ayudarle a comprender las desventajas técnicas entre los métodos. # Migración in situ La migración in situ elimina la necesidad de volver a escribir todos los archivos de datos. En su lugar, los archivos de metadatos de Iceberg se generan y se vinculan a los archivos de datos existentes. Este método suele ser más rápido y rentable, especialmente para conjuntos de datos o tablas de gran tamaño que tienen formatos de archivo compatibles, como Parquet, Avro y ORC. **nota** La migración in situ no se puede utilizar al migrar a [Amazon S3 Tables](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables.html). Iceberg ofrece dos opciones principales para implementar la migración in situ: + Se utiliza el procedimiento de [captura](https://iceberg.apache.org/docs/latest/spark-procedures/#snapshot) de pantalla para crear una nueva tabla de Iceberg y, al mismo tiempo, mantener la tabla de origen sin cambios. Para obtener más información, consulte la [tabla de instantáneas](https://iceberg.apache.org/docs/latest/table-migration/#snapshot-table) en la documentación de Iceberg. + Uso del procedimiento de [migración](https://iceberg.apache.org/docs/latest/spark-procedures/#migrate) para crear una nueva tabla de Iceberg como sustitución de la tabla de origen. Para obtener más información, consulte [Migrate Table](https://iceberg.apache.org/docs/latest/table-migration/#migrate-table) en la documentación de Iceberg. Aunque este procedimiento funciona con Hive Metastore (HMS), actualmente no es compatible con. AWS Glue Data Catalog El [procedimiento de replicación de la tabla, que se describe más AWS Glue Data Catalog adelante en](#replicate-data-catalog) esta guía, proporciona una solución alternativa para lograr un resultado similar con el catálogo de datos. Después de realizar la migración in situ mediante uno `snapshot` o varios archivos de datos`migrate`, es posible que algunos archivos de datos permanezcan sin migrar. Esto suele ocurrir cuando los escritores siguen escribiendo en la tabla de origen durante o después de la migración. Para incorporar los archivos restantes a la tabla Iceberg, puede utilizar el procedimiento [add\$1files](https://iceberg.apache.org/docs/latest/spark-procedures/#add_files). Para obtener más información, consulte [Añadir archivos](https://iceberg.apache.org/docs/latest/table-migration/#add-files) en la documentación de Iceberg. Supongamos que tiene una `products` tabla basada en Parquet que se creó y rellenó en Athena de la siguiente manera: ``` CREATE EXTERNAL TABLE mydb.products ( product_id INT, product_name STRING ) PARTITIONED BY (category STRING) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/products/'; INSERT INTO mydb.products VALUES (1001, 'Smartphone', 'electronics'), (1002, 'Laptop', 'electronics'), (2001, 'T-Shirt', 'clothing'), (2002, 'Jeans', 'clothing'); ``` En las siguientes secciones se explica cómo puede utilizar los `migrate` procedimientos `snapshot` y con esta tabla. ## Opción 1: procedimiento de captura de pantalla El `snapshot` procedimiento crea una nueva tabla Iceberg con un nombre diferente, pero que replica el esquema y la partición de la tabla de origen. Esta operación deja la tabla de origen completamente inalterada durante y después de la acción. De forma eficaz, crea una copia ligera de la tabla, que resulta especialmente útil para probar escenarios o explorar datos sin correr el riesgo de modificar la fuente de datos original. Este enfoque permite un período de transición en el que tanto la tabla original como la tabla Iceberg permanecen disponibles (consulte las notas al final de esta sección). Una vez finalizadas las pruebas, puede pasar la nueva mesa Iceberg a la de producción haciendo la transición de todos los grabadores y lectores a la nueva tabla. Puede ejecutar el `snapshot` procedimiento mediante Spark en cualquier modelo de implementación de Amazon EMR (por ejemplo, Amazon EMR en EC2, Amazon EMR en EKS, EMR Serverless) y. AWS Glue Para probar la migración in situ con el procedimiento de Spark, siga estos pasos`snapshot`: 1. Abre una aplicación de Spark y configura la sesión de Spark con los siguientes ajustes: + `"spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"` + `"spark.sql.catalog.spark_catalog":"org.apache.iceberg.spark.SparkSessionCatalog"` + `"spark.sql.catalog.spark_catalog.type":"glue"` + `"spark.hadoop.hive.metastore.client.factory.class":"com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory"` 1. Ejecute el `snapshot` procedimiento para crear una nueva tabla de Iceberg que apunte a los archivos de datos de la tabla original: ``` spark.sql(f""" CALL system.snapshot( source_table => 'mydb.products', table => 'mydb.products_iceberg', location => 's3://amzn-s3-demo-bucket/products_iceberg/' ) """ ).show(truncate=False) ``` El marco de datos de salida contiene `imported_files_count` (el número de archivos que se agregaron). 1. Valide la nueva tabla consultándola: ``` spark.sql(f""" SELECT * FROM mydb.products_iceberg LIMIT 10 """ ).show(truncate=False) ``` **Notas** Tras ejecutar el procedimiento, cualquier modificación del archivo de datos en la tabla de origen desincronizará la tabla generada. Los archivos nuevos que añada no estarán visibles en la tabla Iceberg y los archivos que elimine afectarán a las capacidades de consulta de la tabla Iceberg. Para evitar los problemas de sincronización: Si la nueva tabla Iceberg está destinada a ser utilizada en producción, detenga todos los procesos que escriban en la tabla original y redirija los procesos a la nueva tabla. Si necesita un período de transición o si la nueva tabla de Iceberg es para realizar pruebas, consulte [Mantener sincronizadas las tablas de Iceberg tras una migración local, más adelante en esta sección, para obtener instrucciones sobre cómo mantener la sincronización](#migrate-sync) de las tablas. Al utilizar `snapshot` este procedimiento, la `gc.enabled` propiedad se establece `false` en las propiedades de la tabla Iceberg creada. Esta configuración prohíbe acciones como `expire_snapshots``remove_orphan_files`, o `DROP TABLE` con la `PURGE` opción, que eliminarían físicamente los archivos de datos. Las operaciones de eliminación o fusión tipo iceberg, que no afectan directamente a los archivos fuente, siguen estando permitidas. Para que su nueva tabla Iceberg sea completamente funcional, sin límites en cuanto a las acciones que eliminan físicamente los archivos de datos, puede cambiar la propiedad de la `gc.enabled` tabla a. `true` Sin embargo, esta configuración permitirá realizar acciones que afecten a los archivos de datos de origen, lo que podría dañar el acceso a la tabla original. Por lo tanto, cambie la `gc.enabled` propiedad solo si ya no necesita mantener la funcionalidad de la tabla original. Por ejemplo: ``` spark.sql(f""" ALTER TABLE mydb.products_iceberg SET TBLPROPERTIES ('gc.enabled' = 'true'); """) ``` ## Opción 2: procedimiento de migración El `migrate` procedimiento crea una nueva tabla Iceberg que tiene el mismo nombre, esquema y partición que la tabla de origen. Cuando se ejecuta este procedimiento, bloquea la tabla de origen y le cambia el nombre a `_BACKUP_` (o a un nombre personalizado especificado en el parámetro del `backup_table_name` procedimiento). **nota** Si establece el parámetro de `drop_backup` procedimiento en`true`, la tabla original no se conservará como copia de seguridad. En consecuencia, el procedimiento de la `migrate` tabla requiere que se detengan todas las modificaciones que afecten a la tabla de origen antes de realizar la acción. Antes de ejecutar el `migrate` procedimiento: + Detenga todos los grabadores que interactúen con la tabla fuente. + Modifique los lectores y escritores que no sean compatibles de forma nativa con Iceberg para habilitar la compatibilidad con Iceberg. Por ejemplo: + Athena sigue trabajando sin modificaciones. + Spark requiere: + Archivos Iceberg Java Archive (JAR) que se incluirán en la ruta de clases (consulte las secciones Cómo [trabajar con Iceberg en Amazon EMR y Trabajar con](iceberg-emr.md) [Iceberg AWS Glue](iceberg-glue.md) en las secciones anteriores de esta guía). + Las siguientes configuraciones del catálogo de sesiones de Spark (se utilizan `SparkSessionCatalog` para añadir compatibilidad con Iceberg y, al mismo tiempo, mantener las funcionalidades de catálogo integradas para tablas que no son de Iceberg): + `"spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"` + `"spark.sql.catalog.spark_catalog":"org.apache.iceberg.spark.SparkSessionCatalog"` + `"spark.sql.catalog.spark_catalog.type":"glue"` + `"spark.hadoop.hive.metastore.client.factory.class":"com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory"` Tras ejecutar el procedimiento, puedes reiniciar las grabadoras con su nueva configuración de Iceberg. Actualmente, el `migrate` procedimiento no es compatible con el AWS Glue Data Catalog, porque el catálogo de datos no admite la `RENAME` operación. Por lo tanto, le recomendamos que utilice este procedimiento únicamente cuando trabaje con Hive Metastore. Si utiliza el catálogo de datos, consulte la [siguiente sección](#replicate-data-catalog) para ver un enfoque alternativo. Puede ejecutar el `migrate` procedimiento en todos los modelos de implementación de Amazon EMR (Amazon EMR en EC2, Amazon EMR en EKS, EMR Serverless) y AWS Glue, pero requiere una conexión configurada a Hive Metastore. Amazon EMR en EC2 es la opción recomendada porque proporciona una configuración integrada de Hive Metastore, que minimiza la complejidad de la configuración. Para probar la migración in situ con el procedimiento `migrate` Spark desde un clúster de Amazon EMR en EC2 configurado con Hive Metastore, siga estos pasos: 1. Inicie una aplicación de Spark y configure la sesión de Spark para usar la implementación del catálogo de Iceberg Hive. Por ejemplo, si utiliza la `pyspark` CLI: ``` pyspark --conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions --conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog --conf spark.sql.catalog.spark_catalog.type=hive ``` 1. Cree una `products` tabla en Hive Metastore. Esta es la tabla de origen, que ya existe en una migración típica. 1. Cree la tabla Hive `products` externa en Hive Metastore para que apunte a los datos existentes en Amazon S3: ``` spark.sql(f""" CREATE EXTERNAL TABLE products ( product_id INT, product_name STRING ) PARTITIONED BY (category STRING) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/products/'; """ ) ``` 1. Agregue las particiones existentes mediante el comando: `MSCK REPAIR TABLE` ``` spark.sql(f""" MSCK REPAIR TABLE products """ ) ``` 1. Confirme que la tabla contiene datos ejecutando una `SELECT` consulta: ``` spark.sql(f""" SELECT * FROM products """ ).show(truncate=False) ``` Código de salida de ejemplo: ![\[Ejemplo del resultado de la validación de datos durante la migración de la tabla Iceberg.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/in-place-1.png) 1. Utilice el procedimiento de Iceberg: `migrate` ``` df_res=spark.sql(f""" CALL system.migrate( table => 'default.products' ) """ ) df_res.show() ``` El marco de datos de salida contiene `migrated_files_count` (el número de archivos que se agregaron a la tabla Iceberg): ![\[Ejemplo de resultado de la validación del recuento de archivos durante la migración de la tabla Iceberg.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/in-place-2.png) 1. Confirme que se creó la tabla de respaldo: ``` spark.sql("show tables").show() ``` Código de salida de ejemplo: ![\[Ejemplo de resultado de la validación de copias de seguridad durante la migración de la tabla Iceberg.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/in-place-3.png) 1. Valide la operación consultando la tabla de Iceberg: ``` spark.sql(f""" SELECT * FROM products """ ).show(truncate=False) ``` **Notas** Tras ejecutar el procedimiento, todos los procesos actuales que consultan o escriben en la tabla de origen se verán afectados si no están configurados correctamente con el soporte de Iceberg. Por lo tanto, le recomendamos que siga estos pasos: Detenga todos los procesos utilizando la tabla de origen antes de la migración. Realice la migración. Reactive los procesos utilizando la configuración de Iceberg adecuada. Si se producen modificaciones en los archivos de datos durante el proceso de migración (se añaden archivos nuevos o se eliminan archivos), la tabla generada no estará sincronizada. Para ver las opciones de sincronización, consulte [Mantener sincronizadas las tablas de Iceberg tras una migración local](#migrate-sync) más adelante en esta sección. ## Replicar el procedimiento de migración de tablas en AWS Glue Data Catalog Puede replicar el resultado del procedimiento de migración AWS Glue Data Catalog (haciendo una copia de seguridad de la tabla original y sustituyéndola por una tabla Iceberg) siguiendo estos pasos: 1. Utilice el procedimiento de captura de pantalla para crear una nueva tabla de iceberg que apunte a los archivos de datos de la tabla original. 1. Haga una copia de seguridad de los metadatos de la tabla original en el catálogo de datos: 1. Utilice la [GetTable](https://docs.aws.amazon.com/glue/latest/webapi/API_GetTable.html)API para recuperar la definición de la tabla de origen. 1. Usa la [GetPartitions](https://docs.aws.amazon.com/glue/latest/webapi/API_GetPartitions.html)API para recuperar la definición de partición de la tabla fuente. 1. Utilice la [CreateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_CreateTable.html)API para crear una tabla de respaldo en el catálogo de datos. 1. Utilice la [BatchCreatePartition](https://docs.aws.amazon.com/glue/latest/webapi/API_BatchCreatePartition.html)API [CreatePartition](https://docs.aws.amazon.com/glue/latest/webapi/API_CreatePartition.html)o para registrar las particiones en la tabla de respaldo del catálogo de datos. 1. Cambie la propiedad de la tabla `gc.enabled` Iceberg `false` a para habilitar todas las operaciones de la tabla. 1. Elimine la tabla original. 1. Localice el archivo JSON de metadatos de la tabla Iceberg en la carpeta de metadatos de la ubicación raíz de la tabla. 1. Registre la nueva tabla en el catálogo de datos mediante el procedimiento [register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) con el nombre de la tabla original y la ubicación del `metadata.json` archivo que se creó mediante el procedimiento: `snapshot` ``` spark.sql(f""" CALL system.register_table( table => 'mydb.products', metadata_file => '{iceberg_metadata_file}' ) """ ).show(truncate=False) ``` ## Mantener sincronizadas las tablas de Iceberg tras la migración in situ El `add_files` procedimiento proporciona una forma flexible de incorporar los datos existentes en las tablas de Iceberg. En concreto, registra los archivos de datos existentes (como los archivos Parquet) haciendo referencia a sus rutas absolutas en la capa de metadatos de Iceberg. De forma predeterminada, el procedimiento agrega archivos de todas las particiones de tabla a una tabla de Iceberg, pero puede agregar archivos de particiones específicas de forma selectiva. Este enfoque selectivo es particularmente útil en varios escenarios: + Cuando se agregan nuevas particiones a la tabla de origen después de la migración inicial. + Cuando se agregan o eliminan archivos de datos de las particiones existentes después de la migración inicial. Sin embargo, si se vuelven a añadir particiones modificadas, primero se debe eliminar la partición. Más adelante en esta sección se proporciona más información al respecto. Estas son algunas consideraciones para utilizar el `add_file` procedimiento después de realizar (`snapshot`o`migrate`) la migración in situ, a fin de mantener la nueva tabla de Iceberg sincronizada con los archivos de datos de origen: + Cuando se agreguen nuevos datos a las nuevas particiones de la tabla de origen, utilice el `add_files` procedimiento con la `partition_filter` opción de incorporar estas adiciones de forma selectiva en la tabla de Iceberg: ``` spark.sql(f""" CALL system.add_files( source_table => 'mydb.products', table => 'mydb.products_iceberg', partition_filter => map('category', 'electronics') ).show(truncate=False) ``` o bien: ``` spark.sql(f""" CALL system.add_files( source_table => '`parquet`.`s3://amzn-s3-demo-bucket/products/`', table => 'mydb.products_iceberg', partition_filter => map('category', 'electronics') ).show(truncate=False) ``` + El `add_files` procedimiento busca archivos en toda la tabla de origen o en particiones específicas cuando se especifica la `partition_filter` opción e intenta añadir todos los archivos que encuentre a la tabla de Iceberg. De forma predeterminada, la propiedad del `check_duplicate_files` procedimiento está establecida en`true`, lo que impide que el procedimiento se ejecute si los archivos ya existen en la tabla Iceberg. Esto es importante porque no hay una opción integrada para omitir los archivos agregados anteriormente y, al deshabilitarlos, los archivos se `check_duplicate_files` añadirán dos veces, lo que generará duplicados. Cuando se agreguen nuevos archivos a la tabla de origen, siga estos pasos: 1. Para particiones nuevas, `add_files` utilícelo con `partition_filter` a para importar solo los archivos de la nueva partición. 1. En el caso de las particiones existentes, elimine primero la partición de la tabla de Iceberg y, a continuación, vuelva a ejecutarla `add_files` para esa partición, especificando la. `partition_filter` Por ejemplo: ``` # We initially perform in-place migration with snapshot spark.sql(f""" CALL system.snapshot( source_table => 'mydb.products', table => 'mydb.products_iceberg', location => 's3://amzn-s3-demo-bucket/products_iceberg/' ) """ ).show(truncate=False) # Then on the source table, some new files were generated under the category='electronics' partition. Example: spark.sql(""" INSERT INTO mydb.products VALUES (1003, 'Tablet', 'electronics') """) # We delete the modified partition from the Iceberg table. Note this is a metadata operation only spark.sql(""" DELETE FROM mydb.products_iceberg WHERE category = 'electronics' """) # We add_files from the modified partition spark.sql(""" CALL system.add_files( source_table => 'mydb.products', table => 'mydb.products_iceberg', partition_filter => map('category', 'electronics') ) """).show(truncate=False) ``` **nota** Cada `add_files` operación genera una nueva instantánea de la tabla de Iceberg con datos adjuntos. ## Elegir la estrategia de migración local adecuada Para elegir la mejor estrategia de migración local, tenga en cuenta las preguntas de la siguiente tabla. | Pregunta | Recomendación | Explicación | | --- | --- | --- | | ¿Desea realizar una migración rápida sin tener que volver a escribir los datos y, al mismo tiempo, mantener accesibles las tablas de Hive e Iceberg para realizar pruebas o realizar una transición gradual? | `snapshot`procedimiento seguido de procedimiento `add_files` | Utilice el `snapshot` procedimiento para crear una nueva tabla Iceberg clonando el esquema y haciendo referencia a los archivos de datos, sin modificar la tabla de origen. Utilice el `add_files` procedimiento para incorporar las particiones que se agregaron o modificaron después de la migración, teniendo en cuenta que volver a agregar las particiones modificadas requiere primero eliminarlas. | | ¿Utiliza Hive Metastore y desea reemplazar la tabla de Hive por una tabla de Iceberg inmediatamente, sin tener que volver a escribir los datos? | `migrate``add_files`procedimiento seguido de procedimiento | Utilice `migrate` este procedimiento para crear una tabla Iceberg, hacer una copia de seguridad de la tabla de origen y sustituir la tabla original por la versión Iceberg. **Nota:** Esta opción es compatible con Hive Metastore, pero no con. AWS Glue Data Catalog Utilice el `add_files` procedimiento para incorporar las particiones que se agregaron o modificaron después de la migración, teniendo en cuenta que volver a añadir las particiones modificadas requiere primero eliminarlas. | | ¿Está utilizando la tabla Hive por una tabla Iceberg AWS Glue Data Catalog y desea sustituirla inmediatamente, sin tener que volver a escribir los datos? | Adaptación del `migrate` procedimiento, seguida del procedimiento `add_files` | Replicar `migrate` el comportamiento del procedimiento: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/table-migration-inplace.html) **Nota:** Esta opción requiere la gestión manual de las llamadas a la AWS Glue API para la copia de seguridad de los metadatos. Utilice el `add_files` procedimiento para incorporar las particiones que se agregaron o modificaron después de la migración. Tenga en cuenta que, para volver a agregar las particiones modificadas, primero es necesario eliminarlas. | # Migración completa de datos La migración completa de datos recrea los archivos de datos y los metadatos. Este enfoque lleva más tiempo y requiere recursos informáticos adicionales en comparación con la migración in situ. Sin embargo, la migración completa de los datos ofrece importantes oportunidades para mejorar la calidad de las tablas y optimizar los patrones de acceso y almacenamiento de datos. Durante la migración completa de los datos, puede realizar varias operaciones beneficiosas, como la validación de los datos para garantizar su integridad y corrección, las modificaciones del esquema para cumplir mejor los requisitos actuales y los ajustes de la estrategia de partición para mejorar el rendimiento de las consultas. También puede reordenar los datos para optimizar los patrones de acceso comunes, implementar la partición oculta de Iceberg para mejorar la eficacia de las consultas y realizar la conversión del formato de archivo (por ejemplo, de CSV a Parquet) si lo desea. Estas capacidades hacen que la migración completa de datos sea ideal para la transición al formato Iceberg y para refinar y optimizar de manera integral su estrategia de almacenamiento de datos. Si bien la migración completa de los datos requiere más tiempo y recursos por adelantado, las mejoras resultantes en la calidad de los datos, la organización y el rendimiento de las consultas pueden proporcionar beneficios a largo plazo. Para implementar una migración de datos completa, utilice una de las siguientes opciones: + Usa la declaración `CREATE TABLE ... AS SELECT` ([CTAS](https://iceberg.apache.org/docs/latest/spark-ddl/#create-table--as-select)) en Spark (en Amazon EMR AWS Glue o) o en Athena. Puede establecer la especificación de partición y las propiedades de la tabla de la nueva tabla Iceberg mediante las cláusulas y. `PARTITIONED BY` `TBLPROPERTIES` Puede cambiar el esquema y las particiones de la nueva tabla según sus necesidades en lugar de heredarlos de la tabla de origen. + Lee la tabla de origen y escribe los datos como una nueva tabla Iceberg mediante Spark en Amazon AWS Glue EMR o. Para obtener más información, consulta [Cómo crear una tabla en la documentación](https://iceberg.apache.org/docs/nightly/spark-getting-started/#creating-a-table) de Iceberg. # Elección de una estrategia de migración Al realizar la transición al formato Iceberg, es crucial elegir entre la migración local o la migración completa. Para determinar el enfoque más adecuado para sus necesidades específicas, tenga en cuenta las siguientes preguntas y recomendaciones: | Pregunta | Recomendación | | --- | --- | | **¿Qué formato tiene el archivo de datos (por ejemplo, CSV o Apache Parquet)?** | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-strategy.html) | | **¿Desea actualizar o consolidar el esquema de la tabla?** | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-strategy.html) | | **¿Se beneficiaría la tabla de cambiar la estrategia de partición?** | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-strategy.html) | | **¿Sería beneficioso para la tabla añadir o cambiar la estrategia de ordenación?** | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-strategy.html) | | **¿La tabla tiene muchos archivos pequeños?** | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-strategy.html) | # Resumen de las opciones de migración En esta tabla se resumen las principales características y consideraciones de cada opción de migración. | **Característica** | **Migración in situ** [instantánea](table-migration-inplace.md#in-place-snapshot) | **Migración in situ** [migrate](table-migration-inplace.md#in-place-migrate) | **Migración completa de datos** [CTAS o (CREAR TABLA \$1 INSERTAR)](table-migration-full.md) | | --- | --- | --- | --- | | **Mejoras en el diseño de los datos como parte del proceso de migración** | | | | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-options.html) | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-yes.png) Sí | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-options.html) | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-yes.png) Sí | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-options.html) | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-yes.png) Sí | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-options.html) | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-yes.png) Sí | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-options.html) | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-yes.png) Sí | | **Formatos de archivo compatibles** | Parquet, Avro, ORC | Parquet, Avro, ORC | Parquet, Avro, ORC, JSON, CSV | | **Sustitución de la tabla fuente por una tabla Iceberg** | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No(crea una tabla nueva, pero con pasos adicionales puede reemplazar la tabla de origen) | ![\[Yes\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-yes.png) Sí(crea una tabla de respaldo y sustituye la tabla de origen por una tabla Iceberg) | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No(crea una tabla nueva) | | **Impacto en la tabla de origen** | | | | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-options.html) | Corrompe la tabla de fuentes | Daña la tabla de respaldo | Seguro, la fuente no se ve afectada | | **Impacto en una mesa de iceberg** | | | | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-options.html) | Daña la tabla Iceberg | Corrompe la mesa Iceberg | No afecta a la mesa Iceberg | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/migration-options.html) | No está visible en la tabla nueva(es necesario incorporar una partición con`add_files`) | No está visible en la nueva tabla(es necesario incorporar una partición con`add_files`) | No está visible en la nueva tabla(necesito `INSERT INTO` la nueva mesa) | | **Costo** | Bajo | Bajo | Más alto (reescritura completa de los datos) | | **Velocidad de migración** | Fast | Fast | Más lento | | **Se puede usar para migrar a Amazon S3 Tables** | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-yes.png) Sí | | **Requiere un DDL manual** | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No(el esquema y las particiones se copian de la tabla fuente) | ![\[No\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/icon-no.png) No(el esquema y las particiones se copian de la tabla fuente) | Si usa CTAS, solo requiere especificar la partición | | **El mejor uso** | Migración rápida sin reescribir los datos, lo que permite side-by-side utilizar Hive e Iceberg para realizar pruebas o realizar una transición gradual. | Sustituir una tabla de Hive sin tener que volver a escribir los datos cuando sea aceptable un cambio inmediato. | Optimización completa de Iceberg con reescritura de datos. Ideal para rediseñar particiones o esquemas, o para mejorar el diseño y el rendimiento. Se recomienda siempre que sea posible. |