Version 2 du moteur Athena

Améliorations et nouvelles fonctions

Évolutions

EXPLAINet EXPLAINANALYZE— Vous pouvez utiliser l'EXPLAINinstruction dans Athena pour afficher le plan d'exécution de vos SQL requêtes. Permet EXPLAIN ANALYZE de visualiser le plan d'exécution distribué pour vos SQL requêtes et le coût de chaque opération. Pour plus d’informations, consultez Utiliser EXPLAIN et EXPLAIN ANALYZE dans Athéna.

Requêtes fédérées – Les requêtes fédérées sont prises en charge dans la version 2 du moteur Athena. Pour plus d’informations, consultez Utiliser la requête fédérée Amazon Athena.

Fonctions géospatiales – Plus de 25 fonctions géospatiales ont été ajoutées. Pour plus d’informations, consultez Nouvelles fonctions géospatiales de la version 2 du moteur Athena.

Schéma imbriqué – La prise en charge de la lecture de schémas imbriqués a été ajoutée, réduisant ainsi les coûts.

Instructions préparés – Utilisez des instructions préparées pour l'exécution répétée d'une même requête avec des paramètres de requête différents. Une déclaration préparée contient des paramètres fictifs dont vous transmettez les valeurs au moment de l'exécution. Les déclarations préparées aident à prévenir les attaques SQL par injection. Pour plus d’informations, consultez Utiliser des requêtes paramétrées.

Prise en charge d'évolution de schéma – La prise en charge de l'évolution du schéma a été ajoutée pour les données au format Parquet.

SQLOFFSET— La SQL OFFSET clause est désormais soutenue dans les SELECT déclarations. Pour plus d’informations, consultez SELECT.

UNLOADinstruction — Vous pouvez utiliser l'UNLOADinstruction pour écrire le résultat d'une SELECT requête aux JSON formats PARQUET ORCAVRO,, et. Pour plus d’informations, consultez UNLOAD.

Regroupement complexe – Ajout de la prise en charge des opérations de regroupement complexes.

Sous-requêtes corrélées – Ajout de la prise en charge des sous-requêtes corrélées dans les prédicats IN et des sous-requêtes corrélées nécessitant des forçages de type.

CROSSJOIN— Ajout du support pour CROSS JOIN les tables LATERAL dérivées.

GROUPINGSETS— Ajout de la prise en charge des ORDER BY clauses dans les agrégations pour les requêtes qui utilisentGROUPING SETS.

Expressions Lambda – Ajout de la prise en charge du déréférencement des champs de ligne dans les expressions Lambda.

Valeurs nulles dans les semi-jointures – Ajout de la prise en charge des valeurs nulles sur le côté gauche d'une semi-jointure (c'est-à-dire un prédicat IN avec des sous-requêtes).

Jointures spatiales – Ajout de la prise en charge des jointures spatiales de diffusion et des jointures spatiales gauches.

Déversement sur le disque – Pour les opérations INNER JOIN et LEFT JOIN à nécessitant beaucoup de mémoire, Athena décharge les résultats des opérations intermédiaires sur le disque. Cela permet l'exécution de requêtes nécessitant de grandes quantités de mémoire.

INTfor INTEGER — Ajout du support pour INT en tant qu'alias pour le type de INTEGER données.

INTERVALtypes — Ajout du support pour le casting en INTERVAL types.

IPADDRESS— Ajout d'un nouveau IPADDRESS type pour représenter les adresses IP dans les DML requêtes. Ajout de la prise en charge de la conversion entre le type VARBINARY et le type IPADDRESS. Le IPADDRESS type n'est pas reconnu dans les DDL requêtes.

IS DISTINCT FROM — Ajout du IS DISTINCT FROM support pour les IPADDRESS types JSON et.

Contrôles d'égalité des nuls – Les contrôles d'égalité pour les valeurs nulles dans les structures de données ARRAY, MAP et ROW sont désormais pris en charge. Par exemple, l'expression ARRAY ['1', '3', null] = ARRAY ['1', '2', null] renvoie false. Auparavant, un élément nul renvoyait le message d'erreur comparison not supported (comparaison non prise en charge).

