Athena-Engine-Version 2 - Amazon Athena
Neue Features und Verbesserungen Abwärtskompatible Änderungen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Athena-Engine-Version 2

Athena-Engine-Version 2 führte die folgenden Änderungen ein.

Neue Features und Verbesserungen

  • EXPLAIN und EXPLAIN ANALYZE – Sie können jetzt die EXPLAIN-Anweisung in Athena verwenden, um die Ausführungspläne für Ihre SQL-Abfragen anzuzeigen. Verwenden Sie EXPLAIN ANALYZE, um den verteilten Ausführungsplan für Ihre SQL-Abfragen und die Kosten für jeden Vorgang anzuzeigen. Weitere Informationen finden Sie unter Verwenden von EXPLAIN und EXPLAIN ANALYZE in Athena.

  • Verbundabfragen – Verbundabfragen werden in Athena-Engine-Version 2 unterstützt. Weitere Informationen finden Sie unter Nutzung von Amazon-Athena-Verbundabfrage.

  • Räumliche Funktionen – Mehr als 25 räumliche Funktionen wurden hinzugefügt. Weitere Informationen finden Sie unter Neue Geodaten-Funktionen in Athena-Engine-Version 2.

  • Verschachteltes Schema – Support für das Lesen verschachtelter Schemas hinzugefügt, wodurch die Kosten gesenkt werden.

  • Vorbereitete Anweisungen – Verwenden Sie vorbereitete Anweisungen für die wiederholte Ausführung derselben Abfrage mit unterschiedlichen Abfrageparametern. Eine vorbereitete Anweisung enthält Platzhalterparameter, deren Werte Sie zur Laufzeit übergeben. Vorbereitete Anweisungen verhindern SQL-Injections-Angriffe. Weitere Informationen finden Sie unter Verwenden von parametrisierten Abfragen.

  • Support der Schema-Evolution – Support für Schema-Evolution wurde hinzugefügt, um Daten im Parquet-Format zu unterstützen.

    • Support für das Lesen von Array-, Map- oder Zeilentypspalten von Partitionen, bei denen sich das Partitionsschema vom Tabellenschema unterscheidet, wurde hinzugefügt. Dies kann auftreten, wenn das Tabellenschema nach dem Erstellen der Partition aktualisiert wurde. Die geänderten Spaltentypen müssen kompatibel sein. Bei Zeilentypen können nachfolgende Felder hinzugefügt oder gelöscht werden, aber die entsprechenden Felder (nach Ordinalzahl) müssen denselben Namen haben.

    • ORC-Dateien können nun Strukturspalten mit fehlenden Feldern enthalten. Dadurch kann das Tabellenschema geändert werden, ohne die ORC-Dateien neu zu schreiben.

    • ORC-Strukturspalten werden nun nach Namen und nicht nach Ordinalnamen zugeordnet. Dadurch werden fehlende oder zusätzliche Strukturfelder in der ORC-Datei korrekt behandelt.

  • SQL-OFFSET – Die SQL-OFFSET-Klausel wird jetzt in SELECT-Anweisungen unterstützt. Weitere Informationen finden Sie unter SELECT.

  • UNLOAD-Anweisung – Sie können die UNLOAD-Anweisung verwenden, um die Ausgabe einer SELECT-Abfrage in die Formate PARQUET, ORC, AVRO und JSON zu schreiben. Weitere Informationen finden Sie unter UNLOAD.

