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. # Trino Trino es un motor de consultas de código abierto diseñado para consultas interactivas en una amplia gama de origen de datos. Estos pueden incluir bases de datos relacionales, datos basados en archivos, datos HDFS y más. El propósito más común de Trino con Amazon EMR es ejecutar consultas SQL complejas en conjuntos de datos de gran tamaño almacenados en Amazon S3. También es compatible con ANSI SQL, lo que hace que sea familiar para los ingenieros de bases de datos, los analistas de datos y los científicos de datos que estén familiarizados con SQL. **nota** PrestoSQL pasó a llamarse Trino en diciembre de 2020. Las versiones 6.4.0 y posteriores de Amazon EMR generalmente hacen referencia a [Trino](https://trino.io/), mientras que las versiones anteriores hacen referencia a PrestoSQL. **importante** PrestosQL, la versión anterior de Trino, todavía está disponible para su uso con Amazon EMR. Sin embargo, recomendamos encarecidamente utilizar Trino en el futuro con Amazon EMR. Tenga en cuenta también que Trino y PrestosQL no se pueden ejecutar simultáneamente en el mismo clúster. En la siguiente tabla, se muestra la versión de Trino incluida en la última versión de la serie 7.x de Amazon EMR, junto con los componentes que Amazon EMR instala con Trino. Para ver la versión de los componentes instalados con Trino en esta versión, consulte Versiones de componentes de la [versión 7.12.0](emr-7120-release.md). **Información sobre la versión de Trino (PrestosQL) para emr-7.12.0** | Etiqueta de versión de Amazon EMR | Versión de Trino (PrestoSQL) | Componentes instalados con Trino (PrestoSQL) | | --- | --- | --- | | emr-7.12.0 | trino-prestosql 476-amzn-1 | emrfs, emr-goodies, hadoop-client, hadoop-hdfs-datanode, hadoop-hdfs-library, hadoop-hdfs-namenode, hadoop-hdfs-zkfc, hadoop-kms-server, hadoop-yarn-nodemanager, hadoop-yarn-resourcemanager, hadoop-yarn-timeline-server, hive-client, hudi, hudi-trino, hcatalog-server, mariadb-server, trino-coordinator, trino-worker | **Topics** + [Historia y diseño de Trino](emr-trino-intro-history.md) + [Introducción a Trino](emr-trino-getting-started.md) + [Configuración de Trino en Amazon EMR](emr-trino-config.md) + [Prácticas recomendadas para Trino en Amazon EMR](emr-trino-advanced.md) + [Consideraciones sobre Trino](Trino-considerations.md) + [Historial de versiones de Trino](Trino-release-history.md) # Historia y diseño de Trino Trino se especializa en consultar grandes conjuntos de datos de muchas fuentes diferentes. Trino puede acceder a HDFS y consultarlo en un caso de uso tradicional de macrodatos, pero también puede consultar fuentes adicionales, como bases de datos relacionales y bases de datos NoSQL. Comenzó originalmente como una bifurcación del motor de consultas Presto en 2019. Desde entonces, se ha desarrollado independientemente del código base de Presto. Para obtener más información sobre el motor de consultas de Trino y cómo se utiliza, consulte el [sitio web de Trino](https://trino.io/). Para leer la documentación original de Trino, consulte la [Trino Overview](https://trino.io/docs/current/overview.html). ## Conceptos arquitectónicos Trino puede ejecutar consultas rápidas y eficientes porque procesa los datos en paralelo en un clúster. Se ha diseñado teniendo en cuenta las consultas a un lago de datos, ya que está especializado para consultas sobre grandes volúmenes de datos, normalmente en casos de uso relacionados con Hadoop y HDFS. Sin embargo, también puede consultar bases de datos relacionales tradicionales. Para obtener más información, consulte [Architecture](https://trino.io/docs/current/overview/concepts.html#architecture) en la *documentación sobre Trino*. ### Componentes de Trino Trino tiene algunos componentes de arquitectura clave que funcionan juntos para que las consultas se ejecuten rápidamente. Es útil tener un conocimiento práctico de estos elementos a la hora de refinar el clúster para obtener un mejor rendimiento: + El **coordinador** es responsable de la orquestación de las consultas. Analiza y optimiza las consultas SQL entrantes, genera planes de ejecución, asigna tareas a los nodos de trabajo, y recopila y reúne los resultados de las consultas. Además, monitorea el uso de los recursos y rastrea el estado de los nodos de trabajo. Para obtener más información, consulte la sección [Coordinator](https://trino.io/docs/current/overview/concepts.html#coordinator) en la *documentación sobre Trino*. + Los **nodos de trabajo** se encargan del procesamiento de datos para las consultas. Una vez que el coordinador asigna las tareas, los trabajadores recuperan los datos, realizan las operaciones necesarias, como uniones y agregaciones, e intercambian datos intermedios con otros trabajadores. Para obtener más información, consulte la sección [Worker](https://trino.io/docs/current/overview/concepts.html#worker) en la *documentación de Trino*. + Los **conectores** son complementos que permiten a Trino conectarse a diversas fuentes de datos y consultarlas. Cada conector sabe cómo acceder a los datos de su origen y recuperarlos, como Amazon S3, Apache Hive o bases de datos relacionales. Estos conectores asignan los datos de origen a la estructura del esquema de Trino. + Un **catálogo** es una colección lógica de esquemas y tablas asociadas a un conector específico. Definidos en el coordinador, los catálogos permiten a Trino tratar diferentes orígenes de datos como un único espacio de nombres. Esto permite a los usuarios consultar varias fuentes juntas, como Hive y MySQL, de forma unificada en la misma consulta. + Los **clientes**, como la CLI de Trino, se conectan mediante controladores JDBC y ODBC al coordinador de Trino para enviar consultas SQL. El coordinador gestiona el ciclo de vida de las consultas y proporciona los resultados al cliente para su posterior análisis o elaboración de informes. ### Ejecución de consultas Para entender cómo Trino toma las instrucciones SQL y las ejecuta como consultas, consulte los [conceptos de Trino](https://trino.io/docs/current/overview/concepts.html#query-execution-model) en la *documentación de Trino*. # Introducción a Trino Los procedimientos de esta sección le muestran cómo configurar un clúster de Amazon EMR para consultar los orígenes de datos de metaalmacenes con Trino. Estos metaalmacenes, que incluyen el catálogo de datos de AWS Glue, almacenan metadatos y objetos de bases de datos y administran los permisos de acceso. Los procedimientos abarcan los requisitos previos, los valores de configuración recomendados, la creación de conectores y la ejecución de consultas en las tablas de metaalmacenes. **Topics** + [Complete los pasos previos para usar Amazon EMR con Trino](emr-trino-getting-started-pre.md) + [Lanzamiento de un clúster de Amazon EMR con Trino](emr-trino-getting-started-launch.md) + [Conexión al nodo principal del clúster de Amazon EMR y ejecución de consultas](emr-trino-getting-started-connect.md) # Complete los pasos previos para usar Amazon EMR con Trino Si no ha utilizado AWS o no ha creado un clúster de Amazon EMR, complete estos pasos previos antes de crear un clúster de Amazon EMR con Trino. ## AWS configuración del entorno Complete estos pasos para configurar su AWS cuenta si aún no lo ha hecho: 1. Crea una AWS cuenta, si aún no tienes una. Para obtener más información, consulta [Crear una AWS cuenta](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html) en la *Guía de referencia de administración de AWS cuentas*. 1. Inicie sesión en su cuenta como un usuario administrativo. 1. Cree un grupo y asígnele usuarios. 1. Cree un par de claves de Amazon EC2, que podrá utilizar más adelante para proteger la comunicación entre los recursos mediante SSH. Este paso es necesario si planea conectarse al nodo principal para llevar a cabo tareas. Para obtener más información, consulte [Connect to the Amazon EMR cluster primary node using SSH](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html). # Lanzamiento de un clúster de Amazon EMR con Trino A continuación, se describen las opciones de configuración correctas al momento de crear un clúster con Trino. ## Uso de un conector Hive para que los datos estén disponibles para su consulta Puede configurar un conector Trino para un metalmacén de Hive con el fin de consultar los datos del metalmacén de su clúster. Un metalmacén es una capa de abstracción que hace que el contenido o los datos basados en archivos estén disponibles en forma de tablas, por lo que es fácil consultarlos. Debe configurar un conector en Amazon EMR para que las tablas del metalmacén de Hive estén disponibles en el clúster. El procedimiento siguiente demuestra cómo hacerlo. 1. Elija AWS Glue en la consola y cree una tabla basada en sus datos de origen en Amazon S3. Una tabla del catálogo de datos de AWS Glue es la definición de metadatos de los datos. En este contexto, tiene sentido crear la tabla manualmente, creando las columnas que desee a partir de los datos de origen. Para obtener más información sobre la creación de tablas en AWS Glue a partir de datos semiestructurados en Amazon S3, consulte [Creación de tablas con la consola](https://docs.aws.amazon.com/glue/latest/dg/tables-described.html#console-tables) en la *Guía del usuario de AWS Glue*. 1. Ajuste su configuración como parte de la creación de clústeres. Seleccione la pestaña **Configuraciones**. Las configuraciones son requisitos opcionales para su clúster. Cuando introduzcas una configuración, añade JSON como en el siguiente ejemplo, en el que se indica a Trino que utilice el catálogo de datos de AWS Glue como su metabastore externo de Hive para los metadatos de las tablas: ``` { "classification": "trino-connector-hive", "properties": { "hive.metastore": "glue" } } ``` Como alternativa, puede aplicar las configuraciones en la sección **Configuración de software** al momento de crear un clúster. Además, puede configurar otros tipos de conectores, por ejemplo, para conectarse con Apache Iceberg. Para obtener más información, consulte [Use an Iceberg cluster with Trino](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-iceberg-use-trino-cluster.html) en la *Guía de versiones de Amazon EMR*. La configuración de ajustes adicionales es opcional. Para continuar con los pasos de introducción, consulte [Conexión al nodo principal del clúster de Amazon EMR y ejecución de consultas](emr-trino-getting-started-connect.md). ## Creación de un clúster con Trino A continuación, se describen las opciones de configuración correctas al crear un clúster que desee utilizar con Trino. **importante** Antes de crear el clúster, complete la configuración del catálogo de datos de AWS Glue como su metaalmacén de Hive, que le recomendamos para empezar. Para obtener más información, consulte [Uso de un conector Hive para que los datos estén disponibles para su consulta](#emr-trino-getting-started-connect-hive). 1. En la AWS consola, seleccione Amazon EMR de los servicios. Cuando elige Amazon EMR, si tiene clústeres existentes, se muestran sus clústeres de **EMR en EC2**. 1. Elija **Create cluster**. Desde aquí, se inicia el proceso de creación de un clúster. 1. Asigne un nombre a su clúster y elija una **versión de Amazon EMR**. Puede elegir la versión más reciente para el tutorial. 1. Elija el paquete **Trino**, que tiene la aplicación Trino preseleccionada. Los paquetes se configuran para mayor comodidad cuando se conoce con antelación el propósito del clúster. De lo contrario, puede simplemente seleccionar la casilla de verificación de Trino. 1. En **Configuración del clúster**, elija **Grupos de instancias uniformes**. Continúe y elimine grupos de instancias adicionales. 1. Elija un **tipo de instancia**. Por lo general, recomendamos que elija un tipo de instancia con al menos 16 GiB de memoria. Además, para **Aprovisionamiento y escalado de clústeres**, elija **Establecer el tamaño del clúster manualmente**. 1. En este punto, establece la configuración de tu metatienda de Hive para que apunte a Glue AWS . Esto se detalla en la sección [Uso de un conector Hive para que los datos estén disponibles para su consulta](#emr-trino-getting-started-connect-hive). Complételo antes de crear el clúster. 1. Elija **Create cluster**. Puede tardar unos minutos en finalizar. Los pasos que aparecen aquí no cubren todos los pasos de configuración en detalle. Encontrará más información sobre la configuración de un clúster en [Plan, configure and launch Amazon EMR clusters](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan.html). **nota** No seleccione Presto y Trino para usarlos en el mismo clúster. No se admite su ejecución conjunta. También se recomienda que, si ejecuta Trino, no ejecute ninguna otra aplicación en el clúster, como Spark. # Conexión al nodo principal del clúster de Amazon EMR y ejecución de consultas ## Aprovisione datos de prueba y configure permisos Puede probar Amazon EMR con Trino mediante AWS Glue Data Catalog y su metatienda Hive. Estos pasos previos describen cómo configurar los datos de prueba: 1. Si aún no lo ha hecho, cree una clave SSH para cifrar las comunicaciones. 1. Puede elegir entre varios sistemas de archivos para almacenar datos y archivos de registro. Para comenzar, cree un bucket de Amazon S3. Asigne un nombre único al bucket. Al crearlo, especifique la clave de cifrado que creó. **nota** Elija la misma región para crear el bucket de almacenamiento y el clúster de Amazon EMR. 1. Elija el bucket que ha creado. Elija **Crear carpeta** y asigne a la carpeta un nombre fácil de recordar. Al momento de crear la carpeta, elija una configuración de seguridad. Puede elegir la configuración de seguridad para la principal o hacer que la configuración de seguridad sea más especializada. 1. Agregue los datos de prueba a la carpeta. Para los fines de este tutorial, el uso de un archivo .csv de registros separados por comas funciona bien para completar este caso de uso. 1. Tras añadir datos a un bucket de Amazon S3, configura una tabla en AWS Glue para proporcionar una capa de abstracción para consultar los datos. ## Conexión y ejecución de consultas A continuación, se describe cómo conectarse y ejecutar consultas en un clúster que ejecuta Trino. Antes de hacerlo, asegúrese de configurar el conector del metalmacén de Hive, que se describe en el procedimiento anterior, de modo que las tablas del metalmacén estén visibles. 1. Se recomienda utilizar EC2 Instance Connect para conectarse al clúster, ya que proporciona una conexión segura. Elija **Conectarse al nodo principal mediante SSH** desde el resumen del clúster. La conexión requiere que el grupo de seguridad tenga una regla de entrada que permita las conexiones a través del puerto 22 a los clientes de la subred. También debe usar el usuario **Hadoop** cuando se conecte. 1. Inicie la CLI de Trino ejecutando `trino-cli`. Esto le permite ejecutar comandos y consultar datos con Trino. 1. Ejecute `show catalogs;`. Compruebe que el catálogo de **Hive** esté en la lista. Este proporciona una lista de los catálogos disponibles, que contienen almacenes de datos o configuraciones del sistema. 1. Para ver los esquemas disponibles, ejecute `show schemas in hive;`. Desde aquí, puede ejecutar `use schema-name;` e incluir el nombre del esquema. A continuación, puede ejecutar `show tables;` para enumerar las tablas. 1. Consulte una tabla ejecutando un comando como `SELECT * FROM table-name`, por ejemplo, usando el nombre de una tabla de su esquema. Si ya ejecutaste la `USE` sentencia para conectarte a un esquema específico, no tienes que usar una notación de dos partes, como. *schema* *table*. # Configuración de Trino en Amazon EMR **Topics** + [Configuración de conectores para Trino](#emr-trino-config-connector) + [Supervisión](#emr-trino-monitoring) ## Configuración de conectores para Trino ### Conéctate a AWS Glue como tu metatienda de Hive Es importante y útil entender que puedes configurar AWS Glue Data Catalog como tu metabastore de Hive cuando ejecutas consultas con Trino. Para obtener información adicional, incluidos los pasos para configurar un clúster con un metaalmacén de Hive, consulte [Uso del catálogo de datos de AWS Glue como metaalmacén de](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html) Hive. Para obtener información sobre la integración de EMR en EKS con AWS Glue, consulte las siguientes prácticas recomendadas, [integración de contenedores EMR](https://aws.github.io/aws-emr-containers-best-practices/metastore-integrations/docs/aws-glue/) con Glue. AWS ### Conexión a tablas Iceberg al usar Trino con Amazon EMR Iceberg es un formato de tabla abierto para tablas analíticas. Se creó para que motores como Spark y Trino consultaran macrodatos de las mismas tablas mediante consultas SQL. Incluye características, como aislar las lecturas y escrituras de datos, para que el lector pueda evitar consultar datos que estén parcialmente actualizados, por ejemplo. También es compatible con características de estado, como las instantáneas. Proporciona una capa de abstracción mediante el uso de metadatos y archivos de manifiesto. Describen el esquema de la tabla y facilitan la consulta de datos sin tener que conocer muchos detalles sobre su formato u organización. Cuando está conectado, puede leer los datos de las tablas, actualizarlos o escribir otros nuevos en los archivos subyacentes. Hay un taller disponible en el que se muestra cómo configurar tablas Iceberg con Amazon EMR y AWS Glue. Para obtener más información, consulte [Analytics Workshop - Set Up and Use Apache Iceberg Tables on Your Data Lake](https://youtu.be/SZDYmWIStUo?si=sW35AjSWIcHu5x_p). ### Conexión con los clientes Puede conectarse con Trino mediante un controlador JDBC disponible. Para obtener más información, consulte [JDBC driver](https://trino.io/docs/current/client/jdbc.html) en la *documentación de Trino*. ## Supervisión Puede supervisar los clústeres de Amazon EMR a través del. Consola de administración de AWS Para obtener más información, consulte [View and monitor an Amazon EMR cluster as it performs work](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view.html). Amazon EMR también envía sus métricas de supervisión a Amazon CloudWatch. Para obtener más información sobre la supervisión de un clúster de Amazon EMR, consulte [Amazon CloudWatch events and metrics from Amazon EMR](). # 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). # Consideraciones sobre Trino Tenga en cuenta los siguientes elementos al ejecutar Trino en Amazon EMR. ## Propiedades de la implementación de Trino no configurables En la siguiente tabla, se muestran las distintas opciones de configuración de los archivos `properties` de Trino. | Archivos | Configurable | | --- | --- | | `log.properties` | Trino: configurable en versiones 6.1.0 y posteriores de Amazon EMR. Utilice la clasificación de configuración `prestosql-log` o `trino-log`. | | `config.properties` | Trino: configurable en versiones 6.1.0 y posteriores de Amazon EMR. Utilice la clasificación de configuración `prestosql-config` o `trino-config`. | | `hive.properties` | Trino: configurable en versiones 6.1.0 y posteriores de Amazon EMR. Utilice la clasificación de configuración `prestosql-connector-hive` o `trino-connector-hive`. | | `node.properties` | Trino: configurable en versiones 6.1.0 y posteriores de Amazon EMR. Utilice la clasificación de configuración `prestosql-node` o `trino-node`. | | `jvm.config` | No se puede configurar. | ## Consideraciones adicionales + Para la versión 6.1.0 y posteriores de Trino en EMR, Amazon EMR configura automáticamente una clave secreta compartida para una comunicación interna segura entre los nodos del clúster. No necesita llevar a cabo ninguna configuración adicional para habilitar esta característica de seguridad y puede anular la configuración con su propia clave secreta. Para obtener información sobre la autenticación interna de Trino, consulte la [documentación de Trino 353: Comunicación interna segura](https://trino.io/docs/current/security/internal-communication.html). # Historial de versiones de Trino Las secciones de notas de la versión detallan los cambios y actualizaciones de una versión específica de Trino en Amazon EMR. ## Notas de la versión de Trino por versión + [Amazon EMR 7.6.0: notas de la versión de Trino](Trino-release-history-760.md) + [Amazon EMR 7.3.0: notas de la versión de Trino](Trino-release-history-730.md) + [Amazon EMR 6.9.0: notas de la versión de Trino](Trino-release-history-690.md) # Amazon EMR 7.6.0: notas de la versión de Trino ## Amazon EMR 7.6.0: nuevas características de Trino + Para admitir consultas de ejecución prolongada, Trino ahora incluye un mecanismo de ejecución tolerante a errores. La ejecución tolerante a errores mitiga los errores de las consultas al volver a intentar las consultas con errores o las tareas que las componen. ## Amazon EMR 7.6.0: cambios en Trino **Amazon EMR 7.6.0: cambios en Trino** | Tipo | Description (Descripción) | | --- | --- | | Upgrade | Actualización de Trino a 457 | # Amazon EMR 7.3.0: notas de la versión de Trino ## Amazon EMR 7.3.0: cambios en Trino + Esta versión actualiza Trino de la versión 436 a la 442. + Esta versión redirige las consultas de Hudi al nuevo corrector de Hudi. El antiguo conector Hive ya no puede leer las tablas Hudi. Nota + Esta versión elimina el módulo Rubix de Amazon EMR porque ahora está en desuso desde el código abierto. + Esta versión [elimina el modo heredado](https://github.com/trinodb/trino/pull/21013) de la propiedad `hive.security`. El valor predeterminado es `allow-all`. # Amazon EMR 6.9.0: notas de la versión de Trino ## Amazon EMR 6.9.0: nuevas características de Trino + Para admitir consultas de ejecución prolongada, Trino ahora incluye un mecanismo de ejecución tolerante a errores. La ejecución tolerante a errores mitiga los errores de las consultas al volver a intentar las consultas con errores o las tareas que las componen. ## Amazon EMR 6.9.0: cambios en Trino **Amazon EMR 6.9.0: cambios en Trino** | Tipo | Description (Descripción) | | --- | --- | | Upgrade | Actualización de Trino a 398 | | Upgrade | Compatibilidad con Hadoop 3.3.3 | | Característica | Compatibilidad con Tardigrade: se agrega compatibilidad con el intercambio en cadena en HDFS y Amazon S3. | | Corrección de errores | Cuando se usa Trino Iceberg y el catálogo de Glue esté activado, se evita agregar la URL de metaalmacén en `iceberg.properties.` | ## Amazon EMR 6.9.0: problemas conocidos de Trino + En el caso de la versión 6.9.0 de Amazon EMR, Trino no funciona en clústeres habilitados para Apache Ranger. Si tiene que utilizar Trino con Ranger, contacte con [Soporte](https://console.aws.amazon.com/support/home#/).