

# Versión 3 del motor Athena
<a name="engine-versions-reference-0003"></a>

Para la versión 3 del motor, Athena presenta un enfoque de integración continua para la administración del software de código abierto que mejora la aceptación de los proyectos de [Trino](https://trino.io/) y [Presto](https://prestodb.io/) de modo que pueda acceder más rápido a las mejoras de la comunidad, integradas y ajustadas en el motor de Athena.

Este lanzamiento de la versión 3 del motor de Athena es compatible con todas las características de las versiones anteriores del motor. En este documento se destacan las principales diferencias entre las versiones anteriores y la versión 3 del motor de Athena. Para obtener más información, consulte el artículo del *Blog de macrodatos de AWS* [Actualizar a la versión 3 del motor de Athena para aumentar el rendimiento de las consultas y acceder a más características de análisis](https://aws.amazon.com/blogs/big-data/upgrade-to-athena-engine-version-3-to-increase-query-performance-and-access-more-analytics-features/).
+ [Introducción](#engine-versions-reference-0003-getting-started)
+ [Mejoras y nuevas características](#engine-versions-reference-0003-improvements-and-new-features)
  + [Características agregadas](#engine-versions-reference-0003-added-features)
  + [Funciones agregadas](#engine-versions-reference-0003-added-functions)
  + [Mejoras en el rendimiento](#engine-versions-reference-0003-performance-improvements)
  + [Mejoras de la fiabilidad](#engine-versions-reference-0003-reliability-enhancements)
  + [Mejoras de la sintaxis de las consultas](#engine-versions-reference-0003-query-syntax-enhancements)
  + [Mejoras en el formato y el tipo de datos](#engine-versions-reference-0003-data-format-and-data-type-enhancements)
+ [Cambios bruscos](#engine-versions-reference-0003-breaking-changes)
  + [Cambios en la sintaxis de las consultas](#engine-versions-reference-0003-syntax-changes)
  + [Cambios en el procesamiento de datos](#engine-versions-reference-0003-data-processing-changes)
  + [Cambios en la marca de tiempo](#engine-versions-reference-0003-timestamp-changes)
+ [Limitaciones](#engine-versions-reference-0003-known-limitations)

## Introducción
<a name="engine-versions-reference-0003-getting-started"></a>

Para empezar, cree un nuevo grupo de trabajo de Athena que utilice la versión 3 del motor Athena o configure un grupo de trabajo existente para que utilice la versión 3. 

Para obtener más información, consulte [Cambio de las versiones del motor Athena](https://docs.aws.amazon.com/athena/latest/ug/engine-versions-changing.html).

## Mejoras y nuevas características
<a name="engine-versions-reference-0003-improvements-and-new-features"></a>

Las características y actualizaciones enumeradas incluyen mejoras de Athena y de la funcionalidad incorporada desde Trino de código abierto. Para obtener una lista exhaustiva de las funciones y los operadores de consultas SQL, consulte la [documentación de Trino](https://trino.io/docs/current/functions.html).

### Características agregadas
<a name="engine-versions-reference-0003-added-features"></a>

#### Compatibilidad con el algoritmo de agrupación en buckets de Apache
<a name="engine-versions-reference-0003-spark-bucketing-support"></a>

Athena puede leer los buckets generados por el algoritmo hash de Spark. Para especificar que, originalmente, el algoritmo hash de Spark escribió los datos, ingrese `('bucketing_format'='spark')` en la cláusula `TBLPROPERTIES` de la instrucción `CREATE TABLE`. Si no se especifica esta propiedad, se utiliza el algoritmo hash de Hive.

```
CREATE EXTERNAL TABLE `spark_bucket_table`(
  `id` int, 
  `name` string
  )
CLUSTERED BY (`name`) 
INTO 8 BUCKETS
STORED AS PARQUET
LOCATION 
  's3://amzn-s3-demo-bucket/to/bucketed/table/'
TBLPROPERTIES ('bucketing_format'='spark')
```

### Funciones agregadas
<a name="engine-versions-reference-0003-added-functions"></a>

Las funciones de esta sección se introdujeron en la versión 3 del motor Athena.

#### Funciones de agregación
<a name="engine-versions-reference-0003-aggregate-functions"></a>

**listagg(x, separator)**: devuelve los valores de entrada concatenados, separados por la cadena de separación.

```
SELECT listagg(value, ',') WITHIN GROUP (ORDER BY value) csv_value 
FROM (VALUES 'a', 'c', 'b') t(value);
```

#### Funciones de matriz
<a name="engine-versions-reference-0003-array-functions"></a>

**contains\_sequence(x, seq)**: devuelve True (Verdadero) si la matriz x contiene toda la secuencia de matrices como un subconjunto secuencial (todos los valores en el mismo orden consecutivo).

```
SELECT contains_sequence(ARRAY [1,2,3,4,5,6], ARRAY[1,2]);
```

#### Funciones binarias
<a name="engine-versions-reference-0003-binary-functions"></a>

**murmur3(binary)**: calcula el hash MurmurHash3 de 128 bits del binario.

```
SELECT murmur3(from_base64('aaaaaa'));
```

#### Funciones de conversión
<a name="engine-versions-reference-0003-conversion-functions"></a>

**format\_number(number)**: devuelve una cadena formateada con un símbolo de unidad.

```
SELECT format_number(123456); -- '123K'
```

```
SELECT format_number(1000000); -- '1M'
```

#### Funciones de fecha y hora
<a name="engine-versions-reference-0003-date-and-time-functions"></a>

**timezone\_hour(timestamp)**: devuelve la hora de diferencia de zona horaria con respecto a la marca de tiempo.

```
SELECT EXTRACT(TIMEZONE_HOUR FROM TIMESTAMP '2020-05-10 12:34:56 +08:35');
```

**timezone\_minute(timestamp)**: devuelve los minutos de diferencia de la zona horaria con respecto a la marca de tiempo.

```
SELECT EXTRACT(TIMEZONE_MINUTE FROM TIMESTAMP '2020-05-10 12:34:56 +08:35');
```

#### Funciones geoespaciales
<a name="engine-versions-reference-0003-geospatial-functions"></a>

**to\_encoded\_polyline(Geometry)**: codifica una cadena lineal o un multipunto en una polilínea.

```
SELECT to_encoded_polyline(ST_GeometryFromText(
   'LINESTRING (-120.2 38.5, -120.95 40.7, -126.453 43.252)'));
```

**from\_encoded\_polyline(varchar)**: decodifica una polilínea en una cadena de líneas.

```
SELECT ST_AsText(from_encoded_polyline('_p~iF~ps|U_ulLnnqC_mqNvxq`@'));         
```

**to\_geojson\_geometry(SphericalGeography)**: devuelve la geografía esférica especificada en formato GeoJSON.

```
SELECT to_geojson_geometry(to_spherical_geography(ST_GeometryFromText(
   'LINESTRING (0 0, 1 2, 3 4)')));
```

**from\_geojson\_geometry(varchar)**: devuelve el objeto de tipo geográfico esférico de la representación de GeoJSON después de eliminar las claves o los valores no geométricos. `Feature` y `FeatureCollection` no son compatibles.

```
SELECT from_geojson_geometry(to_geojson_geometry(to_spherical_geography(ST_GeometryFromText(
   'LINESTRING (0 0, 1 2, 3 4)'))));
```

**geometry\_nearest\_points(Geometry, Geometry)**: devuelve los puntos de cada geometría que están más cerca unos de otros. Si la geometría está vacía, devuelve un valor NULL. De lo contrario, devuelve una fila de dos objetos `Point` que tienen la distancia mínima de dos puntos en las geometrías. El primer punto proviene del primer argumento Geometry, y el segundo proviene del segundo argumento Geometry. Si hay varios pares con la misma distancia mínima, se elige un par arbitrariamente.

```
SELECT geometry_nearest_points(ST_GeometryFromText(
   'LINESTRING (50 100, 50 200)'), ST_GeometryFromText(
   'LINESTRING (10 10, 20 20)'));
```

#### Configuración de funciones Digest
<a name="engine-versions-reference-0003-set-digest-functions"></a>

**make\_set\_digest(x)**: compone todos los valores de entrada de x en un setdigest.

```
SELECT make_set_digest(value) FROM (VALUES 1, 2, 3) T(value);
```

#### Funciones de cadena
<a name="engine-versions-reference-0003-string-functions"></a>

**soundex(char)**: devuelve una cadena de caracteres que contiene la representación fonética de char.

```
SELECT name 
FROM nation 
WHERE SOUNDEX(name) = SOUNDEX('CHYNA'); -- CHINA
```

**concat\_ws(string0, string1, ..., stringN)**: devuelve la concatenación de `string1, string2, ..., stringN` con `string0` como separador. Si `string0` es NULL, el valor devuelto es NULL. Se omiten todos los valores nulos proporcionados en los argumentos después del separador.

```
SELECT concat_ws(',', 'def', 'pqr', 'mno');
```

#### Funciones de ventana
<a name="engine-versions-reference-0003-window-functions"></a>

**GROUPS**: agrega compatibilidad para marcos de ventanas basados en grupos.

```
SELECT array_agg(a) OVER(
   ORDER BY a ASC NULLS FIRST GROUPS BETWEEN 1 PRECEDING AND 2 FOLLOWING) 
FROM (VALUES 3, 3, 3, 2, 2, 1, null, null) T(a);
```

### Mejoras en el rendimiento
<a name="engine-versions-reference-0003-performance-improvements"></a>

En la versión 3 del motor Athena, se ha mejorado el rendimiento de las siguientes características:
+ **Recuperación más rápida de los metadatos de las tablas de AWS Glue**: las consultas con varias tablas reducirán el tiempo de planificación de las consultas.
+ **Filtrado dinámico para RIGHT JOIN**: el filtrado dinámico ahora está habilitado para las operaciones RIGHT JOIN que tienen condiciones de combinación de igualdad, como en el siguiente ejemplo.

  ```
  SELECT * 
  FROM lineitem RIGHT JOIN tpch.tiny.supplier 
  ON lineitem.suppkey = supplier.suppkey 
  WHERE supplier.name = 'abc';
  ```
+ **Instrucciones preparadas de gran tamaño**: se ha aumentado el tamaño predeterminado del encabezado de solicitud y respuesta HTTP a 2 MB para permitir instrucciones preparadas de gran tamaño.
+ **approx\_percentile()**: la función `approx_percentile` ahora utiliza `tdigest` en lugar de `qdigest` para recuperar valores cuantiles aproximados de las distribuciones. Esto se traduce en un mayor rendimiento y un menor uso de memoria. Tenga en cuenta que, como consecuencia de este cambio, la función devuelve resultados diferentes a los que devolvía en versiones anteriores del motor. Para obtener más información, consulte [La función approx\_percentile devuelve resultados diferentes](#engine-versions-reference-0003-approx-percentile-function).

### Mejoras de la fiabilidad
<a name="engine-versions-reference-0003-reliability-enhancements"></a>

Se han mejorado el uso general de la memoria del motor y el seguimiento en la versión 3 del motor Athena. Las consultas de gran tamaño son menos susceptibles de fallar por caídas de nodos.

### Mejoras de la sintaxis de las consultas
<a name="engine-versions-reference-0003-query-syntax-enhancements"></a>

**INTERSECT ALL**: se agregó compatibilidad con `INTERSECT ALL`.

```
SELECT * FROM (VALUES 1, 2, 3, 4) INTERSECT ALL SELECT * FROM (VALUES 3, 4);
```

**EXCEPT ALL**: se agregó compatibilidad con `EXCEPT ALL`.

```
SELECT * FROM (VALUES 1, 2, 3, 4) EXCEPT ALL SELECT * FROM (VALUES 3, 4);
```

**RANGE PRECEDING**: se agregó compatibilidad con `RANGE PRECEDING` en funciones de ventana.

```
SELECT sum(x) over (order by x range 1 preceding) 
FROM (values (1), (1), (2), (2)) t(x);
```

**MATCH\_RECOGNIZE**: se agregó compatibilidad con la coincidencia de patrones de filas, como en el siguiente ejemplo.

```
SELECT m.id AS row_id, m.match, m.val, m.label 
FROM (VALUES(1, 90),(2, 80),(3, 70),(4, 70)) t(id, value) 
MATCH_RECOGNIZE ( 
        ORDER BY id 
        MEASURES match_number() AS match, 
        RUNNING LAST(value) AS val, 
        classifier() AS label 
        ALL ROWS PER MATCH 
        AFTER MATCH SKIP PAST LAST ROW 
        PATTERN (() | A) DEFINE A AS true 
) AS m;
```

### Mejoras en el formato y el tipo de datos
<a name="engine-versions-reference-0003-data-format-and-data-type-enhancements"></a>

La versión 3 del motor Athena incluye las siguientes mejoras de formato y tipo de datos:
+ **LZ4 y ZSTD**: se agregó compatibilidad con la lectura de datos de Parquet comprimidos con LZ4 y ZSTD. Se agregó compatibilidad con la lectura de datos de ORC comprimidos con ZSTD.
+ **Tablas basadas en enlaces simbólicos**: se agregó compatibilidad con la lectura de tablas basadas en enlaces simbólicos en archivos de Avro. Ejemplo:

  ```
  CREATE TABLE test_avro_symlink  
  ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.avro.AvroSerDe'  
  ... 
  INPUTFORMAT 'org.apache.hadoop.hive.ql.io.SymlinkTextInputFormat'
  ```
+ **SphericalGeography**: el tipo SphericalGeography proporciona soporte nativo para las características espaciales representadas en coordenadas geográficas (a veces denominadas coordenadas geodésicas, lat/lon o lon/lat). Las coordenadas geográficas son coordenadas esféricas expresadas en unidades angulares (grados).

  La función `to_spherical_geography` devuelve coordenadas geográficas (esféricas) a partir de coordenadas geométricas (planas), como en el siguiente ejemplo.

  ```
  SELECT to_spherical_geography(ST_GeometryFromText(
     'LINESTRING (-40.2 28.9, -40.2 31.9, -37.2 31.9)'));
  ```

## Cambios bruscos
<a name="engine-versions-reference-0003-breaking-changes"></a>

Al migrar de versiones anteriores a la versión 3 del motor de Athena, es posible que ciertos cambios afecten al esquema de la tabla, la sintaxis o el uso de los tipos de datos. En esta sección, se enumeran los mensajes de error asociados y se sugieren soluciones alternativas.

### Cambios en la sintaxis de las consultas
<a name="engine-versions-reference-0003-syntax-changes"></a>

#### IGNORE NULLS no se puede utilizar con funciones de ventana sin valores
<a name="engine-versions-reference-0003-remove-ignore-nulls-for-bool_or"></a>

**Mensaje de error**: No se puede especificar una cláusula de tratamiento nulo para la función `bool_or`.

**Causa**: ahora solo se puede usar `IGNORE NULLS` con las [funciones de valor](https://trino.io/docs/current/functions/window.html#value-functions) `first_value`, `last_value`, `nth_value`, `lead` y `lag`. Este cambio se hizo para cumplir con la especificación ANSI SQL.

**Solución sugerida**: eliminar `IGNORE NULLS` de las funciones de ventana sin valores en las cadenas de consulta.

#### La función CONCAT debe tener dos o más argumentos
<a name="engine-versions-reference-0003-concat-str-minimum-two-args"></a>

**Mensaje de error**: INVALID\_FUNCTION\_ARGUMENT: debe haber dos o más argumentos de concatenación

**Causa**: anteriormente, la función de cadena `CONCAT` aceptaba un solo argumento. En la versión 3 del motor Athena, la función `CONCAT` requiere un mínimo de dos argumentos.

**Solución sugerida**: cambie las ocurrencias de `CONCAT(str)` por `CONCAT(str, '')`.

En la versión 3 del motor de Athena, las funciones no pueden tener más de 127 argumentos. Para obtener más información, consulte [Hay demasiados argumentos para llamar a la función](troubleshooting-athena.md#troubleshooting-athena-too-many-arguments).

#### La función approx\_percentile devuelve resultados diferentes
<a name="engine-versions-reference-0003-approx-percentile-function"></a>

La función `approx_percentile` devuelve resultados diferentes en la versión 3 que en las versiones anteriores del motor Athena.

**Mensaje de error**: ninguno.

**Causa**: la función `approx_percentile` está sujeta a cambios de versión.

**importante**  
Como los resultados de la función `approx_percentile` son aproximaciones y las aproximaciones están sujetas a cambios de una versión a otra, no debe confiar en la función `approx_percentile` para aplicaciones críticas.

**Solución sugerida**: para aproximarse al comportamiento de `approx_percentile` de versiones anteriores del motor, puede utilizar un conjunto diferente de funciones en la versión 3 del motor de Athena. Por ejemplo, suponga que se realiza la siguiente consulta en versiones anteriores del motor:

```
SELECT approx_percentile(somecol, 2E-1)
```

Para obtener aproximadamente el mismo resultado en la versión 3 del motor de Athena, puede probar las funciones `qdigest_agg` y `value_at_quantile`, como en el siguiente ejemplo. Tenga en cuenta que, incluso con esta solución alternativa, no se garantiza el mismo comportamiento.

```
SELECT value_at_quantile(qdigest_agg(somecol, 1), 2E-1)
```

#### La función geoespacial no admite la entrada varbinary
<a name="engine-versions-reference-0003-geo-spatial-function-does-not-support-varbinary-input"></a>

**Mensaje de error**: FUNCTION\_NOT\_FOUND para st\_XXX

**Causa**: algunas funciones geoespaciales ya no admiten el tipo de entrada `VARBINARY` heredado o las firmas de funciones relacionadas con el texto.

**Solución sugerida**: utilice funciones geoespaciales para convertir los tipos de entrada en los tipos compatibles. Los tipos de entrada admitidos se indican en el mensaje de error.

#### Las columnas anidadas deben ir entre comillas dobles en las cláusulas GROUP BY
<a name="engine-versions-reference-0003-group-by-nested-columns-require-double-quotes"></a>

**Mensaje de error**:  “{{column\_name}}”.“{{nested\_column}}” debe ser una expresión agregada o aparecer en la cláusula GROUP BY

**Causa**: la versión 3 del motor de Athena requiere que los nombres de las columnas anidadas en las cláusulas `GROUP BY` estén entre comillas dobles. Por ejemplo, la siguiente consulta produce el error porque, en la cláusula `GROUP BY`, `user.name` no está entre comillas dobles.

```
SELECT "user"."name" FROM dataset 
GROUP BY user.name
```

**Solución sugerida**: coloque comillas dobles alrededor de los nombres de las columnas anidadas en las cláusulas `GROUP BY`, como en el siguiente ejemplo.

```
SELECT "user"."name" FROM dataset 
GROUP BY "user"."name"
```

#### Error inesperado de FilterNode al utilizar OPTIMIZE en una tabla Iceberg
<a name="engine-versions-reference-0003-iceberg-optimize-where-clause-filters"></a>

**Mensaje de error**: Se encontró un FilterNode inesperado en el plan; probablemente el conector no pudo gestionar la expresión WHERE proporcionada.

**Causa**: la instrucción `OPTIMIZE` que se ejecutó en la tabla Iceberg utilizaba una cláusula `WHERE` que incluía una columna que no era de partición en su expresión de filtro.

**Solución sugerida**: la instrucción `OPTIMIZE` solo admite el filtrado por particiones. Cuando ejecute `OPTIMIZE` en las tablas particionadas, incluya solo las columnas de partición en la cláusula `WHERE`. Si ejecuta `OPTIMIZE` en una tabla no particionada, no especifique ninguna cláusula `WHERE`.

#### Orden de los argumentos de la función Log()
<a name="engine-versions-reference-0003-log-function"></a>

En la versión 3 del motor de Athena, el orden de los argumentos de la función `log()` ha cambiado a `log({{base}}, {{value}})` para ajustarse a los estándares de SQL.

#### La función minute() no admite intervalos de un año a un mes
<a name="engine-versions-reference-0003-minute-function"></a>

**Mensaje de error**: Parámetros inesperados (intervalo de un año a un mes) para la función minute. Expected: minute(timestamp with time zone), minute(time with time zone), minute(timestamp), minute(time), minute(interval day to second) (Valores esperados: minute[marca de tiempo con zona horaria], minute[hora con zona horaria], minute[marca de tiempo], minute[hora], minute[intervalo de días a segundos).

**Causa**: en la versión 3 del motor Athena, las comprobaciones de tipo se han hecho más precisas para `EXTRACT` de acuerdo con la especificación ANSI SQL.

**Solución sugerida**: actualice las consultas para asegurarse de que los tipos coincidan con las firmas de funciones sugeridas.

#### Las expresiones ORDER BY deben aparecer en la lista SELECT
<a name="engine-versions-reference-0003-order-by-expressions-must-appear-in-select-list"></a>

**Mensaje de error**: En el caso de SELECT DISTINCT, las expresiones ORDER BY deben aparecer en la lista SELECT

**Causa**: en una cláusula `SELECT`, se utiliza un alias de tabla incorrecto.

**Solución sugerida**: compruebe que todas las columnas de la expresión `ORDER BY` tengan las referencias adecuadas en la cláusula `SELECT DISTINCT`.

#### Error en la consulta al comparar varias columnas devueltas por una subconsulta
<a name="engine-versions-reference-0003-subquery-failure-multiple-columns"></a>

**Ejemplo de mensaje de error**: la expresión del valor y el resultado de la subconsulta deben ser del mismo tipo: row(varchar, varchar) vs. row(row (varchar, varchar)).

**Causa**: debido a una actualización de sintaxis en la versión 3 del motor de Athena, este error se produce cuando una consulta intenta comparar varios valores devueltos por una subconsulta y la instrucción `SELECT` de la subconsulta incluye su lista de columnas entre paréntesis, como en el siguiente ejemplo. 

```
SELECT *
FROM table1
WHERE (t1_col1, t1_col2)
IN (SELECT (t2_col1, t2_col2) FROM table2)
```

**Solución**: en la versión 3 del motor de Athena, elimine los paréntesis que rodean la lista de columnas de la instrucción `SELECT` de la subconsulta, como en la siguiente consulta de ejemplo actualizada.

```
SELECT *
FROM table1
WHERE (t1_col1, t1_col2)
IN (SELECT t2_col1, t2_col2 FROM table2)
```

#### SKIP es una palabra reservada para las consultas DML
<a name="engine-versions-reference-0003-skip-is-a-reserved-word-for-dml"></a>

La palabra `SKIP` ahora es una palabra reservada para consultas DML como `SELECT`. Para utilizar `SKIP` como identificador en una consulta DML, escríbala entre comillas dobles.

Para obtener más información acerca de palabras reservadas en Athena, consulte [Aplicación de caracteres de escape a las palabras clave reservadas de las consultas](reserved-words.md).

#### Las cláusulas SYSTEM\_TIME y SYSTEM\_VERSION están obsoletas para los desplazamientos en el tiempo
<a name="engine-versions-reference-0003-time-travel-syntax"></a>

**Mensaje de error**: mismatched input 'SYSTEM\_TIME'. Expecting: 'TIMESTAMP', 'VERSION' (La entrada “SYSTEM\_TIME” no coincide. Valor esperado: “TIMESTAMP”, “VERSION'

**Causa**: en versiones anteriores del motor de Athena, las tablas de Iceberg utilizaban las cláusulas `FOR SYSTEM_TIME AS OF` y `FOR SYSTEM_VERSION AS OF` para la marca de tiempo y el desplazamiento en el tiempo de la versión. La versión 3 del motor Athena utiliza las cláusulas `FOR TIMESTAMP AS OF` y `FOR VERSION AS OF`. 

**Solución sugerida**: actualice la consulta SQL para utilizar las cláusulas `TIMESTAMP AS OF` y `VERSION AS OF` para las operaciones de desplazamiento en el tiempo, como en los siguientes ejemplos.

Desplazamiento en el tiempo por marca de tiempo:

```
SELECT * FROM TABLE FOR TIMESTAMP AS OF (current_timestamp - interval '1' day)
```

 Desplazamiento en el tiempo por versión:

```
SELECT * FROM TABLE FOR VERSION AS OF 949530903748831860
```

#### Demasiados argumentos para un constructor de matrices
<a name="engine-versions-reference-0003-array-max-elements"></a>

**Mensaje de error**: TOO\_MANY\_ARGUMENTS: hay demasiados argumentos para el constructor de matrices.

**Causa**: el número máximo de elementos en un constructor de matrices ahora está establecido en 254.

**Solución sugerida**: divida los elementos en varias matrices que tengan 254 o menos elementos cada una y utilice la función `CONCAT` para concatenar las matrices, como en el siguiente ejemplo.

```
CONCAT(
ARRAY[x1,x2,x3...x254],
ARRAY[y1,y2,y3...y254],
...
)
```

#### No se permite el identificador delimitado por longitud cero
<a name="engine-versions-reference-0003-zero-length-delimited-identifier"></a>

**Mensaje de error**: No se permite el identificador delimitado por longitud cero.

**Causa**: una consulta utilizaba una cadena vacía como alias de columna.

**Solución sugerida**: actualice la consulta para usar un alias que no esté vacío en la columna.

### Cambios en el procesamiento de datos
<a name="engine-versions-reference-0003-data-processing-changes"></a>

#### Validación de buckets
<a name="engine-versions-reference-0003-bucket-validation"></a>

**Mensaje de error**: HIVE\_INVALID\_BUCKET\_FILES: la tabla de Hive está dañada.

**Causa**: es posible que la tabla esté dañada. La versión 3 del motor de Athena permite una validación adicional en las tablas agrupadas en buckets para garantizar la corrección de las consultas y evitar errores inesperados en el tiempo de ejecución.

**Solución sugerida**: vuelva a crear la tabla con la versión 3 del motor de Athena.

#### Cuando se convierte una estructura a JSON ahora se devuelven los nombres de los campos
<a name="engine-versions-reference-0003-cast-struct-to-json"></a>

Cuando se convierte una estructura `struct` a JSON en una consulta `SELECT` en la versión 3 del motor Athena, la conversión ahora devuelve tanto los nombres de los campos como los valores; por ejemplo, "`useragent":null` en lugar de solo los valores (como `null`).

#### Cambio de aplicación de medidas de seguridad de nivel de columna de tablas de Iceberg
<a name="engine-versions-reference-0003-iceberg-column-security"></a>

**Mensaje de error**: Acceso denegado: no se puede hacer una selección en las columnas

**Causa**: la tabla de Iceberg no se creó con Athena y utiliza una versión del [SDK de Apache Iceberg](https://iceberg.apache.org/releases/) anterior a la 0.13.0. Como las versiones anteriores del SDK no rellenan las columnas en AWS Glue, Lake Formation no pudo determinar las columnas autorizadas para el acceso.

**Solución sugerida**: realice una actualización mediante la instrucción [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) de Athena o utilice el SDK de Iceberg más reciente para corregir la tabla y actualizar la información de la columna en AWS Glue.

#### Los valores nulos en los tipos de datos de la lista ahora se propagan a las UDF.
<a name="engine-versions-reference-0003-nulls-in-list-datatypes-for-udfs"></a>

**Mensaje de error**: Excepción de puntero nulo

**Causa**: este problema puede afectarle si usa el conector de la UDF y ha implementado una función de Lambda definida por el usuario.

Las versiones anteriores del motor excluían los valores nulos en los tipos de datos de lista que se transmitían a una función definida por el usuario. En la versión 3 del motor Athena, los valores nulos ahora se conservan y se transfieren a la UDF. Esto puede provocar una excepción de puntero nulo si la UDF intenta anular la referencia al elemento nulo sin comprobarlo.

Por ejemplo, si tiene los datos `[null, 1, null, 2, 3, 4]` en un origen de datos, como DynamoDB, se pasa lo siguiente a la función de Lambda definida por el usuario:

**Versión 3 del motor Athena 3**: `[null, 1, null, 2, 3, 4]`

**Solución sugerida**: asegúrese de que la función de Lambda definida por el usuario gestione los elementos nulos en los tipos de datos de la lista.

#### Las subcadenas de las matrices de caracteres ya no contienen espacios rellenados
<a name="engine-versions-reference-0003-substring-no-padded-spaces"></a>

**Mensaje de error**: no se produce ningún error, pero la cadena devuelta ya no contiene espacios rellenados. Por ejemplo, `substr(char[20],1,100)` devuelve ahora una cadena con una longitud de 20 en lugar de 100.

**Solución sugerida**: no se requiere hacer nada.

#### Coacción de tipo columna decimal no compatible
<a name="engine-versions-reference-0003-unsupported-column-type"></a>

**Mensajes de error**: HIVE\_CURSOR\_ERROR: Failed to read Parquet file: s3://amzn-s3-demo-bucket/{{path}}/{{file\_name}}.parquet o Unsupported column type (varchar) for Parquet column ([{{column\_name}}]

**Causa**: la versión 2 del motor de Athena tenía éxito en ocasiones (pero fallaba con frecuencia) al intentar coercionar tipos de datos de `varchar` a decimal. Como la versión 3 del motor de Athena tiene una validación de tipos que comprueba que el tipo sea compatible antes de intentar leer el valor, estos intentos de coerción ahora siempre fallan.

**Solución sugerida**: para la versión 3 del motor de Athena, modifique el esquema en AWS Glue a fin de utilizar un tipo de datos numéricos en lugar de `varchar` para columnas decimales en los archivos Parquet. Vuelva a rastrear los datos y asegúrese de que el nuevo tipo de datos de la columna sea de tipo decimal o vuelva a crear manualmente la tabla en Athena y utilice la sintaxis `decimal({{precision}}, {{scale}})` a fin de especificar un tipo de datos [decimal](data-types.md#data-types-decimal) para la columna.

#### Los valores NaN flotante o doble ya no se pueden convertir a bigint
<a name="engine-versions-reference-0003-no-nan-to-bigint"></a>

**Mensaje de error**: INVALID\_CAST\_ARGUMENT: no se puede convertir NaN real/doble a bigint

**Causa**: en la versión 3 del motor de Athena, ya no se puede convertir `NaN` en 0 como `bigint`.

**Solución sugerida**: asegúrese de que los valores `NaN` no estén presentes en las columnas `float` o `double` al realizar la conversión a `bigint`.

#### Cambio en el tipo de devolución de la función uuid()
<a name="engine-versions-reference-0003-uuid-function-return-type-change"></a>

El siguiente problema afecta tanto a las tablas como a las vistas.

**Mensaje de error**: Unsupported Hive type: uuid (Tipo de Hive no compatible: uuid).

**Causa**: en versiones anteriores del motor, la función `uuid()` devolvía una cadena, pero en la versión 3 del motor de Athena, devuelve un UUID generado de forma pseudoaleatoria (tipo 4). Como Athena no admite el tipo de datos de la columna UUID, la función `uuid()` ya no se puede utilizar directamente en las consultas CTAS para generar columnas UUID en la versión 3 del motor de Athena.

Por ejemplo, la siguiente instrucción `CREATE TABLE` se completa correctamente en versiones previas del motor, pero devuelve NOT\_SUPPORTED: el tipo de Hive no es compatible: uuid en la versión 3 del motor de Athena:

```
CREATE TABLE uuid_table AS 
   SELECT uuid() AS myuuid
```

Del mismo modo, la siguiente instrucción `CREATE VIEW` se completa correctamente en la versión 2 del motor de Athena, pero devuelve El tipo de columna no es válido para la columna myuuid: el tipo de Hive no es compatible: uuid en la versión 3 del motor de Athena:

```
CREATE VIEW uuid_view AS 
   SELECT uuid() AS myuuid
```

Cuando una vista creada de este modo en versiones anteriores del motor se consulta en la versión 3 del motor de Athena, se produce un error como el siguiente:

VIEW\_IS\_STALE: línea 1:15: la vista “awsdatacatalog.mydatabase.uuid\_view” está obsoleta o en un estado no válido: la columna [myuuid] de tipo uuid proyectada desde la vista de consulta en la posición 0 no se puede convertir en la columna [myuuid] de tipo varchar almacenada en la definición de la vista

**Solución sugerida**: al crear la tabla o vista, utilice la función `cast()` para convertir la salida de `uuid()` a `varchar`, como en los siguientes ejemplos:

```
CREATE TABLE uuid_table AS
   SELECT CAST(uuid() AS VARCHAR) AS myuuid
```

```
CREATE VIEW uuid_view AS
   SELECT CAST(uuid() AS VARCHAR) AS myuuid
```

#### Problemas de coerción de CHAR y VARCHAR
<a name="engine-versions-reference-0003-char-varchar-coercion-issues"></a>

Utilice las soluciones alternativas de esta sección si tiene problemas de coerción con `varchar` y `char` en la versión 3 del motor de Athena. Si no puede utilizar estas soluciones alternativas, póngase en contacto con Soporte.

##### Error en la función CONCAT con entradas CHAR y VARCHAR mixtas
<a name="engine-versions-reference-0003-concat-function-failure"></a>

**Problema**: la siguiente consulta se realiza correctamente en la versión 2 del motor de Athena.

```
SELECT concat(CAST('abc' AS VARCHAR(20)), '12', CAST('a' AS CHAR(1)))
```

Sin embargo, en la versión 3 del motor de Athena, la misma consulta falla y ocurre lo siguiente:

**Mensaje de error**: FUNCTION\_NOT\_FOUND: line 1:8: Unexpected parameters (varchar(20), varchar(2), char(1)) for function concat. Expected: concat(char(x), char(y)), concat(array(E), E) E, concat(E, array(E)) E, concat(array(E)) E, concat(varchar), concat(varbinary) [FUNCTION\_NOT\_FOUND: línea 1:8: parámetros inesperados (varchar(20), varchar(2), char(1)) para la función concat. Parámetros esperados: concat(char(x), char(y)), concat(array(E), E) E, concat(E, array(E)) E, concat(array(E)) E, concat(varchar), concat(varbinary)

**Solución sugerida**: al usar la función `concat`, cámbiela a `char` o `varchar`, pero no a una combinación de ambas.

##### Error de concatenación de \|\| SQL con las entradas CHAR y VARCHAR
<a name="engine-versions-reference-0003-double-pipe-char-varchar-failure"></a>

En la versión 3 del motor de Athena, el operador de concatenación `||` de barras verticales dobles requiere `varchar` como entradas. Las entradas no pueden ser una combinación de los tipos `varchar` y `char`.

**Mensaje de error**: TYPE\_NOT\_FOUND: line 1:26: Unknown type: char(65537) [TYPE\_NOT\_FOUND: línea 1:26: tipo desconocido: char(65537)].

**Causa**: una consulta que usa `||` para concatenar `char` y `varchar` puede producir el error, como en el siguiente ejemplo.

```
SELECT CAST('a' AS CHAR) || CAST('b' AS VARCHAR)
```

**Solución sugerida**: concatenar `varchar` con `varchar`, como en el siguiente ejemplo.

```
SELECT CAST('a' AS VARCHAR) || CAST('b' AS VARCHAR) 
```

##### Error de consulta CHAR y VARCHAR UNION
<a name="engine-versions-reference-0003-char-varchar-union-query-failure"></a>

**Mensaje de error**: NOT\_SUPPORTED: Unsupported Hive type: char(65536). Supported CHAR types: CHAR(<=255)

**Causa**: consulta que intenta combinar `char` y `varchar`, como en el siguiente ejemplo:

```
CREATE TABLE t1 (c1) AS SELECT CAST('a' as CHAR) as c1 UNION ALL SELECT CAST('b' AS VARCHAR) AS c1 
```

**Solución sugerida**: en la consulta de ejemplo, utilice `'a'` como `varchar` en lugar de `char`. 

##### Espacios vacíos no deseados tras la coerción de CHAR o VARCHAR
<a name="engine-versions-reference-0003-empty-spaces-added-after-coercion"></a>

En la versión 3 del motor de Athena, cuando los datos `char(X)` y `varchar` se convierten en un solo tipo al formar una matriz o una sola columna, `char(65535)` es el tipo objetivo y cada campo contiene muchos espacios finales no deseados.

**Causa**: la versión 3 del motor de Athena convierte `varchar` y `char(X)` en `char(65535)` y luego rellena los datos con espacios.

**Solución sugerida**: convertir cada campo de forma explícita en `varchar`.

### Cambios en la marca de tiempo
<a name="engine-versions-reference-0003-timestamp-changes"></a>

#### El desbordamiento de la marca de tiempo de fecha y hora devuelve un error
<a name="engine-versions-reference-0003-date-timestamp-overflow"></a>

**Mensaje de error**: Desbordamiento de milisegundos: XXX

**Causa**: dado que en versiones anteriores del motor de Athena no se comprobó la existencia de desbordamientos en las fechas ISO 8601, algunas fechas produjeron una marca de tiempo negativa. La versión 3 del motor Athena comprueba este desbordamiento y devuelve una excepción.

**Solución sugerida**: asegúrese de que la marca de tiempo esté dentro del intervalo.

#### No se admiten zonas horarias políticas con TIME
<a name="engine-versions-reference-0003-political-time-zones"></a>

**Mensaje de error**: LITERAL NO VÁLIDO

**Causa**: consultas como `SELECT TIME '13:21:32.424 America/Los_Angeles'`.

**Solución sugerida**: evite usar zonas horarias políticas con `TIME`.

#### La falta de coincidencia de precisión en las columnas de marca de tiempo provoca un error de serialización
<a name="engine-versions-reference-0003-timestamp-precision-serialization-error"></a>

**Mensaje de error**: SERIALIZATION\_ERROR: no se pudo serializar la columna “{{COLUMNZ}}” de tipo “timestamp(3)” en la posición {{X}}:{{Y}}

{{COLUMNZ}} es el nombre de salida de la columna que causa el problema. Los números {{X}}: {{Y}} indican la posición de la columna en la salida.

**Causa**: la versión 3 del motor Athena comprueba que la precisión de las marcas de tiempo de los datos sea la misma que la precisión especificada para el tipo de datos de la columna en la especificación de la tabla. Actualmente, esta precisión es siempre de 3. Si los datos tienen una precisión superior a esta, las consultas fallan y se produce el error observado.

**Solución sugerida**: compruebe los datos para asegurarse de que las marcas de tiempo tengan una precisión de milisegundos.

#### La precisión de la marca de tiempo es incorrecta en las consultas UNLOAD y CTAS para las tablas de Iceberg
<a name="engine-versions-reference-0003-timestamp-precision-unload-ctas-iceberg"></a>

**Mensaje de error**: Precisión de la marca de tiempo incorrecta para timestamp (6); la precisión configurada es MILLISECONDS.

**Causa**: la versión 3 del motor Athena comprueba que la precisión de las marcas de tiempo de los datos sea la misma que la precisión especificada para el tipo de datos de la columna en la especificación de la tabla. Actualmente, esta precisión es siempre de 3. Si los datos tienen una precisión superior a esta (por ejemplo, microsegundos en lugar de milisegundos), las consultas pueden fallar y arrojar el error mencionado.

**Solución**: a fin de solucionar este problema, primero utilice `CAST` para la precisión de la marca de tiempo en 6, como en el siguiente ejemplo de CTAS, en el que se crea una tabla de Iceberg. Tenga en cuenta que la precisión debe especificarse como 6 en lugar de 3 para evitar el error La precisión de la marca de tiempo (3) no es compatible con Iceberg.

```
CREATE TABLE my_iceberg_ctas
WITH (table_type = 'ICEBERG', location = 's3://amzn-s3-demo-bucket/table_ctas/',
format = 'PARQUET')
AS SELECT id, CAST(dt AS timestamp(6)) AS "dt"
FROM my_iceberg
```

A continuación, dado que Athena no admite la marca de tiempo 6, vuelva a convertir el valor en marca de tiempo (por ejemplo, en una vista). En el siguiente ejemplo se crea una vista de la tabla `my_iceberg_ctas`.

```
CREATE OR REPLACE VIEW my_iceberg_ctas_view AS
SELECT cast(dt AS timestamp) AS dt
FROM my_iceberg_ctas
```

#### Ahora se produce un error de archivo de ORC con formato incorrecto al leer el tipo Long como marca de tiempo o viceversa en los archivos de ORC
<a name="engine-versions-reference-0003-orc-no-implicit-long-to-timestamp-coercion"></a>

**Mensaje de error**: Error al abrir el archivo de ORC con formato incorrecto “FILE (SPLIT POSITION)” dividido en Hive. No se puede leer la marca de tiempo de tipo SQL del flujo de ORC .long\_type de tipo LONG

**Causa**: la versión 3 del motor de Athena ahora rechaza la coerción implícita del tipo de datos `Long` a `Timestamp` o de `Timestamp` a `Long`. Anteriormente, los valores `Long` se convertían implícitamente en marcas de tiempo como si fueran milisegundos de epoch.

**Solución sugerida**: utilice la función `from_unixtime` para convertir la columna de forma explícita o utilice la función `from_unixtime` a fin de crear una columna adicional para consultas futuras.

#### No se admiten los intervalos de tiempo a mes
<a name="engine-versions-reference-0003-time-and-interval-year-to-month"></a>

**Mensaje de error**: EL TIPO NO COINCIDE

**Causa**: la versión 3 del motor Athena no admite el tiempo ni el intervalo de un año a otro (por ejemplo, `SELECT TIME '01:00' + INTERVAL '3' MONTH`).

#### Desbordamiento de marca de tiempo para el formato int96 de Parquet
<a name="engine-versions-reference-0003-timestamp-overflow-for-int96-parquet-format"></a>

**Mensaje de error**: TimeOfDayNanos no válido

**Causa**: un desbordamiento de marca de tiempo para el formato de Parquet `int96`.

**Solución sugerida**: identifique los archivos específicos que tienen el problema. A continuación, vuelva a generar el archivo de datos con una biblioteca de Parquet actualizada y conocida, o utilice Athena CTAS. Si el problema persiste, contacte con el servicio de asistencia de Athena y explíquenos cómo se generan los archivos de datos.

#### Se requiere espacio entre los valores de fecha y hora al convertir una cadena en una marca de tiempo
<a name="engine-versions-reference-0003-timestamp-cast-space"></a>

**Mensaje de error**: INVALID\_CAST\_ARGUMENT: el valor no se puede convertir en una marca de tiempo.

**Causa**: la versión 3 del motor de Athena ya no acepta un guion como separador válido entre los valores de fecha y hora de la cadena de entrada para `cast`. Por ejemplo, la siguiente consulta no funciona en la versión 3 del motor de Athena:

```
SELECT CAST('2021-06-06-23:38:46' AS timestamp) AS this_time
```

**Solución sugerida**: en la versión 3 del motor de Athena, sustituya el guion entre la fecha y la hora por un espacio, como en el siguiente ejemplo.

```
SELECT CAST('2021-06-06 23:38:46' AS timestamp) AS this_time
```

#### Cambio en el valor de devolución de la marca de tiempo to\_iso8601()
<a name="engine-versions-reference-0003-to-iso8601-function"></a>

**Mensaje de error**: ninguno.

**Causa**: en versiones anteriores del motor de Athena, la función `to_iso8601` devuelve una marca de tiempo con la zona horaria incluso si el valor transmitido a la función no incluye la zona horaria. En la versión 3 del motor de Athena, la función `to_iso8601` devuelve una marca de tiempo con la zona horaria solo cuando el argumento pasado incluye la zona horaria.

Por ejemplo, la siguiente consulta pasa la fecha actual a la función `to_iso8601` dos veces: primero como marca de tiempo con zona horaria y, después, como marca de tiempo.

```
SELECT TO_ISO8601(CAST(CURRENT_DATE AS TIMESTAMP WITH TIME ZONE)), TO_ISO8601(CAST(CURRENT_DATE AS TIMESTAMP))
```

El siguiente resultado se obtiene a partir de una consulta en la versión 3 del motor de Athena.

En versiones anteriores del motor:


****  

| \# | \_col0 | \_col1 | 
| --- | --- | --- | 
| 1 | `2023-02-24T00:00:00.000Z ` | `2023-02-24T00:00:00.000Z` | 

Versión 3 del motor de Athena:


****  

| \# | \_col0 | \_col1 | 
| --- | --- | --- | 
| 1 | `2023-02-24T00:00:00.000Z` | `2023-02-24T00:00:00.000` | 

**Solución sugerida**: para replicar el comportamiento anterior, puede pasar el valor de la marca de tiempo a la función `with_timezone` antes de pasarlo a `to_iso8601`, como en el siguiente ejemplo: 

```
SELECT to_iso8601(with_timezone(TIMESTAMP '2023-01-01 00:00:00.000', 'UTC'))
```

Resultado


****  

| \# | \_col0 | 
| --- | --- | 
| 1 |  2023-01-01T00:00:00.000Z  | 

#### El primer parámetro de at\_timezone() debe especificar una fecha
<a name="engine-versions-reference-at-timezone-function"></a>

**Problema**: en la versión 3 del motor de Athena, la función `at_timezone` no puede tomar un valor `time_with_timezone` como primer parámetro.

**Causa**: sin información de fecha, no se puede determinar si el valor transferido corresponde al horario diurno o a la hora estándar. Por ejemplo, `at_timezone('12:00:00 UTC', 'America/Los_Angeles')` es ambiguo, ya que no hay forma de determinar si el valor transferido es la hora diurna del Pacífico (PDT) o la hora estándar del Pacífico (PST).

## Limitaciones
<a name="engine-versions-reference-0003-known-limitations"></a>

La versión 3 del motor Athena tiene las siguientes limitaciones:
+ **Rendimiento de las consultas**: muchas consultas se ejecutan más rápido en la versión 3 del motor de Athena, pero algunos planes de consultas pueden diferir de versiones anteriores del motor de Athena. Como resultado, algunas consultas pueden diferir en la latencia o el costo.
+ **Conectores de Trino y Presto**: no se admiten los conectores de [Trino](https://trino.io/docs/current/connector.html) ni de [Presto](https://prestodb.io/docs/current/connector.html). Utilice la consulta federada de Amazon Athena para conectar orígenes de datos. Para obtener más información, consulte [Uso de consulta federada de Amazon Athena](federated-queries.md).
+ **Ejecución tolerante a errores**: no se admite la [ejecución tolerante a errores](https://trino.io/docs/current/admin/fault-tolerant-execution.html) de Trino (Trino Tardigrade).
+ **Límite de parámetros de las funciones**: las funciones no pueden aceptar más de 127 parámetros. Para obtener más información, consulte [Hay demasiados argumentos para llamar a la función](troubleshooting-athena.md#troubleshooting-athena-too-many-arguments).

En la versión 2 del motor Athena se introdujeron los siguientes límites para garantizar que las consultas no fallen debido a limitaciones de recursos. Los usuarios no pueden configurar estos límites.
+ **Número de elementos de resultado**: el número de elementos de resultado `n` está restringido a 10 000 o menos para las siguientes funciones: `min(col, n)`, `max(col, n)`, `min_by(col1, col2, n)` y `max_by(col1, col2, n)`.
+ **Conjuntos de agrupación**: el número máximo de sectores en un conjunto de agrupación es 2048.
+ **Longitud máxima de línea del archivo de texto**: la longitud máxima de línea predeterminada para los archivos de texto es de 200 MB.
+ **Tamaño máximo del resultado de la función de secuencia**: el tamaño máximo de resultado de una función de secuencia es 50 000 entradas. Por ejemplo, `SELECT sequence(0,45000,1)` se realiza correctamente, pero `SELECT sequence(0,55000,1)` falla con el mensaje de error El resultado de la función de secuencia no debe tener más de 50 000 entradas. Este límite se aplica a todos los tipos de entrada de funciones de secuencia, incluidas las marcas de tiempo.