Verbesserungen bei Gruppierung, Verknüpfung und Unterabfrage

  • Komplexe Gruppierung – Support für komplexe Gruppierungsoperationen wurde hinzugefügt.

  • Korrelierte Unterabfragen – Support für korrelierte Unterabfragen in IN-Prädikaten und für korrelierte Unterabfragen, die Zwang erfordern, wurde hinzugefügt.

  • CROSS-JOIN – Unterstützung für CROSS JOIN gegen LATERAL abgeleitete Tabellen hinzugefügt.

  • GROUPING SETS – Unterstützung für ORDER BY-Klauseln in Aggregationen für Abfragen hinzugefügt, die GROUPING SETS verwenden.

  • Lambda Ausdrücke – Unterstützung für die Dereferenzierung von Zeilenfeldern in Lambda-Ausdrücken hinzugefügt.

  • Null-Werte in Semijoins – Unterstützung für Nullwerte auf der linken Seite eines Semijoin hinzugefügt (dh ein IN-Prädikat mit Unterabfragen).

  • Räumliche Joins – Unterstützung für Räumliche Broadcast-Joins und Räumliche linke Joins hinzugefügt.

  • Auf Festplatte auslagern – Für speicherintensive Vorgänge INNER JOIN- und LEFT JOIN-Operationen lagert Athena Zwischenergebnisse auf die Festplatte aus. Dies ermöglicht die Ausführung von Abfragen, die große Mengen an Speicher benötigen.

  • INT für INTEGER – Unterstützung für INT hinzugefügt als Alias für den INTEGER-Datentyp.

  • Intervall-Typen – Unterstützung für das Umwandeln in INTERVAL-Typen hinzugefügt.

  • IPADDRESS – Es wurde ein neuer IPADDRESS Typ hinzugefügt, um IP-Adressen in DML-Abfragen darzustellen. Unterstützung für die Umwandlung zwischen VARBINARY-Typ und IPADDRESS-Typ Der IPADDRESS Typ wird in DDL-Abfragen nicht erkannt.

  • IS DISTINCT FROM – IS DISTINCT FROM-Unterstützung für die JSON- und IPADDRESS-Typen hinzugefügt.

  • Nullgleichsprüfungen – Gleichheitsüberprüfungen auf Nullwerte in ARRAY-, MAP- und ROW-Datenstrukturen werden jetzt unterstützt. Der Ausdruck ARRAY ['1', '3', null] = ARRAY ['1', '2', null] gibt beispielsweise false zurück. Zuvor gab ein null-Element die Fehlernachricht Vergleich nicht unterstützt zurück.

  • Zeilentyp-Zwang – Zwang zwischen Zeilentypen unabhängig von Feldnamen ist jetzt erlaubt. Bisher war ein Zeilentyp nur dann auf einen anderen umsetzbar, wenn der Feldname im Quelltyp mit dem Zieltyp übereinstimmte oder wenn der Zieltyp einen anonymen Feldnamen hatte.

  • Zeitsubtraktion – Implementiert Subtraktion für alle TIME- und TIMESTAMP-Typen.

  • Unicode – Unterstützung für Escape-Unicode-Sequenzen in Zeichenfolgen-Literalen hinzugefügt.

  • Verkettung von VARBINARY – Unterstützung für die Verkettung von VARBINARY-Werten hinzugefügt.

    Fensterwertfunktionen – Fensterwertfunktionen unterstützen jetzt IGNORE NULLS und RESPECT NULLS.

Zusätzliche Eingabetypen für Funktionen

Die folgenden Funktionen akzeptieren jetzt zusätzliche Eingabetypen. Weitere Informationen zu jeder Funktion finden Sie unter dem entsprechenden Link zur Presto-Dokumentation.

  • approx_distinct () – Die approx_distinct () unterstützt jetzt die folgenden Typen: INTEGER, SMALLINT, TINYINT, DECIMAL, REAL, DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, TIME, TIME WITH TIME ZONE, IPADDRESS und CHAR.

  • Avg(), sum() – Die avg()- und sum()-Aggregatfunktionen unterstützen nun den INTERVAL-Datentyp.

  • Lpad(), rpad() – Die lpad- und rpad-Funktionen funktionieren jetzt auf VARBINARY-Eingaben.

  • Min(), max() – Die min()- und max()-Aggregationsfunktionen erlauben nun unbekannte Eingabetypen zur Abfrageanalyse, sodass Sie die Funktionen mit NULL-Literalen verwenden können.

  • regexp_replace () – Variante der regexp_replace ()-Funktion hinzugefügt, die eine Lambda-Funktion für jede Ersetzung ausführen kann.

  • Sequence() – DATE-Varianten für die sequence()-Funktion hinzugefügt, einschließlich Variante mit einer impliziten Schrittweite von einem Tag.

  • ST_Area() – Die Geodatenfunktion ST_Area() unterstützt jetzt alle Geometrietypen.

  • Substr() – Die substr()-Funktion funktioniert jetzt auf VARBINARY-Eingaben.

  • zip_with() – Arrays mit nicht übereinstimmender Länge können jetzt mit zip_with() verwendet werden. Fehlende Positionen werden mit null gefüllt. Zuvor wurde ein Fehler ausgelöst, wenn Arrays unterschiedlicher Länge übergeben wurden. Diese Änderung kann es schwierig machen, zwischen Werten, die ursprünglich null waren, von Werten zu unterscheiden, die hinzugefügt wurden, um die Arrays auf die gleiche Länge aufzufüllen.

