Ajuste del rendimiento en Athena - Amazon Athena
Service QuotasLímites de recursosTécnicas de optimización de consultasTécnicas de optimización de datosRecursos adicionales de

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.

Ajuste del rendimiento en Athena

En este tema se proporciona información general y sugerencias específicas para mejorar el rendimiento de las consultas de Athena y para solucionar los errores relacionados con los límites y el uso de recursos.

Service Quotas

Athena aplica cuotas para métricas como el tiempo de ejecución de las consultas, el número de consultas simultáneas en una cuenta y las tasas de solicitudes de API. Para obtener más información acerca de estas cuotas, consulte Service Quotas. Si se superan estas cuotas, se produce un error en una consulta, ya sea al enviarla o durante la ejecución.

Muchos de los consejos de optimización del rendimiento de esta página pueden ayudar a reducir el tiempo de ejecución de las consultas. La optimización libera capacidad para que pueda ejecutar más consultas dentro de la cuota de simultaneidad y evita que las consultas se cancelen por ejecutarse durante demasiado tiempo.

Las cuotas de la cantidad de consultas y solicitudes de API simultáneas son por Cuenta de AWS y Región de AWS. Recomendamos ejecutar una carga de trabajo por carga de trabajo Cuenta de AWS (o utilizar reservas de capacidad aprovisionadas independientes) para evitar que las cargas de trabajo compitan por la misma cuota.

Si se ejecutan dos cargas de trabajo en la misma cuenta, una de las cargas de trabajo puede ejecutar una ráfaga de consultas. Esto puede provocar que la carga de trabajo restante se limite o impida la ejecución de consultas. Para evitarlo, puede mover las cargas de trabajo a cuentas independientes a fin de asignar a cada carga de trabajo su propia cuota de simultaneidad. Al crear una reserva de capacidad aprovisionada para una o ambas cargas de trabajo, se logra el mismo objetivo.

Cuotas en otros servicios

Cuando Athena ejecuta una consulta, puede llamar a otros servicios que imponen cuotas. Durante la ejecución de la consulta, Athena puede realizar llamadas a la AWS Glue Data Catalog API a Amazon S3 y a otros AWS servicios, como IAM y. AWS KMS Si utilizas consultas federadas, Athena también llama. AWS Lambda Todos estos servicios tienen sus propios límites y cuotas que pueden superarse. Cuando la ejecución de una consulta detecta errores de estos servicios, se produce un error e incluye el error del servicio de origen. Los errores recuperables se vuelven a intentar, pero las consultas pueden seguir fallando si el problema no se resuelve a tiempo. Asegúrese de leer detenidamente los mensajes de error para determinar si provienen de Athena o de otro servicio. En este documento se describen algunos de los errores más relevantes.

Para obtener más información sobre cómo solucionar los errores relacionados con las cuotas de servicio de Amazon S3, consulte Cómo evitar tener demasiados archivos más adelante en este documento. Para obtener más información sobre la optimización del rendimiento de Amazon S3, consulte Prácticas recomendadas para patrones de diseño: optimizar el rendimiento de Amazon S3 en la Guía del usuario de Amazon S3.

Límites de recursos

Athena ejecuta las consultas en un motor de consultas distribuido. Al enviar una consulta, el planificador de consultas del motor de Athena calcula la capacidad de procesamiento necesaria para ejecutar la consulta y prepara un clúster de nodos de computación en consecuencia. Algunas consultas, como las consultas DDL, se ejecutan en un solo nodo. Las consultas complejas sobre conjuntos de datos de gran tamaño se ejecutan en clústeres mucho más grandes. Los nodos son uniformes y tienen las mismas configuraciones de disco, CPU y memoria. Athena escala horizontalmente, no verticalmente, para procesar consultas más exigentes.

A veces, las demandas de una consulta superan los recursos disponibles para el clúster que ejecuta la consulta. Cuando esto ocurre, la consulta genera el error La consulta agotó los recursos con este factor de escala.

El recurso que se agota con más frecuencia es la memoria, pero en raras ocasiones también puede ser el espacio en disco. Los errores de memoria suelen producirse cuando el motor ejecuta una función de unión o ventana, pero también pueden producirse en distintos recuentos y agregaciones.

Aunque una consulta falle una vez y muestre el error de “falta de recursos”, es posible que se ejecute correctamente cuando se vuelva a ejecutar. La ejecución de la consulta no es determinista. Factores como el tiempo que se tarda en cargar los datos y la forma en que se distribuyen los conjuntos de datos intermedios en los nodos pueden provocar un uso diferente de los recursos. Imagine una consulta que une dos tablas y presenta un gran sesgo en la distribución de los valores de la condición de unión. Una consulta de este tipo puede funcionar correctamente la mayoría de las veces, pero en ocasiones falla cuando los valores más comunes terminan siendo procesados por el mismo nodo.