Forçage de type de rangée – La forçage entre les types de lignes sans tenir compte des noms de champs est maintenant autorisée. Auparavant, un type de ligne était forçable avec un autre type de ligne uniquement si le nom du champ dans le type source correspondait au type cible, ou si le type cible avait un nom de champ anonyme.

Soustraction temporelle – Mise en œuvre de la soustraction pour tous les types TIME et TIMESTAMP.

Unicode – Ajout de la prise en charge des séquences Unicode échappées dans les libellés chaînes.

VARBINARYconcaténation — Ajout du support pour la concaténation de valeurs. VARBINARY

Fonctions de fenêtrage – Les fonctions de valeur de fenêtre prennent désormais en charge IGNORE NULLS et RESPECT NULLS.

approx_distinct() – La fonction approx_distinct () prend désormais en charge les types suivants : INTEGER, SMALLINT, TINYINT, DECIMAL, REAL, DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, TIME, TIME WITH TIME ZONE, IPADDRESS et CHAR.

Avg(), sum() – Les fonctions d'agrégation avg() et sum() prennent désormais en charge le type de données INTERVAL.

Lpad(), rpad() – Les fonctions lpad et rpad fonctionnent maintenant sur les entrées VARBINARY.

Min(), max() – Les fonctions d'agrégation min() and max() autorisent désormais les types d'entrée inconnus au moment de l'analyse de la requête afin que vous puissiez utiliser les fonctions avec des libellés NULL.

regexp_replace() – Ajout d'une variante de la fonction regexp_replace() qui peut exécuter une fonction Lambda pour chaque remplacement.

Sequence() – Ajout de variantes DATE pour la fonction sequence(), y compris une variante avec un incrément implicite d'un jour.

ST_Area() – La fonction géospatiale ST_Area() prend désormais en charge tous les types de géométrie.

Substr() – La fonction substr fonctionne désormais sur les entrées VARBINARY.

zip_with() – Les tableaux dont la longueur n'est pas adaptée peuvent maintenant être utilisés avec zip_with(). Les positions manquantes sont remplies avec le caractère nul. Auparavant, une erreur était générée lorsque des tableaux de longueurs différentes étaient transmis. Cette modification peut rendre difficile la distinction entre les valeurs qui étaient nulles à l'origine et celles qui ont été ajoutées pour compléter les tableaux à la même longueur.

Performance de jointure de diffusion – Amélioration des performances de jointure de diffusion en appliquant une taille dynamique de partition dans le composant master.

Tables compartimentées – Amélioration des performances pour l'écriture dans des tables compartimentées lorsque les données écrites sont déjà partitionnées de manière appropriée (par exemple, lorsque la sortie provient d'une jointure compartimentée).

DISTINCT— Performances améliorées pour certaines requêtes utilisantDISTINCT.

Filtrage dynamique et élagage des partitions – Ces améliorations permettent d'augmenter les performances et de réduire la quantité de données analysées dans les requêtes.

Opérations de filtrage et projection – Les opérations de filtrage et de projection sont désormais toujours traitées par des colonnes si possible. Le moteur tire automatiquement parti des codages de dictionnaire lorsqu'ils sont efficaces.

Regroupement des échanges – Amélioration des performances pour les requêtes avec regroupement des échanges.

Agrégations globales – Amélioration des performances pour certaines requêtes qui effectuent des agrégations globales filtrées.

GROUPINGSETS,CUBE, ROLLUP — Performances améliorées pour les requêtes impliquant CUBE ou GROUPING SETSROLLUP, que vous pouvez utiliser pour agréger plusieurs ensembles de colonnes en une seule requête.

Filtres hautement sélectifs – Amélioration des performances des requêtes avec des filtres hautement sélectifs.

JOINet AGGREGATE opérations — Les performances JOIN et les AGGREGATE opérations ont été améliorées.

LIKE— Amélioration des performances des requêtes qui utilisent des LIKE prédicats sur les colonnes des information_schema tables.

ORDERBY et LIMIT — Plans, performances et utilisation de la mémoire améliorés pour les requêtes impliquant ORDER BY et LIMIT afin d'éviter des échanges de données inutiles.

ORDERBY : les ORDER BY opérations sont désormais distribuées par défaut, ce qui permet d'utiliser ORDER BY des clauses plus volumineuses.

ROWconversions de types : performances améliorées lors de la conversion entre ROW types.

Types structurels – Amélioration des performances des requêtes qui traitent des types structurels et qui contiennent des balayages, des jointures, des agrégations ou des écritures de table.

Analyse de table – Une règle d'optimisation a été introduite pour éviter les analyses de tables en double dans certains cas.

UNION— Performances améliorées pour les UNION requêtes.

Performances de planification – Amélioration des performances de planification des requêtes qui joignent plusieurs tables avec un grand nombre de colonnes.

Évaluations des prédicats – Amélioration des performances d'évaluation des prédicats lors du refoulement des prédicats dans la planification.

Support du pushdown du prédicat pour le casting — Support du pushdown du prédicat pour le <column> IN <values list> prédicat où les valeurs de la liste de valeurs doivent être tranchées pour correspondre au type de colonne.

Inférence de prédicat et pushdown : inférence de prédicat et pushdown étendus pour les requêtes utilisant un <symbol> IN <subquery> prédicat.

Délais – Correction d'un bug qui pouvait, dans de rares cas, entraîner des délais d'expiration de la planification des requêtes.

Jointures avec des colonnes mappées – Amélioration des performances des jointures et des agrégations qui incluent des colonnes mappées.

Jointures avec uniquement des conditions de non-égalité – Amélioration des performances des jointures avec uniquement des conditions de non-égalité en utilisant une jointure par boucle imbriquée au lieu d'une jointure par hachage.

Jointures externes – Le type de distribution de jointure est désormais automatiquement sélectionné pour les requêtes impliquant des jointures externes.

Jointure de plage sur une fonction – Amélioration des performances des jointures lorsque la condition est une plage sur une fonction (par exemple, a JOIN b ON b.x < f(a.x) AND b.x > g(a.x)).

S pill-to-disk — Correction de bogues et de problèmes de mémoire spill-to-disk connexes afin d'améliorer les performances et de réduire les erreurs de mémoire lors JOIN des opérations.

EXISTSSous-requêtes corrélées : amélioration des performances des sous-requêtes corréléesEXISTS.

Sous-requêtes corrélées avec des égalités – Amélioration de la prise en charge des sous-requêtes corrélées contenant des prédicats d'égalité.

Sous-requêtes corrélées avec des inégalités – Amélioration des performances des sous-requêtes corrélées qui contiennent des inégalités.

Agrégations Count(*) sur les sous-requêtes – Amélioration des performances des agrégations count(*) sur des sous-requêtes avec une cardinalité constante connue.

Propagation du filtre de requête externe – Amélioration des performances des sous-requêtes corrélées lorsque les filtres de la requête externe peuvent être propagés à la sous-requête.

Fonctions de fenêtrage d'agrégation – Amélioration des performances des fonctions de fenêtrage d'agrégation.

element_at() – Amélioration des performances de element_at() pour les mappages afin que le temps soit constant plutôt que proportionnel à la taille du mappage.

Grouping() – Amélioration des performances des requêtes impliquant grouping().

JSONcasting — Amélioration des performances du casting de MAP types JSON à ARRAY ou.

Fonctions de retour de mappage – Amélioration des performances des fonctions de retour de mappage.

ap-to-map Casting M — Amélioration des performances du map-to-map casting.

Min() et max() – Les fonctions min() et max() ont été optimisées pour éviter la création inutile d'objets, réduisant ainsi les coûts du récupérateur de mémoire.

row_number() – Amélioration des performances et de l'utilisation de la mémoire pour les requêtes utilisant row_number() suivi d'un filtre sur les numéros de ligne générés.

Fonctions de fenêtrage – Amélioration des performances des requêtes contenant des fonctions de fenêtrage avec des clauses PARTITION BY et ORDER BY identiques.