Erweiterte Funktionen

Die folgende Liste enthält Funktionen, die ab Version 2 der Athena-Engine neu sind. Die Liste enthält keine räumlichen Funktionen. Eine Liste der Geodatenfunktionen finden Sie unter Neue Geodaten-Funktionen in Athena-Engine-Version 2.

Weitere Informationen zu jeder Funktion finden Sie unter dem entsprechenden Link zur Presto-Dokumentation.

Aggregationsfunktionen

reduce_agg()

Array-Funktionen und -Operatoren

array_sort () – Variante dieser Funktion hinzugefügt, die eine Lambda-Funktion als Komparator nimmt.

ngrams()

Binäre Funktionen und Operatoren

from_big_endian_32()

from_ieee754_32()

from_ieee754_64()

hmac_md5()

hmac_sha1()

hmac_sha256()

hmac_sha512()

spooky_hash_v2_32()

spooky_hash_v2_64()

to_big_endian_32()

to_ieee754_32()

to_ieee754_64()

Datums- und Zeitfunktionen und -Operatoren

millisecond()

parse_duration()

to_milliseconds()

Zuordnungs-Funktionen und -Operatoren

multimap_from_entries()

Mathematische Funktionen und Operatoren

inverse_normal_cdf()

wilson_interval_lower()

wilson_interval_upper()

Quantildigest-Funktionen

Quantildigest-Funktionen und qdigest-Quantil-Digest-Typ hinzugefügt.

Zeichenfolgen-Funktionen und -Operatoren

hamming_distance()

split_to_multimap()

Leistungsverbesserungen

Die Leistung der folgenden Features hat sich in Athena-Engine-Version 2 verbessert.

Abfrageleistung

  • Broadcast-Beitrittleistung – Verbesserte Broadcast-Beitrittleistung durch Anwenden des dynamischen Partitionsschnitts im Worker-Knoten.

  • Tabellen mit Buckets – Verbesserte Leistung beim Schreiben in Bucket-Tabellen, wenn die zu schreibenden Daten bereits entsprechend partitioniert sind (z. B. wenn die Ausgabe von einem Bucket-Boot stammt).

  • DISTINCT – Verbesserte Leistung für einige Abfragen, die DISTINCT verwenden.

    Dynamische Filterung und Partitionsbereinigung – Verbesserungen erhöhen die Leistung und reduzieren die bei Abfragen gescannte Datenmenge.

  • Filter- und Projektionsoperationen – Filter- und Projektionsoperationen werden nun immer nach Möglichkeit von Spalten verarbeitet. Die Engine nutzt automatisch Wörterbuchkodierungen, wo sie wirksam sind.

  • Sammelbörsen – Verbesserte Leistung für Abfragen mit Sammelbörsen.

  • Globale Aggregationen – Verbesserte Leistung für einige Abfragen, die gefilterte globale Aggregationen durchführen.

  • GROUPING SETS, CUBE, ROLLUP – Verbesserte Leistung für Abfragen mit GROUPING SETS, CUBE oder ROLLUP, mit dem Sie mehrere Sätze von Spalten in einer einzelnen Abfrage aggregieren können.

  • Sehr selektive Filter – Die Leistung von Anfragen mit hochselektiven Filtern wurde verbessert.

  • Operationen JOIN und AGREGATE – Die Leistung von JOIN und AGGREGATE-Operationen wurde verbessert.

  • LIKE – Die Leistung von Abfragen, die LIKE-Prädikate für die Spalten von information_schema-Tabellen verwenden, wurde verbessert.

  • ORDER BY UND LIMIT – Verbesserte Pläne, Leistung und Speichernutzung für Abfragen mit ORDER BY und LIMIT, um unnötigen Datenaustausch zu vermeiden.

  • ORDER BY – ORDER BY-Operationen werden jetzt standardmäßig verteilt, sodass größere ORDER BY-Klauseln verwendet werden können.

  • Konvertierungen von Zeilentypen – Verbesserte Leistung bei der Konvertierung zwischen ROW-Typen.

  • Strukturelle Typen – Verbesserte Leistung von Abfragen, die Strukturtypen verarbeiten und Scan-, Join-, Aggregations- oder Tabellenschreibvorgänge enthalten.

  • Tabellen-Scans – Eine Optimierungsregel wurde eingeführt, um in bestimmten Fällen doppelte Tabellenscans zu vermeiden.

  • UNION – Verbesserte Leistung für UNION-Abfragen.