Para evitar que las consultas superen los recursos disponibles, utilice los consejos de ajuste de rendimiento que se mencionan en este documento. Para obtener consejos sobre cómo optimizar las consultas que agotan los recursos disponibles, consulte Optimización de uniones, Optimización de las funciones de ventana y Optimización de las consultas mediante aproximaciones.

Técnicas de optimización de consultas

Utilice las técnicas de optimización de consultas que se describen en esta sección para hacer que las consultas se ejecuten más rápido o como soluciones para las consultas que superan los límites de recursos en Athena.

Optimización de uniones

Existen muchas estrategias diferentes para ejecutar uniones en un motor de consultas distribuido. Dos de las más comunes son las uniones hash distribuidas y las consultas con condiciones de unión complejas.

Uniones hash distribuidas

El tipo de unión más común utiliza una comparación de igualdad como condición de unión. Athena ejecuta este tipo de unión como una unión hash distribuida.

En una unión hash distribuida, el motor crea una tabla de consulta (tabla hash) a partir de uno de los lados de la unión. Este lado se denomina lado de compilación. Los registros del lado de compilación se distribuyen entre los nodos. Cada nodo crea una tabla de búsqueda para su subconjunto. El otro lado de la unión, denominado lado de sondeo, se transmite a través de los nodos. Los registros del lado de sondeo se distribuyen entre los nodos de la misma manera que en el lado de compilación. Esto permite que cada nodo realice la unión buscando los registros coincidentes en su propia tabla de búsqueda.

Cuando las tablas de búsqueda creadas a partir del lado de compilación de la unión no caben en la memoria, las consultas pueden fallar. Aun si el tamaño total del lado de compilación es inferior a la memoria disponible, las consultas pueden fallar si la distribución de los registros presenta un sesgo significativo. En un caso extremo, todos los registros podrían tener el mismo valor para la condición de unión y tener que caber en la memoria de un único nodo. Incluso una consulta con menos asimetría puede fallar si se envía un conjunto de valores al mismo nodo y los valores suman más que la memoria disponible. Los nodos tienen la capacidad de almacenar registros en el disco, pero esto ralentiza la ejecución de la consulta y puede que no sea suficiente para evitar que la consulta falle.

Athena intenta reordenar las uniones para usar la relación más grande como el lado de sondeo y la relación más pequeña como el lado de compilación. Sin embargo, como Athena no gestiona los datos de las tablas, tiene información limitada y, a menudo, debe suponer que la primera tabla es la más grande y la segunda es la más pequeña.

Al escribir uniones con condiciones de unión basadas en la igualdad, suponga que la tabla situada a la izquierda de la palabra clave JOIN corresponde al lado de sondeo y la tabla a la derecha corresponde al lado de compilación. Asegúrese de que la tabla correcta, la del lado de compilación, sea la más pequeña de las tablas. Si no es posible hacer que el lado de compilación de la unión sea lo suficientemente pequeño como para caber en la memoria, considere la posibilidad de ejecutar varias consultas que unan subconjuntos de la tabla de compilación.

Otros tipos de uniones

Las consultas con condiciones de unión complejas (por ejemplo, las consultas que utilizan LIKE, > u otros operadores) suelen ser exigentes desde el punto de vista computacional. En el peor de los casos, todos los registros de un lado de la unión deben compararse con todos los registros del otro lado de la unión. Como el tiempo de ejecución aumenta con el cuadrado del número de registros, estas consultas corren el riesgo de superar el tiempo máximo de ejecución.

Para saber de antemano cómo Athena ejecutará su consulta, puede usar la instrucción EXPLAIN. Para más información, consulte Uso de EXPLAIN y EXPLAIN ANALYZE en Athena y Descripción de los resultados de la instrucción EXPLAIN de Athena.

Optimización de las funciones de ventana

Como las funciones de ventana son operaciones que consumen muchos recursos, pueden hacer que las consultas se ejecuten con lentitud o incluso que se produzcan errores con el mensaje La consulta agotó los recursos con este factor de escala. Las funciones de ventana guardan en la memoria todos los registros en los que operan para calcular su resultado. Cuando la ventana es muy grande, la función de ventana puede quedarse sin memoria.

Para asegurarse de que las consultas se ejecuten dentro de los límites de memoria disponibles, reduzca el tamaño de las ventanas sobre las que trabajan las funciones de ventana. Para ello, puede agregar una cláusula PARTITIONED BY o reducir el alcance de las cláusulas de partición existentes.

Uso de funciones que no sean de ventana

A veces, las consultas con funciones de ventana se pueden reescribir sin funciones de ventana. Por ejemplo, en lugar de utilizar row_number para buscar los registros de N principales, puede utilizar ORDER BY y LIMIT. En lugar de usar row_number o rank para desduplicar registros, puede usar funciones de agregado como max_by, min_by y arbitrary.

Por ejemplo, supongamos que tiene un conjunto de datos con actualizaciones de un sensor. El sensor informa periódicamente el estado de la batería e incluye algunos metadatos, como la ubicación. Si desea saber el último estado de la batería de cada sensor y su ubicación, puede usar la siguiente consulta:

