Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Version 3 du moteur Athena
Pour la version 3 du moteur, Athena a introduit une approche d'intégration continue de la gestion des logiciels open source. Celle-ci améliore la simultanéité des projets [Trino](https://trino.io/) et [Presto](https://prestodb.io/), afin que vous puissiez accéder plus rapidement aux améliorations de la communauté, intégrées et ajustées au sein du moteur Athena.
Cette publication de la version 3 du moteur Athena prend en charge toutes les fonctionnalités des précédentes versions du moteur. Ce document met en évidence les principales différences entre les précédentes versions du moteur et la version 3 du moteur Athena. Pour plus d'informations, consultez l'article du *blog AWS Big Data* sur la [mise à niveau vers la version 3 du moteur Athena pour améliorer les performances des requêtes et accéder à davantage de fonctionnalités d'analyse](https://aws.amazon.com/blogs/big-data/upgrade-to-athena-engine-version-3-to-increase-query-performance-and-access-more-analytics-features/).
+ [Mise en route](#engine-versions-reference-0003-getting-started)
+ [Améliorations et nouvelles fonctions](#engine-versions-reference-0003-improvements-and-new-features)
+ [Fonctionnalités ajoutées](#engine-versions-reference-0003-added-features)
+ [Fonctions ajoutées](#engine-versions-reference-0003-added-functions)
+ [Améliorations des performances](#engine-versions-reference-0003-performance-improvements)
+ [Améliorations de la fiabilité](#engine-versions-reference-0003-reliability-enhancements)
+ [Améliorations de la syntaxe des requêtes](#engine-versions-reference-0003-query-syntax-enhancements)
+ [Améliorations du format et du type de données](#engine-versions-reference-0003-data-format-and-data-type-enhancements)
+ [Évolutions](#engine-versions-reference-0003-breaking-changes)
+ [Modifications de la syntaxe de requête](#engine-versions-reference-0003-syntax-changes)
+ [Modifications du traitement des données](#engine-versions-reference-0003-data-processing-changes)
+ [Modifications d'horodatage](#engine-versions-reference-0003-timestamp-changes)
+ [Limitations](#engine-versions-reference-0003-known-limitations)
## Mise en route
Pour commencer, créez un nouveau groupe de travail Athena utilisant la version 3 du moteur Athena ou configurez un groupe de travail existant pour qu'il utilise la version 3.
Pour plus d’informations, consultez la rubrique [Modification des versions du moteur Athena](https://docs.aws.amazon.com/athena/latest/ug/engine-versions-changing.html).
## Améliorations et nouvelles fonctions
Les fonctionnalités et mises à jour répertoriées incluent des améliorations provenant d'Athena lui-même et de fonctionnalités intégrées à partir de Trino open source. Pour consulter une liste exhaustive des opérateurs et des fonctions de requête SQL, consultez la [documentation de Trino](https://trino.io/docs/current/functions.html).
### Fonctionnalités ajoutées
#### Prise en charge des algorithmes de mise en compartiments Apache Spark
Athena peut lire les compartiments générés par l'algorithme de hachage Spark. Pour spécifier que les données ont été initialement rédigées par l'algorithme de hachage Spark, insérez `('bucketing_format'='spark')` dans la clause `TBLPROPERTIES` de votre instruction `CREATE TABLE`. Si cette propriété n'est pas spécifiée, l'algorithme de hachage Hive est utilisé.
```
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')
```
### Fonctions ajoutées
Les fonctions de cette section sont nouvelles pour la version 3 du moteur Athena.
#### Fonctions d’agrégation
**listagg(x, separator)** : renvoie les valeurs d'entrée concaténées, séparées par la chaîne de séparation.
```
SELECT listagg(value, ',') WITHIN GROUP (ORDER BY value) csv_value
FROM (VALUES 'a', 'c', 'b') t(value);
```
#### Fonctions de tableau
**contains\$1sequence(x, seq)** : renvoie « true » (vrai) si le tableau x contient l'ensemble du tableau seq sous forme de sous-ensemble séquentiel (toutes les valeurs dans le même ordre consécutif).
```
SELECT contains_sequence(ARRAY [1,2,3,4,5,6], ARRAY[1,2]);
```
#### Fonctions binaires
**murmur3 (binary)** — Calcule le hachage de 128 bits MurmurHash sur 3 du binaire.
```
SELECT murmur3(from_base64('aaaaaa'));
```
#### Fonctions de conversion
**format\$1number(number)** : renvoie une chaîne formatée à l'aide d'un symbole d'unité.
```
SELECT format_number(123456); -- '123K'
```
```
SELECT format_number(1000000); -- '1M'
```
#### Fonctions de date et d’heure
**timezone\$1hour(timestamp)** : renvoie l'heure du décalage de fuseau horaire par rapport à l'horodatage.
```
SELECT EXTRACT(TIMEZONE_HOUR FROM TIMESTAMP '2020-05-10 12:34:56 +08:35');
```
**timezone\$1minute(timestamp)** : renvoie la minute du décalage de fuseau horaire par rapport à l'horodatage.
```
SELECT EXTRACT(TIMEZONE_MINUTE FROM TIMESTAMP '2020-05-10 12:34:56 +08:35');
```
#### Fonctions géospatiales
**to\$1encoded\$1polyline(Geometry)** : encode une linestring ou un multipoint en polyligne.
```
SELECT to_encoded_polyline(ST_GeometryFromText(
'LINESTRING (-120.2 38.5, -120.95 40.7, -126.453 43.252)'));
```
**from\$1encoded\$1polyline(varchar)** : décode un polyligne en linestring.
```
SELECT ST_AsText(from_encoded_polyline('_p~iF~ps|U_ulLnnqC_mqNvxq`@'));
```
**to\$1geojson\$1geometry (SphericalGeography)** — Renvoie la géographie sphérique spécifiée au format GeoJSON.
```
SELECT to_geojson_geometry(to_spherical_geography(ST_GeometryFromText(
'LINESTRING (0 0, 1 2, 3 4)')));
```
**from\$1geojson\$1geometry(varchar)** : renvoie l'objet de type géographique sphérique à partir de la représentation GeoJSON, en supprimant les clés/valeurs non géométriques. `Feature` et `FeatureCollection` ne sont pas pris en charge.
```
SELECT from_geojson_geometry(to_geojson_geometry(to_spherical_geography(ST_GeometryFromText(
'LINESTRING (0 0, 1 2, 3 4)'))));
```
**geometry\$1nearest\$1points(Geometry, Geometry)** : renvoie les points les plus proches les uns des autres sur chaque géométrie. Si l'une des géométries est vide, renvoie NULL (nul). Dans le cas contraire, renvoie une ligne de deux objets `Point` ayant la distance minimale de deux points quelconques sur les géométries. Le premier point provient du premier argument de géométrie, le second du second argument de géométrie. S'il existe plusieurs paires ayant la même distance minimale, une paire est choisie arbitrairement.
```
SELECT geometry_nearest_points(ST_GeometryFromText(
'LINESTRING (50 100, 50 200)'), ST_GeometryFromText(
'LINESTRING (10 10, 20 20)'));
```
#### Fonctions Set Digest
**make\$1set\$1digest(x)** : compose toutes les valeurs d'entrée de x dans un setdigest.
```
SELECT make_set_digest(value) FROM (VALUES 1, 2, 3) T(value);
```
#### Fonctions de chaîne
**soundex (char)** : renvoie une chaîne de caractères contenant la représentation phonétique de char.
```
SELECT name
FROM nation
WHERE SOUNDEX(name) = SOUNDEX('CHYNA'); -- CHINA
```
**concat\$1ws(string0, string1, …, stringN)** : renvoie la concaténation de `string1, string2, ..., stringN` avec `string0` comme séparateur. Si `string0` a la valeur NULL, la valeur de retour est NULL. Toutes les valeurs nulles fournies dans les arguments après le séparateur sont ignorées.
```
SELECT concat_ws(',', 'def', 'pqr', 'mno');
```
#### Fonctions de fenêtrage
**GROUPS** : intègre une prise en charge des cadres de fenêtre basés sur des groupes.
```
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);
```
### Améliorations des performances
La version 3 du moteur Athena comprend les améliorations de performances suivantes.
+ **Récupération plus rapide des métadonnées des AWS Glue tables** : les requêtes impliquant plusieurs tables réduiront le temps de planification des requêtes.
+ **Filtrage dynamique pour les JOINTURES DROITES** : le filtrage dynamique est désormais activé pour les jointures droites qui ont des conditions de jointure égales, comme dans l'exemple suivant.
```
SELECT *
FROM lineitem RIGHT JOIN tpch.tiny.supplier
ON lineitem.suppkey = supplier.suppkey
WHERE supplier.name = 'abc';
```
+ **Instructions préparées volumineuses** : augmentation de la taille d' request/response en-tête HTTP par défaut à 2 Mo pour autoriser les instructions préparées de grande taille.
+ **approx\$1percentile()** : la fonction `approx_percentile` utilise désormais `tdigest` au lieu de `qdigest` pour récupérer des quantiles approximatives à partir des distributions. Cela permet d'améliorer les performances et de réduire l'utilisation de la mémoire. Notez qu’à la suite de ce changement, la fonction renvoie des résultats différents de ceux qu’elle renvoyait dans les précédentes versions du moteur. Pour de plus amples informations, veuillez consulter [La fonction approx\$1percentile renvoie des résultats différents](#engine-versions-reference-0003-approx-percentile-function).
### Améliorations de la fiabilité
L'utilisation générale de la mémoire du moteur et le suivi dans la version 3 du moteur Athena ont été améliorés. Les requêtes volumineuses sont moins susceptibles d'échouer en cas de panne de nœud.
### Améliorations de la syntaxe des requêtes
**INTERSECT ALL** : ajout de la prise en charge de `INTERSECT ALL`.
```
SELECT * FROM (VALUES 1, 2, 3, 4) INTERSECT ALL SELECT * FROM (VALUES 3, 4);
```
**EXCEPT ALL** : ajout de la prise en charge de `EXCEPT ALL`.
```
SELECT * FROM (VALUES 1, 2, 3, 4) EXCEPT ALL SELECT * FROM (VALUES 3, 4);
```
**RANGE PRECEDING** : ajout de la prise en charge de `RANGE PRECEDING` dans les fonctions de fenêtrage.
```
SELECT sum(x) over (order by x range 1 preceding)
FROM (values (1), (1), (2), (2)) t(x);
```
**MATCH\$1RECOGNIZE** : ajout de la prise en charge de la mise en correspondance des modèles de lignes, comme dans l'exemple suivant.
```
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;
```
### Améliorations du format et du type de données
La version 3 du moteur Athena comporte les améliorations suivantes en matière de format et de type de données.
+ **LZ4 et ZSTD** — Ajout du support pour la lecture LZ4 et la compression des données Parquet par ZSTD. Ajout de la prise en charge de l'écriture de données ORC compressées ZSTD.
+ **Tables basées sur des liens symboliques** : ajout de la prise en charge de la création de tables basées sur des liens symboliques sur les fichiers Avro. Un exemple suit.
```
CREATE TABLE test_avro_symlink
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.avro.AvroSerDe'
...
INPUTFORMAT 'org.apache.hadoop.hive.ql.io.SymlinkTextInputFormat'
```
+ **SphericalGeography**— Le SphericalGeography type fournit un support natif pour les entités spatiales représentées sur les coordonnées géographiques (parfois appelées coordonnées géodésiqueslat/lon, or lon/lat). Les coordonnées géographiques sont des coordonnées sphériques exprimées en unités angulaires (degrés).
La fonction `to_spherical_geography` renvoie des coordonnées géographiques (sphériques) à partir de coordonnées géométriques (planes), comme dans l'exemple suivant.
```
SELECT to_spherical_geography(ST_GeometryFromText(
'LINESTRING (-40.2 28.9, -40.2 31.9, -37.2 31.9)'));
```
## Évolutions
Lorsque vous migrez depuis les précédentes versions du moteur vers la version 3 du moteur Athena, certains changements peuvent affecter le schéma des tables, la syntaxe ou l’utilisation des types de données. Cette section répertorie les messages d'erreur associés et propose des solutions de contournement.
### Modifications de la syntaxe de requête
#### IGNORE NULLS ne peut pas être utilisé avec des fonctions de fenêtrage sans valeur
**Message d'erreur** : Impossible de spécifier une clause de traitement nulle pour la fonction `bool_or`.
**Cause** : `IGNORE NULLS` ne peut désormais être utilisé qu'avec les [fonctions de valeur](https://trino.io/docs/current/functions/window.html#value-functions) `first_value`, `last_value`, `nth_value`, `lead` et `lag`. Cette modification a été apportée pour se conformer à la spécification SQL ANSI.
**Solution suggérée** : Supprimer `IGNORE NULLS` des fonctions de fenêtrage sans valeur dans les chaînes de requête.
#### La fonction CONCAT doit comporter deux arguments ou plus.
**Message d'erreur** : INVALID\$1FUNCTION\$1ARGUMENT: There must be two or more concatenation arguments (INVALID\$1FUNCTION\$1ARGUMENT : il doit y avoir au moins deux arguments de concaténation)
**Cause** : auparavant, la fonction de chaîne `CONCAT` acceptait un seul argument. Dans la version 3 du moteur Athena, la fonction `CONCAT` nécessite un minimum de deux arguments.
**Solution suggérée** : remplacez les occurrences `CONCAT(str)` par `CONCAT(str, '')`.
Dans la version 3 du moteur Athena, les fonctions ne peuvent pas comporter plus de 127 arguments. Pour de plus amples informations, veuillez consulter [Trop d'arguments pour un appel de fonction](troubleshooting-athena.md#troubleshooting-athena-too-many-arguments).
#### La fonction approx\$1percentile renvoie des résultats différents
La fonction `approx_percentile` renvoie dans la version 3 du moteur Athena des résultats différents de ceux qu’elle renvoyait dans les précédentes versions du moteur.
**Messages d'erreur** : aucun.
**Cause** : la fonction `approx_percentile` est sujette à des modifications de version.
**Important**
Comme les sorties de la fonction `approx_percentile` sont des approximations et que les approximations sont susceptibles de changer d'une version à l'autre, vous ne devez pas vous fier à la fonction `approx_percentile` pour les applications critiques.
**Solution suggérée** : pour vous rapprocher du comportement que la fonction `approx_percentile` avait dans les précédentes versions du moteur, vous pouvez utiliser un ensemble de fonctions différent dans la version 3 du moteur Athena. Supposons par exemple que vous ayez la requête suivante dans les précédentes versions du moteur :
```
SELECT approx_percentile(somecol, 2E-1)
```
Pour obtenir approximativement le même résultat dans la version 3 du moteur Athena, vous pouvez essayer les fonctions `qdigest_agg` et `value_at_quantile`, comme dans l'exemple suivant. Notez que, même avec cette solution de contournement, le même comportement n'est pas garanti.
```
SELECT value_at_quantile(qdigest_agg(somecol, 1), 2E-1)
```
#### La fonction géospatiale ne prend pas en charge l'entrée varbinary
**Message d'erreur** : FUNCTION\$1NOT\$1FOUND for st\$1XXX (FUNCTION\$1NOT\$1FOUND pour st\$1XXX)
**Cause** : certaines fonctions géospatiales ne prennent plus en charge le type d'entrée `VARBINARY` hérité ou les signatures de fonctions liées au texte.
**Solution suggérée** : utilisez les fonctions géospatiales pour convertir les types d'entrée en types pris en charge. Les types d'entrée pris en charge sont indiqués dans le message d'erreur.
#### Dans les clauses GROUP BY, les colonnes imbriquées doivent être entre guillemets doubles
**Message d'erreur** : "*column\$1name*«. » *nested\$1column*« doit être une expression agrégée ou apparaître dans la clause GROUP BY
**Cause** : la version 3 du moteur Athena exige que les noms de colonnes imbriqués dans les clauses `GROUP BY` soient placés entre guillemets doubles. Par exemple, la requête suivante génère l’erreur, car dans la clause `GROUP BY`, `user.name` n’est pas entre guillemets doubles.
```
SELECT "user"."name" FROM dataset
GROUP BY user.name
```
**Solution suggérée** : placez des guillemets autour des noms de colonnes imbriqués dans les clauses `GROUP BY`, comme dans l'exemple suivant.
```
SELECT "user"."name" FROM dataset
GROUP BY "user"."name"
```
#### FilterNode Erreur inattendue lors de l'utilisation d'OPTIMIZE sur une table Iceberg
**Message d'erreur** : Inattendu FilterNode détecté dans le plan ; le connecteur n'a probablement pas pu gérer l'expression WHERE fournie.
**Cause** : l’instruction `OPTIMIZE` exécutée sur la table Iceberg a utilisé une clause `WHERE` incluant une colonne autre qu’une colonne de partition dans son expression de filtrage.
**Solution suggérée** : l’instruction `OPTIMIZE` gère le filtrage par partitions uniquement. Lorsque vous exécutez `OPTIMIZE` sur des tables partitionnées, incluez uniquement des colonnes de partition dans la clause `WHERE`. Si vous exécutez `OPTIMIZE` sur une table non partitionnée, ne spécifiez pas de clause `WHERE`.
#### Ordre des arguments de la fonction Log()
Dans la version 3 du moteur Athena, l’ordre des arguments de la fonction `log()` a été modifié en `log(base, value)` pour être conforme aux normes SQL.
#### La fonction Minute() ne prend pas en charge le type de données « interval year to month » (intervalle de l'année au mois)
**Message d'erreur** : Unexpected parameters (interval year to month) for function minute. (Paramètres inattendus [intervalle année-mois] pour la fonction minute.) Prévu : minute(timestamp with time zone) [minute(horodatage avec fuseau horaire)], minute(time with time zone) [minute(heure avec fuseau horaire)], minute(timestamp) [minute(horodatage)], minute(time) [minute(heure)], minute(interval day to second) [minute(intervalle d'une journée à une seconde)].
**Cause** : dans la version 3 du moteur Athena, les vérifications de type ont été rendues plus précises pour `EXTRACT`, conformément à la spécification SQL ANSI.
**Solution suggérée** : mettez à jour les requêtes pour vous assurer que les types correspondent aux signatures de fonctions suggérées.
#### Les expressions ORDER BY doivent apparaître dans la liste SELECT
**Message d'erreur** : For SELECT DISTINCT, ORDER BY expressions must appear in SELECT list (Pour SELECT DISTINCT, les expressions ORDER BY doivent apparaître dans la liste SELECT)
**Cause** : un crénelage de table incorrect est utilisé dans une clause `SELECT`.
**Solution suggérée** : vérifiez que toutes les colonnes de l'expression `ORDER BY` ont des références appropriées dans la clause `SELECT DISTINCT`.
#### Échec de la requête lors de la comparaison de plusieurs colonnes renvoyées par une sous-requête
**Exemple de message d'erreur** : l'expression de valeur et le résultat de la sous-requête doivent être du même type : ligne (varchar, varchar) et ligne (ligne (varchar, varchar))
**Cause** : en raison d'une mise à jour de syntaxe dans la version 3 du moteur Athena, cette erreur se produit lorsqu'une requête tente de comparer plusieurs valeurs renvoyées par une sous-requête et que l'instruction `SELECT` de sous-requête met sa liste de colonnes entre parenthèses, comme dans l'exemple suivant.
```
SELECT *
FROM table1
WHERE (t1_col1, t1_col2)
IN (SELECT (t2_col1, t2_col2) FROM table2)
```
**Solution** : dans la version 3 du moteur Athena, supprimez les parenthèses entourant la liste des colonnes dans l'instruction `SELECT` de sous-requête, comme dans l'exemple de requête mis à jour suivant.
```
SELECT *
FROM table1
WHERE (t1_col1, t1_col2)
IN (SELECT t2_col1, t2_col2 FROM table2)
```
#### SKIP est un mot réservé pour les requêtes DML.
Le mot `SKIP` est désormais un mot réservé aux requêtes DML telles que `SELECT`. Pour utiliser `SKIP` en tant qu’identifiant dans une requête DML, mettez-le entre guillemets.
Pour plus d’informations sur les mots réservés dans Athena, consultez [Échappement des mots-clés réservés dans les requêtes](reserved-words.md).
#### Clauses SYSTEM\$1TIME et SYSTEM\$1VERSION obsolètes pour les voyages dans le temps
**Message d'erreur** : mismatched input 'SYSTEM\$1TIME'. (entrée « SYSTEM\$1TIME » non concordante.) En attente de : « TIMESTAMP », « VERSION »
**Cause** : dans les précédentes versions du moteur, les tables Iceberg utilisaient les clauses `FOR SYSTEM_TIME AS OF` et `FOR SYSTEM_VERSION AS OF` pour l’horodatage et l’historique des versions. La version 3 du moteur Athena utilise les clauses `FOR TIMESTAMP AS OF` et `FOR VERSION AS OF`.
**Solution suggérée** : mettez à jour la requête SQL afin d'utiliser les clauses `TIMESTAMP AS OF` et `VERSION AS OF` pour les opérations de voyage dans le temps, comme dans les exemples suivants.
Voyage dans le temps par horodatage :
```
SELECT * FROM TABLE FOR TIMESTAMP AS OF (current_timestamp - interval '1' day)
```
Voyage dans le temps par version :
```
SELECT * FROM TABLE FOR VERSION AS OF 949530903748831860
```
#### Trop d'arguments pour un constructeur de tableaux
**Message d'erreur** : TOO\$1MANY\$1ARGUMENTS : trop d'arguments pour le constructeur de tableau.
**Cause** : le nombre maximum d'éléments dans un constructeur de tableau est désormais fixé à 254.
**Solution suggérée** : divisez les éléments en plusieurs tableaux de 254 éléments ou moins chacun, et utilisez la fonction `CONCAT` pour concaténer les tableaux, comme dans l'exemple suivant.
```
CONCAT(
ARRAY[x1,x2,x3...x254],
ARRAY[y1,y2,y3...y254],
...
)
```
#### L'identifiant délimité par une longueur nulle n'est pas autorisé
**Message d'erreur** : Zero-length delimited identifier not allowed. (L'identifiant délimité par une longueur nulle n'est pas autorisé.)
**Cause** : une requête utilisait une chaîne vide comme alias de colonne.
**Solution suggérée** : mettez à jour la requête afin d'utiliser un alias non vide pour la colonne.
### Modifications du traitement des données
#### Validation du compartiment
**Message d'erreur** : HIVE\$1INVALID\$1BUCKET\$1FILES : la table Hive est corrompue..
**Cause** : la table a peut-être été corrompue. Pour garantir l'exactitude des requêtes des tables compartimentées, la version 3 du moteur Athena permet une validation supplémentaire sur les tables compartimentées afin de garantir l'exactitude des requêtes et d'éviter des échecs inattendus lors de l'exécution.
**Solution suggérée** : recréez la table à l'aide de la version 3 du moteur Athena.
#### La conversion d’un struct au format JSON renvoie désormais des noms de champs.
Lorsque vous convertissez un `struct` au format JSON dans une requête `SELECT` dans la version 3 du moteur Athena, la conversion renvoie désormais à la fois les noms des champs et les valeurs (par exemple, « `useragent":null` »), plutôt qu’uniquement les valeurs (par exemple, `null`).
#### Modification de l'application de la sécurité au niveau des colonnes de la table Iceberg
**Message d'erreur** : Access Denied: Cannot select from columns (Accès refusé : impossible de sélectionner parmi les colonnes)
**Cause** : la table Iceberg a été créée en dehors d'Athena et utilise une version du kit [SDK Apache Iceberg](https://iceberg.apache.org/releases/) antérieure à 0.13.0. Comme les versions antérieures du SDK ne remplissaient pas les colonnes AWS Glue, Lake Formation n'a pas pu déterminer les colonnes autorisées à accéder.
**Solution suggérée** : effectuez une mise à jour à l'aide de l'instruction Athena [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) ou utilisez la dernière version du kit SDK Iceberg pour corriger la table et mettre à jour les informations des colonnes dans AWS Glue.
#### Les valeurs nulles des types de données de liste sont désormais propagées vers UDFs
**Message d'erreur** : Null Pointer Exception (Exception de pointeur nul)
**Cause** : ce problème peut vous affecter si vous utilisez le connecteur UDF et avez implémenté une fonction Lambda définie par l'utilisateur.
Les précédentes versions du moteur filtraient les valeurs nulles dans les types de données List transmis à une fonction définie par l’utilisateur. Dans la version 3 du moteur Athena, les valeurs nulles sont désormais préservées et transmises à l'UDF. Cela peut provoquer une exception de pointeur nul si l'UDF tente de déréférencer l'élément nul sans vérification.
Par exemple, si les données `[null, 1, null, 2, 3, 4]` se trouvent dans une source de données d'origine telle que DynamoDB, les éléments suivants sont transmis à la fonction Lambda définie par l'utilisateur :
**Version 3 du moteur Athena** : `[null, 1, null, 2, 3, 4]`
**Solution suggérée** : assurez-vous que votre fonction Lambda définie par l'utilisateur gère les éléments nuls dans les types de données List.
#### Les sous-chaînes des tableaux de caractères ne contiennent plus d'espaces rembourrés
**Message d'erreur** : No error is thrown, but the string returned no longer contains padded spaces. (Il n'y a pas d'erreur, mais la chaîne de caractères renvoyée ne contient plus d'espaces rembourrés.) Par exemple, `substr(char[20],1,100)` renvoie désormais une chaîne de longueur 20 au lieu de 100.
**Solution suggérée** : aucune action n'est requise.
#### Forçage d'un type de colonne décimale non pris en charge
**Messages d'erreur** : HIVE\$1CURSOR\$1ERROR : Impossible de lire le fichier Parquet : s3://amzn-s3-demo-bucket/*path*/*file\$1name*.parquet ou type de colonne non pris en charge (varchar) pour la colonne Parquet ([] *column\$1name*
**Cause** : la version 2 du moteur Athena réussissait parfois (mais échouait fréquemment) lors de tentatives de forçage du type de données de `varchar` à la décimale. Comme la version 3 du moteur Athena comporte une validation du type qui vérifie que le type est compatible avant d'essayer de lire la valeur, ces tentatives de forçage échouent désormais toujours.
**Solution suggérée** : Pour la version 3 du moteur Athena, modifiez votre schéma AWS Glue pour utiliser un type de données numérique plutôt que `varchar` pour les colonnes décimales dans les fichiers Parquet. Explorez à nouveau les données et assurez-vous que le nouveau type de données de colonne est de type décimal, ou recréez manuellement la table dans Athena et utilisez la syntaxe `decimal(precision, scale)` pour spécifier un type de données [decimal](data-types.md#data-types-decimal) pour la colonne.
#### Les valeurs NaN flottantes ou doubles ne peuvent plus être converties en bigint
**Message d'erreur** : INVALID\$1CAST\$1ARGUMENT : Impossible de convertir NaN en bigint real/double
**Cause** : dans la version 3 du moteur Athena, `NaN` ne peut plus être converti en 0 en tant que `bigint`.
**Solution suggérée** : assurez-vous que les valeurs `NaN` ne sont pas présentes dans les colonnes `float` ou `double` lorsque vous convertissez en `bigint`.
#### changement de type de retour de la fonction uuid()
Le problème suivant concerne à la fois les tables et les vues.
**Message d'erreur** : Type Hive non pris en charge : uuid
**Cause** : dans les précédentes versions du moteur, la fonction `uuid()` renvoyait une chaîne, mais dans la version 3 du moteur Athena, elle renvoie un pseudo UUID généré de manière aléatoire (type 4). Le type de données de colonne UUID n'étant pas pris en charge dans Athena, la fonction `uuid()` ne peut plus être utilisée directement dans les requêtes CTAS pour générer des colonnes UUID dans la version 3 du moteur Athena.
Par exemple, l’instruction `CREATE TABLE` suivante s’exécute correctement dans les précédentes versions du moteur, mais renvoie le message NOT\$1SUPPORTED: Unsupported Hive type: uuid dans la version 3 du moteur Athena :
```
CREATE TABLE uuid_table AS
SELECT uuid() AS myuuid
```
De même, l’instruction `CREATE VIEW` suivante s’exécutait correctement dans la version 2 du moteur Athena, mais renvoie le message Invalid column type for column myuuid: Unsupported Hive type: uuid dans la version 3 du moteur Athena :
```
CREATE VIEW uuid_view AS
SELECT uuid() AS myuuid
```
Lorsqu’une vue ainsi créée dans les précédentes versions du moteur est interrogée dans la version 3 du moteur Athena, une erreur semblable à ce qui suit se produit :
VIEW\$1IS\$1STALE : ligne 1:15 : La vue « awsdatacatalog.mydatabase.uuid\$1view » est obsolète ou dans un état non valide : la colonne [myuuid] de type uuid projetée depuis la vue de la requête à la position 0 ne peut pas être forcée vers la colonne [myuuid] de type varchar stockée dans la définition de la vue
**Solution suggérée** : lorsque vous créez la table ou la vue, utilisez la fonction `cast()` pour convertir la sortie de `uuid()` en un `varchar`, comme dans les exemples suivants :
```
CREATE TABLE uuid_table AS
SELECT CAST(uuid() AS VARCHAR) AS myuuid
```
```
CREATE VIEW uuid_view AS
SELECT CAST(uuid() AS VARCHAR) AS myuuid
```
#### Problèmes de forçage liés à CHAR et VARCHAR
Utilisez les solutions de contournement décrites dans cette section si vous rencontrez des problèmes de forçage avec `varchar` et `char` dans la version 3 du moteur Athena. Si vous ne parvenez pas à utiliser ces solutions de contournement, veuillez contacter. Support
##### Échec de la fonction CONCAT avec des entrées CHAR et VARCHAR mixtes
**Problème** : la requête suivante réussit dans la version 2 du moteur Athena.
```
SELECT concat(CAST('abc' AS VARCHAR(20)), '12', CAST('a' AS CHAR(1)))
```
Cependant, dans la version 3 du moteur Athena, la même requête échoue avec ce qui suit :
**Message d'erreur** : FUNCTION\$1NOT\$1FOUND : ligne 1:8 : paramètres inattendus (varchar (20), varchar (2), char (1)) pour la fonction concat. Attendu : concat (char (x), char (y)), concat (tableau (E), E) E, concat (E, tableau (E)) E, concat (tableau (E)) E, concat (varchar), (varbinary)
**Solution suggérée** : lorsque vous utilisez la fonction `concat`, convertissez en `char` ou `varchar`, mais pas en un mélange des deux.
##### Échec de la concaténation SQL \$1\$1 avec les entrées CHAR et VARCHAR
Dans la version 3 du moteur Athena, l'opérateur de concaténation `||` à double barre verticale a besoin de `varchar` comme entrées. Les entrées ne peuvent pas être une combinaison de types `varchar` et `char`.
**Message d'erreur** : TYPE\$1NOT\$1FOUND : ligne 1:26 : type inconnu : char (65537)
**Cause** : une requête qui utilise `||` pour concaténer un `char` et un `varchar` peut produire l'erreur, comme dans l'exemple suivant.
```
SELECT CAST('a' AS CHAR) || CAST('b' AS VARCHAR)
```
**Solution suggérée** : concaténer `varchar` avec `varchar`, comme dans l'exemple suivant.
```
SELECT CAST('a' AS VARCHAR) || CAST('b' AS VARCHAR)
```
##### Échec des requêtes CHAR et VARCHAR UNION
**Message d'erreur** : NOT\$1SUPPORTED : type Hive non pris en charge : char (65536). Supported CHAR types: CHAR(<=255)
**Cause** : une requête qui tente de combiner `char` et `varchar`, comme dans l'exemple suivant :
```
CREATE TABLE t1 (c1) AS SELECT CAST('a' as CHAR) as c1 UNION ALL SELECT CAST('b' AS VARCHAR) AS c1
```
**Solution suggérée** : dans l'exemple de requête, convertissez `'a'` en `varchar` plutôt qu'en `char`.
##### Espaces vides indésirables après le forçage CHAR ou VARCHAR
Dans la version 3 du moteur Athena, lorsque les données `char(X)` et `varchar` sont forcées en un seul type lors de la formation d'un tableau ou d'une seule colonne, `char(65535)` est le type cible et chaque champ contient de nombreux espaces de fin indésirables.
**Cause** : la version 3 du moteur Athena force `varchar` et `char(X)` en `char(65535)`, puis remplit correctement les données avec des espaces.
**Solution suggérée** : convertissez chaque champ de manière explicite en `varchar`.
### Modifications d'horodatage
#### Le dépassement de date et d'horodatage génère une erreur
**Message d'erreur** : Millis overflow: XXX (Dépassement millis : XXX)
**Cause** : le débordement des dates ISO 8601 n’était pas vérifié dans les précédentes versions du moteur. Certaines dates ont ainsi généré un horodatage négatif. La version 3 du moteur Athena vérifie la présence de ce dépassement et génère une exception.
**Solution suggérée** : assurez-vous que l'horodatage se situe dans la plage.
#### Fuseaux horaires politiques avec TIME non pris en charge
**Message d'erreur** : INVALID LITERAL
**Cause** : requêtes telles que `SELECT TIME '13:21:32.424 America/Los_Angeles'`.
**Solution suggérée** : évitez d'utiliser des fuseaux horaires politiques avec `TIME`.
#### Le décalage de précision dans les colonnes d'horodatage provoque une erreur de sérialisation
**Message d'erreur** : SERIALIZATION\$1ERROR : Impossible de sérialiser la colonne « » de type « timestamp (3) *COLUMNZ* » à la position : *X* *Y*
*COLUMNZ*est le nom de sortie de la colonne à l'origine du problème. Les chiffres *X* : *Y* indiquent la position de la colonne dans la sortie.
**Cause** : la version 3 du moteur Athena vérifie que la précision des horodatages des données est identique à la précision spécifiée pour le type de données de colonne dans la spécification de la table. Actuellement, cette précision est toujours de 3. Si les données ont une précision supérieure à cette valeur, les requêtes échouent et l'erreur est signalée.
**Solution suggérée** : vérifiez vos données pour vous assurer que vos horodatages ont une précision de l'ordre de la milliseconde.
#### Précision d'horodatage incorrecte dans les requêtes UNLOAD et CTAS pour les tables Iceberg
**Message d'erreur** : précision d'horodatage incorrecte pour horodatage (6) ; la précision configurée est de MILLISECONDES
**Cause** : la version 3 du moteur Athena vérifie que la précision des horodatages des données est identique à la précision spécifiée pour le type de données de colonne dans la spécification de la table. Actuellement, cette précision est toujours de 3. Si les données ont une précision supérieure à cette valeur (par exemple, microsecondes au lieu de millisecondes), les requêtes peuvent échouer et l'erreur est signalée.
**Solution** : pour contourner ce problème, commencez par `CAST` la précision de l'horodatage sur 6, comme dans l'exemple CTAS suivant qui crée une table Iceberg. Notez que la précision doit être spécifiée comme 6 au lieu de 3 pour éviter l'erreur Précision d'horodatage (3) non prise en charge pour 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
```
Ensuite, comme Athéna ne prend pas en charge l'horodatage 6, convertissez à nouveau la valeur en horodatage (par exemple, dans une vue). L'exemple suivant crée une vue à partir de la table `my_iceberg_ctas`.
```
CREATE OR REPLACE VIEW my_iceberg_ctas_view AS
SELECT cast(dt AS timestamp) AS dt
FROM my_iceberg_ctas
```
#### La lecture du type Long comme horodatage ou vice versa dans les fichiers ORC provoque désormais une erreur de fichier ORC mal formée
**Message d’erreur** : Error opening Hive split ‘FILE (SPLIT POSITION)’ Malformed ORC file. (Erreur lors de l’ouverture du fichier ORC mal formé « FILE (SPLIT POSITION) » du fractionnement Hive.) Impossible de lire l'horodatage de type SQL à partir du flux ORC .long\$1type de type LONG
**Cause** : la version 3 du moteur Athena rejette désormais tout forçage implicite du type de données `Long` en `Timestamp` ou de `Timestamp` en `Long`. Auparavant, les valeurs `Long` étaient implicitement converties en horodatage comme s'il s'agissait de millisecondes d'époque.
**Solution suggérée** : utilisez la fonction `from_unixtime` pour convertir explicitement la colonne, ou utilisez la fonction `from_unixtime` pour créer une colonne supplémentaire pour les requêtes futures.
#### Heure et intervalle d'une année au mois non pris en charge
**Message d'erreur** : TYPE MISMATCH
**Cause** : la version 3 du moteur Athena ne prend pas en charge l'heure et l'intervalle d'une année au mois (par exemple, `SELECT TIME '01:00' + INTERVAL '3' MONTH`).
#### Dépassement d'horodatage pour le format Parquet int96
**Message d'erreur** : timeOfDayNanos non valide
**Cause** : dépassement d'horodatage pour le format Parquet `int96`.
**Solution suggérée** : identifiez les fichiers spécifiques qui présentent ce problème. Générez ensuite à nouveau le fichier de données avec une up-to-date bibliothèque Parquet bien connue, ou utilisez Athena CTAS. Si le problème persiste, contactez le support d'Athena et indiquez-nous comment les fichiers de données sont générés.
#### Espace requis entre les valeurs de date et d'heure lors de la conversion d'une chaîne en un horodatage
**Message d'erreur** : INVALID\$1CAST\$1ARGUMENT : la valeur ne peut pas être convertie en horodatage.
**Cause** : la version 3 du moteur Athena n'accepte plus le tiret comme séparateur valide entre les valeurs de date et d'heure dans la chaîne d'entrée à `cast`. Ainsi, la requête suivante ne fonctionne pas dans la version 3 du moteur Athena :
```
SELECT CAST('2021-06-06-23:38:46' AS timestamp) AS this_time
```
**Solution suggérée** : dans la version 3 du moteur Athena, remplacez le tiret entre la date et l'heure par un espace, comme dans l'exemple suivant.
```
SELECT CAST('2021-06-06 23:38:46' AS timestamp) AS this_time
```
#### changement de la valeur de retour de l'horodatage to\$1iso8601()
**Message d'erreur** : aucun.
**Cause** : dans les précédentes versions du moteur, la fonction `to_iso8601` renvoyait un horodatage avec le fuseau horaire, même si la valeur transmise à la fonction n’incluait pas le fuseau horaire. Dans la version 3 du moteur Athena, la fonction `to_iso8601` renvoie un horodatage avec le fuseau horaire uniquement lorsque l'argument passé inclut le fuseau horaire.
Par exemple, la requête suivante transmet deux fois la date actuelle à la fonction `to_iso8601` : d'abord sous forme d'horodatage avec fuseau horaire, puis sous forme d'horodatage.
```
SELECT TO_ISO8601(CAST(CURRENT_DATE AS TIMESTAMP WITH TIME ZONE)), TO_ISO8601(CAST(CURRENT_DATE AS TIMESTAMP))
```
La sortie suivante montre le résultat de la requête dans la version 3 du moteur Athena.
Précédentes versions du moteur :
****
| \$1 | \$1col0 | \$1col1 |
| --- | --- | --- |
| 1 | `2023-02-24T00:00:00.000Z ` | `2023-02-24T00:00:00.000Z` |
Version 3 du moteur Athena :
****
| \$1 | \$1col0 | \$1col1 |
| --- | --- | --- |
| 1 | `2023-02-24T00:00:00.000Z` | `2023-02-24T00:00:00.000` |
**Solution suggérée** : pour reproduire le comportement précédent, vous pouvez transmettre la valeur d'horodatage à la fonction `with_timezone` avant de la transmettre à `to_iso8601`, comme dans l'exemple suivant :
```
SELECT to_iso8601(with_timezone(TIMESTAMP '2023-01-01 00:00:00.000', 'UTC'))
```
Résultat
****
| \$1 | \$1col0 |
| --- | --- |
| 1 | 2023-01-01T00:00:00.000Z |
#### Le premier paramètre at\$1timezone() doit spécifier une date
**Problème** : dans la version 3 du moteur Athena, la fonction `at_timezone` ne peut pas prendre une valeur `time_with_timezone` comme premier paramètre.
**Cause** : sans informations de date, il est impossible de déterminer si la valeur transmise est l'heure d'été ou l'heure normale. Par exemple, `at_timezone('12:00:00 UTC', 'America/Los_Angeles')` est ambigu car il n'existe aucun moyen de déterminer si la valeur transmise est l'heure d'été du Pacifique (PDT) ou l'heure normale du Pacifique (PST).
## Limitations
La version 3 du moteur Athena présente les limitations suivantes.
+ **Performances des requêtes** : de nombreuses requêtes s’exécutent plus rapidement sur la version 3 du moteur Athena, mais certains plans de requêtes peuvent différer des précédentes versions du moteur. Par conséquent, certaines requêtes peuvent différer en termes de latence ou de coût.
+ **Connecteurs Trino et Presto** : les connecteurs [Trino](https://trino.io/docs/current/connector.html) et [Presto](https://prestodb.io/docs/current/connector.html) ne sont pas pris en charge. Utilisation d'une requête fédérée d'Amazon Athena pour vous connecter aux sources de données. Pour de plus amples informations, veuillez consulter [Utilisation de la requête fédérée Amazon Athena](federated-queries.md).
+ **Exécution tolérante aux pannes** : l'[exécution tolérante aux pannes](https://trino.io/docs/current/admin/fault-tolerant-execution.html) de Trino (Trino Tardigrade) n'est pas prise en charge.
+ **Limite de paramètres de fonction** : les fonctions ne peuvent pas comporter plus de 127 paramètres. Pour de plus amples informations, veuillez consulter [Trop d'arguments pour un appel de fonction](troubleshooting-athena.md#troubleshooting-athena-too-many-arguments).
Les limites suivantes ont été introduites dans la version 2 du moteur Athena afin de s'assurer que les requêtes n'échouent pas en raison de limitations de ressources. Ces limites ne sont pas configurables par les utilisateurs.
+ **Nombre d'éléments de résultat** : le nombre d'éléments de résultat `n` est limité à 10 000 ou moins pour les fonctions suivantes : `min(col, n)`, `max(col, n)`, `min_by(col1, col2, n)` et `max_by(col1, col2, n)`.
+ **JEUX DE GROUPES** : le nombre maximal de tranches dans un jeu de groupes est 2048.
+ **Longueur maximale de la ligne du fichier texte** : la longueur de ligne maximale par défaut pour les fichiers texte est de 200 Mo.
+ **Taille maximale des résultats de la fonction de séquence** : la taille maximale de résultat d'une fonction de séquence est de 50 000 entrées. Par exemple, `SELECT sequence(0,45000,1)` réussit, mais `SELECT sequence(0,55000,1)` échoue avec le message d'erreur Le résultat de la fonction de séquence ne doit pas comporter plus de 50 000 entrées. Cette limite s'applique à tous les types d'entrées pour les fonctions de séquence, y compris aux horodatages.