# Consultas, funciones y operadores de DML El motor de consultas DML de Athena generalmente admite la sintaxis de Trino y Presto y agrega sus propias mejoras. Athena no es compatible con todas las características de Presto. Para obtener más información, consulte los temas sobre instrucciones específicas de esta sección, así como [Consideraciones y limitaciones](other-notable-limitations.md). Para obtener información sobre las funciones, consulte [Funciones en Amazon Athena](functions.md). Para obtener más información acerca de las versiones de motor Athena, consulte [Control de versiones del motor Athena](engine-versions.md). Para obtener información sobre las instrucciones DDL, consulte [Instrucciones DDL](ddl-reference.md). Para ver una lista de las instrucciones DDL no admitidas, consulte [DDL no admitido](unsupported-ddl.md). **Topics** + [SELECT](select.md) + [INSERT INTO](insert-into.md) + [VALUES](values-statement.md) + [DELETE](delete-statement.md) + [UPDATE](update-statement.md) + [MERGE INTO](merge-into-statement.md) + [OPTIMIZE](optimize-statement.md) + [VACUUM](vacuum-statement.md) + [EXPLAIN y EXPLAIN ANALYZE](athena-explain-statement.md) + [PREPARE](sql-prepare.md) + [UNLOAD](unload.md) + [Funciones](functions.md) + [Uso de zonas horarias admitidas](athena-supported-time-zones.md) # SELECT Recupera filas de datos de cero o más tablas. **nota** En este tema se proporciona un resumen de información de referencia. La información completa sobre el uso de `SELECT` y el lenguaje SQL está fuera del alcance de esta documentación. Para obtener información sobre el uso de SQL específico de Athena, consulte [Consideraciones y limitaciones de las consultas SQL en Amazon Athena](other-notable-limitations.md) y [Ejecución de consultas SQL en Amazon Athena](querying-athena-tables.md). Para ver un ejemplo de cómo crear una base de datos, crear una tabla y ejecutar una consulta `SELECT` en una tabla en Athena, consulte [Introducción](getting-started.md). ## Sinopsis ``` [ WITH with_query [, ...] ] SELECT [ ALL | DISTINCT ] select_expression [, ...] [ FROM from_item [, ...] ] [ WHERE condition ] [ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ] [ HAVING condition ] [ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ] [ ORDER BY expression [ ASC | DESC ] [ NULLS FIRST | NULLS LAST] [, ...] ] [ OFFSET count [ ROW | ROWS ] ] [ LIMIT [ count | ALL ] ] ``` **nota** Las palabras reservadas en las instrucciones SELECT de SQL deben ponerse entre comillas dobles. Para obtener más información, consulte [Palabras reservadas para incluir en las instrucciones SQL SELECT](reserved-words.md#list-of-reserved-words-sql-select). ## Parameters **[ WITH with\$1query [, ....] ]** Puede utilizar `WITH` para aplanar consultas anidadas o para simplificar subconsultas. Se admite el uso de la cláusula `WITH` para crear consultas recursivas con la versión 3 del motor de Athena. La profundidad máxima de recursión es 10. La cláusula `WITH` precede a la lista `SELECT` de una consulta y define una o varias subconsultas para utilizarlas en la consulta `SELECT`. Cada subconsulta define una tabla temporal, similar a la definición de una vista, a la que puede hacer referencia en la cláusula `FROM`. Las tablas se utilizan solo cuando se ejecuta la consulta. `with_query`La sintaxis de es: ``` subquery_table_name [ ( column_name [, ...] ) ] AS (subquery) ``` Donde: + `subquery_table_name` es un nombre único para una tabla temporal que define los resultados de la subconsulta de cláusula `WITH`. Cada `subquery` debe tener un nombre de tabla al que se pueda hacer referencia en la cláusula `FROM`. + `column_name [, ...]` es una lista opcional de los nombres de columna de salida. La cantidad de nombres de columnas debe ser igual o menor que la cantidad de columnas definidas por la `subquery`. + `subquery` es cualquier declaración de consulta. **[ ALL \$1 DISTINCT ] select\$1expression** `select_expression` determina las filas que deben seleccionarse. Con la opción `select_expression` se puede usar uno de los siguientes formatos: ``` expression [ [ AS ] column_alias ] [, ...] ``` ``` row_expression.* [ AS ( column_alias [, ...] ) ] ``` ``` relation.* ``` ``` * ``` + La sintaxis `expression [ [ AS ] column_alias ]` especifica una columna de salida. La sintaxis opcional `[AS] column_alias` especifica un nombre de encabezado personalizado que se utilizará en la columna de la salida. + Para `row_expression.* [ AS ( column_alias [, ...] ) ]`, `row_expression` es una expresión arbitraria de tipo `ROW`. Los campos de la fila definen las columnas de salida que se incluirán en el resultado. + Para `relation.*`, las columnas de `relation` se incluyen en el resultado. Esta sintaxis no permite el uso de alias de columna. + El asterisco `*` especifica que todas las columnas deben incluirse en el conjunto de resultados. + En el conjunto de resultados, el orden de las columnas es el mismo que el orden de su especificación según la expresión seleccionada. Si una expresión seleccionada devuelve varias columnas, el orden de las columnas sigue el orden utilizado en la relación de origen o la expresión de tipo fila. + Cuando se especifican alias de columna, estos sustituyen a los nombres de columna o campos de fila preexistentes. Si la expresión seleccionada no tiene nombres de columna, en la salida se muestran los nombres de columna anónimos indexados a cero (`_col0`, `_col1` y `_col2, ...`). + `ALL` es el valor predeterminado. El uso de `ALL` se trata de la misma manera que si se hubiera omitido; todas las filas de todas las columnas se seleccionan y se conservan los duplicados. + Utilice `DISTINCT` para devolver solo valores únicos cuando una columna contiene valores duplicados. **FROM from\$1item [, ...]** Indica la entrada de datos de la consulta, donde `from_item` puede ser una vista, una construcción JOIN o una subconsulta, tal y como se describe a continuación. `from_item` puede ser: + `table_name [ [ AS ] alias [ (column_alias [, ...]) ] ]` Donde `table_name` es el nombre de la tabla de destino en la que se seleccionan las filas, `alias` es el nombre que se debe dar a la salida de la instrucción `SELECT` y `column_alias` define las columnas para el `alias` especificado. **-O BIEN-** + `join_type from_item [ ON join_condition | USING ( join_column [, ...] ) ]` Donde `join_type` es uno de los valores siguientes: + `[ INNER ] JOIN` + `LEFT [ OUTER ] JOIN` + `RIGHT [ OUTER ] JOIN` + `FULL [ OUTER ] JOIN` + `CROSS JOIN` + `ON join_condition | USING (join_column [, ...])` Donde con `join_condition` puede especificar nombres de columnas para claves de combinación en varias tablas y el uso de `join_column` requiere que `join_column` exista en ambas tablas. **[ WHERE condition ]** Filtra los resultados de acuerdo con la `condition` que especifique, donde `condition` por lo general tiene la siguiente sintaxis. ``` column_name operator value [[[AND | OR] column_name operator value] ...] ``` El *operador* puede ser uno de los comparadores `=`, `>`, `<`, `>=`, `<=`, `<>`, `!=`. Las siguientes expresiones de subconsulta también se pueden utilizar en la cláusula `WHERE`. + `[NOT] BETWEEN integer_A AND integer_B`: especifica un rango entre dos enteros, como en el ejemplo siguiente. Si el tipo de datos de la columna es `varchar`, primero se debe convertir la columna a números enteros. ``` SELECT DISTINCT processid FROM "webdata"."impressions" WHERE cast(processid as int) BETWEEN 1500 and 1800 ORDER BY processid ``` + `[NOT] LIKE value`: busca el patrón especificado. Utilice el signo de porcentaje (`%`) como carácter comodín, como en el ejemplo siguiente. ``` SELECT * FROM "webdata"."impressions" WHERE referrer LIKE '%.org' ``` + `[NOT] IN (value[, value[, ...])`: especifica una lista de valores posibles para una columna, como en el ejemplo siguiente. ``` SELECT * FROM "webdata"."impressions" WHERE referrer IN ('example.com','example.net','example.org') ``` **[ GROUP BY [ ALL \$1 DISTINCT ] grouping\$1expressions [, ...] ]** Divide la salida de la instrucción `SELECT` en filas con valores coincidentes. `ALL` y `DISTINCT` determinan si los conjuntos de agrupación duplicados producen cada uno filas de salida diferenciadas. Si se omite, el sistema presupone que se utiliza `ALL`. `grouping_expressions` le permite realizar operaciones de agrupación complejas. Puede utilizar operaciones de agrupación complejas para realizar análisis que requieran la agregación de varios conjuntos de columnas en una sola consulta. El elemento `grouping_expressions` puede ser cualquier función, como `SUM`, `AVG` o `COUNT`, realizado en columnas de entrada. Las expresiones `GROUP BY` pueden agrupar la salida por nombres de columna de entrada que no se muestran en la salida de la instrucción `SELECT`. Todas las expresiones de salida deben ser funciones o columnas agregadas que existan en la cláusula `GROUP BY`. Puede utilizar una sola consulta para realizar análisis que requieran la agregación de varios conjuntos de columnas. Athena admite agregaciones complejas usando `GROUPING SETS`, `CUBE` y `ROLLUP`. `GROUP BY GROUPING SETS` especifica varias listas de columnas en las que se agruparán. `GROUP BY CUBE` genera todos los conjuntos de agrupación posibles para un conjunto determinado de columnas. `GROUP BY ROLLUP` genera todos los subtotales posibles para un conjunto determinado de columnas. Las operaciones de agrupación complejas no admiten agrupación en expresiones compuestas por columnas de entrada. Solo se admiten nombres de columnas. A menudo puede utilizar `UNION ALL` para obtener los mismos resultados que estas operaciones `GROUP BY`, pero las consultas que utilizan `GROUP BY` tienen la ventaja de leer los datos una vez, mientras que `UNION ALL` lee los datos subyacentes tres veces y puede producir resultados incoherentes cuando el origen de los datos está sujeto a cambios. **[ HAVING condition ]** Se usa con funciones agregadas y la cláusula `GROUP BY`. Controla qué grupos se seleccionan, con lo que se eliminan los grupos que no cumplen el valor de `condition`. Este filtro se aplica después de calcular los grupos y los agregados. **[ \$1 UNION \$1 INTERSECT \$1 EXCEPT \$1 [ ALL \$1 DISTINCT ] union\$1query] ]** `UNION`, `INTERSECT` y `EXCEPT` combinan los resultados de más de una instrucción `SELECT` en una sola consulta. `ALL` o `DISTINCT` determinan el carácter único de las filas que se incluyen en el conjunto de resultados final. `UNION` combina las filas resultantes de la primera consulta con las filas resultantes de la segunda consulta. Para eliminar duplicados, `UNION` construye una tabla hash, que consume memoria. Para un mejor rendimiento, considere utilizar `UNION ALL` si la consulta no requiere la eliminación de duplicados. Si hay varias cláusulas `UNION`, dichas cláusulas se procesan de izquierda a derecha a menos que utilice paréntesis para definir explícitamente el orden de procesamiento. `INTERSECT` devuelve solo las filas que están presentes en los resultados de la primera y la segunda consulta. `EXCEPT` devuelve las filas de los resultados de la primera consulta, y excluye las filas encontradas por la segunda consulta. `ALL` hace que se incluyan todas las filas, incluso si dichas filas son idénticas. `DISTINCT` hace que solo se incluyan filas únicas en el conjunto de resultados combinados. **[ ORDER BY expression [ ASC \$1 DESC ] [ NULLS FIRST \$1 NULLS LAST] [, ...] ]** Ordena un conjunto de resultados por una o varias salidas `expression`. Cuando la cláusula contiene varias expresiones, el conjunto de resultados se ordena de acuerdo con la primera `expression`. A continuación, se aplica la segunda `expression` a las filas que tienen valores coincidentes de la primera expresión y así sucesivamente. Cada `expression` puede especificar columnas de salida de `SELECT` o un número ordinal para una columna de salida por posición, a partir de uno. `ORDER BY` se evalúa como el último paso después de cualquier cláusula `GROUP BY` o `HAVING`. `ASC` y `DESC` determinan si los resultados se ordenan de forma ascendente o descendente. El orden es ascendente de manera predeterminada (`ASC`). El orden de los valores nulos predeterminado es `NULLS LAST`, sea cual sea el orden de clasificación, ascendente o descendente. **[ OFFSET count [ ROW \$1 ROWS ] ]** Utilice la cláusula `OFFSET` para descartar varias filas iniciales del conjunto de resultados. Si la cláusula `ORDER BY` está presente, la cláusula `OFFSET` se evalúa sobre un conjunto de resultados ordenado. El conjunto permanece ordenado después de descartar las filas omitidas. Si la consulta no tiene la cláusula `ORDER BY`, es arbitrario qué filas se descartan. Si el recuento especificado por `OFFSET` es igual o superior al tamaño del conjunto de resultados, el resultado final estará vacío. **LIMIT [ count \$1 ALL ]** Restringe el número de filas del conjunto de resultados a `count`. `LIMIT ALL` equivale a omitir la cláusula `LIMIT`. Si la consulta no contiene ninguna cláusula `ORDER BY`, los resultados son arbitrarios. **TABLESAMPLE [ BERNOULLI \$1 SYSTEM ] (porcentaje)** Operador opcional para seleccionar filas de una tabla basado en un método de muestreo. `BERNOULLI` selecciona cada fila que se muestra en la tabla con una probabilidad de `percentage`. Todos los bloques físicos de la tabla se analizan y determinadas filas se omiten basándose en una comparación entre el valor de `percentage` de muestra y un valor aleatorio calculado en el tiempo de ejecución. Con `SYSTEM`, la tabla se divide en segmentos lógicos de datos y la tabla se muestrea con esta granularidad. O bien se seleccionan todas las filas de un segmento en particular, o el segmento se omite basándose en la comparación del valor de `percentage` de la muestra con un valor aleatorio calculado en tiempo de ejecución. El muestreo de `SYSTEM` depende del conector. Este método no garantiza que las probabilidades de muestreo sean independientes. **[ UNNEST (array\$1or\$1map) [WITH ORDINALITY] ]** Amplía una matriz o un mapa a una relación. Las matrices se amplían a una sola columna. Los mapas se amplían a dos columnas (*clave*, *valor*). Puede utilizar `UNNEST` con varios argumentos, que se amplían en varias columnas con tantas filas como el mayor argumento de cardinalidad. Las demás columnas se rellenan con valores nulos. La cláusula `WITH ORDINALITY` añade una columna de ordinalidad al final. `UNNEST` suele utilizarse con `JOIN` y puede hacer referencia a columnas de relaciones del lado izquierdo de `JOIN`. ## Obtención de las ubicaciones de archivos para los datos de origen en Simple Storage Service (Amazon S3) Para ver la ubicación del archivo de Amazon S3 para los datos de una fila de tabla, puede utilizar `"$path"` en una consulta `SELECT`, como en el ejemplo siguiente: ``` SELECT "$path" FROM "my_database"."my_table" WHERE year=2019; ``` Esta consulta devuelve un resultado similar al siguiente: ``` s3://amzn-s3-demo-bucket/datasets_mytable/year=2019/data_file1.json ``` Para devolver una lista ordenada y única de las rutas de nombre de archivo S3 para los datos de una tabla, puede utilizar `SELECT DISTINCT` y `ORDER BY`, como en el ejemplo a continuación. ``` SELECT DISTINCT "$path" AS data_source_file FROM sampledb.elb_logs ORDER By data_source_file ASC ``` Para devolver solo los nombres de archivo sin la ruta, puede pasar `"$path"` como parámetro a una función `regexp_extract`, como en el siguiente ejemplo. ``` SELECT DISTINCT regexp_extract("$path", '[^/]+$') AS data_source_file FROM sampledb.elb_logs ORDER By data_source_file ASC ``` Para devolver los datos de un archivo específico, especifique el archivo en la cláusula `WHERE`, como en el siguiente ejemplo. ``` SELECT *,"$path" FROM my_database.my_table WHERE "$path" = 's3://amzn-s3-demo-bucket/my_table/my_partition/file-01.csv' ``` Para obtener más información y ejemplos, consulte el artículo del Centro de conocimientos [¿Cómo puedo ver el archivo de origen de Amazon S3 de una fila en una tabla de Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/find-s3-source-file-athena-table-row/). **nota** En Athena, las columnas de metadatos ocultas de Hive o Iceberg `$bucket`, `$file_modified_time`, `$file_size` y `$partition` no son compatibles con las vistas. ## Incluir las comillas simples en caracteres de escape Para incluir una comilla simple en caracteres de escape, inserte delante otra comilla simple, como en el ejemplo siguiente. Esto no debe confundirse con las comillas dobles. ``` Select 'O''Reilly' ``` **Resultados** `O'Reilly` ## Recursos adicionales Para obtener más información acerca del uso de instrucciones `SELECT` en Athena, consulte los siguientes recursos. | Para obtener información sobre este tema | Consulte | | --- | --- | | Ejecución de consultas en Athena | [Ejecución de consultas SQL en Amazon Athena](querying-athena-tables.md) | | Uso de SELECT para crear una tabla | [Creación de una tabla a partir de los resultados de una consulta (CTAS)](ctas.md) | | Insertar datos desde una consulta SELECT en otra tabla | [INSERT INTO](insert-into.md) | | Uso de funciones integradas en instrucciones SELECT | [Funciones en Amazon Athena](functions.md) | | Uso de funciones definidas por el usuario en instrucciones SELECT | [Consulta con funciones definidas por el usuario](querying-udf.md) | | Consulta de metadatos del catálogo de datos | [Consulta de AWS Glue Data Catalog](querying-glue-catalog.md) | # INSERT INTO Inserta filas nuevas en una tabla de destino en función de una instrucción de consulta `SELECT` que se ejecuta en una tabla de origen o en función de un conjunto de `VALUES` proporcionados como parte de la instrucción. Cuando la tabla de origen se basa en datos subyacentes con un formato concreto, como CSV o JSON, y la tabla de destino emplea otro formato, como Parquet u ORC, puede utilizar consultas `INSERT INTO` para transformar los datos seleccionados en el formato de la tabla de destino. ## Consideraciones y limitaciones Cuando utilice las consultas `INSERT` con Athena, tenga en cuenta lo siguiente. + De forma predeterminada, cuando se ejecuta una consulta `INSERT` en una tabla con datos subyacentes cifrados en Amazon S3, los archivos de salida que escribe la consulta `INSERT` no se cifran. Le recomendamos que cifre los resultados de las consultas `INSERT` si se van a insertar en tablas con datos cifrados. Para obtener más información acerca cómo cifrar los resultados de las consultas utilizando la consola, consulte [Cifrado de los resultados de las consultas de Athena en Amazon S3](encrypting-query-results-stored-in-s3.md). Para habilitar el cifrado mediante la AWS CLI o la API de Athena, utilice las propiedades `EncryptionConfiguration` de la acción [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html) para especificar las opciones de cifrado de Amazon S3 en función de sus necesidades. + Para las instrucciones `INSERT INTO`, la configuración del propietario del bucket esperado no se aplica a la ubicación de la tabla de destino en Amazon S3. La configuración del propietario esperado del bucket se aplica solo a la ubicación de salida de Amazon S3 especificada para los resultados de las consultas de Athena. Para obtener más información, consulte [Especificación de una ubicación de resultados de consulta mediante la consola de Athena](query-results-specify-location-console.md). + En relación con las instrucciones `INSERT INTO` que cumplen con los requisitos de ACID, consulte la sección `INSERT INTO` de [Actualización de los datos de las tablas de Iceberg](querying-iceberg-updating-iceberg-table-data.md). ### Formatos y SerDes compatibles Puede ejecutar una consulta `INSERT` en las tablas creadas a partir de datos con los siguientes formatos y SerDes. | Formato de los datos | SerDe | | --- | --- | | Avro | org.apache.hadoop.hive.serde2.avro.AvroSerDe | | Ion | com.amazon.ionhiveserde.IonHiveSerDe | | JSON | org.apache.hive.hcatalog.data.JsonSerDe | | ORC | org.apache.hadoop.hive.ql.io.orc.OrcSerde | | Parquet | org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe | | Archivo de texto | org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe Se admiten archivos TSV y con delimitadores personalizados. | | CSV | org.apache.hadoop.hive.serde2.OpenCSVSerde Las escrituras solo son compatibles con tipos de datos de cadena. Desde Athena, no se puede escribir en tablas cuyo esquema de Glue contenga tipos de datos que no sean de cadena. Para obtener más información, consulte [CSV SerDe](csv-serde.md#csv-serde-opencsvserde-considerations-non-string). | ### No se admiten tablas en buckets. `INSERT INTO` no es compatible con las tablas en buckets. Para obtener más información, consulte [Uso de particiones y asignación de buckets](ctas-partitioning-and-bucketing.md). ### Consultas federadas no compatibles `INSERT INTO` no es compatible con las consultas federadas. Si intenta hacerlo, puede aparecer el mensaje de error This operation is currently not supported for external catalogs (Esta operación no es compatible actualmente con catálogos externos). Para obtener información sobre las consultas federadas, consulte [Uso de consulta federada de Amazon Athena](federated-queries.md). ### Particiones Tenga en cuenta los puntos de esta sección al utilizar particiones con consultas `INSERT INTO` o `CREATE TABLE AS SELECT`. #### Límites La instrucción `INSERT INTO` admite escribir un máximo de 100 particiones en la tabla de destino. Si ejecuta la cláusula `SELECT` en una tabla con más de 100 particiones, se produce un error en la consulta a menos que la consulta `SELECT` esté limitada a 100 particiones o menos. Para obtener más información sobre cómo evitar esta limitación, consulte [Uso de CTAS e INSERT INTO para evitar el límite de 100 particiones](ctas-insert-into.md). #### Ordenamiento de columnas Las instrucciones `INSERT INTO` o `CREATE TABLE AS SELECT` esperan que la columna particionada sea la última de la lista de columnas proyectadas en una instrucción `SELECT`. Si la tabla de origen no está particionada o está particionada en columnas diferentes en comparación con la tabla de destino, las consultas como `INSERT INTO destination_table SELECT * FROM source_table` consideran que los valores de la última columna de la tabla de origen son valores para una columna de partición en la tabla de destino. Tenga esto en cuenta al intentar crear una tabla particionada desde una tabla no particionada. #### Recursos Para obtener más información acerca del uso de `INSERT INTO` con la partición, consulte los siguientes recursos. + Para insertar datos particionados en una tabla particionada, consulte [Uso de CTAS e INSERT INTO para evitar el límite de 100 particiones](ctas-insert-into.md). + Para insertar datos no particionados en una tabla particionada, consulte [Uso de CTAS e INSERT INTO en ETL y análisis de datos](ctas-insert-into-etl.md). ### Archivos escritos en Simple Storage Service (Amazon S3) Tras ejecutar el comando `INSERT`, Athena escribe archivos en las ubicaciones de datos de origen de Amazon S3. Cada operación `INSERT` crea un nuevo archivo, en lugar de anexar el resultado a un archivo existente. Las ubicaciones de los archivos dependen de la estructura de la tabla y la consulta `SELECT`, si procede. Athena genera un archivo de manifiesto de datos para cada consulta `INSERT`. El manifiesto realiza un seguimiento de los archivos que escribió la consulta. Se guarda en la ubicación del resultado de la consulta de Athena en Amazon S3. Para obtener más información, consulte [Identificación de archivos de salida de consultas](querying-finding-output-files.md#querying-identifying-output-files). ### Evite las actualizaciones altamente transaccionales Cuando utiliza `INSERT INTO` para añadir filas a una tabla en Amazon S3, Athena no reescribe ni modifica los archivos existentes. En su lugar, escribe las filas como uno o más archivos nuevos. Dado que las tablas con [ muchos archivos pequeños reducen el rendimiento de las consultas](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files) y que las operaciones de escritura lectura, como `PutObject` y `GetObject`, generan costes más altos de Amazon S3, tenga en cuenta las siguientes opciones cuando utiliza `INSERT INTO`: + Ejecute las operaciones `INSERT INTO` con menos frecuencia en lotes más grandes de filas. + Para grandes volúmenes de ingesta de datos, considere la posibilidad de utilizar un servicio como [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html). + Evite por completo el uso de `INSERT INTO`. En su lugar, acumule filas en archivos más grandes y cárguelos directamente en Amazon S3, donde Athena podrá consultarlos. ### Localización de archivos huérfanos Si una instrucción `CTAS` o `INSERT INTO` falla, los datos huérfanos se pueden dejar en la ubicación de los datos y se pueden leer en consultas posteriores. Para localizar archivos huérfanos para su inspección o eliminación, puede utilizar el archivo de manifiesto de datos que Athena proporciona para realizar un seguimiento de la lista de archivos que se van a escribir. Para obtener más información, consulte [Identificación de archivos de salida de consultas](querying-finding-output-files.md#querying-identifying-output-files) y [DataManifestLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_QueryExecutionStatistics.html#athena-Type-QueryExecutionStatistics-DataManifestLocation). ## INSERT INTO...SELECT Especifica la consulta que se va a ejecutar en una tabla, `source_table`, lo que determina las filas que se van a insertar en una segunda tabla, `destination_table`. Si la consulta `SELECT` especifica columnas de `source_table`, las columnas deben coincidir exactamente con las de `destination_table`. Para obtener más información acerca de las consultas `SELECT`, consulte [SELECT](select.md). ### Sinopsis ``` INSERT INTO destination_table SELECT select_query FROM source_table_or_view ``` ### Ejemplos Seleccione todas las filas de la tabla `vancouver_pageviews` e insértelas en la tabla `canada_pageviews`: ``` INSERT INTO canada_pageviews SELECT * FROM vancouver_pageviews; ``` Seleccione solo las filas de la tabla `vancouver_pageviews` en las que la columna `date` tiene un valor comprendido entre `2019-07-01` y `2019-07-31`. Después, insértelas en `canada_july_pageviews`: ``` INSERT INTO canada_july_pageviews SELECT * FROM vancouver_pageviews WHERE date BETWEEN date '2019-07-01' AND '2019-07-31'; ``` En la tabla `city`, seleccione los valores de las columnas `state` y `cities_world` de aquellas filas que tengan el valor `usa` en la columna `country` e insértelos en las columnas `city` y `state` de la tabla `cities_usa`: ``` INSERT INTO cities_usa (city,state) SELECT city,state FROM cities_world WHERE country='usa' ``` ## INSERT INTO...VALUES Inserta filas en una tabla existente especificando columnas y valores. Las columnas especificadas y los tipos de datos asociados deben coincidir exactamente con las columnas y los tipos de datos de la tabla de destino. **importante** No es recomendable utilizar `VALUES` para insertar las filas, ya que Athena genera archivos con cada operación `INSERT`. Esto puede provocar que se creen muchos archivos pequeños y reducir el rendimiento de las consultas de la tabla. Para identificar los archivos que crea una consulta `INSERT`, examine el archivo del manifiesto de datos. Para obtener más información, consulte [Trabajo con resultados de la consulta y consultas recientes](querying.md). ### Sinopsis ``` INSERT INTO destination_table [(col1,col2,...)] VALUES (col1value,col2value,...)[, (col1value,col2value,...)][, ...] ``` ### Ejemplos En los siguientes ejemplos, la tabla de ciudades tiene varias columnas: , , y: `id`, `city`, `state`, `state_motto`. La columna `id` es de tipo `INT`, mientras que todas las demás columnas son de tipo `VARCHAR`. Inserte una sola fila en la tabla `cities` con todos los valores de columna especificados: ``` INSERT INTO cities VALUES (1,'Lansing','MI','Si quaeris peninsulam amoenam circumspice') ``` Inserte dos filas en la tabla `cities`: ``` INSERT INTO cities VALUES (1,'Lansing','MI','Si quaeris peninsulam amoenam circumspice'), (3,'Boise','ID','Esto perpetua') ``` # VALUES Crea una tabla en línea literal. La tabla puede ser anónima o puede usar la cláusula `AS` para especificar un nombre de tabla, nombres de columnas o ambos. ## Sinopsis ``` VALUES row [, ...] ``` ## Parámetros **fila** El parámetro `row` puede ser una expresión única o `( column_expression [, ...] )`. ## Ejemplos Devolver una tabla con una columna y tres filas: ``` VALUES 1, 2, 3 ``` Devolver una tabla con dos columnas y tres filas: ``` VALUES (1, 'a'), (2, 'b'), (3, 'c') ``` Devolver una tabla con las columnas `id` y `name`: ``` SELECT * FROM ( VALUES (1, 'a'), (2, 'b'), (3, 'c') ) AS t (id, name) ``` Crear una tabla llamada `customers` con las columnas `id` y `name`: ``` CREATE TABLE customers AS SELECT * FROM ( VALUES (1, 'a'), (2, 'b'), (3, 'c') ) AS t (id, name) ``` ## Véase también [INSERT INTO...VALUES](insert-into.md#insert-into-values) # DELETE Elimina filas de una tabla de Apache Iceberg. `DELETE` es transaccional y solo se admite en tablas de Apache Iceberg. ## Sinopsis Para eliminar las filas de una tabla de Iceberg, use la siguiente sintaxis. ``` DELETE FROM [db_name.]table_name [WHERE predicate] ``` Para obtener más información y ejemplos, consulte la sección de `DELETE` de [Actualización de los datos de las tablas de Iceberg](querying-iceberg-updating-iceberg-table-data.md). # UPDATE Actualice las filas de una tabla de Apache Iceberg. `UPDATE` es transaccional y solo se admite en tablas de Apache Iceberg. La instrucción solo funciona en las filas existentes y no se puede utilizar para insertar o anexar una fila. ## Sinopsis Para actualizar las filas de una tabla de Iceberg, use la siguiente sintaxis. ``` UPDATE [db_name.]table_name SET xx=yy[,...] [WHERE predicate] ``` Para obtener más información y ejemplos, consulte la sección de `UPDATE` de [Actualización de los datos de las tablas de Iceberg](querying-iceberg-updating-iceberg-table-data.md). # MERGE INTO Actualiza, elimina o inserta filas de forma condicional en una tabla de Apache Iceberg. Una sola instrucción puede combinar acciones de actualización, eliminación e inserción. **nota** `MERGE INTO` es transaccional y solo es compatible con las tablas de Apache Iceberg en la versión 3 del motor Athena. ## Sinopsis Para actualizar, eliminar o insertar filas de forma condicional de una tabla de Iceberg, use la siguiente sintaxis. ``` MERGE INTO target_table [ [ AS ] target_alias ] USING { source_table | query } [ [ AS ] source_alias ] ON search_condition when_clause [...] ``` La cláusula *when\$1clause* es una de las siguientes: ``` WHEN MATCHED [ AND condition ] THEN DELETE ``` ``` WHEN MATCHED [ AND condition ] THEN UPDATE SET ( column = expression [, ...] ) ``` ``` WHEN NOT MATCHED [ AND condition ] THEN INSERT (column_name[, column_name ...]) VALUES (expression, ...) ``` `MERGE` admite un número arbitrario de cláusulas `WHEN` con diferentes condiciones `MATCHED`. Las cláusulas de condición ejecutan la operación `DELETE`, `UPDATE` o `INSERT` de la primera cláusula `WHEN` seleccionada por el estado `MATCHED` y la condición de coincidencia. Para cada fila de origen, las cláusulas `WHEN` se procesan en orden. Solo se ejecuta la primera cláusula `WHEN` coincidente. Las demás cláusulas se ignoran. Se produce un error de usuario cuando una sola fila de la tabla de destino coincide con más de una fila de origen. Si una fila de origen no coincide con ninguna cláusula `WHEN` y no hay ninguna cláusula `WHEN NOT MATCHED`, se ignora la fila de origen. En las cláusulas `WHEN` que tienen operaciones `UPDATE`, las expresiones de valores de la columna pueden hacer referencia a cualquier campo del destino o del origen. En el caso de `NOT MATCHED`, las expresiones `INSERT` pueden referirse a cualquier campo del origen. **Ejemplo** En el siguiente ejemplo, se combinan filas de la segunda tabla en la primera tabla si las filas no existen en la primera tabla. Tenga en cuenta que las columnas que aparecen en la cláusula `VALUES` deben ir precedidas del alias de la tabla de origen. Las columnas de destino enumeradas en la cláusula `INSERT` *no* deben tener ese prefijo. ``` MERGE INTO iceberg_table_sample as ice1 USING iceberg2_table_sample as ice2 ON ice1.col1 = ice2.col1 WHEN NOT MATCHED THEN INSERT (col1) VALUES (ice2.col1) ``` Para obtener más ejemplos de `MERGE INTO`, consulte [Actualización de los datos de las tablas de Iceberg](querying-iceberg-updating-iceberg-table-data.md). # OPTIMIZE Optimiza las filas de una tabla de Apache Iceberg al reescribir los archivos de datos en un diseño más optimizado en función de su tamaño y del número de archivos de eliminación asociados. **nota** `OPTIMIZE` es transaccional y solo se admite en tablas de Apache Iceberg. ## Sintaxis En el siguiente resumen de sintaxis, se muestra cómo optimizar el diseño de datos de una tabla de Iceberg. ``` OPTIMIZE [db_name.]table_name REWRITE DATA USING BIN_PACK [WHERE predicate] ``` **nota** Solo se permiten columnas de partición en el *predicado* de la cláusula `WHERE`. Si se especifica una columna que no es de partición, se producirá un error en la consulta. La acción de compactación se cobra por la cantidad de datos analizados durante el proceso de reescritura. La acción `REWRITE DATA` usa predicados para seleccionar los archivos que contienen filas que coinciden. Si alguna fila del archivo coincide con el predicado, el archivo se selecciona para la optimización. Así, para controlar el número de archivos afectados por la operación de compactación, puede especificar una cláusula `WHERE`. ## Configuración de las propiedades de compactación Para controlar el tamaño de los archivos que se seleccionarán para la compactación y el tamaño de archivo resultante después de la compactación, puede usar parámetros de propiedades de tabla. Puede utilizar el comando [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) para configurar las siguientes [propiedades de la tabla](querying-iceberg-creating-tables.md#querying-iceberg-table-properties) relacionadas. ## Recursos adicionales [Optimización de las tablas de Iceberg](querying-iceberg-data-optimization.md) # VACUUM La instrucción `VACUUM` realiza el mantenimiento de las tablas de Apache Iceberg al ocuparse del [vencimiento de las instantáneas](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files) y la [eliminación de los archivos huérfanos](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots). **nota** `VACUUM` es transaccional y solo es compatible con las tablas de Apache Iceberg en la versión 3 del motor Athena. La instrucción `VACUUM` optimiza las tablas de Iceberg al reducir el consumo de almacenamiento. Para obtener más información acerca del uso de `VACUUM`, consulte [Optimización de las tablas de Iceberg](querying-iceberg-data-optimization.md). Tenga en cuenta que, debido a que la instrucción `VACUUM` realiza llamadas de API a Amazon S3, se aplican cargos por las solicitudes asociadas a Amazon S3. **aviso** Si ejecuta una operación de vencimiento de instantáneas, ya no podrá viajar en el tiempo a instantáneas vencidas. ## Sinopsis Para eliminar los archivos de datos que ya no se necesitan para una tabla de Iceberg, use la siguiente sintaxis. ``` VACUUM [database_name.]target_table ``` + Tenga en cuenta que `VACUUM` espera que los datos de Iceberg estén en una carpeta de Amazon S3 en lugar de estar en un bucket de Amazon S3. Por ejemplo, si los datos de Iceberg se encuentran en `s3://amzn-s3-demo-bucket`/ en lugar de `s3://amzn-s3-demo-bucket/myicebergfolder/`, la instrucción `VACUUM` falla con el mensaje de error GENERIC\$1INTERNAL\$1ERROR: Falta la ruta en la ubicación del sistema de archivos: `s3://amzn-s3-demo-bucket`. + Para que `VACUUM` pueda eliminar archivos de datos, su función de ejecución de consultas debe tener `s3:DeleteObject` permisos en el bucket en el que se encuentran las tablas, los metadatos, las instantáneas y los archivos de datos de Iceberg. Si el permiso no está presente, la consulta `VACUUM` se realizará correctamente, pero los archivos no se eliminarán. + Para ejecutar `VACUUM` en una tabla cuyo nombre comience con un guión bajo (por ejemplo, `_mytable`), encierre el nombre de la tabla entre comillas inversas, como en el siguiente ejemplo. Si antepone al nombre de la tabla un nombre de base de datos, no encierre el nombre de la base de datos entre comillas inversas. Tenga en cuenta que las comillas dobles no funcionarán en lugar de las comillas inversas. Este comportamiento es específico de `VACUUM`. Las instrucciones `CREATE` y `INSERT INTO` no requieren comillas inversas para los nombres de tabla que comienzan con guiones bajos. ``` VACUUM `_mytable` VACUUM my_database.`_mytable` ``` ## Operaciones realizadas `VACUUM` lleva a cabo las siguientes operaciones: + Elimina las instantáneas que tengan una antigüedad superior a la cantidad de tiempo especificada en la propiedad de la tabla `vacuum_max_snapshot_age_seconds`. De forma predeterminada, esta propiedad se establece en 432 000 segundos (5 días). + Elimina las instantáneas que no estén dentro del periodo de conservación y que superen el número especificado en la propiedad de la tabla `vacuum_min_snapshots_to_keep`. El valor predeterminado de es 1. Puede especificar estas propiedades de la tabla en su instrucción `CREATE TABLE`. Después de crear la tabla, se puede usar la instrucción [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) para actualizarla. + Elimina los metadatos y los archivos de datos a los que no se pueda acceder como resultado de la eliminación de la instantánea. Puede configurar la cantidad de archivos de metadatos antiguos que se van a retener al configurar la propiedad de la tabla `vacuum_max_metadata_files_to_keep`. El valor predeterminado es 100. + Elimina los archivos huérfanos que tienen una antigüedad superior al tiempo especificado en la propiedad de la tabla `vacuum_max_snapshot_age_seconds`. Los archivos huérfanos son archivos del directorio de datos de la tabla que no forman parte del estado de la tabla. Para obtener más información acerca de la creación y administración de tablas de Apache Iceberg en Athena, consulte [Creación de tablas de Iceberg](querying-iceberg-creating-tables.md) y [Administración de tablas de Iceberg](querying-iceberg-managing-tables.md). # Uso de EXPLAIN y EXPLAIN ANALYZE en Athena La instrucción `EXPLAIN` muestra el plan de ejecución lógico o distribuido de una instrucción SQL especificada, o valida la instrucción SQL. Puede generar los resultados en formato de texto o en formato de datos para representarlos en un gráfico. **nota** Puede ver representaciones gráficas de planes lógicos y distribuidos para sus consultas en la consola de Athena sin usar la sintaxis `EXPLAIN`. Para obtener más información, consulte [Visualización de planes de ejecución para consultas SQL](query-plans.md). La instrucción `EXPLAIN ANALYZE` muestra el plan de ejecución distribuido de una instrucción SQL especificada y el costo computacional de cada operación en una consulta SQL. Puede generar los resultados en formato de texto o JSON. ## Consideraciones y limitaciones Las instrucciones `EXPLAIN` y `EXPLAIN ANALYZE` de Athena tienen las siguientes limitaciones. + Dado que las consultas `EXPLAIN` no escanean ningún dato, Athena no cobra por ellas. Sin embargo, como las consultas `EXPLAIN` realizan llamadas a AWS Glue para recuperar metadatos de la tabla, puede incurrir en cargos de Glue si las llamadas superan el [límite de nivel gratuito de Glue](https://aws.amazon.com/free/?all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Categories=categories%23analytics&all-free-tier.q=glue&all-free-tier.q_operator=AND). + Como se ejecutan las consultas `EXPLAIN ANALYZE`, analizan datos, de modo que Athena cobra en función de los datos escaneados. + La información de filtrado de filas o celdas definida en Lake Formation y la información de estadísticas de consultas no se muestran en la salida de `EXPLAIN` y `EXPLAIN ANALYZE`. ## Sintaxis de EXPLAIN ``` EXPLAIN [ ( option [, ...]) ] statement ``` La *opción* puede ser una de las siguientes: ``` FORMAT { TEXT | GRAPHVIZ | JSON } TYPE { LOGICAL | DISTRIBUTED | VALIDATE | IO } ``` Si no se especifica la opción `FORMAT`, la salida predeterminada es en formato `TEXT`. El tipo `IO` proporciona información sobre las tablas y esquemas que la consulta lee. ## Sintaxis de EXPLAIN ANALYZE Además de la salida incluida en `EXPLAIN`, la salida `EXPLAIN ANALYZE` también incluye estadísticas de tiempo de ejecución de la consulta especificada, como el uso de CPU, el número de filas de entrada y el número de filas de salida. ``` EXPLAIN ANALYZE [ ( option [, ...]) ] statement ``` La *opción* puede ser una de las siguientes: ``` FORMAT { TEXT | JSON } ``` Si no se especifica la opción `FORMAT`, la salida predeterminada es en formato `TEXT`. Como todas las consultas para `EXPLAIN ANALYZE` son `DISTRIBUTED`, la opción `TYPE` no está disponible para `EXPLAIN ANALYZE`. La *instrucción* puede ser una de las siguientes: ``` SELECT CREATE TABLE AS SELECT INSERT UNLOAD ``` ## Ejemplos de EXPLAIN Los siguientes ejemplos de `EXPLAIN` avanzan de los más sencillos a los más complejos. ### Ejemplo 1: uso de la instrucción EXPLAIN para mostrar un plan de consulta en formato de texto En el siguiente ejemplo, `EXPLAIN` muestra el plan de ejecución de una consulta `SELECT` en registros de Elastic Load Balancing. El formato se establece de forma predeterminada en la salida de texto. ``` EXPLAIN SELECT request_timestamp, elb_name, request_ip FROM sampledb.elb_logs; ``` #### Resultados ``` - Output[request_timestamp, elb_name, request_ip] => [[request_timestamp, elb_name, request_ip]] - RemoteExchange[GATHER] => [[request_timestamp, elb_name, request_ip]] - TableScan[awsdatacatalog:HiveTableHandle{schemaName=sampledb, tableName=elb_logs, analyzePartitionValues=Optional.empty}] => [[request_timestamp, elb_name, request_ip]] LAYOUT: sampledb.elb_logs request_ip := request_ip:string:2:REGULAR request_timestamp := request_timestamp:string:0:REGULAR elb_name := elb_name:string:1:REGULAR ``` ### Ejemplo 2: uso de EXPLAIN para la representación gráfica de un plan de consulta Puede utilizar la consola de Athena para representar de manera gráfica un plan de consultas. Ingrese una instrucción `SELECT` como la siguiente en el editor de consultas de Athena y, a continuación, elija **EXPLICAR**. ``` SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.customer c JOIN tpch100.orders o ON c.c_custkey = o.o_custkey ``` Se abrirá la página **Explain** (Explicar) del editor de consultas de Athena y se mostrára un plan distribuido y un plan lógico para la consulta. En el siguiente gráfico se muestra el plan lógico para el ejemplo. ![\[Gráfico del plan de consulta representado por el editor de consulta de Athena.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/athena-explain-statement-tpch.png) **importante** Actualmente, es posible que algunos filtros de partición no estén visibles en el gráfico de árbol de operadores anidado, aunque Athena los aplique a la consulta. Para comprobar el efecto de dichos filtros, ejecute `EXPLAIN` o `EXPLAIN ANALYZE` en la consulta y observe los resultados. Para obtener más información sobre cómo usar las características de representación gráfica de planes de consulta en la consola de Athena, consulte [Visualización de planes de ejecución para consultas SQL](query-plans.md). ### Ejemplo 3: uso de la instrucción EXPLAIN para comprobar la eliminación de particiones Cuando se utiliza un predicado de filtrado en una clave particionada para consultar una tabla particionada, el motor de consultas aplica el predicado a la clave particionada para reducir la cantidad de datos leídos. En el siguiente ejemplo se utiliza una consulta `EXPLAIN` para verificar la poda de partición para una consulta `SELECT` en una tabla particionada. Primero, una instrucción `CREATE TABLE` crea la tabla `tpch100.orders_partitioned`. La tabla está particionada en la columna `o_orderdate`. ``` CREATE TABLE `tpch100.orders_partitioned`( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_totalprice` double, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string) PARTITIONED BY ( `o_orderdate` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket//' ``` La tabla `tpch100.orders_partitioned` tiene varias particiones en `o_orderdate`, como se muestra en el comando `SHOW PARTITIONS`. ``` SHOW PARTITIONS tpch100.orders_partitioned; o_orderdate=1994 o_orderdate=2015 o_orderdate=1998 o_orderdate=1995 o_orderdate=1993 o_orderdate=1997 o_orderdate=1992 o_orderdate=1996 ``` La siguiente consulta `EXPLAIN` comprueba la poda de partición en la instrucción `SELECT` especificada. ``` EXPLAIN SELECT o_orderkey, o_custkey, o_orderdate FROM tpch100.orders_partitioned WHERE o_orderdate = '1995' ``` #### Resultados ``` Query Plan - Output[o_orderkey, o_custkey, o_orderdate] => [[o_orderkey, o_custkey, o_orderdate]] - RemoteExchange[GATHER] => [[o_orderkey, o_custkey, o_orderdate]] - TableScan[awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=orders_partitioned, analyzePartitionValues=Optional.empty}] => [[o_orderkey, o_custkey, o_orderdate]] LAYOUT: tpch100.orders_partitioned o_orderdate := o_orderdate:string:-1:PARTITION_KEY :: [[1995]] o_custkey := o_custkey:int:1:REGULAR o_orderkey := o_orderkey:int:0:REGULAR ``` El texto en negrita del resultado muestra que se aplicó el predicado `o_orderdate = '1995'` en `PARTITION_KEY`. ### Ejemplo 4: uso de una consulta EXPLAIN para comprobar el orden de unión y el tipo de unión La siguiente consulta `EXPLAIN` verifica el orden y el tipo de unión de la instrucción `SELECT`. Utilice una consulta como esta para examinar el uso de la memoria de consulta de modo que pueda reducir las posibilidades de obtener un error `EXCEEDED_LOCAL_MEMORY_LIMIT`. ``` EXPLAIN (TYPE DISTRIBUTED) SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.customer c JOIN tpch100.orders o ON c.c_custkey = o.o_custkey WHERE c.c_custkey = 123 ``` #### Resultados ``` Query Plan Fragment 0 [SINGLE] Output layout: [c_custkey, o_orderkey, o_orderstatus] Output partitioning: SINGLE [] Stage Execution Strategy: UNGROUPED_EXECUTION - Output[c_custkey, o_orderkey, o_orderstatus] => [[c_custkey, o_orderkey, o_orderstatus]] - RemoteSource[1] => [[c_custkey, o_orderstatus, o_orderkey]] Fragment 1 [SOURCE] Output layout: [c_custkey, o_orderstatus, o_orderkey] Output partitioning: SINGLE [] Stage Execution Strategy: UNGROUPED_EXECUTION - CrossJoin => [[c_custkey, o_orderstatus, o_orderkey]] Distribution: REPLICATED - ScanFilter[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=customer, analyzePartitionValues=Optional.empty}, grouped = false, filterPredicate = ("c_custkey" = 123)] => [[c_custkey]] LAYOUT: tpch100.customer c_custkey := c_custkey:int:0:REGULAR - LocalExchange[SINGLE] () => [[o_orderstatus, o_orderkey]] - RemoteSource[2] => [[o_orderstatus, o_orderkey]] Fragment 2 [SOURCE] Output layout: [o_orderstatus, o_orderkey] Output partitioning: BROADCAST [] Stage Execution Strategy: UNGROUPED_EXECUTION - ScanFilterProject[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=orders, analyzePartitionValues=Optional.empty}, grouped = false, filterPredicate = ("o_custkey" = 123)] => [[o_orderstatus, o_orderkey]] LAYOUT: tpch100.orders o_orderstatus := o_orderstatus:string:2:REGULAR o_custkey := o_custkey:int:1:REGULAR o_orderkey := o_orderkey:int:0:REGULAR ``` La consulta de ejemplo se optimizó en una combinación cruzada para obtener un mejor rendimiento. Los resultados muestran que `tpch100.orders` se distribuirá como el tipo de distribución `BROADCAST`. Esto implica que la tabla `tpch100.orders` se distribuirá a todos los nodos que realizan la operación de unión. El tipo de distribución `BROADCAST` requerirá que todos los resultados filtrados de la tabla `tpch100.orders` se ajusten en la memoria de cada nodo que realiza la operación de unión. Sin embargo, la tabla `tpch100.customer` es más pequeña que `tpch100.orders`. Dado que `tpch100.customer` requiere menos memoria, puede reescribir la consulta en `BROADCAST tpch100.customer` en lugar de `tpch100.orders`. Esto reduce la posibilidad de que la consulta reciba el error `EXCEEDED_LOCAL_MEMORY_LIMIT`. Esta estrategia supone los siguientes puntos: + La `tpch100.customer.c_custkey` es única en la tabla `tpch100.customer`. + Existe una relación de asignación de uno a muchos entre `tpch100.customer` y `tpch100.orders`. En el siguiente ejemplo, se muestra la consulta reescrita. ``` SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.orders o JOIN tpch100.customer c -- the filtered results of tpch100.customer are distributed to all nodes. ON c.c_custkey = o.o_custkey WHERE c.c_custkey = 123 ``` ### Ejemplo 5: uso de una consulta EXPLAIN para eliminar predicados que no tengan efecto Puede utilizar una consulta `EXPLAIN` para verificar la eficacia de los predicados de filtrado. Puede utilizar los resultados para eliminar predicados que no tengan ningún efecto, como en el ejemplo a continuación. ``` EXPLAIN SELECT c.c_name FROM tpch100.customer c WHERE c.c_custkey = CAST(RANDOM() * 1000 AS INT) AND c.c_custkey BETWEEN 1000 AND 2000 AND c.c_custkey = 1500 ``` #### Resultados ``` Query Plan - Output[c_name] => [[c_name]] - RemoteExchange[GATHER] => [[c_name]] - ScanFilterProject[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=customer, analyzePartitionValues=Optional.empty}, filterPredicate = (("c_custkey" = 1500) AND ("c_custkey" = CAST(("random"() * 1E3) AS int)))] => [[c_name]] LAYOUT: tpch100.customer c_custkey := c_custkey:int:0:REGULAR c_name := c_name:string:1:REGULAR ``` El `filterPredicate` en los resultados muestra que el optimizador fusionó los tres predicados originales en dos predicados y cambió su orden de aplicación. ``` filterPredicate = (("c_custkey" = 1500) AND ("c_custkey" = CAST(("random"() * 1E3) AS int))) ``` Como los resultados muestran que el predicado `AND c.c_custkey BETWEEN 1000 AND 2000` no tiene ningún efecto, puede eliminar este predicado sin cambiar los resultados de la consulta. Para obtener información sobre los términos utilizados en los resultados de las consultas `EXPLAIN`, consulte [Descripción de los resultados de la instrucción EXPLAIN de Athena](athena-explain-statement-understanding.md). ## Ejemplos de EXPLAIN ANALYZE En los siguientes ejemplos, se muestran consultas y salidas `EXPLAIN ANALYZE`. ### Ejemplo 1: uso de EXPLAIN ANALYZE para mostrar un plan de consulta y los costos computacionales en formato de texto En el siguiente ejemplo, `EXPLAIN ANALYZE` muestra el plan de ejecución y los costos computacionales de una consulta `SELECT` en los registros de CloudFront. El formato se establece de forma predeterminada en la salida de texto. ``` EXPLAIN ANALYZE SELECT FROM cloudfront_logs LIMIT 10 ``` #### Resultados ``` Fragment 1 CPU: 24.60ms, Input: 10 rows (1.48kB); per task: std.dev.: 0.00, Output: 10 rows (1.48kB) Output layout: [date, time, location, bytes, requestip, method, host, uri, status, referrer,\ os, browser, browserversion] Limit[10] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 1.00ms (0.03%), Output: 10 rows (1.48kB) Input avg.: 10.00 rows, Input std.dev.: 0.00% LocalExchange[SINGLE] () => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 0.00ns (0.00%), Output: 10 rows (1.48kB) Input avg.: 0.63 rows, Input std.dev.: 387.30% RemoteSource[2] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 1.00ms (0.03%), Output: 10 rows (1.48kB) Input avg.: 0.63 rows, Input std.dev.: 387.30% Fragment 2 CPU: 3.83s, Input: 998 rows (147.21kB); per task: std.dev.: 0.00, Output: 20 rows (2.95kB) Output layout: [date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion] LimitPartial[10] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 5.00ms (0.13%), Output: 20 rows (2.95kB) Input avg.: 166.33 rows, Input std.dev.: 141.42% TableScan[awsdatacatalog:HiveTableHandle{schemaName=default, tableName=cloudfront_logs,\ analyzePartitionValues=Optional.empty}, grouped = false] => [[date, time, location, bytes, requestip, method, host, uri, st CPU: 3.82s (99.82%), Output: 998 rows (147.21kB) Input avg.: 166.33 rows, Input std.dev.: 141.42% LAYOUT: default.cloudfront_logs date := date:date:0:REGULAR referrer := referrer:string:9:REGULAR os := os:string:10:REGULAR method := method:string:5:REGULAR bytes := bytes:int:3:REGULAR browser := browser:string:11:REGULAR host := host:string:6:REGULAR requestip := requestip:string:4:REGULAR location := location:string:2:REGULAR time := time:string:1:REGULAR uri := uri:string:7:REGULAR browserversion := browserversion:string:12:REGULAR status := status:int:8:REGULAR ``` ### Ejemplo  2: uso de EXPLAIN ANALYZE para mostrar un plan de consulta en formato JSON En el siguiente ejemplo, se muestra el plan de ejecución y los costos computacionales de una consulta `SELECT` en los registros de CloudFront. En el ejemplo se especifica JSON como formato de salida. ``` EXPLAIN ANALYZE (FORMAT JSON) SELECT * FROM cloudfront_logs LIMIT 10 ``` #### Resultados ``` { "fragments": [{ "id": "1", "stageStats": { "totalCpuTime": "3.31ms", "inputRows": "10 rows", "inputDataSize": "1514B", "stdDevInputRows": "0.00", "outputRows": "10 rows", "outputDataSize": "1514B" }, "outputLayout": "date, time, location, bytes, requestip, method, host,\ uri, status, referrer, os, browser, browserversion", "logicalPlan": { "1": [{ "name": "Limit", "identifier": "[10]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 10.0, "nodeInputRowsStdDev": 0.0 }] }, "children": [{ "name": "LocalExchange", "identifier": "[SINGLE] ()", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 0.625, "nodeInputRowsStdDev": 387.2983346207417 }] }, "children": [{ "name": "RemoteSource", "identifier": "[2]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 0.625, "nodeInputRowsStdDev": 387.2983346207417 }] }, "children": [] }] }] }] } }, { "id": "2", "stageStats": { "totalCpuTime": "1.62s", "inputRows": "500 rows", "inputDataSize": "75564B", "stdDevInputRows": "0.00", "outputRows": "10 rows", "outputDataSize": "1514B" }, "outputLayout": "date, time, location, bytes, requestip, method, host, uri, status,\ referrer, os, browser, browserversion", "logicalPlan": { "1": [{ "name": "LimitPartial", "identifier": "[10]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host", "uri",\ "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 83.33333333333333, "nodeInputRowsStdDev": 223.60679774997897 }] }, "children": [{ "name": "TableScan", "identifier": "[awsdatacatalog:HiveTableHandle{schemaName=default,\ tableName=cloudfront_logs, analyzePartitionValues=Optional.empty},\ grouped = false]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host", "uri",\ "status", "referrer", "os", "browser", "browserversion"], "details": "LAYOUT: default.cloudfront_logs\ndate := date:date:0:REGULAR\nreferrer :=\ referrer: string:9:REGULAR\nos := os:string:10:REGULAR\nmethod := method:string:5:\ REGULAR\nbytes := bytes:int:3:REGULAR\nbrowser := browser:string:11:REGULAR\nhost :=\ host:string:6:REGULAR\nrequestip := requestip:string:4:REGULAR\nlocation :=\ location:string:2:REGULAR\ntime := time:string:1: REGULAR\nuri := uri:string:7:\ REGULAR\nbrowserversion := browserversion:string:12:REGULAR\nstatus :=\ status:int:8:REGULAR\n", "distributedNodeStats": { "nodeCpuTime": "1.62s", "nodeOutputRows": 500, "nodeOutputDataSize": "75564B", "operatorInputRowsStats": [{ "nodeInputRows": 83.33333333333333, "nodeInputRowsStdDev": 223.60679774997897 }] }, "children": [] }] }] } }] } ``` ## Recursos adicionales Para obtener información adicional, consulte los siguientes recursos. + [Descripción de los resultados de la instrucción EXPLAIN de Athena](athena-explain-statement-understanding.md) + [Visualización de planes de ejecución para consultas SQL](query-plans.md) + [Visualización de estadísticas y detalles de ejecución de consultas completadas](query-stats.md) + Documentación de Trino sobre [https://trino.io/docs/current/sql/explain.html](https://trino.io/docs/current/sql/explain.html) + Documentación de Trino sobre [https://trino.io/docs/current/sql/explain-analyze.html](https://trino.io/docs/current/sql/explain-analyze.html) + [Optimice el rendimiento de las consultas federadas con EXPLAIN y EXPLAIN ANALYZE en Amazon Athena](https://aws.amazon.com/blogs/big-data/optimize-federated-query-performance-using-explain-and-explain-analyze-in-amazon-athena/) en el *Blog de macrodatos de AWS*. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/7JUyTqglmNU/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/7JUyTqglmNU) # Descripción de los resultados de la instrucción EXPLAIN de Athena Este tema proporciona una breve guía de los términos operativos utilizados en los resultados de instrucciones `EXPLAIN` en Athena. ## Tipos de salida de instrucciones EXPLAIN `EXPLAIN`Las salidas de instrucciones pueden ser de dos tipos: + **Plan lógico**: muestra el plan lógico que utiliza el motor SQL para ejecutar una instrucción. La sintaxis para esta opción es `EXPLAIN` o `EXPLAIN (TYPE LOGICAL)`. + **Plan distribuido**: muestra un plan de ejecución en un entorno distribuido. La salida muestra fragmentos, que son etapas de procesamiento. Cada fragmento de plan es procesado por uno o más nodos. Los datos se pueden intercambiar entre los nodos que procesan los fragmentos. La sintaxis para esta opción es `EXPLAIN (TYPE DISTRIBUTED)`. En la salida de un plan distribuido, los fragmentos (etapas de procesamiento) están indicados por un `Fragment` *número* [*fragment\$1type*], donde el *número* es un entero basado en cero y *fragment\$1type* especifica cómo los nodos ejecutan el fragmento. En la siguiente tabla se describen los tipos de fragmentos, que proporcionan información del diseño del intercambio de datos. **Tipos de fragmentos del plan distribuido** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/athena-explain-statement-understanding.html) ## Exchange Los términos relacionados con el intercambio describen cómo se intercambian datos entre nodos de trabajo. Las transferencias pueden ser locales o remotas. **LocalExchange [*exchange\$1type*] ** Transfiere datos de manera local dentro de los nodos de trabajo para diferentes etapas de una consulta. El valor de *exchange\$1type* puede ser uno de los tipos de intercambio lógicos o distribuidos, como se describe más adelante en esta sección. **RemoteExchange [*exchange\$1type*] ** Transfiere datos entre los nodos de trabajo para diferentes etapas de una consulta. El valor de *exchange\$1type* puede ser uno de los tipos de intercambio lógicos o distribuidos, como se describe más adelante en esta sección. ### Tipos de intercambio lógico Los siguientes tipos de intercambio describen las acciones efectuadas durante la fase de intercambio de un plan lógico. + **`GATHER`** – un nodo de trabajo único recopila la salida de todos los demás nodos de trabajo. Por ejemplo, la última etapa de una consulta de selección reúne los resultados de todos los nodos y los escribe en Amazon S3. + **`REPARTITION`** – envía los datos de fila a un empleado específico según el esquema de partición necesario para aplicar al siguiente operador. + **`REPLICATE`** – copia los datos de fila en todos los empleados. ### Tipos de intercambio distribuido Los siguientes tipos de intercambio indican el diseño de los datos cuando se intercambian entre nodos en un plan distribuido. + **`HASH`** – el intercambio distribuye datos a varios destinos utilizando una función hash. + **`SINGLE`** – el intercambio distribuye los datos a un único destino. ## Análisis Los siguientes términos describen cómo se analizan los datos durante una consulta. **TableScan ** Analiza los datos de origen de una tabla desde Amazon S3 o un conector Apache Hive y aplica la poda de partición generada a partir del predicado del filtro. **ScanFilter ** Analiza los datos de origen de una tabla desde Amazon S3 o un conector Hive y aplica la poda de partición generada a partir del predicado del filtro y de predicados de filtro adicionales no aplicados a través de la poda de partición. **ScanFilterProject ** Primero, analiza los datos de origen de una tabla desde Amazon S3 o un conector Hive y aplica la poda de partición generada a partir del predicado del filtro y de predicados de filtro adicionales no aplicados a través de la poda de partición. A continuación, modifica el diseño de la memoria de los datos de salida en una nueva proyección para mejorar el rendimiento de etapas posteriores. ## Join Une datos entre dos tablas. Las uniones se pueden clasificar por tipo de unión y por tipo de distribución. ### Tipos de combinación Los tipos de unión definen la manera en que se produce la operación de unión. **CrossJoin**: produce el producto cartesiano de las dos tablas unidas. **InnerJoin**: selecciona registros que tienen valores coincidentes en ambas tablas. **LeftJoin**: selecciona todos los registros de la tabla izquierda y los registros coincidentes de la tabla derecha. Si no se produce ninguna coincidencia, el resultado en el lado derecho es NULL. **Right Join**: selecciona todos los registros de la tabla derecha y los registros coincidentes de la tabla izquierda. Si no se produce ninguna coincidencia, el resultado en el lado izquierdo es NULL. **FullJoin**: selecciona todos los registros en los que hay una coincidencia en los registros de la tabla izquierda o derecha. La tabla combinada contiene todos los registros de las tablas y rellena NULL para las coincidencias que faltan en ambos lados. **nota** Por razones de rendimiento, el motor de consultas puede reescribir una consulta de unión en un tipo de unión diferente para producir los mismos resultados. Por ejemplo, una consulta de unión interna con predicado en una tabla se puede volver a escribir en una `CrossJoin`. Esto empuja el predicado a la fase de escaneo de la tabla para que se escaneen menos datos. ### Tipos de distribución de unión Los tipos de distribución definen la manera en que se intercambian los datos entre nodos de trabajo cuando se realiza la operación de unión. **Particionada**: tanto la tabla izquierda como la derecha están particionadas en hash en todos los nodos de trabajo. La distribución particionada consume menos memoria en cada nodo. La distribución particionada puede ser mucho más lenta que las uniones replicadas. Las uniones particionadas son adecuadas cuando se unen dos tablas grandes. **Replicada**: una tabla está particionada en hash en todos los nodos de trabajo y la otra tabla se replica en todos los nodos de trabajo para realizar la operación de unión. La distribución replicada puede ser mucho más rápida que las uniones particionadas, pero consume más memoria en cada nodo de trabajo. Si la tabla replicada es demasiado grande, el nodo de trabajo puede experimentar un error de memoria insuficiente. Las uniones replicadas son adecuadas cuando una de las tablas combinadas es pequeña. # PREPARE Crea una instrucción SQL con el nombre `statement_name` que se ejecutará en un momento posterior. La instrucción puede incluir parámetros representados por signos de interrogación. Para proporcionar valores para los parámetros y ejecutar la instrucción preparada, utilice [EXECUTE](sql-execute.md). ## Sinopsis ``` PREPARE statement_name FROM statement ``` En la tabla siguiente se describen estos parámetros. **** | Parámetro | Descripción | | --- | --- | | statement\$1name | Nombre de la instrucción a preparar. El nombre debe ser único dentro del grupo de trabajo. | | statement | Una consulta SELECT, CTAS o INSERT INTO. | **nota** El número máximo de instrucciones preparadas en un grupo de trabajo es 1000. ## Ejemplos El siguiente ejemplo prepara una consulta SELECT sin parámetros. ``` PREPARE my_select1 FROM SELECT * FROM nation ``` El siguiente ejemplo prepara una consulta SELECT que incluye parámetros. Los valores `productid` y `quantity` serán suministrados por la cláusula `USING` de una instrucción `EXECUTE`: ``` PREPARE my_select2 FROM SELECT order FROM orders WHERE productid = ? and quantity < ? ``` En el siguiente ejemplo, se prepara una consulta de inserción. ``` PREPARE my_insert FROM INSERT INTO cities_usa (city, state) SELECT city, state FROM cities_world WHERE country = ? ``` ## Recursos adicionales de [Uso de instrucciones preparadas](querying-with-prepared-statements-querying.md) [EXECUTE](sql-execute.md) [DEALLOCATE PREPARE](sql-deallocate-prepare.md) [INSERT INTO](insert-into.md) # EXECUTE Ejecuta una instrucción preparada con el nombre `statement_name`. Los valores de los parámetros para los signos de interrogación de la instrucción preparada se definen en la cláusula `USING` en una lista separada por comas. Para crear una instrucción preparada, utilice [PREPARE](sql-prepare.md). ## Sinopsis ``` EXECUTE statement_name [ USING parameter1[, parameter2, ... ] ] ``` ## Ejemplos El siguiente ejemplo prepara y ejecuta una consulta sin parámetros. ``` PREPARE my_select1 FROM SELECT name FROM nation EXECUTE my_select1 ``` El siguiente ejemplo prepara y ejecuta una consulta con un único parámetro. ``` PREPARE my_select2 FROM SELECT * FROM "my_database"."my_table" WHERE year = ? EXECUTE my_select2 USING 2012 ``` Equivale a: ``` SELECT * FROM "my_database"."my_table" WHERE year = 2012 ``` El siguiente ejemplo prepara y ejecuta una consulta con dos parámetros. ``` PREPARE my_select3 FROM SELECT order FROM orders WHERE productid = ? and quantity < ? EXECUTE my_select3 USING 346078, 12 ``` ## Recursos adicionales de [Uso de instrucciones preparadas](querying-with-prepared-statements-querying.md) [PREPARE](sql-prepare.md) [INSERT INTO](insert-into.md) # DEALLOCATE PREPARE Elimina la instrucción preparada con el nombre especificado de las instrucciones preparadas del grupo de trabajo actual. ## Sinopsis ``` DEALLOCATE PREPARE statement_name ``` ## Ejemplos En el siguiente ejemplo, se elimina la instrucción preparada `my_select1` del grupo de trabajo actual. ``` DEALLOCATE PREPARE my_select1 ``` ## Recursos adicionales de [Uso de instrucciones preparadas](querying-with-prepared-statements-querying.md) [PREPARE](sql-prepare.md) # UNLOAD Escribe los resultados de la consulta desde una instrucción `SELECT` al formato de datos especificado. Los formatos admitidos para `UNLOAD` incluyen Apache Parquet, ORC, Apache Avro y JSON. CSV es el único formato de salida compatible con el comando `SELECT` de Athena; no obstante, pero puede usar el comando `UNLOAD`, que admite una variedad de formatos de salida, para incluir la consulta `SELECT` y reescribir su salida en uno de los formatos compatibles con `UNLOAD`. Si bien puede utilizar la instrucción `CREATE TABLE AS` (CTAS) para generar datos en formatos distintos a CSV, esas instrucciones también requieren la creación de una tabla en Athena. La instrucción `UNLOAD` es útil cuando se desea generar los resultados de una consulta `SELECT` en un formato que no sea CSV, pero no se requiere la tabla asociada. Por ejemplo, una aplicación descendente puede requerir que los resultados de una consulta `SELECT` estén en formato JSON, y Parquet u ORC podrían proporcionar una ventaja de rendimiento sobre CSV si tiene la intención de utilizar los resultados de la consulta `SELECT` para un análisis adicional. ## Consideraciones y limitaciones Cuando utiliza la instrucción `UNLOAD` en Athena, tenga en cuenta los siguientes puntos: + **Sin orden global de archivos**: los resultados de `UNLOAD` se escriben en varios archivos en paralelo. Si la consulta `SELECT` en la instrucción `UNLOAD` especifica un orden de clasificación, el contenido de cada archivo está en orden de clasificación, pero los archivos no están ordenados entre sí. + **Datos huérfanos no eliminados**: en caso de error, Athena no intenta eliminar datos huérfanos. Este comportamiento es el mismo que en instrucciones CTAS y `INSERT INTO`. + **Particiones máximas**: el número máximo de particiones que se pueden utilizar con `UNLOAD` es 100. + **Archivos de manifiesto y metadatos**: Athena genera un archivo de metadatos y un archivo de manifiesto de datos para cada consulta `UNLOAD`. El manifiesto realiza un seguimiento de los archivos que escribió la consulta. Ambos archivos se guardan en la ubicación de resultados de consulta de Athena en Amazon S3. Para obtener más información, consulte [Identificación de archivos de salida de consultas](querying-finding-output-files.md#querying-identifying-output-files). + **Cifrado**: Los archivos de salida `UNLOAD` se cifran de acuerdo con la configuración de cifrado utilizada para Amazon S3. Para configurar la configuración de cifrado para cifrar el resultado `UNLOAD`, puede utilizar la [API EncryptionConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_EncryptionConfiguration.html). + **Instrucciones preparadas**: `UNLOAD` se puede utilizar con instrucciones preparadas. Para obtener información acerca de las instrucciones preparadas en Athena, consulte [Uso de consultas parametrizadas](querying-with-prepared-statements.md). + **Service quotas**: `UNLOAD` utiliza cuotas de consultas DML. Para obtener información sobre las cuotas, consulte [Service Quotas](service-limits.md). + **Propietario esperado del bucket**: la configuración del propietario esperado del bucket no se aplica a la ubicación de Amazon S3 de destino especificada en la consulta `UNLOAD`. La configuración del propietario esperado del bucket se aplica solo a la ubicación de salida de Amazon S3 especificada para los resultados de las consultas de Athena. Para obtener más información, consulte [Especificación de una ubicación de resultados de consulta mediante la consola de Athena](query-results-specify-location-console.md). ## Sintaxis La instrucción `UNLOAD` utiliza la siguiente sintaxis. ``` UNLOAD (SELECT col_name[, ...] FROM old_table) TO 's3://amzn-s3-demo-bucket/my_folder/' WITH ( property_name = 'expression' [, ...] ) ``` Excepto cuando se escribe en particiones, el destino de `TO` debe especificar una ubicación en Amazon S3 que no tenga datos. Antes de que la consulta `UNLOAD` escriba en la ubicación especificada, verifica que la ubicación del bucket está vacía. Como `UNLOAD` no escribe datos en la ubicación especificada si la ubicación ya tiene datos en ella, `UNLOAD` no sobrescribe los datos existentes. Para reutilizar una ubicación de bucket como destino para `UNLOAD`, elimine los datos de la ubicación del bucket y, a continuación, vuelva a ejecutar la consulta. Tenga en cuenta que cuando `UNLOAD` escribe en particiones, este comportamiento es diferente. Si ejecuta la misma consulta `UNLOAD` varias veces con la misma instrucción `SELECT`, la misma ubicación `TO` y las mismas particiones, cada consulta `UNLOAD` descargará los datos en Amazon S3 en la ubicación y las particiones especificadas. ### Parameters Los valores posibles para *property\$1name* son los siguientes. ** format = '*file\$1format*' ** Obligatorio. Especifica el formato de archivo de la salida. Los valores posibles para *file\$1format* son `ORC`, `PARQUET`, `AVRO`, `JSON` o `TEXTFILE`. ** compression = '*compression\$1format*' ** Opcional. Esta opción es específica de los formatos ORC y Parquet. Para ORC, el valor predeterminado es `zlib`, y para Parquet, el valor predeterminado es `gzip`. Para obtener información sobre los formatos de compresión compatibles, consulte [Compatibilidad con la compresión de Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html). Esta opción no se aplica al formato `AVRO`. Athena utiliza `gzip` para los formatos `JSON` y `TEXTFILE`. **compression\$1level = *compression\$1level* ** Opcional. El nivel de compresión que se debe utilizar para la compresión ZSTD. Esta propiedad solo se aplica a la compresión ZSTD. Para obtener más información, consulte [Uso de niveles de compresión de ZSTD](compression-support-zstd-levels.md). ** field\$1delimiter = '*delimiter*' ** Opcional. Especifica un delimitador de campo de un solo carácter para archivos con formato CSV, TSV y otros formatos de texto. En el ejemplo siguiente se especifica un delimitador de coma. ``` WITH (field_delimiter = ',') ``` Actualmente, no se admiten delimitadores de campos de caracteres múltiples. Si no especifica un delimitador de campo, se utiliza el carácter octal `\001` (^A). ** partitioned\$1by = ARRAY[ *col\$1name*[,...] ] ** Opcional. Una matriz de columnas por las que se particiona la salida. Asegúrese de que en su instrucción `SELECT`, los nombres de las columnas particionadas aparezcan en último lugar en la lista de columnas. ## Ejemplos En el siguiente ejemplo se escribe el resultado de una consulta `SELECT` en la ubicación `s3://amzn-s3-demo-bucket/unload_test_1/` de Amazon S3 utilizando el formato JSON. ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/unload_test_1/' WITH (format = 'JSON') ``` En el siguiente ejemplo se escribe el resultado de una consulta `SELECT` en formato Parquet mediante compresión Snappy. ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET',compression = 'SNAPPY') ``` En el siguiente ejemplo se escriben cuatro columnas en formato de texto, con la salida particionada por la última columna. ``` UNLOAD (SELECT name1, address1, comment1, key1 FROM table1) TO 's3://amzn-s3-demo-bucket/ partitioned/' WITH (format = 'TEXTFILE', partitioned_by = ARRAY['key1']) ``` En el siguiente ejemplo se descargan los resultados de la consulta en la ubicación especificada mediante el formato de archivo Parquet, compresión ZSTD y el nivel 4 de compresión ZSTD. ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET', compression = 'ZSTD', compression_level = 4) ``` ## Recursos adicionales + [Simplificar las canalizaciones de ETL y ML con la característica UNLOAD de Amazon Athena](https://aws.amazon.com/blogs/big-data/simplify-your-etl-and-ml-pipelines-using-the-amazon-athena-unload-feature/) en el *Blog de macrodatos de AWS*. # Funciones en Amazon Athena Para obtener información acerca de los cambios en las funciones entre las versiones del motor de Athena, consulte [Control de versiones del motor Athena](engine-versions.md). Para obtener una lista de las zonas horarias que se pueden utilizar con el operador `AT TIME ZONE`, consulte [Uso de zonas horarias admitidas](athena-supported-time-zones.md). **Topics** + [Versión 3 del motor Athena](functions-env3.md) # Funciones de la versión 3 del motor Athena Las funciones de la versión 3 del motor Athena se basan en Trino. Para obtener información sobre las funciones, los operadores y las expresiones de Trino, consulte [Funciones y operadores](https://trino.io/docs/current/functions.html) y las siguientes subsecciones de la documentación de Trino. + [Aggregate](https://trino.io/docs/current/functions/aggregate.html) + [Array](https://trino.io/docs/current/functions/array.html) (Matriz) + [Binario](https://trino.io/docs/current/functions/binary.html) + [Bitwise](https://trino.io/docs/current/functions/bitwise.html) (Bit a bit) + [Color](https://trino.io/docs/current/functions/color.html) + [Comparación](https://trino.io/docs/current/functions/comparison.html) + [Condicional](https://trino.io/docs/current/functions/conditional.html) + [Conversion](https://trino.io/docs/current/functions/conversion.html) (Conversión) + [Fecha y hora](https://trino.io/docs/current/functions/datetime.html) + [Decimal](https://trino.io/docs/current/functions/decimal.html) (Decimal) + [Geospatial](https://trino.io/docs/current/functions/geospatial.html) (Geoespacial) + [HyperLogLog](https://trino.io/docs/current/functions/hyperloglog.html) + [IP Address](https://trino.io/docs/current/functions/ipaddress.html) (Dirección IP) + [JSON](https://trino.io/docs/current/functions/json.html) + [Lambda](https://trino.io/docs/current/functions/lambda.html) + [Logical](https://trino.io/docs/current/functions/logical.html) (Lógica) + [Machine learning](https://trino.io/docs/current/functions/ml.html) + [Map](https://trino.io/docs/current/functions/map.html) + [Math (Matemática)](https://trino.io/docs/current/functions/math.html) + [Quantile digest](https://trino.io/docs/current/functions/qdigest.html) (Resumen de cuantiles) + [Expresión regular](https://trino.io/docs/current/functions/regexp.html) + [Session](https://trino.io/docs/current/functions/session.html) (Sesión) + [Set Digest](https://trino.io/docs/current/functions/setdigest.html) (Establecer resumen) + [Cadena](https://trino.io/docs/current/functions/string.html) + [Tabla](https://trino.io/docs/current/functions/table.html) + [Teradata](https://trino.io/docs/current/functions/teradata.html) + [T-Digest](https://trino.io/docs/current/functions/tdigest.html) + [URL](https://trino.io/docs/current/functions/url.html) + [UUID](https://trino.io/docs/current/functions/uuid.html) (Identificador único universal) + [Window](https://trino.io/docs/current/functions/window.html) ## función invoker\$1principal() La función `invoker_principal` es exclusiva de la versión 3 del motor de Athena y no se encuentra en Trino. Devuelve `VARCHAR` que contiene el ARN de la entidad principal (rol de IAM o identidad del Centro de Identidades) que ejecutó la consulta que llama a la función. Por ejemplo, si el invocador de la consulta utiliza los permisos de un rol IAM para ejecutar la consulta, la función devuelve el ARN del rol de IAM. El rol que ejecuta la consulta debe permitir la acción `LakeFormation:GetDataLakePrincipal`. ### Uso ``` SELECT invoker_principal() ``` En la tabla que figura a continuación aparece un ejemplo de resultado. **** | \$1 | \$1col0 | | --- | --- | | 1 | arn:aws:iam::111122223333:role/Admin | # Uso de zonas horarias admitidas Puede utilizar el operador `AT TIME ZONE` en una instrucción `SELECT timestamp` para especificar la zona horaria de la marca de tiempo que se devuelve, como en el ejemplo siguiente: ``` SELECT timestamp '2012-10-31 01:00 UTC' AT TIME ZONE 'America/Los_Angeles' AS la_time; ``` **Resultados** ``` la_time 2012-10-30 18:00:00.000 America/Los_Angeles ``` Para ver una lista de las zonas horarias compatibles en Athena, amplíe la [Lista de zonas horarias admitidas](#athena-supported-time-zones-list) al final de este tema. ## Funciones y ejemplos de zona horaria A continuación, se muestran más funciones y ejemplos relacionados con zona horaria. + **at\$1timezone (*timestamp*, *zone*)**: devuelve el valor de *timestamp* (marca temporal) en la hora local correspondiente para *zone* (zona). **Ejemplo** ``` SELECT at_timezone(timestamp '2021-08-22 00:00 UTC', 'Canada/Newfoundland') ``` **Resultado** ``` 2021-08-21 21:30:00.000 Canada/Newfoundland ``` + **timezone\$1hour (*timestamp*)**: devuelve la hora de diferencia de la zona horaria con respecto al valor timestamp como `bigint`. **Ejemplo** ``` SELECT timezone_hour(timestamp '2021-08-22 04:00 UTC' AT TIME ZONE 'Canada/Newfoundland') ``` **Resultado** ``` -2 ``` + **timezone\$1minute (*timestamp*)**: devuelve los minutos de diferencia de la zona horaria con respecto a *timestamp* como `bigint`. **Ejemplo** ``` SELECT timezone_minute(timestamp '2021-08-22 04:00 UTC' AT TIME ZONE 'Canada/Newfoundland') ``` **Resultado** ``` -30 ``` + **with\$1timezone (*timestamp*, *zone*)**: devuelve una marca temporal con zona horaria de los valores *timestamp* y *zone* especificados. **Ejemplo** ``` SELECT with_timezone(timestamp '2021-08-22 04:00', 'Canada/Newfoundland') ``` **Resultado** ``` 2021-08-22 04:00:00.000 Canada/Newfoundland ``` ## Lista de zonas horarias admitidas La siguiente lista contiene las zonas horarias que se pueden utilizar con el operador `AT TIME ZONE` en Athena. Para obtener más funciones y ejemplos relacionados con zona horaria, consulte [Funciones y ejemplos de zona horaria](#athena-supported-time-zones-functions-examples). ``` Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers Africa/Asmara Africa/Asmera Africa/Bamako Africa/Bangui Africa/Banjul Africa/Bissau Africa/Blantyre Africa/Brazzaville Africa/Bujumbura Africa/Cairo Africa/Casablanca Africa/Ceuta Africa/Conakry Africa/Dakar Africa/Dar_es_Salaam Africa/Djibouti Africa/Douala Africa/El_Aaiun Africa/Freetown Africa/Gaborone Africa/Harare Africa/Johannesburg Africa/Juba Africa/Kampala Africa/Khartoum Africa/Kigali Africa/Kinshasa Africa/Lagos Africa/Libreville Africa/Lome Africa/Luanda Africa/Lubumbashi Africa/Lusaka Africa/Malabo Africa/Maputo Africa/Maseru Africa/Mbabane Africa/Mogadishu Africa/Monrovia Africa/Nairobi Africa/Ndjamena Africa/Niamey Africa/Nouakchott Africa/Ouagadougou Africa/Porto-Novo Africa/Sao_Tome Africa/Timbuktu Africa/Tripoli Africa/Tunis Africa/Windhoek America/Adak America/Anchorage America/Anguilla America/Antigua America/Araguaina America/Argentina/Buenos_Aires America/Argentina/Catamarca America/Argentina/ComodRivadavia America/Argentina/Cordoba America/Argentina/Jujuy America/Argentina/La_Rioja America/Argentina/Mendoza America/Argentina/Rio_Gallegos America/Argentina/Salta America/Argentina/San_Juan America/Argentina/San_Luis America/Argentina/Tucuman America/Argentina/Ushuaia America/Aruba America/Asuncion America/Atikokan America/Atka America/Bahia America/Bahia_Banderas America/Barbados America/Belem America/Belize America/Blanc-Sablon America/Boa_Vista America/Bogota America/Boise America/Buenos_Aires America/Cambridge_Bay America/Campo_Grande America/Cancun America/Caracas America/Catamarca America/Cayenne America/Cayman America/Chicago America/Chihuahua America/Coral_Harbour America/Cordoba America/Costa_Rica America/Creston America/Cuiaba America/Curacao America/Danmarkshavn America/Dawson America/Dawson_Creek America/Denver America/Detroit America/Dominica America/Edmonton America/Eirunepe America/El_Salvador America/Ensenada America/Fort_Nelson America/Fort_Wayne America/Fortaleza America/Glace_Bay America/Godthab America/Goose_Bay America/Grand_Turk America/Grenada America/Guadeloupe America/Guatemala America/Guayaquil America/Guyana America/Halifax America/Havana America/Hermosillo America/Indiana/Indianapolis America/Indiana/Knox America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Tell_City America/Indiana/Vevay America/Indiana/Vincennes America/Indiana/Winamac America/Indianapolis America/Inuvik America/Iqaluit America/Jamaica America/Jujuy America/Juneau America/Kentucky/Louisville America/Kentucky/Monticello America/Knox_IN America/Kralendijk America/La_Paz America/Lima America/Los_Angeles America/Louisville America/Lower_Princes America/Maceio America/Managua America/Manaus America/Marigot America/Martinique America/Matamoros America/Mazatlan America/Mendoza America/Menominee America/Merida America/Metlakatla America/Mexico_City America/Miquelon America/Moncton America/Monterrey America/Montevideo America/Montreal America/Montserrat America/Nassau America/New_York America/Nipigon America/Nome America/Noronha America/North_Dakota/Beulah America/North_Dakota/Center America/North_Dakota/New_Salem America/Ojinaga America/Panama America/Pangnirtung America/Paramaribo America/Phoenix America/Port-au-Prince America/Port_of_Spain America/Porto_Acre America/Porto_Velho America/Puerto_Rico America/Punta_Arenas America/Rainy_River America/Rankin_Inlet America/Recife America/Regina America/Resolute America/Rio_Branco America/Rosario America/Santa_Isabel America/Santarem America/Santiago America/Santo_Domingo America/Sao_Paulo America/Scoresbysund America/Shiprock America/Sitka America/St_Barthelemy America/St_Johns America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Swift_Current America/Tegucigalpa America/Thule America/Thunder_Bay America/Tijuana America/Toronto America/Tortola America/Vancouver America/Virgin America/Whitehorse America/Winnipeg America/Yakutat America/Yellowknife Antarctica/Casey Antarctica/Davis Antarctica/DumontDUrville Antarctica/Macquarie Antarctica/Mawson Antarctica/McMurdo Antarctica/Palmer Antarctica/Rothera Antarctica/South_Pole Antarctica/Syowa Antarctica/Troll Antarctica/Vostok Arctic/Longyearbyen Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr Asia/Aqtau Asia/Aqtobe Asia/Ashgabat Asia/Ashkhabad Asia/Atyrau Asia/Baghdad Asia/Bahrain Asia/Baku Asia/Bangkok Asia/Barnaul Asia/Beirut Asia/Bishkek Asia/Brunei Asia/Calcutta Asia/Chita Asia/Choibalsan Asia/Chongqing Asia/Chungking Asia/Colombo Asia/Dacca Asia/Damascus Asia/Dhaka Asia/Dili Asia/Dubai Asia/Dushanbe Asia/Gaza Asia/Harbin Asia/Hebron Asia/Ho_Chi_Minh Asia/Hong_Kong Asia/Hovd Asia/Irkutsk Asia/Istanbul Asia/Jakarta Asia/Jayapura Asia/Jerusalem Asia/Kabul Asia/Kamchatka Asia/Karachi Asia/Kashgar Asia/Kathmandu Asia/Katmandu Asia/Khandyga Asia/Kolkata Asia/Krasnoyarsk Asia/Kuala_Lumpur Asia/Kuching Asia/Kuwait Asia/Macao Asia/Macau Asia/Magadan Asia/Makassar Asia/Manila Asia/Muscat Asia/Nicosia Asia/Novokuznetsk Asia/Novosibirsk Asia/Omsk Asia/Oral Asia/Phnom_Penh Asia/Pontianak Asia/Pyongyang Asia/Qatar Asia/Qyzylorda Asia/Rangoon Asia/Riyadh Asia/Saigon Asia/Sakhalin Asia/Samarkand Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Srednekolymsk Asia/Taipei Asia/Tashkent Asia/Tbilisi Asia/Tehran Asia/Tel_Aviv Asia/Thimbu Asia/Thimphu Asia/Tokyo Asia/Tomsk Asia/Ujung_Pandang Asia/Ulaanbaatar Asia/Ulan_Bator Asia/Urumqi Asia/Ust-Nera Asia/Vientiane Asia/Vladivostok Asia/Yakutsk Asia/Yangon Asia/Yekaterinburg Asia/Yerevan Atlantic/Azores Atlantic/Bermuda Atlantic/Canary Atlantic/Cape_Verde Atlantic/Faeroe Atlantic/Faroe Atlantic/Jan_Mayen Atlantic/Madeira Atlantic/Reykjavik Atlantic/South_Georgia Atlantic/St_Helena Atlantic/Stanley Australia/ACT Australia/Adelaide Australia/Brisbane Australia/Broken_Hill Australia/Canberra Australia/Currie Australia/Darwin Australia/Eucla Australia/Hobart Australia/LHI Australia/Lindeman Australia/Lord_Howe Australia/Melbourne Australia/NSW Australia/North Australia/Perth Australia/Queensland Australia/South Australia/Sydney Australia/Tasmania Australia/Victoria Australia/West Australia/Yancowinna Brazil/Acre Brazil/DeNoronha Brazil/East Brazil/West CET CST6CDT Canada/Atlantic Canada/Central Canada/Eastern Canada/Mountain Canada/Newfoundland Canada/Pacific Canada/Saskatchewan Canada/Yukon Chile/Continental Chile/EasterIsland Cuba EET EST5EDT Egypt Eire Europe/Amsterdam Europe/Andorra Europe/Astrakhan Europe/Athens Europe/Belfast Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Bucharest Europe/Budapest Europe/Busingen Europe/Chisinau Europe/Copenhagen Europe/Dublin Europe/Gibraltar Europe/Guernsey Europe/Helsinki Europe/Isle_of_Man Europe/Istanbul Europe/Jersey Europe/Kaliningrad Europe/Kiev Europe/Kirov Europe/Lisbon Europe/Ljubljana Europe/London Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Mariehamn Europe/Minsk Europe/Monaco Europe/Moscow Europe/Nicosia Europe/Oslo Europe/Paris Europe/Podgorica Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/San_Marino Europe/Sarajevo Europe/Simferopol Europe/Skopje Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Tiraspol Europe/Ulyanovsk Europe/Uzhgorod Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Vilnius Europe/Volgograd Europe/Warsaw Europe/Zagreb Europe/Zaporozhye Europe/Zurich GB GB-Eire Hongkong Iceland Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguelen Indian/Mahe Indian/Maldives Indian/Mauritius Indian/Mayotte Indian/Reunion Iran Israel Jamaica Japan Kwajalein Libya MET MST7MDT Mexico/BajaNorte Mexico/BajaSur Mexico/General NZ NZ-CHAT Navajo PRC PST8PDT Pacific/Apia Pacific/Auckland Pacific/Bougainville Pacific/Chatham Pacific/Chuuk Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Johnston Pacific/Kiritimati Pacific/Kosrae Pacific/Kwajalein Pacific/Majuro Pacific/Marquesas Pacific/Midway Pacific/Nauru Pacific/Niue Pacific/Norfolk Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Pohnpei Pacific/Ponape Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Samoa Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Truk Pacific/Wake Pacific/Wallis Pacific/Yap Poland Portugal ROK Singapore Turkey US/Alaska US/Aleutian US/Arizona US/Central US/East-Indiana US/Eastern US/Hawaii US/Indiana-Starke US/Michigan US/Mountain US/Pacific US/Pacific-New US/Samoa W-SU WET ```