SELECT sensor_id,
       arbitrary(location) AS location,
       max_by(battery_status, updated_at) AS battery_status
FROM sensor_readings
GROUP BY sensor_id

Los metadatos, como la ubicación, son los mismos para todos los registros, por lo que puede utilizar la función arbitrary a fin de seleccionar cualquier valor del grupo.

Para obtener el último estado de la batería, puede usar la función max_by. La función max_by selecciona el valor de una columna del registro en el que se encontró el valor máximo de otra columna. En este caso, devuelve el estado de la batería del registro con la hora de la última actualización del grupo. Esta consulta se ejecuta más rápido y utiliza menos memoria que una consulta equivalente con una función de ventana.

Optimización de las agregaciones

Cuando Athena realiza una agregación, distribuye los registros entre los nodos de trabajo mediante las columnas de la cláusula GROUP BY. Para que la tarea de hacer coincidir los registros con los grupos sea lo más eficiente posible, los nodos intentan mantener los registros en la memoria, pero los transfieren al disco si es necesario.

También es una buena idea evitar incluir columnas redundantes en las cláusulas GROUP BY. Dado que un menor número de columnas requiere menos memoria, resulta más eficaz una consulta que describa un grupo con menos columnas. Las columnas numéricas también utilizan menos memoria que las cadenas. Por ejemplo, al agregar un conjunto de datos que tiene un ID de categoría numérico y un nombre de categoría, utilice únicamente la columna de ID de categoría en la cláusula GROUP BY.

A veces, las consultas incluyen columnas en la cláusula GROUP BY para evitar el hecho de que una columna sea parte de la cláusula GROUP BY o una expresión agregada. Si no se sigue esta regla, puede producirse un error con el siguiente mensaje:

EXPRESSION_NOT_AGGREGATE: line 1:8: 'category' must be an aggregate expression or appear in GROUP BY clause (EXPRESSION_NOT_AGGREGATE: línea 1:8: “categoría” debe ser una expresión agregada o aparecer en la cláusula GROUP BY).

Para evitar tener que agregar columnas redundantes a la cláusula GROUP BY, puede utilizar la función arbitrary, como en el siguiente ejemplo.

SELECT country_id,
       arbitrary(country_name) AS country_name,
       COUNT(*) AS city_count
FROM world_cities
GROUP BY country_id

La función ARBITRARY devuelve un valor arbitrario del grupo. La función resulta útil cuando se sabe que todos los registros del grupo tienen el mismo valor para una columna, pero el valor no identifica al grupo.

Optimización de las consultas N principales

La cláusula ORDER BY devuelve los resultados de una consulta ordenados. Athena usa la clasificación distribuida para ejecutar la operación de clasificación en paralelo en varios nodos.

Si no necesita estrictamente ordenar el resultado, evite agregar una cláusula ORDER BY. Además, evite agregar ORDER BY a las consultas internas si no son estrictamente necesarias. En muchos casos, el planificador de consultas puede eliminar la ordenación redundante, pero esto no está garantizado. Una excepción a esta regla es si una consulta interna está realizando una operación N principal, como buscar los valores N más recientes o los N más comunes.

Cuando Athena ve ORDER BY junto con LIMIT, entiende que se está ejecutando una consulta N principal y utiliza operaciones dedicadas en consecuencia.

nota

Aunque Athena también suele detectar funciones de ventana como row_number que usan N principales, recomendamos la versión más sencilla que usa ORDER BY y LIMIT. Para obtener más información, consulte Optimización de las funciones de ventana.

Inclusión de las columnas necesarias únicamente

Si no necesita estrictamente una columna, no la incluya en la consulta. Cuantos menos datos tenga que procesar una consulta, más rápido se ejecutará. Esto reduce tanto la cantidad de memoria necesaria como la cantidad de datos que deben enviarse entre los nodos. Si utiliza un formato de archivo en columnas, al reducir el número de columnas también se reduce la cantidad de datos que se leen desde Amazon S3.

Athena no tiene un límite específico para el número de columnas de un resultado, pero la forma en que se ejecutan las consultas limita el tamaño combinado de las columnas posible. El tamaño combinado de las columnas incluye los nombres y tipos.

Por ejemplo, el siguiente error se debe a una relación que supera el límite de tamaño de un descriptor de relación:

GENERIC_INTERNAL_ERROR: io.airlift.bytecode. CompilationException

Para solucionar este problema, reduzca el número de columnas de la consulta o cree subconsultas y utilice una cláusula JOIN que recupere una cantidad menor de datos. Si tiene consultas que aplican SELECT * en la consulta más externa, debe cambiar * a una lista de solo las columnas que necesita.

Optimización de las consultas mediante aproximaciones

Athena admite funciones agregadas de aproximación para contar valores distintos, los valores más frecuentes, los percentiles (incluidas las medianas aproximadas) y crear histogramas. Utilice estas funciones siempre que no necesite valores exactos.

