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. # Mejores prácticas para optimizar las cargas de trabajo de Apache Iceberg Iceberg es un formato de tabla diseñado para simplificar la administración de los lagos de datos y mejorar el rendimiento de las cargas de trabajo. Los diferentes casos de uso pueden priorizar diferentes aspectos, como el costo, el rendimiento de lectura, el rendimiento de escritura o la retención de datos, por lo que Iceberg ofrece opciones de configuración para gestionar estas desventajas. En esta sección, se proporciona información para optimizar y ajustar las cargas de trabajo de Iceberg a fin de adaptarlas a sus necesidades. **Topics** + [Prácticas recomendadas generales](best-practices-general.md) + [Optimizar el rendimiento de lectura](best-practices-read.md) + [Optimización del rendimiento de escritura](best-practices-write.md) + [Optimizar el almacenamiento](best-practices-storage.md) + [Mantenimiento de tablas mediante compactación](best-practices-compaction.md) + [Uso de cargas de trabajo de Iceberg en Amazon S3](best-practices-workloads.md) # Prácticas recomendadas generales Sea cual sea su caso de uso, cuando utilice Apache Iceberg en una AWS aplicación, le recomendamos que siga estas prácticas recomendadas generales. + **Utilice la versión 2 del formato Iceberg.** Athena usa el formato Iceberg versión 2 de forma predeterminada. [Cuando utilices Spark en Amazon EMR o AWS Glue para crear tablas de Iceberg, especifica la versión del formato tal y como se describe en la documentación de Iceberg.](https://iceberg.apache.org/docs/nightly/configuration/#reserved-table-properties) + **Utilícela AWS Glue Data Catalog como catálogo de datos.** Athena usa el de forma AWS Glue Data Catalog predeterminada. Cuando utilices Spark en Amazon EMR o AWS Glue para trabajar con Iceberg, añade la siguiente configuración a tu sesión de Spark para usar el. AWS Glue Data Catalog Para obtener más información, consulta la sección [Configuraciones de Spark para Iceberg que aparece AWS Glue anteriormente en](iceberg-glue.md#glue-spark-config) esta guía. ``` "spark.sql.catalog..type": "glue" ``` + **Utilízalo AWS Glue Data Catalog como gestor de bloqueos.** Athena usa el AWS Glue Data Catalog como administrador de bloqueos de forma predeterminada para las tablas Iceberg. Cuando utilices Spark en Amazon EMR o AWS Glue para trabajar con Iceberg, asegúrate de configurar la configuración de tu sesión de Spark para utilizarla AWS Glue Data Catalog como administrador de bloqueos. Para obtener más información, consulta [Optimistic Locking](https://iceberg.apache.org/docs/latest/aws/#optimistic-locking) en la documentación de Iceberg. + **Utilice la compresión Zstandard (ZSTD).** El códec de compresión predeterminado de Iceberg es gzip, que se puede modificar mediante la propiedad table. `write..compression-codec` Athena ya usa ZSTD como códec de compresión predeterminado para las tablas Iceberg. En general, recomendamos usar el códec de compresión ZSTD porque logra un equilibrio entre GZIP y Snappy y ofrece un buen rendimiento sin comprometer la relación de compresión. read/write Además, los niveles de compresión se pueden ajustar para adaptarlos a tus necesidades. Para obtener más información, consulte los [niveles de compresión ZSTD en Athena en](https://docs.aws.amazon.com/athena/latest/ug/compression-support-zstd-levels.html) la documentación de Athena. Puede que Snappy ofrezca el mejor rendimiento general de lectura y escritura, pero tiene una relación de compresión inferior a la de GZIP y ZSTD. Si prioriza el rendimiento, incluso si eso implica almacenar grandes volúmenes de datos en Amazon S3, Snappy podría ser la mejor opción. # Optimizar el rendimiento de lectura En esta sección se describen las propiedades de la tabla que se pueden ajustar para optimizar el rendimiento de lectura, independientemente del motor. ## Particiones Al igual que con las tablas de Hive, Iceberg utiliza las particiones como capa principal de indexación para evitar leer archivos de metadatos y datos innecesarios. Las estadísticas de las columnas también se tienen en cuenta como una capa secundaria de indexación para mejorar aún más la planificación de las consultas, lo que se traduce en un mejor tiempo de ejecución general. ### Partición de datos Para reducir la cantidad de datos que se escanean al consultar las tablas de Iceberg, elige una estrategia de partición equilibrada que se ajuste a los patrones de lectura esperados: + Identifica las columnas que se utilizan con frecuencia en las consultas. Estas son las candidatas ideales para particionar. Por ejemplo, si normalmente consulta datos de un día determinado, un ejemplo natural de columna de partición sería una columna de fecha. + Elija una columna de partición de baja cardinalidad para evitar crear un número excesivo de particiones. Demasiadas particiones pueden aumentar el número de archivos de la tabla, lo que puede afectar negativamente al rendimiento de las consultas. Como regla general, «demasiadas particiones» se puede definir como un escenario en el que el tamaño de los datos de la mayoría de las particiones es inferior a 2 a 5 veces el valor establecido por`target-file-size-bytes`. **nota** Si normalmente realizas consultas con filtros en una columna de cardinalidad alta (por ejemplo, una `id` columna que puede tener miles de valores), utiliza la función de partición oculta de Iceberg con transformaciones de cubos, como se explica en la siguiente sección. ### Usa particiones ocultas Si sus consultas suelen filtrar por un derivado de una columna de la tabla, utilice particiones ocultas en lugar de crear nuevas columnas de forma explícita para que funcionen como particiones. Para obtener más información sobre esta función, consulte la [documentación de Iceberg](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning). Por ejemplo, en un conjunto de datos que tiene una columna de marca de tiempo (por ejemplo,`2023-01-01 09:00:00`), en lugar de crear una nueva columna con la fecha analizada (por ejemplo,`2023-01-01`), utilice transformaciones de partición para extraer la parte de fecha de la marca de tiempo y crear estas particiones sobre la marcha. Los casos de uso más comunes de la partición oculta son: + **Particionar por fecha u hora**, cuando los datos tienen una columna de marca de tiempo. Iceberg ofrece múltiples transformaciones para extraer las partes de fecha u hora de una marca de tiempo. + El **particionamiento en una función hash de una columna**, cuando la columna de partición tiene una cardinalidad alta y daría como resultado demasiadas particiones. La transformación de cubos de Iceberg agrupa varios valores de partición en menos particiones ocultas (de cubos) mediante el uso de funciones de hash en la columna de particiones. Consulte las [transformaciones de partición](https://iceberg.apache.org/spec/#partition-transforms) en la documentación de Iceberg para obtener una descripción general de todas las transformaciones de partición disponibles. Las columnas que se utilizan para crear particiones ocultas pueden formar parte de los predicados de las consultas mediante el uso de funciones SQL habituales, como y. `year()` `month()` Los predicados también se pueden combinar con operadores como y. `BETWEEN` `AND` **nota** Iceberg no puede realizar una depuración de particiones para funciones que producen un tipo de datos diferente; por ejemplo,. `substring(event_time, 1, 10) = '2022-01-01'` ### Utilice la evolución de particiones Utilice la [evolución de particiones de Iceberg](https://iceberg.apache.org/docs/latest/evolution/#partition-evolution) cuando la estrategia de partición existente no sea óptima. Por ejemplo, si eliges particiones horarias que resultan ser demasiado pequeñas (de solo unos pocos megabytes cada una), considera cambiarlas a particiones diarias o mensuales. Puede utilizar este enfoque cuando al principio no esté clara cuál es la mejor estrategia de partición para una tabla y desee afinar su estrategia de partición a medida que obtenga más información. Otro uso eficaz de la evolución de las particiones es cuando los volúmenes de datos cambian y la estrategia de particionamiento actual pierde eficacia con el paso del tiempo. Para obtener instrucciones sobre cómo hacer evolucionar las particiones, consulte las [extensiones SQL de ALTER TABLE](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) en la documentación de Iceberg.  ## Ajustar el tamaño de los archivos La optimización del rendimiento de las consultas implica minimizar la cantidad de archivos pequeños en las tablas. Para obtener un buen rendimiento de las consultas, generalmente recomendamos mantener los archivos Parquet y ORC de más de 100 MB. El tamaño del archivo también afecta a la planificación de las consultas en las tablas Iceberg. A medida que aumenta el número de archivos de una tabla, también lo hace el tamaño de los archivos de metadatos. Los archivos de metadatos más grandes pueden ralentizar la planificación de las consultas. Por lo tanto, cuando el tamaño de la tabla aumente*,* aumente el tamaño del archivo**** para reducir la expansión exponencial de los metadatos. Utilice las siguientes prácticas recomendadas para crear archivos del tamaño adecuado en las tablas Iceberg. ### Establezca el tamaño del archivo de destino y del grupo de filas Iceberg ofrece los siguientes parámetros de configuración clave para ajustar el diseño del archivo de datos. Le recomendamos que utilice estos parámetros para establecer el tamaño del archivo de destino y el tamaño del grupo de filas o del campo. | **Parámetro** | **Valor predeterminado** | **Comentario** | | --- |--- |--- | | `write.target-file-size-bytes` | 512 MB | Este parámetro especifica el tamaño máximo de archivo que creará Iceberg. Sin embargo, es posible que algunos archivos se escriban con un tamaño inferior a este límite. | | `write.parquet.row-group-size-bytes` | 128 MB | Tanto Parquet como ORC almacenan los datos en fragmentos para que los motores puedan evitar leer todo el archivo en algunas operaciones. | | `write.orc.stripe-size-bytes` | 64 MB | | `write.distribution-mode` | Ninguno, para la versión 1.1 y anteriores de IcebergHash, a partir de la versión 1.2 de Iceberg | Iceberg solicita a Spark que clasifique los datos entre sus tareas antes de guardarlos en el almacenamiento. | + En función del tamaño esperado de la tabla, sigue estas pautas generales: + **Tablas pequeñas** (hasta unos pocos gigabytes): reduzca el tamaño del archivo de destino a 128 MB. Reduzca también el tamaño del grupo de filas o de las franjas (por ejemplo, a 8 o 16 MB). + **Tablas de tamaño mediano a grande** (desde unos pocos gigabytes hasta cientos de gigabytes): los valores predeterminados son un buen punto de partida para estas tablas. Si las consultas son muy selectivas, ajuste el tamaño del grupo de filas o de las franjas (por ejemplo, a 16 MB). + **Tablas muy grandes** (cientos de gigabytes o terabytes): aumente el tamaño del archivo de destino a 1024 MB o más y considere la posibilidad de aumentar el tamaño del grupo de filas o de las franjas si las consultas suelen extraer grandes conjuntos de datos. + Para garantizar que las aplicaciones de Spark que escriben en tablas de Iceberg creen archivos del tamaño adecuado, defina la `write.distribution-mode` propiedad en o. `hash` `range` Para obtener una explicación detallada de la diferencia entre estos modos, consulta Cómo [escribir modos de distribución en la documentación](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes) de Iceberg. Estas son pautas generales. Le recomendamos que realice pruebas para identificar los valores más adecuados para sus tablas y cargas de trabajo específicas. ### Realice una compactación regular Las configuraciones de la tabla anterior establecen un tamaño de archivo máximo que pueden crear las tareas de escritura, pero no garantizan que los archivos tengan ese tamaño. Para garantizar un tamaño de archivo adecuado, ejecute la compactación con regularidad para combinar archivos pequeños en archivos más grandes. Para obtener una guía detallada sobre cómo ejecutar la compactación, consulte la sección [Compactación de iceberg más adelante en esta](best-practices-compaction.md) guía. ## Optimice las estadísticas de las columnas Iceberg utiliza las estadísticas de columnas para depurar los archivos, lo que mejora el rendimiento de las consultas al reducir la cantidad de datos que escanean las consultas. Para aprovechar las estadísticas de columnas, asegúrate de que Iceberg recopile las estadísticas de todas las columnas que se utilizan con frecuencia en los filtros de consultas. De forma predeterminada, Iceberg recopila las estadísticas solo de las [100 primeras columnas de cada tabla, tal y como se define en](https://github.com/apache/iceberg/blob/ae15c7e36973501b40443e75816d3eac39eddc90/core/src/main/java/org/apache/iceberg/TableProperties.java#L276) la propiedad de la tabla. `write.metadata.metrics.max-inferred-column-defaults` Si la tabla tiene más de 100 columnas y las consultas suelen hacer referencia a columnas fuera de las 100 primeras columnas (por ejemplo, puede que las consultas se filtren por la columna 132), asegúrese de que Iceberg recopile las estadísticas de esas columnas. Existen dos opciones para lograrlo: + Al crear la tabla Iceberg, reordene las columnas para que las columnas que necesite para las consultas se encuentren dentro del rango de columnas establecido por `write.metadata.metrics.max-inferred-column-defaults` (el valor predeterminado es 100). Nota: Si no necesita estadísticas sobre 100 columnas, puede ajustar la `write.metadata.metrics.max-inferred-column-defaults` configuración al valor que desee (por ejemplo, 20) y reordenar las columnas para que las columnas que necesite para leer y escribir consultas estén dentro de las 20 primeras columnas de la parte izquierda del conjunto de datos. + Si utilizas solo unas pocas columnas en los filtros de consulta, puedes deshabilitar la propiedad general para la recopilación de métricas y elegir de forma selectiva columnas individuales para recopilar estadísticas, como se muestra en este ejemplo: ``` .tableProperty("write.metadata.metrics.default", "none") .tableProperty("write.metadata.metrics.column.my_col_a", "full") .tableProperty("write.metadata.metrics.column.my_col_b", "full") ``` Nota: Las estadísticas de columnas son más eficaces cuando los datos se ordenan en esas columnas. Para obtener más información, consulte la sección [Establecer el orden de clasificación](#read-sort-order) más adelante en esta guía. ## Elija la estrategia de actualización adecuada Utilice una copy-on-write estrategia para optimizar el rendimiento de lectura, cuando las operaciones de escritura más lentas sean aceptables para su caso de uso. Esta es la estrategia por defecto que utiliza Iceberg. Copy-on-write da como resultado un mejor rendimiento de lectura, ya que los archivos se escriben directamente en el almacenamiento de forma optimizada para la lectura. Sin embargo, en comparación con merge-on-read, cada operación de escritura lleva más tiempo y consume más recursos informáticos. Esto supone un equilibrio clásico entre la latencia de lectura y la de escritura. Por lo general, copy-on-write es ideal para casos de uso en los que la mayoría de las actualizaciones se colocan en las mismas particiones de tabla (por ejemplo, para cargas de lotes diarias). Copy-on-write las configuraciones (`write.update.mode``write.delete.mode`, y`write.merge.mode`) se pueden configurar a nivel de tabla o de forma independiente en el lado de la aplicación. ## Utilice la compresión ZSTD Puede modificar el códec de compresión utilizado por Iceberg mediante la propiedad table. `write..compression-codec` Se recomienda utilizar el códec de compresión ZSTD para mejorar el rendimiento general de las tablas. De forma predeterminada, las versiones 1.3 y anteriores de Iceberg utilizan la compresión GZIP, que proporciona un read/write rendimiento más lento en comparación con el ZSTD. Nota: Es posible que algunos motores utilicen valores predeterminados diferentes. Este es el caso de [las tablas Iceberg que se crean con Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-support-iceberg.html) o Amazon EMR versión 7.x. ## Establezca el orden de clasificación Para mejorar el rendimiento de lectura en las tablas Iceberg, se recomienda ordenar la tabla en función de una o más columnas que se utilizan con frecuencia en los filtros de consulta. La clasificación, combinada con las estadísticas de columnas de Iceberg, puede hacer que la depuración de archivos sea considerablemente más eficiente, lo que se traduce en operaciones de lectura más rápidas. La clasificación también reduce el número de solicitudes de Amazon S3 para consultas que utilizan las columnas de ordenación de los filtros de consultas. Puedes establecer un orden de clasificación jerárquico a nivel de tabla ejecutando una sentencia de lenguaje de definición de datos (DDL) con Spark. Para ver las opciones disponibles, consulta la documentación de [Iceberg](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table--write-ordered-by). Una vez establecido el orden de clasificación, los grabadores aplicarán este orden a las operaciones de escritura de datos posteriores en la tabla Iceberg. Por ejemplo, en las tablas divididas por fecha (`yyyy-mm-dd`), donde la mayoría de las consultas filtran por`uuid`, puedes usar la opción DDL `Write Distributed By Partition Locally Ordered` para asegurarte de que Spark escriba archivos con rangos que no se superpongan. El siguiente diagrama ilustra cómo mejora la eficiencia de las estadísticas de columnas cuando se ordenan las tablas. En el ejemplo, la tabla ordenada solo necesita abrir un archivo y se beneficia al máximo de la partición y el archivo de Iceberg. En la tabla sin ordenar, `uuid` puede existir alguno en cualquier archivo de datos, por lo que la consulta debe abrir todos los archivos de datos. ![\[Establecer el orden de clasificación en las tablas Iceberg\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/setting-sort-order.png) Cambiar el orden de clasificación no afecta a los archivos de datos existentes. Puede utilizar la compactación de iceberg para aplicar el orden de clasificación a los mismos. El uso de tablas ordenadas por Iceberg puede reducir los costes de la carga de trabajo, como se muestra en el siguiente gráfico. ![\[Compare los costos de las mesas Iceberg y Parquet\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cost-graph.png) Estos gráficos resumen los resultados de utilizar el índice de referencia TPC-H para las tablas Hive (Parquet) en comparación con las tablas ordenadas de Iceberg. Sin embargo, los resultados pueden ser diferentes para otros conjuntos de datos o cargas de trabajo. ![\[Resultados de la prueba TPC-H entre las tablas Parquet y las tablas Iceberg\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/s3-api-calls.png) # Optimización del rendimiento de escritura En esta sección se describen las propiedades de las tablas que se pueden ajustar para optimizar el rendimiento de escritura en las tablas Iceberg, independientemente del motor. ## Configure el modo de distribución de la tabla Iceberg ofrece varios modos de distribución de escritura que definen cómo se distribuyen los datos de escritura en las tareas de Spark. Para obtener una descripción general de los modos disponibles, consulta Cómo [escribir los modos de distribución](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes) en la documentación de Iceberg. Para los casos de uso que dan prioridad a la velocidad de escritura, especialmente en cargas de trabajo de streaming, `write.distribution-mode` establézcalo en. `none` Esto garantiza que Iceberg no solicite una reorganización adicional de Spark y que los datos se escriban a medida que estén disponibles en las tareas de Spark. Este modo es especialmente adecuado para las aplicaciones de streaming estructurado de Spark. **nota** Si se configura el modo de distribución de escritura, se `none` suelen producir numerosos archivos pequeños, lo que reduce el rendimiento de lectura. Se recomienda compactarlos con regularidad para consolidar estos archivos pequeños en archivos del tamaño adecuado para el rendimiento de las consultas. ## Elija la estrategia de actualización adecuada Utilice una merge-on-read**** estrategia para optimizar el rendimiento de escritura cuando las operaciones de lectura más lentas de los datos más recientes sean aceptables para su caso de uso. Cuando lo usas merge-on-read, Iceberg graba las actualizaciones y las elimina en el almacenamiento como pequeños archivos independientes. Cuando se lee la tabla, el lector debe combinar estos cambios con los archivos base para obtener la última vista de los datos. Esto se traduce en una penalización del rendimiento de las operaciones de lectura, pero acelera la escritura de actualizaciones y eliminaciones. Por lo general, merge-on-read es ideal para transmitir cargas de trabajo con actualizaciones o trabajos con pocas actualizaciones distribuidas en muchas particiones de tablas. Puede configurar merge-on-read las configuraciones (`write.update.mode``write.delete.mode`, y`write.merge.mode`) a nivel de tabla o de forma independiente desde el punto de vista de la aplicación. Su uso merge-on-read requiere una compactación regular para evitar que el rendimiento de lectura se degrade con el tiempo. La compactación reconcilia las actualizaciones y las eliminaciones con los archivos de datos existentes para crear un nuevo conjunto de archivos de datos, lo que elimina la penalización de rendimiento en la parte de lectura. [De forma predeterminada, la compactación de Iceberg no fusiona ni elimina los archivos a menos que se cambie el valor predeterminado de la `delete-file-threshold` propiedad por un valor menor (consulte la documentación de Iceberg).](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files) Para obtener más información sobre la compactación, consulte la sección [Compactación de iceberg](best-practices-compaction.md) más adelante en esta guía. ## Elija el formato de archivo correcto Iceberg admite la escritura de datos en los formatos Parquet, ORC y Avro. El formato predeterminado es Parquet. Parquet y ORC son formatos en columnas que ofrecen un rendimiento de lectura superior, pero generalmente son más lentos de escribir. Esto representa el equilibrio típico entre el rendimiento de lectura y el de escritura. Si la velocidad de escritura es importante para su caso de uso, como en el caso de cargas de trabajo en streaming, considere la posibilidad de escribir en formato Avro configurándolo `Avro` en `write-format` las opciones de grabación. Como Avro es un formato basado en filas, proporciona tiempos de escritura más rápidos a costa de un rendimiento de lectura más lento. Para mejorar el rendimiento de lectura, ejecute una compactación regular para combinar y transformar archivos Avro pequeños en archivos Parquet más grandes. El resultado del proceso de compactación depende de la configuración de la `write.format.default` tabla. El formato predeterminado de Iceberg es Parquet, por lo que si escribe en Avro y, a continuación, ejecuta la compactación, Iceberg transformará los archivos de Avro en archivos de Parquet. A continuación se muestra un ejemplo: ``` spark.sql(f""" CREATE TABLE IF NOT EXISTS glue_catalog.{DB_NAME}.{TABLE_NAME} ( Col_1 float, <<<…other columns…>> ts timestamp) USING iceberg PARTITIONED BY (days(ts)) OPTIONS ( 'format-version'='2', write.format.default'=parquet) """) query = df \ .writeStream \ .format("iceberg") \ .option("write-format", "avro") \ .outputMode("append") \ .trigger(processingTime='60 seconds') \ .option("path", f"glue_catalog.{DB_NAME}.{TABLE_NAME}") \ .option("checkpointLocation", f"s3://{BUCKET_NAME}/checkpoints/iceberg/") .start() ``` # Optimizar el almacenamiento Al actualizar o eliminar los datos de una tabla Iceberg, se aumenta el número de copias de los datos, como se muestra en el siguiente diagrama. Lo mismo ocurre con la compactación en ejecución: aumenta el número de copias de datos en Amazon S3. Esto se debe a que Iceberg trata los archivos subyacentes a todas las tablas como inmutables. ![\[Resultados de la actualización o eliminación de datos en una tabla de Iceberg\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/optimizing-storage.png) Siga las prácticas recomendadas de esta sección para gestionar los costes de almacenamiento. ## Habilite S3 Intelligent-Tiering Utilice la clase de almacenamiento [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html) para mover automáticamente los datos al nivel de acceso más rentable cuando cambien los patrones de acceso. Esta opción no supone una sobrecarga operativa ni afecta al rendimiento.   Nota: No utilice los niveles opcionales (como Archive Access y Deep Archive Access) de S3 Intelligent-Tiering with Iceberg tables. Para archivar datos, consulte las directrices de la siguiente sección. También puede usar [las reglas del ciclo de vida de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) para establecer sus propias reglas para mover objetos a otra clase de almacenamiento de Amazon S3, como S3 Standard-IA o S3 One Zone-IA (consulte [Transiciones compatibles y restricciones relacionadas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#lifecycle-general-considerations-transition-sc) en la documentación de Amazon S3). ## Archive o elimine las instantáneas históricas Por cada transacción confirmada (inserción, actualización, combinación, compactación) en una tabla de Iceberg, se crea una nueva versión o instantánea de la tabla. Con el tiempo, el número de versiones y el número de archivos de metadatos de Amazon S3 se acumulan. Es necesario conservar las instantáneas de una tabla para funciones como el aislamiento de las instantáneas, la reversión de tablas y las consultas sobre viajes en el tiempo. Sin embargo, los costes de almacenamiento aumentan con la cantidad de versiones que se conservan. En la siguiente tabla se describen los patrones de diseño que puede implementar para administrar los costos en función de sus requisitos de retención de datos. | **Patrón de diseño** | **Solución** | **Casos de uso** | | --- |--- |--- | | **Eliminar instantáneas antiguas** | Utilice la [sentencia VACUUM](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) de Athena para eliminar las instantáneas antiguas. Esta operación no implica ningún coste informático. [Como alternativa, puedes usar Spark en Amazon EMR o AWS Glue para eliminar instantáneas. Para obtener más información, consulta expire\$1snapshots en la documentación de Iceberg.](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) | Este enfoque elimina las instantáneas que ya no se necesitan para reducir los costos de almacenamiento. Puede configurar cuántas instantáneas deben conservarse o durante cuánto tiempo, en función de sus requisitos de retención de datos.Esta opción realiza una eliminación definitiva de las instantáneas. No puede revertir ni viajar en el tiempo a instantáneas caducadas. | | **Establezca políticas de retención para instantáneas específicas** | Utilice etiquetas para marcar instantáneas específicas y definir una política de retención en Iceberg. Para obtener más información, consulte las [etiquetas históricas](https://iceberg.apache.org/docs/latest/branching/#historical-tags) en la documentación de Iceberg. Por ejemplo, puedes conservar una instantánea al mes durante un año mediante la siguiente sentencia SQL en Spark on Amazon EMR: 
ALTER TABLE glue_catalog.db.table 
CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 365 DAYS
Usa Spark en Amazon EMR o AWS Glue para eliminar las instantáneas intermedias restantes sin etiquetar. | Este patrón es útil para cumplir con los requisitos empresariales o legales que requieren que muestres el estado de una tabla en un momento dado del pasado. Al colocar políticas de retención en instantáneas etiquetadas específicas, puede eliminar otras instantáneas (sin etiquetar) que se hayan creado. De esta forma, puede cumplir con los requisitos de retención de datos sin conservar todas las instantáneas creadas. | | **Archive las instantáneas antiguas** | Usa las etiquetas de Amazon S3 para marcar objetos con Spark. (Las etiquetas Amazon S3 son diferentes de las etiquetas Iceberg; para obtener más información, consulte la [documentación de Iceberg](https://iceberg.apache.org/docs/latest/aws/#s3-tags)). Por ejemplo: 
spark.sql.catalog.my_catalog.s3.delete-enabled=false and \
spark.sql.catalog.my_catalog.s3.delete.tags.my_key=to_archive
Usa Spark en Amazon EMR o AWS Glue para [eliminar](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) instantáneas. Al utilizar la configuración del ejemplo, este procedimiento etiqueta los objetos y los separa de los metadatos de la tabla Iceberg en lugar de eliminarlos de Amazon S3. Utilice las reglas del ciclo de vida de S3 para transferir los objetos etiquetados `to_archive` a una de las clases de [almacenamiento de S3 Glacier](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html). Para consultar datos archivados: [Restaure los objetos archivados](https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects.html) (este paso no es necesario si los objetos se han transferido a la clase de almacenamiento Amazon Glacier Instant Retrieval). Utilice el [procedimiento register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) de Iceberg para registrar la instantánea como una tabla en el catálogo. Para obtener instrucciones detalladas, consulte la entrada del AWS blog [Mejore la eficiencia operativa de las tablas Apache Iceberg basadas en los lagos de datos de Amazon S3](https://aws.amazon.com/blogs/big-data/improve-operational-efficiencies-of-apache-iceberg-tables-built-on-amazon-s3-data-lakes/).  | Este patrón le permite conservar todas las versiones e instantáneas de las tablas a un costo menor.No puede viajar en el tiempo ni volver a las instantáneas archivadas sin restaurar primero esas versiones como tablas nuevas. Esto suele ser aceptable para fines de auditoría.Puede combinar este enfoque con el patrón de diseño anterior y establecer políticas de retención para instantáneas específicas. | ## Elimine los archivos huérfanos En determinadas situaciones, las aplicaciones de Iceberg pueden fallar antes de que usted confirme sus transacciones. Esto deja los archivos de datos en Amazon S3. Como no se ha realizado ninguna confirmación, estos archivos no se asociarán a ninguna tabla, por lo que puede que tenga que limpiarlos de forma asíncrona. Para gestionar estas eliminaciones, puede utilizar la [declaración VACUUM](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) en Amazon Athena. Esta declaración elimina las instantáneas y también elimina los archivos huérfanos. Esto resulta muy rentable, ya que Athena no cobra por el coste informático de esta operación. Además, no es necesario programar ninguna operación adicional al utilizar el `VACUUM` estado de cuenta. Como alternativa, puedes usar Spark en Amazon EMR o AWS Glue para ejecutar el `remove_orphan_files` procedimiento. Esta operación tiene un coste informático y debe programarse de forma independiente. Para obtener más información, consulte la [documentación de Iceberg](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files). # Mantenimiento de tablas mediante compactación Iceberg incluye funciones que le permiten llevar a cabo [operaciones de mantenimiento de la tabla](https://iceberg.apache.org/docs/latest/maintenance/) después de escribir los datos en la tabla. Algunas operaciones de mantenimiento se centran en simplificar los archivos de metadatos, mientras que otras mejoran la forma en que se agrupan los datos en los archivos para que los motores de consultas puedan localizar de forma eficiente la información necesaria para responder a las solicitudes de los usuarios. Esta sección se centra en las optimizaciones relacionadas con la compactación. ## Compactación de iceberg En Iceberg, puede utilizar la compactación para realizar cuatro tareas: + Combinar archivos pequeños en archivos más grandes que, por lo general, tienen un tamaño superior a 100 MB. Esta técnica se conoce como *embalaje en papelera*. + Combinación de archivos eliminados con archivos de datos. Los archivos de eliminación se generan mediante actualizaciones o eliminaciones que utilizan este enfoque. merge-on-read + (Re) ordenar los datos de acuerdo con los patrones de consulta. Los datos se pueden escribir sin ningún orden de clasificación o con un orden de clasificación adecuado para escrituras y actualizaciones. + Agrupar los datos mediante curvas que rellenan espacios para optimizarlos para distintos patrones de consulta, especialmente la clasificación en orden z. Activado AWS, puede ejecutar operaciones de compactación y mantenimiento de mesas para Iceberg a través de Amazon Athena o mediante Spark en Amazon EMR o. AWS Glue Al ejecutar la compactación mediante el procedimiento [rewrite\$1data\$1files](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files), puede ajustar varios botones para controlar el comportamiento de compactación. En el siguiente diagrama se muestra el comportamiento predeterminado del empaquetado de contenedores. Comprender la compactación del embalaje de contenedores es clave para entender las implementaciones de clasificación jerárquica y clasificación en orden Z, ya que son extensiones de la interfaz de embalaje de contenedores y funcionan de manera similar. La principal diferencia es el paso adicional necesario para ordenar o agrupar los datos. ![\[Comportamiento de empaquetado por defecto en las tablas Iceberg\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/compaction.png) En este ejemplo, la tabla Iceberg consta de cuatro particiones. Cada partición tiene un tamaño y un número de archivos diferentes. Si inicias una aplicación Spark para ejecutar la compactación, la aplicación crea un total de cuatro grupos de archivos para procesarlos. Un grupo de archivos es una abstracción de Iceberg que representa un conjunto de archivos que se procesarán en una sola tarea de Spark. Es decir, la aplicación de Spark que ejecuta la compactación creará cuatro trabajos de Spark para procesar los datos. ## Ajustar el comportamiento de compactación Las siguientes propiedades clave controlan la forma en que se seleccionan los archivos de datos para la compactación: + [MAX\$1FILE\$1GROUP\$1SIZE\$1BYTES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_FILE_GROUP_SIZE_BYTES) establece el límite de datos para un solo grupo de archivos (trabajo de Spark) en 100 GB de forma predeterminada. Esta propiedad es especialmente importante para las tablas sin particiones o las tablas con particiones que ocupan cientos de gigabytes. Al establecer este límite, puede desglosar las operaciones para planificar el trabajo y avanzar, al tiempo que evita que se agoten los recursos del clúster. Nota: Cada grupo de archivos se ordena por separado. Por lo tanto, si desea realizar una ordenación a nivel de partición, debe ajustar este límite para que coincida con el tamaño de la partición. + El valor predeterminado de [MIN\$1FILE\$1SIZE\$1BYTES o MIN\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_BYTES) [es el 75 por ciento del tamaño del archivo de destino establecido a nivel de tabla](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_DEFAULT_RATIO). Por ejemplo, si una tabla tiene un tamaño objetivo de 512 MB, cualquier archivo que sea inferior a 384 MB se incluirá en el conjunto de archivos que se compactarán. + El valor predeterminado de [MAX\$1FILE\$1SIZE\$1BYTES o MAX\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_BYTES) [es el 180 por ciento del tamaño del archivo de destino](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_DEFAULT_RATIO). Al igual que ocurre con las dos propiedades que establecen los tamaños mínimos de los archivos, estas propiedades se utilizan para identificar los archivos candidatos para el trabajo de compactación. + [MIN\$1INPUT\$1FILES especifica el número mínimo de archivos](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_INPUT_FILES) que se deben compactar si el tamaño de la partición de una tabla es menor que el tamaño del archivo de destino. El valor de esta propiedad se utiliza para determinar si vale la pena compactar los archivos en función del número de archivos (el valor predeterminado es 5). + [DELETE\$1FILE\$1THRESHOLD](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#DELETE_FILE_THRESHOLD) especifica el número mínimo de operaciones de eliminación de un archivo antes de incluirlo en la compactación. A menos que especifique lo contrario, la compactación no combina los archivos de eliminación con los archivos de datos. Para habilitar esta funcionalidad, debe establecer un valor umbral mediante esta propiedad. Este umbral es específico de los archivos de datos individuales, por lo que si lo establece en 3, un archivo de datos solo se reescribirá si hay tres o más archivos de eliminación que hagan referencia a él. Estas propiedades proporcionan información sobre la formación de los grupos de archivos del diagrama anterior. Por ejemplo, la partición etiquetada `month=01` incluye dos grupos de archivos porque supera el límite de tamaño máximo de 100 GB. Por el contrario, la `month=02` partición contiene un solo grupo de archivos porque tiene menos de 100 GB. La `month=03` partición no cumple con el requisito mínimo predeterminado de cinco archivos de entrada. Como resultado, no se compactará. Por último, aunque la `month=04` partición no contenga datos suficientes para formar un único archivo del tamaño deseado, los archivos se compactarán porque la partición incluye más de cinco archivos pequeños. Puede configurar estos parámetros para que Spark se ejecute en Amazon EMR o. AWS Glue En el caso de Amazon Athena, puede administrar propiedades similares mediante las propiedades de la [tabla](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties) (que comienzan con el prefijo`optimize_`). ## Ejecutar la compactación con Spark en Amazon EMR o AWS Glue En esta sección se describe cómo dimensionar correctamente un clúster de Spark para ejecutar la utilidad de compactación de Iceberg. El siguiente ejemplo utiliza Amazon EMR Serverless, pero puede utilizar la misma metodología en Amazon EMR en EC2 o EKS, o en. AWS Glue Puede aprovechar la correlación entre los grupos de archivos y las tareas de Spark para planificar los recursos del clúster. Para procesar los grupos de archivos de forma secuencial, teniendo en cuenta el tamaño máximo de 100 GB por grupo de archivos, puedes configurar las siguientes [propiedades de Spark](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults): + `spark.dynamicAllocation.enabled` = `FALSE` + `spark.executor.memory` = `20 GB` + `spark.executor.instances` = `5` Si desea acelerar la compactación, puede escalar horizontalmente aumentando el número de grupos de archivos que se compactan en paralelo. También puede escalar Amazon EMR mediante un escalado manual o dinámico. + **Escalado manual** (por ejemplo, en un factor de 4) + `MAX_CONCURRENT_FILE_GROUP_REWRITES`= `4` (nuestro factor) + `spark.executor.instances`= `5` (valor utilizado en el ejemplo) x `4` (nuestro factor) = `20` + `spark.dynamicAllocation.enabled` = `FALSE` + **Escalado dinámico** + `spark.dynamicAllocation.enabled`= `TRUE ` (predeterminado, no es necesario realizar ninguna acción) + [MAX\$1CONCURRENT\$1FILE\$1GROUP\$1REWRITES =](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_CONCURRENT_FILE_GROUP_REWRITES) `N ` (alinee este valor con`spark.dynamicAllocation.maxExecutors`, que es 100 de forma predeterminada; según las configuraciones del ejecutor del ejemplo, puede establecerlo en 20) `N` Estas son pautas para ayudar a dimensionar el clúster. Sin embargo, también debes monitorear el rendimiento de tus trabajos de Spark para encontrar la mejor configuración para tus cargas de trabajo. ## Ejecutar la compactación con Amazon Athena [Athena ofrece una implementación de la utilidad de compactación de Iceberg como una función gestionada a través de la declaración OPTIMIZE.](https://docs.aws.amazon.com/athena/latest/ug/optimize-statement.html) Puede utilizar esta afirmación para ejecutar la compactación sin tener que evaluar la infraestructura. Esta instrucción agrupa los archivos pequeños en archivos más grandes mediante el algoritmo de empaquetado en contenedores y combina los archivos de eliminación con los archivos de datos existentes. Para agrupar los datos mediante una ordenación jerárquica o una ordenación en orden z, utiliza Spark en Amazon EMR o. AWS Glue Puedes cambiar el comportamiento predeterminado de la `OPTIMIZE` declaración al crear la tabla pasando las propiedades de la tabla en la `CREATE TABLE` declaración, o después de crearla usando la declaración. `ALTER TABLE` Para ver los valores predeterminados, consulte la documentación de [Athena](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties). ## Recomendaciones para ejecutar la compactación | **Caso de uso** | **Recomendación** | | --- |--- | | **Realizar la compactación del embalaje de contenedores según un cronograma** | Usa la `OPTIMIZE` sentencia de Athena si no sabes cuántos archivos pequeños contiene tu tabla. El modelo de precios de Athena se basa en los datos escaneados, por lo que si no hay archivos que compactar, estas operaciones no conllevan ningún coste. Para evitar que se agoten los tiempos de espera en las mesas de Athena, ejecute `OPTIMIZE` de forma gradual. per-table-partition Utilice Amazon EMR o el AWS Glue escalado dinámico cuando espere compactar grandes volúmenes de archivos pequeños. | | **Ejecute la compactación del embalaje de contenedores en función de eventos** | Utilice Amazon EMR o el AWS Glue escalado dinámico cuando espere compactar grandes volúmenes de archivos pequeños. | | **Ejecutar la compactación para ordenar los datos** | Utilice Amazon EMR o AWS Glue, porque la clasificación es una operación cara y es posible que necesite transferir datos al disco. | | **Ejecute la compactación para agrupar los datos mediante la clasificación en orden z** | Utilice Amazon EMR o AWS Glue, porque la clasificación en orden z es una operación muy cara y es posible que necesite transferir datos al disco. | | **Ejecuta la compactación en particiones que otras aplicaciones podrían actualizar debido a la llegada tardía de los datos** | Utilice Amazon EMR o. AWS Glue Habilite la propiedad Iceberg [PARTIAL\$1PROGRESS\$1ENABLED](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#PARTIAL_PROGRESS_ENABLED). Al utilizar esta opción, Iceberg divide el resultado de la compactación en varias confirmaciones. Si se produce una colisión (es decir, si el archivo de datos se actualiza mientras se está compactando), esta configuración reduce el coste del reintento al limitarlo a la confirmación que incluye el archivo afectado. De lo contrario, puede que tenga que volver a compactar todos los archivos. | | **Ejecutar la compactación en particiones frías (particiones de datos que ya no reciben escrituras activas)** | Utilice Amazon EMR o. AWS Glue En el `rewrite_data_files` procedimiento, especifique un `where` predicado que excluya las particiones escritas activamente. Esta estrategia evita los conflictos de datos entre los grabadores y los trabajos de compactación, y deja solo los conflictos de metadatos que Iceberg puede resolver automáticamente. | # Uso de cargas de trabajo de Iceberg en Amazon S3 En esta sección se describen las propiedades de Iceberg que puede utilizar para optimizar la interacción de Iceberg con Amazon S3. ## Evite el particionamiento en caliente (errores HTTP 503) Algunas aplicaciones de lagos de datos que se ejecutan en Amazon S3 gestionan millones o miles de millones de objetos y procesan petabytes de datos. Esto puede provocar que los prefijos reciban un gran volumen de tráfico, lo que normalmente se detecta a través de errores HTTP 503 (servicio no disponible). Para evitar este problema, utilice las siguientes propiedades de Iceberg: + `write.distribution-mode``hash``range`Configúrelo para que Iceberg escriba archivos de gran tamaño, lo que se traduce en menos solicitudes de Amazon S3. Esta es la configuración preferida y debería abordar la mayoría de los casos. + Si sigue experimentando 503 errores debido al inmenso volumen de datos en sus cargas de trabajo, puede hacerlo `true` en Iceberg. `write.object-storage.enabled` Esto le indica a Iceberg que codifique los nombres de los objetos y distribuya la carga entre varios prefijos aleatorios de Amazon S3. Para obtener más información sobre estas propiedades, consulte [Escribir propiedades](https://iceberg.apache.org/docs/latest/configuration/#write-properties) en la documentación de Iceberg. ## Utilice las operaciones de mantenimiento de Iceberg para liberar los datos no utilizados Para gestionar las tablas de Iceberg, puede utilizar la API principal de Iceberg, los clientes de Iceberg (como Spark) o los servicios gestionados como Amazon Athena. Para eliminar archivos antiguos o no utilizados de Amazon S3, le recomendamos que utilice únicamente Iceberg native APIs para [eliminar instantáneas](https://iceberg.apache.org/docs/latest/maintenance/#expire-snapshots), [eliminar archivos de metadatos antiguos y eliminar archivos](https://iceberg.apache.org/docs/latest/maintenance/#remove-old-metadata-files) [huérfanos](https://iceberg.apache.org/docs/latest/maintenance/#delete-orphan-files). El uso de Amazon S3 APIs a través de Boto3, el SDK de Amazon S3 o AWS Command Line Interface (AWS CLI), o el uso de cualquier otro método que no sea de Iceberg para sobrescribir o eliminar archivos de Amazon S3 de una tabla de Iceberg, provoca que la tabla se dañe y se produzcan errores en las consultas. ## Replique los datos en todas partes Regiones de AWS Al almacenar tablas Iceberg en Amazon S3, puede utilizar las funciones integradas en Amazon S3, como la [replicación entre regiones (CRR) y los [puntos de acceso multiregión (MRAP)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html), para replicar datos en varias. Regiones de AWS El MRAP proporciona un punto de enlace global para que las aplicaciones accedan a los depósitos de S3 que se encuentran en varios. Regiones de AWS Iceberg no admite rutas relativas, pero puede usar MRAP para realizar operaciones de Amazon S3 mediante el mapeo de cubos a puntos de acceso. El MRAP también se integra perfectamente con el proceso de replicación entre regiones de Amazon S3, que introduce un retraso de hasta 15 minutos. Debe replicar los archivos de datos y metadatos. **importante** Actualmente, la integración de Iceberg con el MRAP solo funciona con Apache Spark. Si necesitas realizar una conmutación por error a la secundaria Región de AWS, tienes que planificar la redirección de las consultas de los usuarios a un entorno de Spark SQL (como Amazon EMR) en la región de conmutación por error. Las funciones CRR y MRAP te ayudan a crear una solución de replicación entre regiones para las tablas de Iceberg, como se muestra en el siguiente diagrama. ![\[Replicación entre regiones para tablas Iceberg\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cross-region-replication.png) Para configurar esta arquitectura de replicación entre regiones: 1. Cree tablas mediante la ubicación del MRAP. Esto garantiza que los archivos de metadatos de Iceberg apunten a la ubicación del MRAP en lugar de a la ubicación física del depósito. 1. Replique archivos Iceberg mediante Amazon S3 MRAP. ****El MRAP admite la replicación de datos con un acuerdo de nivel de servicio (SLA) de 15 minutos. Iceberg evita que las operaciones de lectura introduzcan inconsistencias durante la replicación. 1. Haga que las tablas estén disponibles AWS Glue Data Catalog en la región secundaria. Puede elegir entre dos opciones. + Configure una canalización para replicar los metadatos de la tabla Iceberg mediante AWS Glue Data Catalog la replicación. Esta utilidad está disponible en el repositorio de [replicación de GitHub Glue Catalog y Lake Formation Permissions](https://github.com/aws-samples/lake-formation-pemissions-sync). Este mecanismo basado en eventos replica las tablas de la región de destino en función de los registros de eventos. + Registre las tablas en la región secundaria cuando necesite realizar una conmutación por error. Para esta opción, puede utilizar la utilidad anterior o el [procedimiento Iceberg register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) y dirigirlo al archivo más reciente. `metadata.json`