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. Estos son candidatos 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 portarget-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.

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 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 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 tiempo.

Para obtener instrucciones sobre cómo hacer evolucionar las particiones, consulte las extensiones SQL de ALTER TABLE 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 Iceberg versión 1.1 y versiones anteriores Hash, 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 medianas o grandes (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 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 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 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 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.

C opy-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).

opy-on-write Las configuraciones C (write.update.modewrite.delete.mode, ywrite.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.<file_type>.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 rendimiento de lectura/escritura 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 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. Tras establecer el orden de clasificación, los redactores 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 poruuid, 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.

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.

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.