A diferencia de las operaciones COUNT(DISTINCT col), approx_distinct utiliza mucha menos memoria y se ejecuta más rápido. Del mismo modo, si se utiliza numeric_histogram en lugar de histogram, se utilizan métodos aproximados y, por lo tanto, se utiliza menos memoria.

Optimización de LIKE

Puede usar LIKE para encontrar cadenas coincidentes, pero con cadenas largas, esto requiere un uso intensivo de cómputos. La función regexp_like es, en la mayoría de los casos, una alternativa más rápida que proporciona más flexibilidad.

A menudo, puede optimizar una búsqueda anclando la subcadena que está buscando. Por ejemplo, si busca un prefijo, es mucho mejor usar “substr%” en lugar de “%substr%”. O bien, si está usando regexp_like, “^substr”.

Uso de UNION ALL en lugar de UNION

UNION ALL y UNION son dos formas de combinar los resultados de dos consultas en un solo resultado. UNION ALL concatena los registros de la primera consulta con la segunda y UNION hace lo mismo, pero también elimina los duplicados. UNION necesita procesar todos los registros y encontrar los duplicados, lo que requiere mucha memoria y procesamiento, pero UNION ALL es una operación relativamente rápida. A menos que necesite desduplicar registros, use UNION ALL para obtener el mejor rendimiento.

Uso de UNLOAD para conjuntos de resultados grandes

Si se espera que los resultados de una consulta sean grandes (por ejemplo, decenas de miles de filas o más), utilice UNLOAD para exportar los resultados. En la mayoría de los casos, esto resulta más rápido que ejecutar una consulta normal y, además, usar UNLOAD permite tener más control sobre el resultado.

Cuando termina de ejecutarse una consulta, Athena almacena el resultado como un único archivo CSV sin comprimir en Amazon S3. Esto lleva más tiempo que UNLOAD, no solo porque el resultado no está comprimido, sino también porque la operación no se puede paralelizar. Por el contrario, UNLOAD escribe los resultados directamente desde los nodos de trabajo y aprovecha al máximo el paralelismo del clúster de computación. Además, puede configurar UNLOAD para escribir los resultados en formato comprimido y en otros formatos de archivo, como JSON y Parquet.

Para obtener más información, consulte UNLOAD.

Uso de CTAS o ETL de Glue para materializar las agregaciones de uso frecuente

La “materialización” de una consulta es una forma de acelerar el rendimiento de la consulta mediante el almacenamiento de resultados de consultas complejas precalculados (por ejemplo, agregaciones y uniones) para reutilizarlos en consultas posteriores.

Si varias de las consultas incluyen las mismas uniones y agregaciones, puede materializar la subconsulta común como una tabla nueva y, a continuación, ejecutar las consultas en esa tabla. Puede crear la nueva tabla con Creación de una tabla a partir de los resultados de una consulta (CTAS) o una herramienta ETL específica, como ETL de Glue.

Por ejemplo, supongamos que tiene un panel con widgets que muestran diferentes aspectos de un conjunto de datos de pedidos. Cada widget tiene su propia consulta, pero todas las consultas comparten las mismas uniones y filtros. Una tabla de pedidos se une a una tabla de líneas de artículos y hay un filtro que muestra solo los últimos tres meses. Si se identifican las características comunes de estas consultas, se puede crear una tabla nueva que los widgets puedan usar. Esto reduce la duplicación y mejora el rendimiento. La desventaja es que se debe mantener la nueva tabla actualizada.

Reutilización de resultados de las consultas

Es habitual que la misma consulta se ejecute varias veces en poco tiempo. Por ejemplo, esto puede ocurrir cuando varias personas abren el mismo panel de datos. Al ejecutar una consulta, puede decirle a Athena que reutilice los resultados calculados con anterioridad. Usted especifica la antigüedad máxima de los resultados que se van a reutilizar. Si la misma consulta se ejecutó anteriormente dentro de ese periodo de tiempo, Athena devuelve esos resultados en lugar de volver a ejecutar la consulta. Para obtener más información, consulte Reutilización de los resultados de las consultas en la Guía del usuario de Amazon Athena y Reducir los costos y mejorar el rendimiento de las consultas con la reutilización de resultados de las consultas de Amazon Athena en el blog sobre macrodatos de AWS .

Técnicas de optimización de datos

El rendimiento no solo depende de las consultas, sino también en gran medida de cómo esté organizado el conjunto de datos y del formato de archivo y de la compresión que utilice.

Partición de datos

La creación de particiones divide la tabla en partes y mantiene los datos relacionados juntos de acuerdo con propiedades como la fecha, el país o la región. Las claves de partición actúan como columnas virtuales. Las claves de partición se definen al crear la tabla y se utilizan para filtrar las consultas. Al filtrar las columnas de claves de partición, solo se leen los datos de las particiones coincidentes. Por ejemplo, si el conjunto de datos está dividido por fecha y la consulta tiene un filtro que solo coincide con la última semana, solo se leerán los datos de la última semana. Para obtener más información sobre la creación de particiones, consulte Particiones de datos en Athena.

Elección de claves de partición compatibles con las consultas

