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. # Prácticas recomendadas para Trino en Amazon EMR La arquitectura de Trino está diseñada para realizar consultas SQL rápidas y distribuidas en grandes conjuntos de datos de varios orígenes de datos siguiendo un modelo de coordinador-trabajador, en el que cada componente desempeña una función especializada en la ejecución de las consultas. Hay algunas áreas o categorías en las que puede centrarse para configurar su clúster de Amazon EMR que ejecuta Trino para obtener el mejor rendimiento. Estos incluyen los siguientes: + Adaptación de los ajustes de configuración del clúster para optimizar la memoria. + Optimización de los ajustes para la partición y la distribución de datos. + Uso del filtrado dinámico para reducir el recuento de resultados de consultas. Algunos de estos ajustes se refinan automáticamente cuando utiliza Trino con Amazon EMR. Otros pueden configurarse manualmente a través de la consola o mediante comandos CLI. Los temas de esta sección ayudan a configurar sus datos y su clúster de forma óptima. **Topics** + [Áreas clave de enfoque para la mejora del rendimiento](emr-trino-performance-areas.md) + [Recopile y utilice estadísticas de tablas](emr-trino-performance-areas-collect-stats.md) + [Desafíos habituales a la hora de escalar las cargas de trabajo de Trino](emr-trino-common-issues.md) # Áreas clave de enfoque para la mejora del rendimiento Trino maximiza el paralelismo de las consultas y la optimización de la memoria. Esta arquitectura proporciona flexibilidad al permitirle consultar múltiples y variados orígenes de datos y, al mismo tiempo, escalar de manera eficiente. Las áreas clave de mejora del rendimiento en Trino incluyen las que se enumeran a continuación. ## Optimización de la memoria La administración de la memoria en Trino es fundamental para lograr un alto rendimiento y estabilidad, especialmente cuando se ejecutan consultas grandes y complejas. Trino utiliza un modelo de memoria distribuida. En este modelo, la memoria se asigna entre los nodos de trabajo para procesar tareas, agregaciones, uniones y otras operaciones. En la siguiente lista, se presenta un conjunto de estos ajustes: + **query.max-memory**: establece la memoria máxima disponible para una sola consulta en todo el clúster. Este es un límite estricto; si una consulta supera esta memoria, fallará. + **consulta. max-memory-per-node** — Define la memoria máxima que puede consumir una consulta en cada nodo de trabajo. Si se establece esto, se garantiza que ninguna consulta monopolice los recursos de ningún trabajador. + **Tamaño del montón de la JVM**: configurado a nivel de JVM, establece el tamaño máximo del montón para el proceso del servidor Trino en cada nodo. **Por lo general, este valor debe ser mayor que las configuraciones relacionadas con la memoria (es la suma de las consultas). **max-memory-per-node**y memoria. heap-headroom-per-node**) en Trino para evitar que el sistema se quede sin memoria a nivel de la JVM. + **memoria. heap-headroom-per-node** — Especifica la cantidad de memoria del búfer que se debe dejar fuera del tamaño del montón de la JVM para operaciones que no sean de consulta. Esto es crucial para garantizar una sobrecarga suficiente para las operaciones internas y la recopilación de elementos no utilizados. ## Filtrado dinámico El filtrado dinámico de Trino es una técnica de optimización que mejora el rendimiento de las consultas al reducir la cantidad de datos procesados, especialmente durante las uniones. Aplica condiciones de filtrado de forma dinámica para limitar los datos escaneados por un lado de una combinación, en función de los datos que se ven en el otro lado, lo que resulta especialmente útil en consultas en las que un lado de la combinación es muy selectivo (lo que significa que contiene un pequeño subconjunto de datos). Está habilitada de forma predeterminada en Amazon EMR. A continuación se muestra una consulta de ejemplo: ``` SELECT orders.order_id, orders.total_amount FROM orders JOIN customers ON orders.customer_id = customers.customer_id WHERE customers.country = 'France'; ``` Sin un filtrado dinámico, Trino escanea toda la tabla de pedidos de una sola vez, aunque solo sea relevante un pequeño subconjunto de clientes (los de Francia). Este enfoque lee todas las filas de la tabla de **pedidos**, lo que se traduce en altos costes de procesamiento I/O . Con el filtrado dinámico, Trino escanea inicialmente la tabla de **clientes** más pequeña, recupera los valores customs\$1id solo de los clientes de Francia y, a continuación, aplica este subconjunto como filtro en los pedidos. Esto significa que solo se escanean las filas relevantes de los **pedidos** (aquellas con un custome\$1id que coincide con el subconjunto filtrado), lo que reduce considerablemente los registros procesados. ## Derrame en el disco En Trino, el almacenamiento de discos permite descargar al disco los resultados de las consultas intermedias, lo que permite completar las consultas que consumen mucha memoria, incluso si superan los límites de memoria establecidos por `query_max_memory` o `query_max_memory_per_node`. De forma predeterminada, Trino impone estos límites para garantizar una asignación de memoria equitativa y evitar que el clúster se bloquee. Sin embargo, cuando una consulta grande supera estos límites, corre el riesgo de ser finalizada. La dispersión de discos soluciona este problema mediante el uso de `revocable memory`, lo que permite que una consulta tome prestada memoria adicional que se puede revocar si se necesitan recursos en otros lugares. Cuando se anula la memoria, los datos intermedios se acumulan en el disco, lo que permite que las consultas continúen procesándose sin sobrepasar los límites de memoria. Tenga en cuenta que una consulta que se ve obligada a extenderse al disco puede tener un tiempo de ejecución más prolongado, por lo que está deshabilitada de forma predeterminada. Para habilitar el derrame en Amazon EMR, utilice la siguiente configuración: + `spill-enabled=true`: permite que el disco se derrame cuando el uso de memoria supera los umbrales disponibles. + `spill-paths`: define los directorios donde se almacenan los datos derramados, `spill-paths=/mnt/spill`. # Recopile y utilice estadísticas de tablas La recopilación de estadísticas de tablas permite al optimizador basado en costes de Trino tomar decisiones informadas sobre las órdenes de unión, el uso de filtros y la reducción de particiones, lo que se traduce en un mejor rendimiento. Puede utilizar el comando `ANALYZE` a fin de recopilar estadísticas para las tablas Hive o Iceberg: ``` ANALYZE sales; ``` Recopilar estadísticas en tablas anchas puede resultar agotador para los recursos. Se recomienda especificar un subconjunto de columnas que se utilicen en las uniones, los filtros o las operaciones de agrupación. Este es otro comando útil. Muestra las estadísticas actuales de una tabla para comprobar si están actualizadas. ``` show stats for table_name; ``` # Desafíos habituales a la hora de escalar las cargas de trabajo de Trino Los principales beneficios de usar Amazon S3 con Trino son la capacidad de S3 para escalar grandes volúmenes de datos y la rentabilidad de S3. Sin embargo, cuando consulta grandes volúmenes de datos, en ocasiones puede producirse una serie de problemas de rendimiento relacionados con el rendimiento. Estos pueden deberse a la forma en que se almacenan los datos, a los ajustes de configuración que restringen el buen rendimiento o a otros motivos. Cuando se producen estos problemas, hay medidas eficaces que puede tomar para evitarlos o mitigarlos. Esta sección comienza con una lista de optimizaciones generales que puede implementar para aumentar el rendimiento de las consultas en grandes volúmenes de datos. A continuación, se detallan los problemas comunes y se proporcionan las mitigaciones para cada uno de ellos. Este tema proviene de la siguiente presentación de la conferencia: [Accelerate performance at scale: Best practices for Trino with Amazon S3](https://www.youtube.com/watch?v=cjUUcHlUKxQ). ## Optimización del diseño de datos para grandes conjuntos de datos Los cuellos de botella en el rendimiento no son infrecuentes cuando se consultan conjuntos de datos de gran tamaño. Sin embargo, existen prácticas recomendadas que puede implementar con el fin de tener una ventaja inicial a la hora de utilizar Trino para consultar datos en Amazon S3. Estos incluyen los siguientes: + **Partición**: significa organizar los datos en una jerarquía y almacenar juntos los datos relacionados en función de atributos afines. La partición permite que las consultas no tengan que escanear tantos datos irrelevantes y mejora el rendimiento de las consultas. Puede usar varias estrategias de partición, como organizar los datos de origen con prefijos, específicamente por rangos de fechas, regiones u otros atributos. Para obtener información más detallada sobre cómo particionar los datos en Amazon S3 para aumentar el rendimiento, consulte la entrada del blog [Comience a administrar particiones para las tablas de Amazon S3 respaldadas por el catálogo de datos de AWS Glue](https://aws.amazon.com/blogs/big-data/get-started-managing-partitions-for-amazon-s3-tables-backed-by-the-aws-glue-data-catalog/) o la publicación Los [10 mejores consejos de ajuste del rendimiento para Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). + **Agrupación en buckets**: agrupar datos relacionados en archivos comunes. Por ejemplo, si consulta datos según una región geográfica, como un estado, puede mejorar el rendimiento de las consultas agrupando todos los datos de un estado concreto en el mismo archivo o grupo de archivos. Para que esto funcione mejor, base la agrupación en buckets en un atributo de datos con una cardinalidad alta, como un estado o una provincia, por ejemplo. Además, puede tener en cuenta sus patrones de consulta. Un ejemplo de esto podría consistir en agrupar los datos de California y Oregón, si las consultas suelen leer datos de esos estados juntos. + **Administración de prefijos de S3**: puede utilizar los prefijos de Amazon S3 para implementar una estrategia de partición. Si utiliza un único prefijo para un bucket de Amazon S3, como una fecha concreta, por ejemplo, esto puede provocar un número elevado de solicitudes y un error HTTP 503. Se recomienda utilizar prefijos para añadir condiciones adicionales y organizar los datos de origen de forma más eficaz. Para obtener más información, consulte [Organizar objetos con prefijos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html) en la documentación de Amazon S3. El siguiente breve ejemplo muestra un prefijo que mejora el rendimiento de las solicitudes: `s3://bucket/country=US/dt=2024-06-13`. En este ejemplo, tanto el país como la fecha están incluidos en el prefijo, lo que resulta en menos lecturas que en un caso en el que el prefijo incluye solo la fecha. La mitigación de los errores HTTP 503 se analiza con más detalle en la sección sobre *ralentización de HTTP* que aparece a continuación en este tema. + **Optimización del tamaño de los datos**: puede ejecutar el comando OPTIMIZE para establecer una configuración que permita que las consultas tengan un mejor rendimiento. Para ejecutarlo en tablas externas de Hive, sigue estos pasos: + Use `OPTIMIZE` con los siguientes parámetros: `hive.non-managed-table-writes-enabled=true`. Para obtener más información sobre esta propiedad, consulte [Hive general configuration properties](https://trino.io/docs/current/connector/hive.html#hive-general-configuration-properties). + Establezca el siguiente parámetro de sesión: `SET SESSION` `catalog.non_transactional_optimize_enabled=true` + Ejecute el comando`OPTIMIZE`: `ALTER TABLE catalog.schema.table EXECUTE optimize(file_size_threshold => '128MB')`. En este caso, `file_size_threshold` es de 100 MB por defecto. Si se aumenta este umbral, como se muestra en el ejemplo, se fusionarán los archivos de menos de 128 MB. + **Configurar los reintentos**: puede aumentar el límite de reintentos, lo que puede mitigar la posibilidad de que se produzcan errores HTTP 503, si configura lo siguiente: `s3.max-error-retries`. Esto se aplica cuando utiliza la TrinoFileSystem API y la versión Trino 449 o posterior. Por otro lado, en el caso de que utilice Amazon EMR con Trino, utilizará EMRFS para acceder a Amazon S3. Con EMRFS, puede aumentar el número de retiradas cambiando el parámetro `fs.s3.maxRetries`. + **Elija una clase de almacenamiento de Amazon S3**: elegir la clase de almacenamiento adecuada para los datos en diferentes momentos de su ciclo de vida puede mejorar tanto el rendimiento como el costo, en función de sus requisitos para recopilaciones de datos específicas. Para obtener más información, consulte [Descripción y administración de clases de almacenamiento de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.htm) en la documentación de Amazon S3. + **Migración hacia Iceberg**: otra solución para mitigar los problemas de rendimiento, específicamente los relacionados con la ejecución de consultas en archivos pequeños, consiste en migrar a tablas de Iceberg. Iceberg tiene características que permiten gestionar bien los archivos pequeños. + **Utilice la compactación automática de datos**: si utiliza tablas Iceberg, la compactación automática de datos con el catálogo de datos de AWS Glue puede optimizar el tamaño de los datos y mejorar el rendimiento de las consultas. ## Desafíos habituales cuando se consultan conjuntos de datos de gran tamaño En esta sección, se incluye una colección de problemas comunes que pueden producirse al acumular un conjunto de datos de gran tamaño en Amazon S3 y consultarlo con Trino. En cada sección, se muestran formas de resolver el problema o reducir su impacto en las consultas. Cada uno de los problemas descritos en las siguientes secciones se ha reproducido y probado con un conector Hive. ### Análisis de datos de gran tamaño Cuando la consulta tiene que escanear conjuntos de datos de gran tamaño, se pueden producir problemas como un rendimiento lento de las consultas y un mayor costo de almacenamiento. Los grandes volúmenes de datos pueden deberse a su rápido crecimiento o a una planificación que no implica el traslado de los datos heredados en un plazo adecuado. Esto puede provocar que las consultas sean más lentas. Para mitigar los impactos en el rendimiento derivados del escaneo de grandes conjuntos de datos, le recomendamos que utilice particiones y agrupaciones en buckets: + La partición agrupa los datos relacionados en función de sus atributos. El uso eficaz de las particiones puede mejorar considerablemente el rendimiento de las consultas. + La agrupación en buckets se refiere a agrupar los datos en archivos o buckets según columnas de datos específicas y relacionadas. Por lo general, agrupar en buckets significa mantener juntos físicamente los archivos de datos de origen relacionados. Para ilustrar cómo puede funcionar la mitigación en escaneos de datos de gran tamaño, supongamos que almacena y consulta datos que tienen registros con un atributo de estado, que puede asignarse a California o Alaska, y que este atributo de estado es una de las condiciones de consulta. Puede mejorar el rendimiento de las consultas almacenando los datos de cada estado en un bucket S3 independiente o dividiendo los datos en función del estado con un prefijo S3. Esta división y agrupación en buckets también pueden mejorar el rendimiento si se basan en una columna adicional, como un atributo de fecha, por ejemplo. **nota** Si una columna tiene una cardinalidad alta y desea utilizarla para agrupar datos, le recomendamos que utilice la agrupación en buckets en este caso. Por otro lado, en general, las claves de partición deberían tener una cardinalidad más baja. **Uso de varios tipos de almacenamiento S3** Por lo general, elige los tipos de almacenamiento en función del rendimiento, el acceso a los datos, la resiliencia y los requisitos de costo de sus cargas de trabajo. Puede haber compensaciones entre el costo y el rendimiento. Es importante elegir la clase de almacenamiento de Amazon S3 adecuada que se adapte a sus patrones de acceso a los datos. Hay dos patrones de acceso principales: + Datos a los que se accede de forma conocida o predecible. Por lo general, si tiene datos a los que se accede con poca frecuencia, S3 Standard IA puede ser una buena opción, ya que ayuda a reducir los costos. Si ha accedido a los datos con frecuencia, S3 Standard es la mejor opción para acceder con Amazon EMR y Trino. + Datos a los que se accede de forma desconocida o impredecible. Esto puede requerir el uso de otras clases de almacenamiento de Amazon S3. Existen compensaciones entre las clases de almacenamiento de S3. Estos incluyen la latencia, el costo de almacenamiento y la disponibilidad. Puede elegir un tipo de almacenamiento de S3 adecuado en función de sus cargas de trabajo y patrones de acceso. Para obtener descripciones de las ventajas de cada clase, consulte [Clases de almacenamiento de Amazon S3](). **Uso de compactación** También puede utilizar la compactación automática de Iceberg, si utiliza tablas de Iceberg, lo que da como resultado tamaños de archivo más óptimos para aumentar la eficiencia de las consultas. Para obtener más información, consulte [AWS Glue Data Catalog now supports automatic compaction of Apache Iceberg tables](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/). ### Errores de ralentización de HTTP Esto ocurre cuando la tasa de solicitudes supera un umbral preconfigurado en un prefijo de Amazon S3. El error HTTP que se produce con más frecuencia cuando se alcanza este estado es el siguiente: **Error 503: reduzca la tasa de solicitudes**. El origen de este problema puede deberse a la presencia de una gran cantidad de archivos pequeños, debido al número de *divisiones* que se deben crear para poder leer los datos. Hay un par de maneras de mitigar el problema: + Aumente el límite de reintentos para las solicitudes de Amazon S3 en Trino. Esto está configurado para los EMRFS que utilizan `fs.s3.maxretries` en Trino 449. + Optimice los tamaños de los archivos, lo que también puede reducir la tasa de solicitudes. Para obtener más información sobre cómo Trino determina el número de divisiones en un conjunto de datos que se van a consultar, consulte [Performance tuning configuration properties](https://trino.io/docs/current/connector/hive.html#performance-tuning-configuration-properties) en la documentación del conector de Hive. ### Dificultad para consultar archivos pequeños La consulta de muchos archivos pequeños puede generar una gran I/O sobrecarga, debido a la gran cantidad de solicitudes GET y LIST, y, posteriormente, afectar negativamente al rendimiento de las consultas. La optimización del tamaño de los archivos puede mejorar el rendimiento de las consultas. Hay unas pocas maneras de hacerlo: + Consolide los datos en menos archivos de gran tamaño. (Por lo general, se recomienda mantener el tamaño de los archivos en unos 128 MB). Puede hacerlo con herramientas al ingerir datos, como en una canalización de ETL, o puede consolidar los datos manualmente. Si estas soluciones no están disponibles, es posible que las opciones restantes sean más adecuadas para usted. + Ejecute el comando `OPTIMIZE`. + Establezca el parámetro `SESSION`. Tenga en cuenta que Iceberg tiene una característica disponible para combinar archivos pequeños en archivos más grandes, que es la compactación automática. Funciona con archivos gestionados con el catálogo de datos de AWS Glue. Para obtener más información, consulte [AWS Glue Data Catalog now supports automatic compaction of Apache Iceberg tables](https://aws.amazon.com/blogs/aws/aws-glue-data-catalog-now-supports-automatic-compaction-of-apache-iceberg-tables/). ### Consultas que incluyen datos que no son necesarios Es habitual que los datos crezcan, por lo que es imprescindible realizar un seguimiento de los patrones de acceso a los datos y moverlos de forma adecuada a medida que envejecen o se vuelven irrelevantes. Esto se debe a que, a medida que aumentan los datos, el rendimiento de las consultas puede degradarse con el tiempo, principalmente debido al enorme volumen de datos que hay que analizar cuando se ejecuta una consulta. Amazon S3 y otros servicios ofrecen orientación para la migración del ciclo de vida de los datos, en la que se muestran las estrategias para mover los datos a diferentes ubicaciones de almacenamiento a medida que se enfrían. Hacer esto también supone una ventaja en cuanto a costos de almacenamiento. Además de la migración de datos, puede utilizar otras estrategias, como eliminar los datos de origen que no sean relevantes para las consultas que está ejecutando. Esto puede llevar algo de trabajo, ya que podría implicar cambiar el esquema de los datos de origen. Sin embargo, su resultado positivo es reducir el volumen de datos y agilizar las consultas. Para obtener más información, consulte [Administración del ciclo de vida de los objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html).