Ajuste del rendimiento en Athena - Amazon Athena
Límites físicosTécnicas de optimización de consultasRecursos adicionales

Ajuste del rendimiento en Athena

En este tema se proporciona información general y sugerencias específicas para mejorar el rendimiento de Athena cuando se tienen grandes cantidades de datos y se experimentan problemas de uso de memoria o rendimiento.

Límites físicos

De forma predeterminada, Athena limita el tiempo de ejecución de las consultas DML a 30 minutos y de las consultas DDL a 600 minutos. Las consultas que superan estos límites se cancelan automáticamente sin costo alguno. Si una consulta se queda sin memoria o un nodo se bloquea durante el procesamiento, se pueden producir errores como los siguientes:

INTERNAL_ERROR_QUERY_ENGINE
EXCEEDED_MEMORY_LIMIT: Query exceeded local memory limit
Query exhausted resources at this scale factor
Encountered too many errors talking to a worker node. The node may have crashed or be under too much load.

Técnicas de optimización de consultas

En el caso de consultas que requieren recursos más allá de los límites existentes, puede optimizar la consulta o reestructurar los datos que se consultan. Tenga en cuenta las sugerencias de esta sección para optimizar las consultas.

Tamaño de los datos

Evite archivos grandes individuales: si el tamaño del archivo es extremadamente grande, intente dividirlo en archivos más pequeños y utilice particiones para organizarlos.

Lea una cantidad menor de datos a la vez: escanear una gran cantidad de datos a la vez puede ralentizar la consulta y aumentar el costo. Utilice particiones o filtros para limitar los archivos que se van a analizar.

Evite tener demasiadas columnas: el mensaje GENERIC_INTERNAL_ERROR: io.airlift.bytecode.CompilationException se puede producir cuando Athena no compila la consulta en bytecode. Por lo general, esta excepción se produce por tener demasiadas columnas en la consulta. Reduzca el número de columnas de la consulta o cree subconsultas y utilice un JOIN que recupere una cantidad menor de datos.

Evite grandes salidas de consulta: una gran cantidad de datos de salida puede ralentizar el rendimiento. Para evitar esto, pruebe utilizar CTAS para crear una nueva tabla con el resultado de la consulta o INSERT INTO para agregar nuevos resultados a una tabla existente.

Evite consultas CTAS con una salida grande: las consultas CTAS también pueden utilizar una gran cantidad de memoria. Si está generando una gran cantidad de datos, intente separar la tarea en consultas más pequeñas.

Si es posible, evite tener una gran cantidad de archivos pequeños: Amazon S3 tiene un límite de 5500 solicitudes por segundo. Las consultas de Athena comparten el mismo límite. Si necesita escanear millones de objetos pequeños en una sola consulta, Amazon S3 puede limitar la consulta con facilidad. Para evitar un escaneo excesivo, utilice ETL de AWS Glue para compactar periódicamente los archivos o particionar la tabla y agregar filtros de clave de partición. Para obtener más información, consulte Lectura de archivos de entrada en grupos más grandes en la Guía para desarrolladores de AWS Glue o How can I configure an AWS Glue ETL job to output larger files? (Configuración de un trabajo ETL de AWS Glue para generar archivos más grandes) en el centro de conocimiento de AWS.

Evite escanear toda una tabla: utilice las siguientes técnicas para evitar escanear tablas enteras:

  • Limite el uso de “*”. Intente no seleccionar todas las columnas a menos que sea necesario.

  • Evite escanear la misma tabla varias veces en la misma consulta

  • Utilice filtros para reducir la cantidad de datos que se van a analizar.

  • Agregue una cláusula LIMIT siempre que sea posible.

Evite hacer referencia a muchas vistas y tablas en una única consulta: dado que las consultas con muchas vistas o tablas deben cargar una gran cantidad de datos, se pueden producir errores de memoria. De ser posible, evite hacer referencia a un número excesivo de vistas o tablas en una sola consulta.

Evite cadenas JSON grandes: si los datos se almacenan en una sola cadena JSON y el tamaño de los datos JSON es grande, se pueden producir errores de memoria al procesar los datos JSON.

Formatos de archivo

Utilice un formato de archivo eficiente, como Parquet u ORC: utilice archivos Parquet u ORC comprimidos para almacenar los datos con el fin de reducir de manera drástica el tiempo de ejecución de las consultas y los costos. Para convertir el conjunto de datos existente a esos formatos en Athena, puede utilizar CTAS. Para obtener más información, consulte Uso de CTAS e INSERT INTO en ETL y análisis de datos.

Cambie entre formatos ORC y Parquet: la experiencia demuestra que puede haber diferencias significativas en el tiempo de procesamiento del mismo conjunto de datos en función de si se almacena en formato ORC o Parquet. Si tiene problemas de rendimiento, pruebe con un formato diferente.