Abfrageplanungsleistung

  • Planungsleistung – Verbesserte Planungsleistung für Anfragen, die mehrere Tabellen mit einer großen Anzahl von Spalten verknüpfen.

  • Prädikatsauswertungen – Verbesserte Leistung bei der Prädikatauswertung während des Prädikaten-Pushdowns in der Planung.

  • Prädikat Pushdown-Unterstützung für Umwandlung – Prädikat-Pushdown für das Prädikat <column> IN <values list> unterstützen, bei dem Werte in der Werteliste umgewandelt werden müssen, um dem Spaltentyp zu entsprechen.

  • Prädikatinferenz und Pushdown – Prädikatinferenz und Pushdown erweitert für Abfragen, die ein Prädikat <symbol> IN <subquery> verwenden.

  • Zeitüberschreitungen – Es wurde ein Fehler behoben, der in seltenen Fällen Timeouts für die Abfrageplanung verursachen konnte.

Join-Leistung

  • Joins mit Map-Spalten – Verbesserte Leistung von Joins und Aggregationen, die Map-Spalten enthalten.

  • Joins mit ausschließlich Ungleichheitsbedingungen – Verbesserte Leistung von Joins mit ausschließlich Ungleichheitsbedingungen durch Verwendung eines verschachtelten Loop-Joins anstelle eines Hash-Joins.

  • Externe Joins – Der Join-Verteilungstyp wird jetzt automatisch für Abfragen mit äußeren Joins ausgewählt.

  • Bereich über Funktions-Joins – Verbesserte Leistung von Joins, bei denen die Bedingung ein Bereich über einer Funktion ist (z. B. a JOIN b ON b.x < f(a.x) AND b.x > g(a.x)).

  • Spill-to-disk – spill-to-disk Verwandte Fehler und Speicherprobleme wurden behoben, um die Leistung zu verbessern und Speicherfehler in -JOINOperationen zu reduzieren.

Unterabfrageleistung

  • Korrelierte EXIST-Unterabfragen – Verbesserte Leistung von korrelierten EXISTS-Unterabfragen.

  • Korrelierte Unterabfragen mit Gleichheiten – Verbesserte Unterstützung für korrelierte Unterabfragen, die Gleichheitsprädikate enthalten.

  • Korrelierte Unterabfragen mit Ungleichheiten – Verbesserte Leistung für korrelierte Unterabfragen, die Ungleichheiten enthalten.

  • Count(*) Aggregationen über Unterabfragen – Verbesserte Leistung von count(*)-Aggregationen über Unterabfragen mit bekannter konstanter Kardinalität.

  • Ausbreitung des äußeren Abfragefilters – Verbesserte Leistung korrelierter Unterabfragen, wenn Filter aus der äußeren Abfrage an die Unterabfrage weitergegeben werden können.