Dado que la creación de particiones tiene un impacto significativo en el rendimiento de las consultas, asegúrese de considerar cuidadosamente cómo crear las particiones al diseñar el conjunto de datos y las tablas. Tener demasiadas claves de partición puede provocar conjuntos de datos fragmentados con demasiados archivos y archivos demasiado pequeños. Por el contrario, tener muy pocas claves de partición, o no tener ninguna partición, hace que las consultas analicen más datos de los necesarios.

Cómo evitar optimizar consultas poco frecuentes

Una buena estrategia consiste en optimizar las consultas más comunes y evitar la optimización para las consultas poco frecuentes. Por ejemplo, si sus consultas están basadas en intervalos de días, no las divida por hora, incluso si algunas consultas se filtran a ese nivel. Si sus datos tienen una columna de marca de tiempo detallada, las consultas poco frecuentes que se filtran por hora pueden usar la columna de marca de tiempo. Incluso si en los casos poco frecuentes se analizan un poco más de datos de los necesarios, reducir el rendimiento general en aras de los casos excepcionales no suele ser una buena compensación.

Para reducir la cantidad de datos que se deben analizar en las consultas y, por lo tanto, mejorar el rendimiento, utilice un formato de archivo en columnas y mantenga los registros ordenados. En lugar de particionar por hora, mantenga los registros ordenados por marca de tiempo. Para las consultas en intervalos de tiempo más cortos, ordenar por marca de tiempo es casi tan eficaz como particionar por hora. Además, la clasificación por marca de tiempo no suele afectar el rendimiento de las consultas en intervalos de tiempo contados en días. Para obtener más información, consulte Utilizar formatos de archivo en columnas.

Tenga en cuenta que las consultas en tablas con decenas de miles de particiones funcionan mejor si hay predicados en todas las claves de partición. Esta es otra razón para diseñar un esquema de particiones para las consultas más comunes. Para obtener más información, consulte Consulta de las particiones por igualdad.

Uso de la proyección de particiones

La proyección de particiones es una función de Athena que almacena la información de la partición no en las propiedades de la tabla AWS Glue Data Catalog, sino como reglas en ellas. AWS Glue Cuando Athena planifica una consulta en una tabla configurada con proyección de particiones, lee las reglas de proyección de particiones de la tabla. Athena calcula las particiones para leerlas en la memoria en función de la consulta y las reglas en lugar de buscar las particiones en el AWS Glue Data Catalog.

Además de simplificar la administración de particiones, la proyección de particiones puede mejorar el rendimiento de los conjuntos de datos que tienen un gran número de particiones. Cuando una consulta incluye intervalos en lugar de valores específicos para las claves de partición, la búsqueda de particiones coincidentes en el catálogo lleva más tiempo a medida que aumenta el número de particiones. Con la proyección de particiones, el filtro se puede calcular en la memoria sin tener que consultar el catálogo, lo que puede ser mucho más rápido.

En determinadas circunstancias, la proyección de particiones puede reducir el rendimiento. Un ejemplo ocurre cuando una tabla se encuentra “dispersa”. Una tabla dispersa no contiene datos para todas las permutaciones de los valores de clave de partición descritos en la configuración de proyección de particiones. Con una tabla dispersa, el conjunto de particiones calculadas a partir de la consulta y la configuración de proyección de particiones se muestran en Amazon S3, incluso cuando no contienen datos.

Cuando utilice la proyección de particiones, asegúrese de incluir los predicados en todas las claves de partición. Limite el alcance de los valores posibles para evitar operaciones de lista innecesarias de Amazon S3. Imagine una clave de partición que tiene un intervalo de un millón de valores y una consulta que no tiene ningún filtro en esa clave de partición. Para ejecutar la consulta, Athena debe realizar al menos un millón de operaciones de lista en Amazon S3. Las consultas son más rápidas cuando se consultan valores específicos, independientemente de si se utiliza la proyección de particiones o se almacena la información de las particiones en el catálogo. Para obtener más información, consulte Consulta de las particiones por igualdad.

Al configurar una tabla para la proyección de particiones, asegúrese de que los intervalos que especifique sean razonables. Si una consulta no incluye un predicado en una clave de partición, se utilizan todos los valores del intervalo de esa clave. Si el conjunto de datos se creó en una fecha específica, utilice esa fecha como punto de partida para cualquier intervalo de fechas. Utilice NOW como el final de los intervalos de fechas. Evite los intervalos numéricos que tengan un gran número de valores y considere usar el tipo inyectado en su lugar.

Para obtener más información sobre la proyección de particiones, consulte Proyección de particiones con Amazon Athena.

Uso de índices de particiones

Los índices de partición son una función AWS Glue Data Catalog que mejora el rendimiento de la búsqueda de particiones en las tablas que tienen un gran número de particiones.

La lista de particiones del catálogo es como una tabla de una base de datos relacional. La tabla tiene las columnas para las claves de partición y una columna adicional para la ubicación de la partición. Al consultar una tabla particionada, las ubicaciones de las particiones se buscan mediante el análisis de esta tabla.