Fonctions de fenêtrage – Amélioration des performances de certaines fonctions de fenêtrage (par exemple, LAG) qui ont des spécifications similaires.

Sérialisation de la géométrie – Amélioration des performances de sérialisation des valeurs géométriques.

Fonctions géospatiales – Amélioration des performances de ST_Intersects(), ST_Contains(), ST_Touches(), ST_Within(), ST_Overlaps(), ST_Disjoint(), transform_values(), ST_XMin(), ST_XMax(), ST_YMin(), ST_YMax(), ST_Crosses() et array_intersect().

ST_Distance() – Amélioration des performances des requêtes de jointure impliquant la fonction ST_Distance().

ST_Intersection() – Optimisation de la fonction ST_Intersection() pour les rectangles alignés sur les axes de coordonnées (par exemple, les polygones produits par les fonctions ST_Envelope() et bing_tile_polygon()).

Amélioration des performances de l'indice de mappage de O(n) à O(1) dans tous les cas. Auparavant, seules les mappages produits par certaines fonctions et lecteurs ont profité de cette amélioration.

Ajout des fonctions map_from_entries() et map_entries().

Ajout de la possibilité de forçer vers JSON à partir de REAL, TINYINT ou SMALLINT.

Vous pouvez désormais forçer JSON vers ROW même si le code JSON ne contient pas tous les champs de la ROW.

Amélioration des performances de CAST(json_parse(...) AS ...).

Amélioration des performances du forçage du type JSON au type ARRAY ou MAP.

is_json_scalar()

Les colonnes de parquet fixed_len_byte_array sont désormais acceptées comme DECIMAL : les requêtes sur les colonnes de type parquet fixed_len_byte_array aboutissent et renvoient des valeurs correctes si elles sont annotées comme dans le schéma de parquet. DECIMAL Les requêtes sur des colonnes fixed_len_byte_array sans annotation DECIMAL échouent avec une erreur. Auparavant, les requêtes sur des fixed_len_byte_array colonnes sans DECIMAL annotation aboutissaient mais renvoyaient des valeurs incompréhensibles.

json_parse() n'ignore plus les caractère de droite – Auparavant, les entrées telles que [1,2]abc étaient analysées avec succès en tant que [1,2]. L'utilisation de caractères de fin produit désormais le message d'erreur Impossible de convertir '[1, 2] abc' en. JSON

Correction de la précision décimale arrondie () : arrondit round(x, d) désormais correctement x quand x est a DECIMAL ou quand x est a DECIMAL avec une échelle de 0 et d est un entier négatif. Auparavant, aucun arrondissement n'était effectué dans ces cas.

round(x, d) et truncate(x, d) – Le paramètre d dans la signature des fonctions round(x, d) et truncate(x, d) est maintenant de type INTEGER. Précédemment, d pourrait être de type BIGINT.

Map() avec des clés dupliquées – map() déclenche désormais une erreur en cas de clés dupliquées au lieu de produire silencieusement un mappage corrompu. Les requêtes qui construisent actuellement des valeurs de mappage en utilisant des clés dupliquées échouent désormais avec une erreur.

map_from_entries() déclenche une erreur avec des entrées nulles – map_from_entries() déclenche désormais une erreur lorsque le tableau d'entrée contient une entrée nulle. Requêtes qui construisent un mappage en passant NULL comme une valeur échouent maintenant.

Tables – Les tables qui ont des types de partition non pris en charge ne peuvent plus être créées.

Amélioration de la stabilité numérique des fonctions statistiques – La stabilité numérique des fonctions statistiques corr(), covar_samp(), regr_intercept() et regr_slope() a été améliorée.

TIMESTAMPla précision définie dans le parquet est désormais respectée — La précision des TIMESTAMP valeurs et la précision définie pour la TIMESTAMP colonne dans le schéma Parquet doivent désormais correspondre. Les précisions non correspondantes entraînent des horodatages incorrects.

