Version 3 du moteur Athena - Amazon Athena

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 et Presto, 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 version 3 du moteur Athena prend en charge toutes les fonctionnalités de la version 2. Ce document met en évidence les principales différences entre les versions 2 et 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.

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. Tout groupe de travail Athena peut effectuer une mise à niveau de la version 2 vers la version 3 du moteur sans interruption de votre capacité à soumettre des requêtes.

Pour plus d’informations, consultez la rubrique Modification des versions du moteur Athena.

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 une liste exhaustive des opérateurs de SQL requête et des fonctions, reportez-vous à la documentation de Trino.

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_sequence(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_number(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_hour(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_minute(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_encoded_polyline(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_encoded_polyline(varchar) : décode un polyligne en linestring.

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

to_geojson_geometry (SphericalGeography) — Renvoie la géographie sphérique spécifiée au format Geo. JSON

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

from_geojson_geometry (varchar) — Renvoie l'objet de type géographie sphérique à partir de la représentation géographique, en supprimant les clés/valeurs non géométriques. JSON Featureet ne FeatureCollection 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_nearest_points(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, renvoieNULL. 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_set_digest(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_ws(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— Ajoute la prise en charge des cadres de fenêtres 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 RIGHT JOIN : le filtrage dynamique est désormais activé pour les jointures droites soumises à 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 de l'en-tête de HTTP demande/réponse par défaut à 2 Mo pour autoriser les instructions préparées de grande taille.

  • approx_percentile() – 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 cette modification, la fonction renvoie des résultats différents de ceux qu'elle renvoyait dans la version 2 du moteur Athena. Pour de plus amples informations, veuillez consulter La fonction approx_percentile renvoie des résultats différents.

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

INTERSECTALL— Ajout du support pourINTERSECT ALL.

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

EXCEPTALL— Ajout du support pourEXCEPT ALL.

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

RANGEPRECEDING— Ajout du support pour les fonctions RANGE PRECEDING intégrées à la fenêtre.

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

MATCH_ RECOGNIZE — Ajout du support pour la 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.

  • LZ4et ZSTD — Ajout du support pour la lecture LZ4 et la ZSTD compression des données Parquet. Ajout du support pour l'écriture de ORC données ZSTD compressées.

  • 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ésiques, lat/lon ou 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 de la version 2 vers la version 3 du moteur Athena, certaines modifications 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

IGNORENULLSne peut pas être utilisé avec des fonctions de fenêtre 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 first_value, last_value, nth_value, lead et lag. Cette modification a été apportée pour se conformer à la ANSI SQL spécification.

Solution suggérée : Supprimer IGNORE NULLS des fonctions de fenêtrage sans valeur dans les chaînes de requête.

CONCATla fonction doit avoir deux arguments ou plus

Message d'erreur : INVALID_ FUNCTION _ ARGUMENT : 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.

La fonction approx_percentile 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 de la version 2 du moteur Athena.

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 se rapprocher du comportement de la version 2 du moteur Athena de la fonction approx_percentile, 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 la version 2 du moteur Athena :

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_ NOT _ FOUND pour st_ XXX

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

Message d'erreur :  »column_name"."nested_column« 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 produit 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 OPTIMIZE sur une table Iceberg

Message d'erreur : Inattendu FilterNode détecté dans le plan ; le connecteur n'a probablement pas pu gérer WHERE l'expression fournie.

Cause : L'OPTIMIZEinstruction exécutée sur la table Iceberg utilisait une WHERE clause qui incluait une colonne non partitionnée dans son expression de filtre.

Solution suggérée : L'OPTIMIZEinstruction prend en charge le filtrage par partitions uniquement. Lorsque vous exécutez OPTIMIZE sur des tables partitionnées, incluez uniquement les colonnes de partition dans la WHERE clause. Si vous exécutez OPTIMIZE sur une table non partitionnée, ne spécifiez aucune clause. WHERE

Ordre des arguments de la fonction Log()

Dans la version 2 du moteur Athena, l'ordre des arguments de la fonction log() était log(value, base). Dans la version 3 du moteur Athena, cela est devenu conforme log(base, value) 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 contrôles de type ont été rendus plus précis EXTRACT conformément aux ANSI SQL spécifications.

Solution suggérée : mettez à jour les requêtes pour vous assurer que les types correspondent aux signatures de fonctions suggérées.

ORDERLes expressions BY doivent apparaître dans la SELECT liste

Message d'erreur : Les expressions For SELECTDISTINCT, ORDER BY doivent apparaître dans la SELECT liste

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)

SKIPest un mot réservé pour les DML requêtes

Le mot SKIP est désormais réservé aux DML requêtes telles queSELECT. Pour l'utiliser SKIP comme identifiant dans une DML requête, mettez-le entre guillemets.

Pour plus d’informations sur les mots réservés dans Athena, consultez Échapper aux mots clés réservés dans les requêtes.

SYSTEMVERSIONClauses _ TIME et SYSTEM _ déconseillées pour les voyages dans le temps

Message d'erreur : l'entrée « SYSTEM _ TIME » ne correspond pas. En attente de : TIMESTAMP « », « VERSION »

Cause : dans la version 2 du moteur Athena, les tables Iceberg utilisaient les clauses FOR SYSTEM_TIME AS OF et FOR SYSTEM_VERSION AS OF pour l'horodatage et le voyage dans le temps 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 SQL requête pour utiliser les VERSION AS OF clauses TIMESTAMP AS OF et 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_ MANY _ ARGUMENTS : 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_ INVALID _ BUCKET _ FILES : La table Hive est endommagée.

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 transformation d'une structure en renvoie JSON désormais les noms de champs

Lorsque vous convertissez un struct vers JSON dans une SELECT requête dans la version 3 du moteur Athena, le cast renvoie désormais à la fois les noms des champs et les valeurs (par exemple, « ») useragent":null au lieu de simplement 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 d'Apache SDK Iceberg antérieure à la version 0.13.0. Étant donné que SDK les versions antérieures ne renseignaient 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'ALTER TABLE SET PROPERTIESinstruction Athena ou utilisez la dernière version d'Iceberg SDK pour corriger le tableau et mettre à jour les informations des colonnes. 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 UDF connecteur et avez implémenté une fonction Lambda définie par l'utilisateur.

La version 2 du moteur Athena a filtré 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 conservées et transmises au. UDF Cela peut provoquer une exception de pointeur nul si le système 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 2 du moteur Athena : [1,2,3,4]

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 _ CURSOR _ ERROR : Impossible de lire le fichier Parquet : s3://amzn-s3-demo-bucket/path/file_name.parquet ou type de colonne non supporté (varchar) pour la colonne Parquet ([column_name]

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 2 du moteur Athena et 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 pour la colonne.

Les valeurs NaN flottantes ou doubles ne peuvent plus être converties en bigint

Message d'erreur : INVALID_ CAST _ ARGUMENT : Impossible de convertir un NaN réel/double en bigint

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 la version 2 du moteur Athena, la uuid() fonction renvoyait une chaîne, mais dans la version 3 du moteur Athena, elle renvoie un pseudo généré aléatoirement UUID (type 4). Le type de données de UUID colonne n'étant pas pris en charge dans Athena, la uuid() fonction ne peut plus être utilisée directement dans les CTAS requêtes pour générer des UUID colonnes dans la version 3 du moteur Athena.

Par exemple, l'CREATE TABLEinstruction suivante s'exécute correctement dans la version 2 du moteur Athena mais renvoie NOT_ SUPPORTED : Type de ruche non pris en charge : uuid dans le moteur Athena version 3 :

CREATE TABLE uuid_table AS SELECT uuid() AS myuuid

De même, l'instruction CREATE VIEW suivante s'exécute correctement dans la version 2 du moteur Athena, mais renvoie Type de colonne non valide pour colonne myuuid  : type Hive non pris en charge  : uuid dans la version 3 du moteur Athena :

CREATE VIEW uuid_view AS SELECT uuid() AS myuuid

Lorsqu'une vue ainsi créée dans la version 2 du moteur Athena est interrogée dans la version 3 du moteur Athena, une erreur semblable à la suivante se produit :

VIEW_IS_ STALE : ligne 1:15 : La vue « awsdatacatalog.mydatabase.uuid_view » est périmée 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 redirigé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

CHARet problèmes de VARCHAR coercition

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. AWS Support

CONCATéchec de fonctionnement avec VARCHAR entrées mixtes CHAR

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_ NOT _ FOUND : 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.

SQL|| échec de la concaténation avec les entrées et CHAR 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_ NOT _ FOUND : 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)
CHARet échec VARCHAR UNION de la requête

Message d'erreur : NOT_ SUPPORTED : Type de ruche non pris en charge : char (65536). CHARTypes pris en charge : 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 CHAR ou VARCHAR coercition

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

Modification de comportement suite à la conversion d'un horodatage avec fuseau horaire en varchar

Dans la version 2 du moteur Athena, la conversion de Timestamp avec un fuseau horaire en varchar a provoqué la modification de certains littéraux du fuseau horaire (par exemple, US/Eastern est devenu America/New_York). Ce comportement ne survient pas dans la version 3 du moteur Athena.

Le dépassement de date et d'horodatage génère une erreur

Message d'erreur : Débordement de Millis : XXX

Cause : les dates ISO 8601 n'ayant pas été vérifiées pour détecter tout dépassement dans la version 2 du moteur Athena, certaines dates ont produit 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 TIME non pris en charge

Message d'erreur : INVALIDLITERAL

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 _ ERROR : Impossible de sérialiser la colonne 'COLUMNZ'de type 'timestamp (3)' à la position X:Y

COLUMNZ est le nom de sortie de la colonne à l'origine du problème. Les chiffres X:Y indique 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 UNLOAD et CTAS requêtes incorrectes pour les tables Iceberg

Message d'erreur : précision d'horodatage incorrecte pour timestamp (6) ; la précision configurée est MILLISECONDS

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 fixer la précision de CAST l'horodatage à 6, comme dans l'CTASexemple 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 sous forme d'horodatage ou vice versa dans ORC les fichiers provoque désormais une erreur de fichier mal formé ORC

Message d'erreur : Erreur lors de l'ouverture du fichier malformé ORC « FILE (SPLITPOSITION) » divisé par Hive. Impossible de lire l'horodatage du SQL type à partir du ORC flux .long_type 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 : TYPEMISMATCH

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 AthenaCTAS. 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_ CAST _ ARGUMENT : 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. Par exemple, la requête suivante fonctionne dans la version 2 du moteur Athena, mais 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_iso8601()

Message d'erreur : aucun.

Cause : dans la version 2 du moteur Athena, la fonction to_iso8601 renvoie un horodatage avec le fuseau horaire même si la valeur transmise à la fonction n'inclut 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 chaque moteur.

Version 2 du moteur Athena :

# _col0 _col1
1

2023-02-24T00:00:00.000Z

2023-02-24T00:00:00.000Z

Version 3 du moteur Athena :

# _col0 _col1
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

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

Le premier paramètre at_timezone() 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 avancée du Pacifique (PDT) ou l'heure normale du Pacifique (PST).

Limites

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 de la version 2 du moteur Athena. Par conséquent, certaines requêtes peuvent différer en termes de latence ou de coût.

  • Connecteurs Trino et Presto : les connecteurs Trino et Presto 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 plus d’informations, consultez Utiliser la requête fédérée Amazon Athena.

  • Exécution tolérante aux pannes : l'exécution tolérante aux pannes 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.

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).

  • GROUPINGSETS— Le nombre maximum de tranches dans un ensemble de regroupement est de 2 048.

  • 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.