Mantenimiento de tablas mediante compactación

Iceberg incluye funciones que le permiten realizar operaciones de mantenimiento de la tabla 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_data_files, puede ajustar varios botones para controlar el comportamiento de compactación. El siguiente diagrama 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.

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_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 el agotamiento de 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_FILE_SIZE_BYTES o MIN_FILE_SIZE_DEFAULT_RATIO es el 75 por ciento del tamaño del archivo de destino establecido a nivel de tabla. 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_FILE_SIZE_BYTES o MAX_FILE_SIZE_DEFAULT_RATIO es el 180 por ciento del tamaño del archivo de destino. 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_INPUT_FILES especifica el número mínimo de archivos 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_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 (que comienzan con el prefijooptimize_).

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 Amazon EC2 o Amazon EKS, o en. AWS Glue

Puede aprovechar la correlación entre los grupos de archivos y los trabajos 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:

• 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_CONCURRENT_FILE_GROUP_REWRITES = N (alinee este valor conspark.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. 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.

Recomendaciones para ejecutar la compactación

Caso de uso	Recomendación
Realizar la compactación del embalaje de contenedores según un cronograma	Use la OPTIMIZE sentencia de Athena si no sabe cuántos archivos pequeños contiene su 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_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.