Al igual que con las bases de datos relacionales, puede aumentar el rendimiento de las consultas gracias a la adición de índices. Puede agregar varios índices para admitir diferentes patrones de consulta. El índice de AWS Glue Data Catalog particiones admite operadores de igualdad y comparación>, por ejemplo>=, y < combinados con el AND operador. Para obtener más información, consulte Trabajar con índices de partición AWS Glue en la Guía para AWS Glue desarrolladores y Mejorar el rendimiento de las consultas de Amazon Athena AWS Glue Data Catalog mediante índices de partición en AWS el blog Big Data.

Uso siempre de STRING como tipo para las claves de partición

Cuando consulte las claves de partición, recuerde que Athena requiere que las claves de partición sean del tipo STRING para poder aplicar el filtrado de particiones en AWS Glue. Si el número de particiones no es pequeño, el uso de otros tipos puede reducir el rendimiento. Si los valores de las claves de partición son similares a una fecha o a un número, cámbielos al tipo adecuado en la consulta.

Eliminación de las particiones antiguas y vacías

Si elimina datos de una partición de Amazon S3 (por ejemplo, mediante el ciclo de vida de Amazon S3), también debe eliminar la entrada de la partición del AWS Glue Data Catalog. Durante la planificación de la consulta, cualquier partición que coincida con la consulta aparece en Amazon S3. Si tiene muchas particiones vacías, la sobrecarga que supone listarlas puede ser perjudicial.

Además, si tiene muchos miles de particiones, considere la posibilidad de eliminar los metadatos de las particiones de los datos antiguos que ya no son relevantes. Por ejemplo, si las consultas nunca analizan datos de más de un año, puede eliminar periódicamente los metadatos de las particiones más antiguas. Si el número de particiones aumenta a decenas de miles, eliminar las particiones no utilizadas puede acelerar las consultas que no incluyen predicados en todas las claves de partición. Para obtener información sobre cómo incluir predicados en todas las claves de partición en las consultas, consulte Consulta de las particiones por igualdad.

Consulta de las particiones por igualdad

Las consultas que incluyen predicados de igualdad en todas las claves de partición se ejecutan más rápido porque los metadatos de las particiones se pueden cargar de forma directa. Evite las consultas en las que una o más claves de partición no tengan un predicado o en las que el predicado seleccione un intervalo de valores. En este tipo de consultas, se debe filtrar la lista de todas las particiones para encontrar valores coincidentes. En la mayoría de las tablas, la sobrecarga es mínima, pero en las tablas con decenas de miles o más particiones, la sobrecarga puede llegar a ser significativa.

Si no es posible reescribir las consultas para filtrar las particiones por igualdad, puede probar la proyección de particiones. Para obtener más información, consulte Uso de la proyección de particiones.

Cómo evitar el uso de MSCK REPAIR TABLE para el mantenimiento de las particiones

Como MSCK REPAIR TABLE puede tardar mucho en ejecutarse, solo agrega particiones nuevas y no elimina las antiguas, no es una forma eficaz de administrar las particiones (consulte Condiciones y limitaciones).

Las particiones se administran mejor de forma manual mediante las API del AWS Glue Data Catalog, ALTER TABLE ADD PARTITION o los rastreadores de AWS Glue. Como alternativa, puede utilizar la proyección de particiones, que elimina por completo la necesidad de administrar las particiones. Para obtener más información, consulte Proyección de particiones con Amazon Athena.

Comprobar que las consultas sean compatibles con el esquema de particiones

Puede comprobar de antemano qué particiones se analizarán en una consulta mediante la instrucción EXPLAIN. Agregue el prefijo a la consulta con la palabra clave EXPLAIN y, a continuación, busque el fragmento de origen (por ejemplo, Fragment 2 [SOURCE]) de cada tabla cerca de la parte inferior del resultado EXPLAIN. Busque tareas en las que el lado derecho esté definido como una clave de partición. La línea inferior incluye una lista de todos los valores de esa clave de partición que se analizarán cuando se ejecute la consulta.

Por ejemplo, supongamos que tiene una consulta en una tabla con una clave de partición dt y agrega el prefijo a la consulta con EXPLAIN. Si los valores de la consulta son fechas y con un filtro se selecciona un intervalo de tres días, el resultado EXPLAIN puede ser similar a lo siguiente:

dt := dt:string:PARTITION_KEY
    :: [[2023-06-11], [2023-06-12], [2023-06-13]]

El resultado EXPLAIN muestra que el planificador encontró tres valores para esta clave de partición que coincidían con la consulta. También muestra cuáles son esos valores. Para obtener más información sobre el uso de EXPLAIN, consulte Uso de EXPLAIN y EXPLAIN ANALYZE en Athena y Descripción de los resultados de la instrucción EXPLAIN de Athena.

Utilizar formatos de archivo en columnas