Informations de fuseau horaire — Les informations de fuseau horaire sont désormais calculées à l'aide du package java.time de Java 1.8. SDK

SUMdes MONTH types de données INTERVAL _ DAY _TO_ SECOND et INTERVAL _ YEAR _TO_ — Vous ne pouvez plus les utiliser directement. SUM(NULL) Pour utiliser SUM(NULL), forcez NULL vers un type de données comme BIGINT, DECIMAL, REAL, DOUBLE, INTERVAL_DAY_TO_SECOND ou INTERVAL_YEAR_TO_MONTH.

Modifications des noms des fonctions – Certains noms de fonctions ont changé. Pour plus d’informations, consultez Modifications des noms des fonctions géospatiales dans la version 2 du moteur Athena.

VARBINARYinput — Le VARBINARY type n'est plus directement pris en charge pour l'entrée dans les fonctions géospatiales. Par exemple, pour calculer directement la surface d'une géométrie, celle-ci doit maintenant être saisie au format VARCHAR ou GEOMETRY. La solution de contournement consiste à utiliser les fonctions de transformation, comme dans les exemples suivants.

ST_ ExteriorRing () et ST_Polygon () — ST_ExteriorRing()et n'acceptent ST_Polygon()désormais que les polygones en entrée. Auparavant, ces fonctions acceptaient par erreur d'autres géométries.

ST_Distance () — Comme l'exige la spécification SQL /MM, la ST_Distance()fonction renvoie désormais NULL si l'une des entrées est une géométrie vide. Auparavant, NaN était renvoyé.

Opérations Cast () — Les opérations Cast () sont actuellement REAL ou DOUBLE DECIMAL seront désormais conformes à la SQL norme. Par exemple, cast (double '100000000000000000000000000000000' as decimal(38)) retournait auparavant 100000000000000005366162204393472, mais retourne maintenant 100000000000000000000000000000000.

JOIN... USING— JOIN ... USING est désormais conforme à la SQL sémantique standard. Auparavant, JOIN ... USING nécessitait de qualifier le nom de la table en colonnes, et la colonne des deux tables était présente dans le résultat. Les qualifications de la table sont maintenant invalides et la colonne n'est présente qu'une seule fois dans le résultat.

ROWlittéraux de type supprimés — Le format de ROW type littéral n'ROW<int, int>(1, 2)est plus pris en charge. Utilisez la syntaxe ROW(1 int, 2 int) à la place.

Sémantique d'agrégation groupée – Les agrégations groupées utilisent la sémantique IS NOT DISTINCT FROM plutôt que sémantique d'égalité. LLes agrégations groupées renvoient désormais des résultats corrects et présentent des performances améliorées lors du regroupement sur des valeurs à virgule flottante NaN. Le regroupement sur les types de mappage, de liste et de ligne qui contiennent des valeurs nulles est pris en charge.

Les types entre guillemets ne sont plus autorisés : conformément à la ANSI SQL norme, les types de données ne peuvent plus être placés entre guillemets. Par exemple, SELECT "date" '2020-02-02' n'est plus une requête valide. À la place, utilisez la syntaxe SELECT date '2020-02-02'.

Accès aux champs de ligne anonymes – Les champs de ligne anonymes ne sont plus accessibles à l'aide de la syntaxe [.field0, .field1, ...].

Opérations de regroupement complexes – Les opérations de regroupement complexes, GROUPING SETS, CUBE et ROLLUP ne prennent pas en charge le regroupement sur des expressions composées de colonnes d'entrée. Seuls les noms de colonnes sont autorisés.

information_schema.__internal_partitions__ – L'utilisation de __internal_partitions__ n'est plus prise en charge par le moteur Athena version 2. Pour une syntaxe équivalente, utilisez SELECT * FROM "<table_name>$partitions" ou SHOW PARTITIONS. Pour plus d’informations, consultez Répertorier les partitions d'une table spécifique.

Fonctions géospatiales remplacées – Pour une liste des fonctions géospatiales dont les noms ont changé, voirModifications des noms des fonctions géospatiales dans la version 2 du moteur Athena.

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.