Funktions-Leistung

  • Aggregationsfensterfunktionen – Verbesserte Leistung von Aggregatfensterfunktionen.

  • element_at () – Verbesserte Leistung von element_at(), für Maps mit konstanter Zeit anstatt proportional zur Größe der Map.

  • Grouping() – Verbesserte Leistung für Abfragen mit grouping().

  • JSON-Umwandlung – Verbesserte Leistung bei der Umwandlung von JSON- auf ARRAY- oder MAP-Typen.

  • Rückgabefunktionen – Verbesserte Leistung von Funktionen, die Karten zurückgeben.

  • Map-to-map -Umwandlung – Die Leistung von map-to-map Casting wurde verbessert.

  • Min() und max() – Die min()- und max()-Funktionen wurden optimiert, um unnötige Objekterstellung zu vermeiden und somit den Garbage-Collection-Overhead zu reduzieren.

  • row_number () – Verbesserte Leistung und Speichernutzung für Abfragen mit row_number() gefolgt von einem Filter für die generierten Zeilennummern.

  • Fensterfunktionen – Verbesserte Leistung von Abfragen, die Fensterfunktionen mit identischen PARTITION BY- und ORDER BY-Klauseln.

  • Fensterfunktionen – Verbesserte Leistung bestimmter Fensterfunktionen (z. B. LAG), die ähnliche Spezifikationen haben.

Räumliche Leistung

  • Geometrieserialisierung – Die Serialisierungsleistung von Geometriewerten wurde verbessert.

  • Räumliche Funktionen – Die Leistung von ST_Intersects(), ST_Contains(), ST_Touches(), ST_Within(), ST_Overlaps(), ST_Disjoint(), transform_values(), ST_XMin(), ST_XMax(), ST_YMin(), ST_YMax(), ST_Crosses() und array_intersect() wurde verbessert.

  • ST_Distance () – Verbesserte Leistung von Join-Abfragen, die die ST_Distance()-Funktion verwenden.

  • ST_Intersection() – Optimierte ST_Intersection()-Funktion für Rechtecke, die an Koordinatenachsen ausgerichtet sind (z. B. Polygone, die von der ST_Envelope()- und bing_tile_polygon()-Funktionen produziert wurden).

Map-Funktionen

  • Verbesserte Leistung von Map tiefgestellt von O(n) auf O(1) in allen Fällen. Bisher nutzten nur Karten, die von bestimmten Funktionen und Lesern erstellt wurden, diese Verbesserung.

  • Funktionen map_from_entries() und map_entries() hinzugefügt.

Umwandlung

  • Es wurde die Möglichkeit hinzugefügt, in JSON von REAL, TINYINT oder SMALLINT umzuwandeln.

  • Sie können jetzt JSON auf ROW umwandeln, selbst wenn die JSON enthält nicht jedes Feld in der ROW aus.

  • Verbesserte Leistung von CAST(json_parse(...) AS ...).

  • Verbesserte Leistung bei der Umwandlung von JSON- auf ARRAY- oder MAP-Typen.

Neue JSON-Funktionen

Abwärtskompatible Änderungen

Unterbrechende Änderungen umfassen Fehlerbehebungen, Änderungen an räumlichen Funktionen, ersetzte Funktionen und die Einführung von Grenzwerten. Verbesserungen bei der ANSI-SQL-Konformität können Abfragen brechen, die von nicht standardmäßigem Verhalten abhängen.

Fehlerbehebungen

Die folgenden Änderungen korrigieren Verhaltensprobleme, die dazu führten, dass Abfragen erfolgreich ausgeführt wurden, aber mit ungenauen Ergebnissen.

  • fixed_len_byte_array Parquet-Spalten werden jetzt als DECIMAL akzeptiert – Abfragen von Parquet-Spalten vom Typ fixed_len_byte_array sind erfolgreich und geben korrekte Werte zurück, wenn sie im Parquet-Schema als DECIMAL annotiert sind. Fragt ab fixed_len_byte_array-Spalten ohne die DECIMAL-Notation schlägt mit einem Fehler fehl. Zuvor wurden Abfragen auf fixed_len_byte_array-Spalten ohne die DECIMAL-Anmerkung erfolgreich, aber unverständliche Werte zurückgegeben.

  • json_parse() ignoriert keine nachgestellten Zeichen mehr – Zuvor wurden Eingaben wie [1,2]abc würde erfolgreich als [1,2] geparst. Die Verwendung nachgestellter Zeichen erzeugt nun die Fehlermeldung '[1, 2] abc' kann nicht in JSON konvertiert werden.

  • Round() Dezimalgenauigkeit korrigiert – round(x, d) rundet x jetzt korrekt, wenn x ein DEZIMAL ist oder wenn x ein DEZIMAL mit Skala 0 und d eine negative Ganzzahl ist. Zuvor trat in diesen Fällen keine Rundung auf.

  • round(x, d) and truncate(x, d) – Der Parameter d in der Signatur von Funktionen round(x, d) und truncate(x, d) ist jetzt vom Typ INTEGER. Zuvor konnte d vom Typ BIGINT sein.

  • Map() mit doppelten Schlüsseln – map() löst jetzt einen Fehler bei doppelten Schlüsseln aus, anstatt eine beschädigte Karte im Hintergrund zu erzeugen. Abfragen, die derzeit Kartenwerte mit doppelten Schlüsseln erstellen, schlagen jetzt mit einem Fehler fehl.

  • map_from_entries() löst einen Fehler mit Nulleinträgen aus – map_from_entries()löst nun einen Fehler aus, wenn das Eingabe-Array einen Nulleintrag enthält. Abfragen, die eine Karte erstellen, indem NULL als Wert übergeben wird, schlagen jetzt fehl.

  • Tabellen – Tabellen mit nicht unterstützten Partitionstypen können nicht mehr erstellt werden.

  • Verbesserte numerische Stabilität in statistischen Funktionen – Die numerische Stabilität der statistischen Funktionen corr(), covar_samp(), regr_intercept() und regr_slope() wurde verbessert.

  • TIMESTAMP-Präzision, die in Parquet definiert ist, wird jetzt eingehalten – Die Präzision von TIMESTAMP-Werten und die Genauigkeit, die für die TIMESTAMP im Parquet-Schema muss nun übereinstimmen. Nicht übereinstimmende Präzisionen führen zu falschen Zeitstempeln.

  • Zeitzoneninformation – Zeitzoneninformationen werden jetzt mithilfe des java.time-Pakets des Java 1.8 SDK berechnet.

  • SUMME der Datentypen INTERVAL_DAY_TO_SECOND und INTERVAL_YEAR_TO_MONTH – Sie können SUM(NULL) nicht mehr direkt verwenden. Um SUM(NULL) zu benutzen, wandeln Sie NULL in einen Datentyp wie BIGINT, DECIMAL, REAL, DOUBLE, INTERVAL_DAY_TO_SECOND oder INTERVAL_YEAR_TO_MONTH um.

Änderungen an Geodatenfunktionen

Folgende Änderungen an räumlichen Funktionen wurden vorgenommen.

  • Änderungen der Funktionsnamen – Einige Funktionsnamen haben sich geändert. Weitere Informationen finden Sie unter Änderungen des Geodaten-Funktionennamens in Athena-Engine-Version 2.

  • VARBINARY – VARBINARY wird nicht mehr direkt für die Eingabe in Geodatenfunktionen unterstützt. Um beispielsweise die Fläche einer Geometrie direkt zu berechnen, muss die Geometrie nun entweder im VARCHAR- oder im GEOMETRY-Format eingegeben werden. Die Problemumgehung besteht darin, Transformationsfunktionen zu verwenden, wie in den folgenden Beispielen.

    • Um ST_area() zum Berechnen der Fläche für die VARBINARY-Eingabe im Well-Known-Binary-(WKB)-Format zu verwenden, übergeben Sie die Eingabe zuerst an ST_GeomFromBinary(), zum Beispiel:

      ST_area(ST_GeomFromBinary(<wkb_varbinary_value>))

    • Um ST_area() zum Berechnen der Fläche für die VARBINARY-Eingabe im Legacy-Binärformat zu verwenden, übergeben Sie dieselbe Eingabe zuerst an die ST_GeomFromLegacyBinary()-Funktion, zum Beispiel:

      ST_area(ST_GeomFromLegacyBinary(<legacy_varbinary_value>))

  • ST_ExteriorRing() und ST_Polygon() – ST_ExteriorRing() und akzeptieren ST_Polygon() jetzt nur Polygone als Eingaben. Zuvor akzeptierten diese Funktionen fälschlicherweise andere Geometrien.

  • ST_Distance() – Wie von der SQL/MM-Spezifikation erforderlich, gibt die ST_Distance()-Funktion jetzt NULL zurück, wenn eine der Eingaben eine leere Geometrie ist. Zuvor wurde NaN zurückgegeben.

ANSI-SQL-Compliance

Die folgenden Syntax- und Verhaltensprobleme wurden entsprechend dem ANSI-SQL-Standard korrigiert.

  • Cast()-Operationen – Cast()-Operationen von REAL oder DOUBLE nach DECIMAL entsprechen nun dem SQL-Standard. Zum Beispiel hat cast (double '100000000000000000000000000000000' as decimal(38)) zuvor 100000000000000005366162204393472 zurückgegeben, jetzt aber 100000000000000000000000000000000.

  • JOIN ... USING – JOIN ... USING entspricht jetzt der Standard-SQL-Semantik. Zuvor musste JOIN ... USING den Tabellennamen in Spalten qualifizieren, und die Spalte aus beiden Tabellen war in der Ausgabe vorhanden. Tabellenqualifikationen sind jetzt ungültig und die Spalte ist nur einmal in der Ausgabe vorhanden.

  • Literale vom Typ ROW entfernt – Das Literalformat des ROW-TypsROW<int, int>(1, 2) wird nicht mehr unterstützt. Verwenden Sie stattdessen die ROW(1 int, 2 int)-Syntax.

  • Semantik für gruppierte Aggregation – Gruppierte Aggregationen verwenden IS NOT DISTINCT FROM-Semantik statt Gleichheitssemantik. Gruppierte Aggregationen geben jetzt korrekte Ergebnisse zurück und zeigen eine verbesserte Leistung beim Gruppieren nach NaN-Gleitkommawerten. Gruppierung auf Karten-, Listen- und Zeilentypen, die Nullen enthalten, wird unterstützt.

  • Typen mit Anführungszeichen sind nicht mehr zulässig – Gemäß ANSI-SQL-Standard dürfen Datentypen nicht mehr in Anführungszeichen eingeschlossen werden. SELECT "date" '2020-02-02' ist beispielsweise keine gültige Abfrage mehr. Verwenden Sie stattdessen die SELECT date '2020-02-02'-Syntax.

  • Zugriff auf anonyme Zeilenfelder – Auf anonyme Zeilenfelder kann nicht mehr mit der Syntax [.field0, .field1, ...] zugegriffen werden.

  • Komplexe Gruppierungsvorgänge – Die komplexen Gruppierungsoperationen GROUPING SETS, CUBE und ROLLUP unterstützen keine Gruppierung von Ausdrücken, die aus Eingabespalten bestehen. Es sind nur Spaltennamen zulässig.

Ersetzte Funktionen

Die folgenden Funktionen werden nicht mehr unterstützt und wurden durch Syntax ersetzt, die dieselben Ergebnisse liefert.

Einschränkungen

Die folgenden Grenzwerte wurden in Athena-Engine-Version 2 eingeführt, um sicherzustellen, dass Abfragen aufgrund von Ressourcenbeschränkungen nicht fehlschlagen. Diese Grenzwerte sind von Benutzern nicht konfigurierbar.

  • Anzahl der Ergebniselemente – Die Anzahl der Ergebniselemente n ist für die folgenden Funktionen auf 10.000 oder weniger beschränkt: min(col, n), max(col, n), min_by(col1, col2, n) und max_by(col1, col2, n).

  • GROUPING SETS – Die maximale Anzahl von Slices in einem Gruppierungssatz ist 2048.

  • Maximale Zeilenlänge der Textdatei – Die standardmäßige maximale Zeilenlänge für Textdateien beträgt 200 MB.

  • Sequenzfunktion maximale Ergebnisgröße – Die maximale Ergebnisgröße einer Sequenzfunktion beträgt 50000 Einträge. Zum Beispiel ist SELECT sequence(0,45000,1) erfolgreich, aber SELECT sequence(0,55000,1) schlägt mit der Fehlermeldung fehl. Das Ergebnis der Sequenzfunktion darf nicht mehr als 50000 Einträge haben. Diese Beschränkung gilt für alle Eingabetypen für Sequenzfunktionen, auch für Zeitstempel.