Los formatos de archivo en columnas, como Parquet y ORC, están diseñados para cargas de trabajo de análisis distribuidas. Organizan los datos por columnas, no por filas. La organización de los datos en formato de columnas ofrece las siguientes ventajas:

  • Solo se cargan las columnas necesarias para la consulta.

  • Se reduce la cantidad total de datos que deben cargarse.

  • Los valores de las columnas se almacenan juntos, por lo que los datos se pueden comprimir de forma eficiente.

  • Los archivos pueden contener metadatos que permiten que el motor omita la carga de datos innecesarios.

Como ejemplo de cómo se pueden utilizar los metadatos de los archivos, los metadatos de los archivos pueden contener información sobre los valores mínimos y máximos de una página de datos. Si los valores consultados no están dentro del intervalo indicado en los metadatos, se puede omitir la página.

Una forma de utilizar estos metadatos para mejorar el rendimiento es garantizar que los datos de los archivos estén ordenados. Por ejemplo, supongamos que tiene consultas que buscan registros en los que la entrada created_at se encuentra dentro de un periodo de tiempo breve. Si los datos están ordenados por la columna created_at, Athena puede usar los valores mínimo y máximo de los metadatos del archivo para omitir las partes innecesarias de los archivos de datos.

Cuando utilice formatos de archivo en columnas, asegúrese de que los archivos no sean demasiado pequeños. Como se indica en Cómo evitar tener demasiados archivos, los conjuntos de datos con muchos archivos pequeños generan problemas de rendimiento. Esto se aplica aún más cuando se habla de formatos de archivo en columnas. En el caso de los archivos pequeños, la sobrecarga del formato de archivo en columnas supera las ventajas.

Tenga en cuenta que Parquet y ORC están organizados internamente por grupos de filas (Parquet) y bandas (ORC). El tamaño predeterminado para los grupos de filas es de 128 MB y para las bandas, de 64 MB. Si tiene muchas columnas, puede aumentar el tamaño del grupo de filas y de las bandas para obtener un mejor rendimiento. No se recomienda reducir el tamaño del grupo de filas o de las bandas a un valor inferior a sus valores predeterminados.

Para convertir otros formatos de datos a Parquet u ORC, puede utilizar AWS Glue ETL o Athena. Para obtener más información acerca del uso de Athena para ETL, consulte Uso de CTAS e INSERT INTO en ETL y análisis de datos.

Compresión de datos

Athena admite una amplia gama de formatos de compresión. La consulta de datos comprimidos es más rápida y económica, ya que se paga por el número de bytes analizados antes de la descompresión.

El formato gzip ofrece buenas relaciones de compresión y es compatible con una amplia gama de herramientas y servicios. El formato zstd (Zstandard) es un formato de compresión más reciente con un buen equilibrio entre rendimiento y relación de compresión.

Al comprimir archivos de texto, como datos JSON y CSV, intente lograr un equilibrio entre el número de archivos y su tamaño. La mayoría de los formatos de compresión requieren que el lector lea los archivos desde el principio. Esto significa que, en general, los archivos de texto comprimidos no se pueden procesar en paralelo. Los archivos grandes sin comprimir suelen dividirse entre los trabajos para lograr un mayor paralelismo durante el procesamiento de las consultas, pero esto no es posible con la mayoría de los formatos de compresión.

Como se explica en Cómo evitar tener demasiados archivos, lo mejor es no tener demasiados archivos ni muy pocos. Como el número de archivos es el límite del número de trabajos que se pueden procesar en la consulta, esta regla se aplica aún más a los archivos comprimidos.

Para obtener más información sobre el uso de la compresión en Athena, consulte Compatibilidad con la compresión de Athena.

Creación de buckets para buscar claves con cardinalidad alta

La agrupación en buckets es una técnica para distribuir los registros en archivos separados según el valor de una de las columnas. Esto garantiza que todos los registros con el mismo valor estén en el mismo archivo. La agrupación en buckets resulta útil cuando se tiene una clave con una cardinalidad alta y muchas de las consultas buscan valores específicos de la clave.

Por ejemplo, supongamos que consulta un conjunto de registros para un usuario específico. Si los datos están agrupados por ID de usuario, Athena sabe de antemano qué archivos contienen registros para un ID específico y cuáles no. Esto permite a Athena leer solo los archivos que pueden contener el ID, lo que reduce de forma significativa la cantidad de datos leídos. También reduce el tiempo de computación que, de otro modo, se necesitaría para buscar el ID específico en los datos.

Desventajas de agrupar en buckets

La agrupación en buckets es menos valiosa cuando las consultas buscan con frecuencia múltiples valores en la columna por la que están agrupados los datos. Cuantos más valores se consulten, mayor será la probabilidad de que se tengan que leer todos los archivos o la mayoría de ellos. Por ejemplo, si tiene tres buckets y una consulta busca tres valores diferentes, es posible que deban leerse todos los archivos. La agrupación en buckets funciona mejor cuando las consultas buscan valores únicos.

Para obtener más información, consulte Creación de particiones y asignación de buckets en Athena.

Cómo evitar tener demasiados archivos

Los conjuntos de datos que consisten en muchos archivos pequeños dan como resultado un rendimiento general de las consultas deficiente. Cuando Athena planifica una consulta, lista todas las ubicaciones de las particiones, lo que lleva tiempo. La administración y solicitud de cada archivo también supone una sobrecarga computacional. Por lo tanto, cargar un solo archivo más grande desde Amazon S3 es más rápido que cargar los mismos registros desde muchos archivos más pequeños.

En casos extremos, es posible que se encuentre con límites de servicio de Amazon S3. Amazon S3 admite hasta 5500 solicitudes por segundo en una sola partición de índice. Inicialmente, un bucket se trata como una partición de índice único, pero a medida que aumentan las cargas de solicitudes, se puede dividir en varias particiones de índice.

Amazon S3 analiza los patrones de solicitudes y los divide en función de los prefijos clave. Si su conjunto de datos consiste en muchos miles de archivos, las solicitudes procedentes de Athena pueden superar la cuota de solicitudes. Incluso con menos archivos, se puede superar la cuota si se realizan varias consultas simultáneas en el mismo conjunto de datos. Otras aplicaciones que tengan acceso a los mismos archivos pueden contribuir al número total de solicitudes.

Cuando se supera la tasa de solicitudes limit, Amazon S3 muestra el siguiente error. Este error se incluye en la información de estado de la consulta en Athena.

SlowDown: Reduzca su tasa de solicitudes

Para solucionar el problema, comience por determinar si el error se debe a una sola consulta o a varias consultas que leen los mismos archivos. Si se debe a lo último, coordine la ejecución de las consultas para que no se ejecuten al mismo tiempo. Para lograrlo, agregue un mecanismo de colas o incluso de reintentos en su aplicación.

Si al ejecutar una sola consulta se desencadena el error, intente combinar archivos de datos o modificar la consulta para leer menos archivos. El mejor momento para combinar archivos pequeños es antes de escribirlos. Para ello, tenga en cuenta las siguientes técnicas:

  • Cambie el proceso de escritura de los archivos para escribir archivos más grandes. Por ejemplo, puede almacenar los registros en búfer durante más tiempo antes de que se escriban.

  • Coloque los archivos en una ubicación de Amazon S3 y utilice una herramienta como ETL de Glue para combinarlos en archivos más grandes. Luego, mueva los archivos más grandes a la ubicación a la que apunta la tabla. Para obtener más información, consulte Leer archivos de entrada en grupos más grandes en la Guía para AWS Glue desarrolladores y ¿Cómo puedo configurar un trabajo de AWS Glue ETL para generar archivos más grandes? en el centro de conocimiento AWS Re:post.

  • Reduzca el número de claves de partición. Si tiene demasiadas claves de partición, es posible que cada partición tenga solo algunos registros, lo que se traduce en un número excesivo de archivos pequeños. Para obtener información sobre cómo decidir qué particiones crear, consulte Elección de claves de partición compatibles con las consultas.

Cómo evitar jerarquías de almacenamiento adicionales más allá de la partición

Para evitar la sobrecarga de planificación de consultas, almacene los archivos en una estructura plana en cada ubicación de partición. No utilice jerarquías de directorios adicionales.

Cuando Athena planifica una consulta, lista todos los archivos de todas las particiones que coinciden con la consulta. Aunque Amazon S3 no tiene directorios propiamente dichos, la convención consiste en interpretar la barra diagonal / como un separador de directorios. Cuando Athena lista las ubicaciones de las particiones, lista de forma recursiva cualquier directorio que encuentre. Cuando los archivos de una partición se organizan en una jerarquía, se producen varias rondas de operaciones de lista.

Cuando todos los archivos están directamente en la ubicación de la partición, la mayoría de las veces solo se debe realizar una operación de lista. Sin embargo, se requieren varias operaciones de lista secuencial si tiene más de 1000 archivos en una partición, ya que Amazon S3 devuelve solo 1000 objetos por operación de lista. Tener más de 1000 archivos en una partición también puede provocar otros problemas de rendimiento más graves. Para obtener más información, consulte Cómo evitar tener demasiados archivos.

Uso de SymlinkTextInputFormat solo cuando sea necesario

El uso de la técnica SymlinkTextInputFormat puede ser una forma de evitar situaciones en las que los archivos de una tabla no estén bien organizados en particiones. Por ejemplo, los enlaces simbólicos pueden resultar útiles cuando todos los archivos tienen el mismo prefijo o si los archivos con esquemas diferentes se encuentran en la misma ubicación.

Sin embargo, el uso de enlaces simbólicos agrega niveles de indirección a la ejecución de la consulta. Estos niveles de indirección afectan el rendimiento general. Se deben leer los archivos de enlace simbólico y se deben listar las ubicaciones que definen. Esto agrega varios viajes de ida y vuelta a Amazon S3 que las tablas de Hive habituales no requieren. En conclusión, SymlinkTextInputFormat solo debe utilizarse cuando no haya mejores opciones disponibles, como la reorganización de archivos.

Recursos adicionales de

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