Consultas de Hudi: dado que las consultas de Hudi omiten el lector nativo y el generador dividido para archivos en formato Parquet, pueden ser lentas. Tenga esto en cuenta al consultar conjuntos de datos de Hudi.

Uniones y agrupaciones

Reduzca las operaciones de uso intensivo de memoria: las operaciones como JOIN, GROUP BY, ORDER BY y UNION requieren la carga de una gran cantidad de datos en la memoria. Para acelerar la consulta, busque otras formas de lograr los mismos resultados o agregue una cláusula como LIMIT a la consulta externa siempre que sea posible.

Considere utilizar UNION ALL: para eliminar duplicados, UNION crea una tabla hash, que consume memoria. Si la consulta no requiere la eliminación de duplicados, considere utilizar UNION ALL para un mejor rendimiento.

Utilice CTAS como paso intermedio para acelerar las operaciones de JOIN: en lugar de cargar y procesar datos intermedios con cada consulta, utilice CTAS para conservar los datos intermedios en Amazon S3. Esto puede ayudar a acelerar el rendimiento de operaciones como JOIN.

Particiones

Limite el número de particiones en una tabla: cuando una tabla tiene más de 100 000 particiones, las consultas pueden ser lentas debido al gran número de solicitudes enviadas a AWS Glue para recuperar información de las particiones. Pruebe una de las siguientes opciones para resolver este problema:

Elimine particiones antiguas incluso si están vacías: incluso si una partición está vacía, los metadatos de la partición aún están almacenados en AWS Glue. Cargar estas particiones innecesarias puede aumentar los tiempos de ejecución de las consultas. Para eliminar las particiones innecesarias, utilice ALTER TABLE DROP PARTITION.

Busque una sola partición: cuando busque una sola partición, intente proporcionar todos los valores de partición para que Athena pueda localizar la partición con una sola llamada a AWS Glue. De lo contrario, Athena debe recuperar todas las particiones y filtrarlas. Esto puede ser costoso y aumentar de manera considerable el tiempo de planificación para la consulta. Si tiene un patrón de partición predecible, puede utilizar la proyección de particiones para evitar que la partición busque llamadas a AWS Glue.

Establezca propiedades razonables para la proyección de particiones: cuando se utiliza la proyección de particiones, Athena intenta crear un objeto de partición para cada nombre de partición. Por este motivo, asegúrese de que las propiedades de tabla que defina no generen una cantidad casi infinita de particiones posibles.

Para agregar particiones nuevas con frecuencia, utilice ALTER TABLE ADD PARTITION: Si utiliza MSCK REPAIR TABLE para agregar particiones nuevas con frecuencia (por ejemplo, a diario) y experimenta tiempos de espera de consulta, considere utilizar ALTER TABLE ADD PARTITION. MSCK REPAIR TABLE se utiliza mejor al crear una tabla por primera vez o cuando hay incertidumbre sobre la paridad entre los datos y los metadatos de partición.

Evite usar coalesce() en una cláusula WHERE con columnas particionadas: en algunas circunstancias, el uso de la función coalesce() u otras funciones en una cláusula WHERE con columnas particionadas podría reducir el rendimiento. En tal caso, intente reescribir la consulta para proporcionar la misma funcionalidad sin utilizar coalesce().

Window functions (Funciones de ventana)

Reduzca al mínimo el uso de funciones de ventana: las funciones de ventana como rank() utilizan mucha memoria. En general, las funciones de ventana requieren que se cargue un conjunto de datos completo en un solo nodo Athena para su procesamiento. Con un conjunto de datos extremadamente grande, se puede correr el riesgo de que se bloquee el nodo. Para evitarlo, pruebe las siguientes opciones:

  • Filtre los datos y ejecute funciones de ventana en un subconjunto de los datos.

  • Utilice PARTITION BY con la función de ventana, siempre que sea posible.

  • Encuentre una forma alternativa de crear la consulta.

Utilice funciones más eficientes

Reemplazar row_number() OVER (...) as rnk ... WHERE rnk = 1: para acelerar una consulta con una cláusula row_number() como esta, reemplace esta sintaxis con una combinación de GROUP BY, ORDER BY y LIMIT 1.

Utilizar expresiones regulares en lugar de cadenas grande LIKE: las consultas que incluyen cláusulas como LIKE '%string%' en cadenas grandes puede ser muy costosas. Considere utilizar la función regexp_like() y una expresión regular en su lugar.

Utilizar max() en lugar de element_at(array_sort(), 1): para aumentar la velocidad, reemplace las funciones anidadas element_at(array_sort(), 1) por max ().

Recursos adicionales

Para obtener información adicional acerca del ajuste de rendimiento en Athena, tenga en cuenta los siguientes recursos: