Athena-Engine-Version 2 - Amazon Athena

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

  • EXPLAINund EXPLAINANALYZE— Sie können die EXPLAIN Anweisung in Athena verwenden, um den Ausführungsplan für Ihre SQL Abfragen einzusehen. EXPLAIN ANALYZEDient zum Anzeigen des verteilten Ausführungsplans für Ihre SQL Abfragen und der Kosten für jeden Vorgang. 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 Verwenden Sie Amazon Athena Federated Query.

  • 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 helfen dabei, SQL Injektionsangriffe zu verhindern. Weitere Informationen finden Sie unter Verwenden Sie parametrisierte 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.

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

    • ORCStrukturspalten werden jetzt nach Namen und nicht nach Ordinalzahlen zugeordnet. Dadurch werden fehlende oder zusätzliche Strukturfelder in der ORC Datei korrekt behandelt.

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

  • UNLOADAnweisung — Sie können die UNLOAD Anweisung verwenden, um die Ausgabe einer SELECT Abfrage in die JSON FormatePARQUET, ORCAVRO, und 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.

  • CROSSJOIN— Unterstützung für CROSS JOIN gegen LATERAL abgeleitete Tabellen hinzugefügt.

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

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

  • INTfor INTEGER — Unterstützung für INT als Alias für den INTEGER Datentyp hinzugefügt.

  • INTERVALtypes — Unterstützung für die Umwandlung in INTERVAL Typen hinzugefügt.

  • IPADDRESS— Ein neuer IPADDRESS Typ zur Darstellung von IP-Adressen in DML Abfragen wurde hinzugefügt. Unterstützung für die Umwandlung zwischen VARBINARY-Typ und IPADDRESS-Typ Der IPADDRESS Typ wird in DDL Abfragen nicht erkannt.

  • IS DISTINCT FROMIS DISTINCT FROM Unterstützung für die IPADDRESS Typen JSON und 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.

  • VARBINARYVerkettung — Unterstützung für die Verkettung von Werten hinzugefügt. VARBINARY

    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 verwenden. DISTINCT

    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.

  • GROUPINGSETS,CUBE, ROLLUP — Verbesserte Leistung bei AbfragenGROUPING SETS, die CUBE oder beinhaltenROLLUP, mit denen Sie mehrere Gruppen von Spalten in einer einzigen Abfrage zusammenfassen können.

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

  • JOINund AGGREGATE Operationen — Die Leistung von JOIN und AGGREGATE -Operationen wurde verbessert.

  • LIKE— Die Leistung von Abfragen, die LIKE Prädikate für Tabellenspalten verwenden, wurde verbessert. information_schema

  • ORDERBY und LIMIT — Verbesserte Pläne, Leistung und Speichernutzung für Abfragen, bei denen unnötiger Datenaustausch erforderlich istLIMIT, ORDER BY und um diese zu vermeiden.

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

  • ROWTypkonvertierungen — 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 bei 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 Casting — Unterstützen Sie das Prädikat Pushdown für das <column> IN <values list> Prädikat, bei dem Werte in der Werteliste eine Umwandlung erfordern, damit sie dem Spaltentyp entsprechen.

  • Prädikat-Inferenz und Pushdown — Erweiterte Prädikat-Inferenz und Pushdown für Abfragen, die a verwenden <symbol> IN <subquery> Prädikat.

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

  • S pill-to-disk — spill-to-disk Verwandte Fehler und Speicherprobleme wurden behoben, um die Leistung zu verbessern und Speicherfehler bei JOIN Vorgängen zu reduzieren.

Unterabfrageleistung

  • Korrelierte EXISTS Unterabfragen — Verbesserte Leistung EXISTS korrelierter 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().

  • JSONCasting — Die Leistung beim Casting von JSON Typen nach oder wurde verbessert. ARRAY MAP

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

  • ap-to-map M-Casting — 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. Durch Verbesserungen der ANSI SQL Konformität können Abfragen, die von einem nicht standardmäßigen Verhalten abhängig waren, nicht mehr funktionieren.

Fehlerbehebungen

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

  • fixed_len_byte_array Parkettspalten werden jetzt akzeptiert als DECIMAL — Abfragen auf Parquet-Spalten des Typs sind fixed_len_byte_array erfolgreich und geben korrekte Werte zurück, wenn sie wie im Parquet-Schema annotiert sind. DECIMAL Fragt ab fixed_len_byte_array-Spalten ohne die DECIMAL-Notation schlägt mit einem Fehler fehl. Bisher waren Abfragen von fixed_len_byte_array Spalten ohne die Anmerkung erfolgreich, lieferten aber unverständliche Werte zurück. DECIMAL

  • json_parse() ignoriert keine nachgestellten Zeichen mehr – Zuvor wurden Eingaben wie [1,2]abc würde erfolgreich als [1,2] geparst. Wenn Sie nachstehende Zeichen verwenden, wird jetzt die Fehlermeldung „[1, 2] abc' kann nicht konvertiert werden zu“ angezeigt. JSON

  • Die Dezimalgenauigkeit von Round () wurde korrigiert — rundet round(x, d) jetzt korrekt ab, x wann A x ist DECIMAL oder wann A DECIMAL mit der Skala 0 x ist und eine negative Ganzzahl d 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üsselnmap() 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 ausmap_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.

  • TIMESTAMPDie in Parquet definierte Genauigkeit wird jetzt respektiert — Die Genauigkeit der TIMESTAMP Werte und die für die TIMESTAMP Spalte im Parquet-Schema definierte Genauigkeit müssen jetzt übereinstimmen. Nicht übereinstimmende Präzisionen führen zu falschen Zeitstempeln.

  • Zeitzoneninformationen — Zeitzoneninformationen werden jetzt mit dem Paket java.time von Java 1.8 berechnet. SDK

  • SUMder MONTH Datentypen INTERVAL _ DAY _TO_ SECOND und _ INTERVAL YEAR _TO_ — Sie können sie nicht mehr direkt verwenden. SUM(NULL) 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.

  • VARBINARYinput — Der VARBINARY Typ wird nicht mehr direkt für die Eingabe von 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 die Fläche für die VARBINARY Eingabe im Format Well-known Binary (WKB) zu berechnen, übergeben Sie ST_area() die Eingabe an ST_GeomFromBinary() first, 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 in der SQL/MM-Spezifikation vorgeschrieben, gibt die ST_Distance()Funktion jetzt zurück, NULL ob es sich bei einer der Eingaben um eine leere Geometrie handelt. Zuvor wurde NaN zurückgegeben.

ANSISQLKonformität

Die folgenden Syntax- und Verhaltensprobleme wurden behoben, um dem ANSI SQL Standard zu entsprechen.

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

  • JOIN... USING— entspricht JOIN ... USING jetzt der SQL Standardsemantik. 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.

  • ROWTypliterale entfernt — Das ROW Typliteralformat ROW<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äß dem ANSI SQL Standard können Datentypen nicht mehr in Anführungszeichen gesetzt 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).

  • GROUPINGSETS— Die maximale Anzahl von Segmenten in einem Gruppierungssatz beträgt 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.