Athena-Engine-Version 3 - 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 3

Für die Engine-Version 3 hat Athena einen kontinuierlichen Integrationsansatz für die Verwaltung von Open-Source-Software eingeführt, der die Aktualität mit den Trino- und Presto-Projekten verbessert. So erhalten Sie schnelleren Zugriff auf Verbesserungen der Community, die in die Athena-Engine integriert und darauf abgestimmt sind.

Diese Version der Athena-Engine-Version 3 unterstützt alle Features der Athena-Engine-Version 2. Dieses Dokument hebt die wichtigsten Unterschiede zwischen der Athena-Engine-Version 2 und der Athena-Engine-Version 3 hervor. Weitere Informationen finden Sie im AWS -Big-Data-Blogartikel Upgrade auf Athena Engine Version 3, um die Abfrageleistung zu erhöhen und auf mehr Analysefeatures zuzugreifen.

Erste Schritte

Erstellen Sie zunächst entweder eine neue Athena-Arbeitsgruppe, die Athena engine version 3 (Athena-Engine-Version 3) verwendet, oder konfigurieren Sie eine vorhandene Arbeitsgruppe für die Verwendung von Version 3. Jede Athena-Arbeitsgruppe kann eine Aktualisierung von der Engine-Version 2 auf die Engine-Version 3 durchführen, ohne dass Ihre Fähigkeit zur Übermittlung von Abfragen unterbrochen wird.

Weitere Informationen finden Sie unter Ändern von Athena-Engine-Versionen.

Neue Features und Verbesserungen

Die aufgeführten Features und Aktualisierungen umfassen Verbesserungen von Athena selbst und von Funktionen, die von Open-Source-Trino integriert wurden. Eine vollständige Liste der SQL Abfrageoperatoren und -funktionen finden Sie in der Trino-Dokumentation.

Hinzugefügte Features

Unterstützung für den Apache-Spark-Bucketing-Algorithmus

Athena kann Buckets lesen, die vom Spark-Hash-Algorithmus generiert wurden. Um anzugeben, dass Daten ursprünglich vom Spark-Hash-Algorithmus geschrieben wurden, fügen Sie ('bucketing_format'='spark') in die TBLPROPERTIES-Klausel Ihrer CREATE TABLE-Anweisung ein. Wenn diese Eigenschaft nicht angegeben wird, wird der Hive-Hash-Algorithmus verwendet.

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

Erweiterte Funktionen

Die Funktionen in diesem Abschnitt sind neu in der Athena-Engine-Version 3.

Aggregationsfunktionen

listagg(x, separator) – Gibt die verketteten Eingabewerte zurück, getrennt durch die Trennzeichenfolge.

SELECT listagg(value, ',') WITHIN GROUP (ORDER BY value) csv_value FROM (VALUES 'a', 'c', 'b') t(value);

Array-Funktionen

contains_sequence(x, seq) – Gibt wahr zurück, wenn Array x alle Array seq als sequentielle Teilmenge enthält (alle Werte in derselben aufeinanderfolgenden Reihenfolge).

SELECT contains_sequence(ARRAY [1,2,3,4,5,6], ARRAY[1,2]);

Binäre Funktionen

murmur3 (binary) — Berechnet den MurmurHash 128-Bit-3-Hash von Binary.

SELECT murmur3(from_base64('aaaaaa'));

Konvertierungs-Funktionen

format_number(number) – Gibt eine formatierte Zeichenfolge mithilfe eines Einheitensymbols zurück.

SELECT format_number(123456); -- '123K'
SELECT format_number(1000000); -- '1M'

Datums- und Zeitfunktionen

timezone_hour(timestamp) – Gibt die Stunde des Zeitzonen-Offsets aus dem Zeitstempel zurück.

SELECT EXTRACT(TIMEZONE_HOUR FROM TIMESTAMP '2020-05-10 12:34:56 +08:35');

timezone_minute(Zeitstempel) – Gibt die Minute des Zeitzonen-Offsets aus dem Zeitstempel zurück.

SELECT EXTRACT(TIMEZONE_MINUTE FROM TIMESTAMP '2020-05-10 12:34:56 +08:35');

Geodatenfunktionen

to_encoded_polyline(Geometry) – Codiert eine Linienfolge oder einen Mehrpunkt in eine Polylinie.

SELECT to_encoded_polyline(ST_GeometryFromText( 'LINESTRING (-120.2 38.5, -120.95 40.7, -126.453 43.252)'));

from encoded polyline(varchar) – Decodiert eine Polylinie in eine Linienfolge.

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

to_geojson_geometry (SphericalGeography) — Gibt die angegebene sphärische Geografie im Geo-Format zurück. JSON

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

from_geojson_geometry (varchar) — Gibt das Objekt vom Typ sphärische Geografie aus der Geo-Repräsentation zurück und entfernt Schlüssel/Werte, die keine Geometrie sind. JSON Featureund FeatureCollection werden nicht unterstützt.

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

geometry_nearest_points(Geometry, Geometry) – Gibt die Punkte auf jeder Geometrie zurück, die einander am nächsten liegen. Wenn eine der Geometrien leer ist, wird zurückgegebenNULL. Gibt andernfalls eine Reihe von zwei Point-Objekten zurück, die den Mindestabstand von zwei beliebigen Punkten auf den Geometrien aufweisen. Der erste Punkt stammt aus dem ersten Geometrie-Argument, der zweite aus dem zweiten Geometrie-Argument. Bei mehreren Paaren mit gleichem Mindestabstand wird ein Paar willkürlich gewählt.

SELECT geometry_nearest_points(ST_GeometryFromText( 'LINESTRING (50 100, 50 200)'), ST_GeometryFromText( 'LINESTRING (10 10, 20 20)'));

Festlegen von Digest-Funktionen

make_set_digest(x) – Fasst alle Eingabewerte von x in einem setdigest zusammen.

SELECT make_set_digest(value) FROM (VALUES 1, 2, 3) T(value);

Zeichenfolgenfunktionen

soundex(char) – Gibt eine Zeichenfolge zurück, die die phonetische Darstellung von char enthält.

SELECT name FROM nation WHERE SOUNDEX(name) = SOUNDEX('CHYNA'); -- CHINA

concat_ws(string0, string1,..., stringN) – Gibt die Verkettung von string1, string2, ..., stringN mit string0 als Trennzeichen zurück. Wenn string0 null ist, ist der Rückgabewert null. Alle in den Argumenten nach dem Trennzeichen angegebenen Nullwerte werden übersprungen.

SELECT concat_ws(',', 'def', 'pqr', 'mno');

Fensterfunktionen

GROUPS— Fügt Unterstützung für Fensterrahmen hinzu, die auf Gruppen basieren.

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

Leistungsverbesserungen

Die Leistungsverbesserungen in Athena-Engine-Version 3 umfassen Folgendes.

  • Schnellerer Abruf von AWS Glue Tabellenmetadaten — Bei Abfragen, die mehrere Tabellen betreffen, wird die Planungszeit für Abfragen reduziert.

  • Dynamisches Filtern für RIGHT JOIN — Dynamisches Filtern ist jetzt für Right-Joins aktiviert, für die gleiche Join-Bedingungen gelten, wie im folgenden Beispiel gezeigt.

    SELECT * FROM lineitem RIGHT JOIN tpch.tiny.supplier ON lineitem.suppkey = supplier.suppkey WHERE supplier.name = 'abc';
  • Große vorbereitete Anweisungen — Die Standardgröße für den HTTP Anforderungs-/Antwort-Header wurde auf 2 MB erhöht, um große vorbereitete Anweisungen zu ermöglichen.

  • approx_percentile () – Die approx_percentile-Funktion verwendet nun tdigest anstelle von qdigest, um ungefähre Quantilwerte aus Verteilungen abzurufen. Dies führt zu höherer Leistung und geringerem Speicherverbrauch. Beachten Sie, dass die Funktion aufgrund dieser Änderung andere Ergebnisse zurückgibt als in Athena-Engine-Version 2. Weitere Informationen finden Sie unter Die Funktion approx_percentile gibt unterschiedliche Ergebnisse zurück.

Verbesserungen der Zuverlässigkeit

Die allgemeine Engine-Speichernutzung und -Nachverfolgung in Athena-Engine-Version 3 wurde verbessert. Große Abfragen sind weniger anfällig für Ausfälle durch Knotenabstürze.

Verbesserungen der Abfragesyntax

INTERSECTALL— Unterstützung für hinzugefügt. INTERSECT ALL

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

EXCEPTALL— Unterstützung für hinzugefügtEXCEPT ALL.

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

RANGEPRECEDING— Unterstützung für RANGE PRECEDING In-Fenster-Funktionen hinzugefügt.

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

MATCH_ RECOGNIZE — Unterstützung für den Abgleich von Zeilenmustern hinzugefügt, wie im folgenden Beispiel.

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;

Verbesserungen des Datenformats und des Datentyps

Athena-Engine-Version 3 verfügt über die folgenden Verbesserungen für Datenformat und Datentyp.

  • LZ4und ZSTD — Unterstützung für das Lesen LZ4 und ZSTD Komprimieren von Parquet-Daten hinzugefügt. Unterstützung für das Schreiben ZSTD komprimierter ORC Daten hinzugefügt.

  • Symlink-basierten Tabellen – Unterstützung für das Erstellen von Symlink-basierten Tabellen in Avro-Dateien hinzugefügt. Ein Beispiel folgt.

    CREATE TABLE test_avro_symlink ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.avro.AvroSerDe' ... INPUTFORMAT 'org.apache.hadoop.hive.ql.io.SymlinkTextInputFormat'
  • SphericalGeography— Der SphericalGeography Typ bietet native Unterstützung für räumliche Merkmale, die auf geographischen Koordinaten dargestellt werden (manchmal auch als geodätische Koordinaten, Breite/Längen oder Breitengrade bezeichnet). Geografische Koordinaten sind sphärische Koordinaten, die in Winkeleinheiten (Grad) ausgedrückt werden.

    Die to_spherical_geography-Funktion gibt geographische (sphärische) Koordinaten aus geometrischen (planaren) Koordinaten zurück, wie im folgenden Beispiel gezeigt.

    SELECT to_spherical_geography(ST_GeometryFromText( 'LINESTRING (-40.2 28.9, -40.2 31.9, -37.2 31.9)'));

Abwärtskompatible Änderungen

Wenn Sie von Athena-Engine-Version 2 zu Athena-Engine-Version 3 migrieren, können sich bestimmte Änderungen auf das Tabellenschema, die Syntax oder die Verwendung von Datentypen auswirken. Dieser Abschnitt listet die zugehörigen Fehlermeldungen auf und enthält Vorschläge für Problemumgehungen.

Änderungen der Abfragesyntax

IGNORENULLSkann nicht mit Fensterfunktionen ohne Wert verwendet werden

Fehlermeldung: Für die bool_or-Funktion kann keine Nullbehandlungsklausel angegeben werden.

Ursache: IGNORE NULLS kann jetzt nur mit den Wertfunktionen first_value, last_value, nth_value, lead und lag verwendet werden. Diese Änderung wurde vorgenommen, um der ANSI SQL Spezifikation zu entsprechen.

Vorgeschlagene Lösung: Entfernen Sie IGNORE NULLS in Abfragezeichenfolgen von Fensterfunktionen ohne Wert.

CONCATDie Funktion muss zwei oder mehr Argumente haben

Fehlermeldung: INVALID_ FUNCTION _ARGUMENT: Es müssen zwei oder mehr Verkettungsargumente vorhanden sein

Ursache: Zuvor akzeptierte die CONCAT-Zeichenfolgenfunktion ein einzelnes Argument. In Athena-Engine-Version 3 erfordert die CONCAT-Funktion mindestens zwei Argumente.

Lösungsvorschlag: Ändern Sie das Vorkommen von CONCAT(str) auf CONCAT(str, '').

In Athena-Engine-Version 3 können Funktionen nicht mehr als 127 Argumente haben. Weitere Informationen finden Sie unter Zu viele Argumente für den Funktionsaufruf.

Die Funktion approx_percentile gibt unterschiedliche Ergebnisse zurück

Die approx_percentile-Funktion liefert in Athena-Engine-Version 3 andere Ergebnisse als in Athena-Engine-Version 2.

Fehlermeldung: Keine.

Ursache: Die approx_percentile-Funktion unterliegt Versionsänderungen.

Wichtig

Da es sich bei den Ausgaben der approx_percentile-Funktion um Näherungen handelt und sich die Näherungen von einer Version zur nächsten ändern können, sollten Sie sich bei kritischen Anwendungen nicht auf die approx_percentile-Funktion verlassen.

Vorgeschlagene Lösung: Um das Verhalten von Athena-Engine-Version 2 approx_percentile anzunähern, können Sie in Athena-Engine-Version 3 einen anderen Funktionsumfang verwenden. Nehmen wir zum Beispiel an, Sie haben die folgende Abfrage in Athena-Engine-Version 2:

SELECT approx_percentile(somecol, 2E-1)

Um die gleiche Ausgabe in Athena-Engine-Version 3 anzunähern, können Sie die Funktionen value_at_quantile und qdigest_agg ausprobieren, wie im folgenden Beispiel. Beachten Sie, dass das gleiche Verhalten auch mit dieser Problemumgehung nicht garantiert werden kann.

SELECT value_at_quantile(qdigest_agg(somecol, 1), 2E-1)

Die Geodatenfunktion unterstützt keine varbinary-Eingabe

Fehlermeldung: FUNCTION_ _ für st_ NOT FOUND XXX

Ursache: Einige Geodatenfunktionen unterstützen den Legacy-Eingabetyp VARBINARY oder textbezogene Funktionssignaturen nicht mehr.

Lösungsvorschlag: Verwenden Sie Geodatenfunktionen, um die Eingabetypen in unterstützte Typen zu konvertieren. Unterstützte Eingabetypen sind in der Fehlermeldung angegeben.

In GROUP BY-Klauseln müssen verschachtelte Spalten in doppelte Anführungszeichen gesetzt werden

Fehlermeldung:column_name"."nested_column"muss ein Aggregatausdruck sein oder in der GROUP BY-Klausel vorkommen

Ursache: Athena-Engine-Version 3 erfordert, dass verschachtelte Spaltennamen in GROUP BY-Klauseln in doppelten Anführungszeichen stehen. Beispielsweise erzeugt die folgende Abfrage den Fehler, weil sie in der GROUP BY-Klausel user.name nicht in doppelten Anführungszeichen steht.

SELECT "user"."name" FROM dataset GROUP BY user.name

Lösungsvorschlag: Setzen Sie geschachtelte Spaltennamen in GROUP BY-Klauseln in doppelte Anführungszeichen, wie im folgenden Beispiel.

SELECT "user"."name" FROM dataset GROUP BY "user"."name"

Unerwarteter FilterNode Fehler bei OPTIMIZE der Verwendung in einer Iceberg-Tabelle

Fehlermeldung: Unerwarteter Fehler im Plan FilterNode gefunden. Wahrscheinlich konnte der Connector den angegebenen WHERE Ausdruck nicht verarbeiten.

Ursache: Die OPTIMIZE Anweisung, die für die Iceberg-Tabelle ausgeführt wurde, verwendete eine WHERE Klausel, deren Filterausdruck eine Spalte enthielt, die keine Partition war.

Vorgeschlagene Lösung: Die OPTIMIZE Anweisung unterstützt nur das Filtern nach Partitionen. Wenn Sie mit partitionierten Tabellen OPTIMIZE arbeiten, nehmen Sie nur Partitionsspalten in die WHERE Klausel auf. Wenn Sie mit einer nicht partitionierten Tabelle arbeiten, geben Sie keine Klausel an. OPTIMIZE WHERE

Reihenfolge der Argumente der Funktion Log()

In Athena-Engine-Version 2 lautete die Reihenfolge der Argumente für die log()-Funktion log(value, base). In der Athena-Engine-Version 3 wurde dies nun log(base, value) SQL standardkonform geändert.

Die Funktion minute() unterstützt nicht das Intervall Jahr bis Monat

Fehlermeldung: Unerwartete Parameter (Intervall von Jahr zu Monat) für die Funktion Minute. Erwartet: minute(Zeitstempel mit Zeitzone), minute(Zeit mit Zeitzone), minute(Zeitstempel), minute(Zeit), minute(Intervall Tag zu Sekunde).

Ursache: In der Athena-Engine-Version 3 wurden die Typprüfungen EXTRACT gemäß der ANSI SQL Spezifikation genauer durchgeführt.

Lösungsvorschlag: Aktualisieren Sie die Abfragen, um sicherzustellen, dass Typen mit den vorgeschlagenen Funktionssignaturen übereinstimmen.

ORDERBY-Ausdrücke müssen in der SELECT Liste erscheinen

Fehlermeldung: For SELECT DISTINCT-, ORDER BY-Ausdrücke müssen in der SELECT Liste erscheinen

Ursache: In einer SELECT-Klausel wird ein falscher Tabellen-Aliasing verwendet.

Lösungsvorschlag: Vergewissern Sie sich, dass alle Spalten im ORDER BY-Ausdruck die richtigen Verweise in der SELECT DISTINCT-Klausel haben.

Abfragefehler beim Vergleich mehrerer Spalten, die von einer Unterabfrage zurückgegeben wurden

Beispiel für eine Fehlermeldung: Wertausdruck und Ergebnis der Unterabfrage müssen vom gleichen Typ sein: row(varchar, varchar) vs row(row(varchar, varchar))

Ursache: Aufgrund einer Syntaxaktualisierung in Athena-Engine-Version 3 tritt dieser Fehler auf, wenn eine Abfrage versucht, mehrere von einer Unterabfrage zurückgegebene Werte zu vergleichen, und die SELECT-Unterabfrage-Anweisung ihre Spaltenliste in Klammern einschließt, wie im folgenden Beispiel.

SELECT * FROM table1 WHERE (t1_col1, t1_col2) IN (SELECT (t2_col1, t2_col2) FROM table2)

Lösung: Entfernen Sie in Athena-Engine-Version 3 die Klammern um die Liste der Spalten in der SELECT-Unterabfrageanweisung, wie in der folgenden aktualisierten Beispielabfrage.

SELECT * FROM table1 WHERE (t1_col1, t1_col2) IN (SELECT t2_col1, t2_col2 FROM table2)

SKIPist ein reserviertes Wort für DML Abfragen

Das Wort SKIP ist jetzt ein reserviertes Wort für DML Abfragen wieSELECT. Um es SKIP als Bezeichner in einer DML Abfrage zu verwenden, setzen Sie es in doppelte Anführungszeichen.

Weitere Informationen zu reservierten Wörtern in Athena finden Sie unter Reservierte Schlüsselwörter in Abfragen umgehen.

SYSTEMDie VERSION Klauseln SYSTEM _ TIME und _ sind für Zeitreisen veraltet

Fehlermeldung: Die Eingabe '_' stimmt nicht überein. SYSTEM TIME Ich erwarte: TIMESTAMP '', 'VERSION

Ursache: In Athena-Engine-Version2 verwendeten Iceberg-Tabellen die FOR SYSTEM_TIME AS OF- und FOR SYSTEM_VERSION AS OF-Klauseln für Zeitstempel- und Versionszeitreisen. Athena-Engine-Version 3 verwendet die FOR TIMESTAMP AS OF- und FOR VERSION AS OF-Klauseln.

Vorgeschlagene Lösung: Aktualisieren Sie die SQL Abfrage so, dass sie die TIMESTAMP AS OF und VERSION AS OF -Klauseln für Zeitreise-Operationen verwendet, wie in den folgenden Beispielen.

Zeitreise nach Zeitstempel:

SELECT * FROM TABLE FOR TIMESTAMP AS OF (current_timestamp - interval '1' day)

Zeitreise nach Version:

SELECT * FROM TABLE FOR VERSION AS OF 949530903748831860

Zu viele Argumente für einen Array-Konstruktor

Fehlermeldung: TOO_ MANY _ARGUMENTS: Zu viele Argumente für den Array-Konstruktor.

Ursache: Die maximale Anzahl von Elementen in einem Array-Konstruktor ist jetzt auf 254 festgelegt.

Vorgeschlagene Lösung: Teilen Sie die Elemente in mehrere Arrays auf, die jeweils 254 oder weniger Elemente enthalten, und verwenden Sie die CONCAT-Funktion, um die Arrays zu verketten, wie im folgenden Beispiel gezeigt.

CONCAT( ARRAY[x1,x2,x3...x254], ARRAY[y1,y2,y3...y254], ... )

Bezeichner mit Null-Längenbegrenzung ist nicht zulässig

Fehlermeldung: Durch Null getrennte Kennung nicht zulässig.

Ursache: Eine Abfrage verwendete eine leere Zeichenfolge als Spalten-Alias.

Lösungsvorschlag: Aktualisieren Sie die Abfrage so, dass für die Spalte ein nicht leerer Alias verwendet wird.

Änderungen der Datenverarbeitung

Bucket-Validierung

Fehlermeldung: HIVE_ _ INVALID BUCKET _FILES: Die Hive-Tabelle ist beschädigt.

Ursache: Die Tabelle ist möglicherweise beschädigt. Um die Richtigkeit der Abfragen für Bucket-Tabellen sicherzustellen, ermöglicht die Athena-Engine-Version 3 eine zusätzliche Validierung von Bucket-Tabellen, um die Richtigkeit der Abfragen sicherzustellen und unerwartete Fehler zur Laufzeit zu vermeiden.

Vorgeschlagene Lösung: Erstellen Sie die Tabelle mit Athena-Engine-Version 3 neu.

Beim Umwandeln einer Struktur in werden JSON jetzt Feldnamen zurückgegeben

Wenn Sie JSON in einer struct SELECT Abfrage in Athena-Engine-Version 3 ein in umwandeln, gibt die Umwandlung jetzt sowohl die Feldnamen als auch die Werte zurück (zum Beispiel ") useragent":null statt nur die Werte (zum Beispielnull).

Änderung der Sicherheitserzwingung auf Spaltenebene der Iceberg-Tabelle

Fehlermeldung: Zugriff verweigert: Kann nicht aus Spalten ausgewählt werden

Ursache: Die Iceberg-Tabelle wurde außerhalb von Athena erstellt und verwendet eine Apache SDK Iceberg-Version vor 0.13.0. Da in früheren SDK Versionen keine Spalten aufgefüllt wurden AWS Glue, konnte Lake Formation die für den Zugriff autorisierten Spalten nicht ermitteln.

Vorgeschlagene Lösung: Führen Sie ein Update mit der ALTER TABLE SET PROPERTIES Athena-Anweisung durch oder verwenden Sie die neueste Version von IcebergSDK, um die Tabelle zu korrigieren und die Spalteninformationen in zu aktualisieren. AWS Glue

Nullen in List-Datentypen werden jetzt weitergegeben an UDFs

Fehlermeldung: Null-Zeiger-Ausnahme

Ursache: Dieses Problem kann Sie betreffen, wenn Sie den UDF Konnektor verwenden und eine benutzerdefinierte Lambda-Funktion implementiert haben.

Athena-Engine-Version 2 hat die Nullen in Listendatentypen herausgefiltert, die an eine benutzerdefinierte Funktion übergeben wurden. In der Athena-Engine-Version 3 werden die Nullen nun beibehalten und an die weitergegeben. UDF Dies kann zu einer Nullzeiger-Ausnahme führen, wenn UDF versucht wird, das Null-Element ohne Überprüfung zu dereferenzieren.

Wenn sich beispielsweise die Daten [null, 1, null, 2, 3, 4] in einer Ursprungsdatenquelle wie DynamoDB befinden, werden die folgenden Daten an die benutzerdefinierte Lambda-Funktion übergeben:

Athena-Engine-Version 2: [1,2,3,4]

Athena-Engine-Version 3: [null, 1, null, 2, 3, 4]

Lösungsvorschlag: Stellen Sie sicher, dass Ihre benutzerdefinierte Lambda-Funktion Nullelemente in Listendatentypen verarbeitet.

Teilzeichenfolgen aus Zeichen-Arrays enthalten keine aufgefüllten Leerzeichen mehr

Fehlermeldung: Es wird kein Fehler ausgegeben, aber die zurückgegebene Zeichenfolge enthält keine aufgefüllten Leerzeichen mehr. Beispielsweise gibt substr(char[20],1,100) jetzt eine Zeichenfolge mit der Länge 20 statt 100 zurück.

Lösungsvorschlag: Es sind keine Maßnahmen erforderlich.

Nicht unterstützte Umwandlung des Dezimalspaltentyps

Fehlermeldungen: HIVE _ CURSOR _ERROR: Die Parquet-Datei konnte nicht gelesen werden: s3://amzn-s3-demo-bucket/path/file_name.parquet oder Nicht unterstützter Spaltentyp (varchar) für die Parquet-Spalte ([column_name]

Ursache: Athena-Engine-Version 2 war gelegentlich erfolgreich (schlug aber häufig fehl), wenn versucht wurde, Datentypzwänge von varchar zu dezimal zu ändern. Da die Athena-Engine-Version 3 über eine Typüberprüfung verfügt, die die Kompatibilität des Typs prüft, bevor sie versucht, den Wert zu lesen, schlagen solche Zwangsverknüpfungen jetzt immer fehl.

Vorgeschlagene Lösung: Ändern Sie Ihr Schema sowohl für Athena-Engine-Version 2 als auch für Athena-Engine-Version 3 so, AWS Glue dass es einen numerischen Datentyp anstelle von varchar Dezimalspalten in Parquet-Dateien verwendet. Durchforsten Sie entweder die Daten erneut und stellen Sie sicher, dass der neue Spaltendatentyp ein Dezimaltyp ist, oder erstellen Sie die Tabelle in Athena manuell neu und verwenden Sie die Syntax decimal(precision, scale), um einen decimal-Datentyp für die Spalte anzugeben.

Float- oder Double-NaN-Werte können nicht mehr in bigint umgewandelt werden

Fehlermeldung: INVALID_ CAST _ARGUMENT: Real/Double NaN kann nicht in Bigint umgewandelt werden

Ursache: NaN kann in Athena-Engine-Version 3 nicht mehr auf 0 als bigint gecastet werden als.

Lösungsvorschlag: Stellen Sie sicher, dass beim Umwandeln in bigint keine NaN-Werte in den Spalten double oder float vorhanden sind.

Änderung des Rückgabetyps der Funktion uuid ()

Das folgende Problem betrifft sowohl Tabellen als auch Ansichten.

Fehlermeldung: Hive-Typ: uuid wird nicht unterstützt

Ursache: In Athena-Engine-Version 2 gab die uuid() Funktion eine Zeichenfolge zurück, aber in Athena-Engine-Version 3 gibt sie einen zufällig generierten Pseudo zurück UUID (Typ 4). Da der UUID Spaltendatentyp in Athena nicht unterstützt wird, kann die uuid() Funktion in Athena-Engine-Version 3 nicht mehr direkt in CTAS Abfragen zum Generieren von UUID Spalten verwendet werden.

Die folgende CREATE TABLE Anweisung wird beispielsweise in Athena-Engine-Version 2 erfolgreich abgeschlossen, gibt aber NOT_ zurückSUPPORTED: Unsupported Hive type: uuid in Athena-Engine-Version 3:

CREATE TABLE uuid_table AS SELECT uuid() AS myuuid

In ähnlicher Weise wird die folgende Anweisung CREATE VIEW in Athena-Engine-Version 2 erfolgreich abgeschlossen, gibt aber den ungültigen Spaltentyp für die Spalte myuuid zurück: Nicht unterstützter Hive-Typ: uuid in Athena-Engine-Version 3:

CREATE VIEW uuid_view AS SELECT uuid() AS myuuid

Wenn eine so in Athena-Engine-Version 2 erstellte Ansicht in Athena-Engine-Version 3 abgefragt wird, tritt ein Fehler wie der folgende auf:

VIEW_IS_STALE: Zeile 1:15: Die Ansicht 'awsdatacatalog.mydatabase.uuid_view' ist veraltet oder hat einen ungültigen Status: Die Spalte [myuuid] vom Typ uuid, die aus der Abfrageansicht an Position 0 projiziert wurde, kann nicht in die Spalte [myuuid] vom Typ varchar gezwungen werden, die in der Viewdefinition gespeichert ist

Vorgeschlagene Lösung: Verwenden Sie beim Erstellen der Tabelle oder Ansicht die cast()-Funktion, um die Ausgabe von uuid() in ein varchar zu konvertieren, wie in den folgenden Beispielen:

CREATE TABLE uuid_table AS SELECT CAST(uuid() AS VARCHAR) AS myuuid
CREATE VIEW uuid_view AS SELECT CAST(uuid() AS VARCHAR) AS myuuid

CHARund VARCHAR Probleme mit Zwang

Verwenden Sie die Problemumgehungen in diesem Abschnitt, wenn Sie mit varchar und char in der Athena-Engine-Version 3 auf Zwangsprobleme stoßen. Wenn Sie diese Problemumgehungen nicht verwenden können, wenden Sie sich bitte an. AWS Support

CONCATFunktionsfehler bei gemischten Eingängen CHAR VARCHAR

Problem: Die folgende Abfrage ist auf Athena-Engine-Version 2 erfolgreich.

SELECT concat(CAST('abc' AS VARCHAR(20)), '12', CAST('a' AS CHAR(1)))

In der Athena-Engine-Version 3 schlägt dieselbe Abfrage jedoch wie folgt fehl:

Fehlermeldung: FUNCTION_ NOT _: Zeile 1:8FOUND: Unerwartete Parameter (varchar (20), varchar (2), char (1)) für die Funktion concat. Erwartet: concat (char (x), char (y)), concat (array (E), E) E, concat (E, array (E)) E, concat (array (E)) E, concat (array (E)) E, concat (varchar), concat (varbinary)

Vorgeschlagene Lösung: Wenn Sie die concat-Funktion verwenden, konvertieren Sie entweder in char oder varchar, aber nicht in eine Mischung aus beidem.

SQL|| Fehler bei der Verkettung mit Eingaben und CHAR VARCHAR

In der Athena-Engine-Version 3 erfordert der ||-Operator für die Verkettung von doppelten vertikalen Balken varchar als Eingaben. Bei den Eingaben darf es sich nicht um eine Kombination von varchar- und char-Typen handeln.

Fehlermeldung: TYPE_ NOT _: Zeile 1:26FOUND: Unbekannter Typ: char (65537)

Ursache: Eine Abfrage, die || verwendet, um ein char und ein varchar zu verketten, kann zu dem Fehler führen, wie im folgenden Beispiel.

SELECT CAST('a' AS CHAR) || CAST('b' AS VARCHAR)

Vorgeschlagene Lösung: Verketten Sie varchar mit varchar, wie im folgenden Beispiel.

SELECT CAST('a' AS VARCHAR) || CAST('b' AS VARCHAR)
CHARund Abfragefehler VARCHAR UNION

Fehlermeldung: NOT_SUPPORTED: Hive-Typ wird nicht unterstützt: char (65536). Unterstützte CHAR Typen: (<=255) CHAR

Ursache: Eine Abfrage, die versucht, char und varchar zu kombinieren, wie im folgenden Beispiel:

CREATE TABLE t1 (c1) AS SELECT CAST('a' as CHAR) as c1 UNION ALL SELECT CAST('b' AS VARCHAR) AS c1

Vorgeschlagene Lösung: Verwenden Sie in der Beispielabfrage die 'a'-Umwandlung zu varchar und nicht char.

Unerwünschte Leerzeichen nach oder Zwang CHAR VARCHAR

In Athena-Engine-Version 3 ist der Zieltyp, wenn char(X)- und varchar-Daten bei der Bildung eines Arrays oder einer einzelnen Spalte zu einem einzigen Typ gezwungen werden char(65535) und jedes Feld enthält viele unerwünschte Leerzeichen am Ende.

Ursache: Athena-Engine-Version 3 wandelt varchar und char(X) zu char(65535) und füllt die Daten dann nach rechts mit Leerzeichen auf.

Vorgeschlagene Lösung: Wandeln Sie jedes Feld explizit in varchar um.

Änderungen des Zeitstempels

Umwandlung eines Zeitstempels mit Zeitzone auf Varchar-Verhaltensänderung

In der Athena-Engine-Version 2 führte das Umwandeln von Timestamp mit Zeitzone in varchar dazu, dass sich einige Zeitzonenliterale änderten (z. B. wurde US/Eastern in America/New_York geändert). Dieses Problem tritt in Athena-Engine-Version 3 nicht auf.

Überlauf des Datums-Zeitstempels löst Fehler aus

Fehlermeldung: Millis Overflow: XXX

Ursache: Da ISO 8601-Daten in Athena-Engine-Version 2 nicht auf Überlauf geprüft wurden, wurde bei einigen Datumsangaben ein negativer Zeitstempel erzeugt. Athena-Engine-Version 3 prüft auf diesen Überlauf und löst eine Ausnahme aus.

Lösungsvorschlag: Stellen Sie sicher, dass der Zeitstempel innerhalb des Bereichs liegt.

Politische Zeitzonen werden nicht unterstützt TIME

Fehlermeldung: INVALIDLITERAL

Ursache: Abfragen wie SELECT TIME '13:21:32.424 America/Los_Angeles'.

Lösungsvorschlag: Vermeiden Sie die Verwendung politischer Zeitzonen mit TIME.

Genauigkeitsabweichung in Timestamp-Spalten verursacht Serialisierungsfehler

Fehlermeldung: SERIALIZATION _ERROR: Spalte 'konnte nicht serialisiert werdenCOLUMNZ'vom Typ 'timestamp (3)' an Position X:Y

COLUMNZ ist der Ausgabename der Spalte, die das Problem verursacht. Die Zahlen X:Y geben die Position der Spalte in der Ausgabe an.

Ursache: Athena-Engine-Version 3 prüft, ob die Genauigkeit der Zeitstempel in den Daten mit der Genauigkeit übereinstimmt, die für den Spaltendatentyp in der Tabellenspezifikation angegeben ist. Derzeit liegt diese Genauigkeit immer bei 3. Wenn die Daten eine höhere Genauigkeit aufweisen, schlagen Abfragen mit dem angegebenen Fehler fehl.

Lösungsvorschlag: Überprüfen Sie Ihre Daten, um sicherzustellen, dass Ihre Zeitstempel auf die Millisekunde genau sind.

Falsche Genauigkeit des Zeitstempels in UNLOAD und CTAS Abfragen für Iceberg-Tabellen

Fehlermeldung: Falsche Zeitstempelgenauigkeit für Timestamp (6); die konfigurierte Genauigkeit ist MILLISECONDS

Ursache: Athena-Engine-Version 3 prüft, ob die Genauigkeit der Zeitstempel in den Daten mit der Genauigkeit übereinstimmt, die für den Spaltendatentyp in der Tabellenspezifikation angegeben ist. Derzeit liegt diese Genauigkeit immer bei 3. Wenn die Daten eine höhere Genauigkeit haben (z. B. Mikrosekunden statt Millisekunden), können Abfragen mit dem angegebenen Fehler fehlschlagen.

Lösung: Um dieses Problem zu umgehen, stellen Sie zunächst CAST die Genauigkeit des Zeitstempels auf 6 ein, wie im folgenden CTAS Beispiel, das eine Iceberg-Tabelle erstellt. Beachten Sie, dass die Genauigkeit mit 6 statt mit 3 angegeben werden muss, um den Fehler Zeitstempelpräzision (3) nicht unterstützt für Iceberg zu vermeiden.

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

Da Athena Zeitstempel 6 nicht unterstützt, wandeln Sie den Wert dann erneut in Zeitstempel um (z. B. in einer Ansicht). Das folgende Beispiel erstellt eine Ansicht aus der my_iceberg_ctas-Tabelle.

CREATE OR REPLACE VIEW my_iceberg_ctas_view AS SELECT cast(dt AS timestamp) AS dt FROM my_iceberg_ctas

Das Lesen des Typs Long als Timestamp oder umgekehrt in ORC Dateien führt jetzt zu einem Fehler in einer falsch formatierten Datei ORC

Fehlermeldung: Fehler beim Öffnen der fehlerhaften Hive-Split-Datei 'FILE(SPLITPOSITION)'. ORC Der Typ-Zeitstempel kann nicht aus dem ORC Stream SQL .long_type des Typs gelesen werden LONG

Ursache: Athena-Engine-Version 3 lehnt nun impliziten Zwang vom Long-Datentyp zu Timestamp oder von Timestamp zu Long ab. Zuvor wurden Long-Werte implizit in Zeitstempel umgewandelt, als wären sie Epochen-Millisekunden.

Lösungsvorschlag: Verwenden Sie die from_unixtime-Funktion, um die Spalte explizit umzuwandeln, oder verwenden Sie die from_unixtime-Funktion, um eine zusätzliche Spalte für zukünftige Abfragen zu erstellen.

Zeit und Intervall von Jahr zu Monat werden nicht unterstützt

Fehlermeldung: TYPEMISMATCH

Ursache: Athena-Engine-Version 3 unterstützt Zeit und Intervall von Jahr zu Monat nicht (z. B. SELECT TIME '01:00' + INTERVAL '3' MONTH).

Zeitstempelüberlauf für das int96-Parquet-Format

Fehlermeldung: Ungültige timeOfDay Nanos

Ursache: Ein Zeitstempelüberlauf für das int96-Parquet-Format.

Lösungsvorschlag: Identifizieren Sie die spezifischen Dateien, bei denen das Problem auftritt. Generieren Sie dann die Datendatei erneut mit einer up-to-date bekannten Parquet-Bibliothek oder verwenden Sie AthenaCTAS. Wenn das Problem weiterhin besteht, wenden Sie sich an den Athena-Support und teilen Sie uns mit, wie die Datendateien generiert werden.

Bei der Umwandlung von einer Zeichenfolge in einen Zeitstempel ist Platz zwischen Datums- und Uhrzeitwerten erforderlich

Fehlermeldung: INVALID_ CAST _ARGUMENT: Der Wert kann nicht in einen Zeitstempel umgewandelt werden.

Ursache: Athena-Engine-Version 3 akzeptiert keinen Bindestrich mehr als gültiges Trennzeichen zwischen Datums- und Uhrzeitwerten in der Eingabezeichenfolge zu cast. Die folgende Abfrage funktioniert beispielsweise in Athena-Engine-Version 2, aber nicht in Athena-Engine-Version 3:

SELECT CAST('2021-06-06-23:38:46' AS timestamp) AS this_time

Vorgeschlagene Lösung: Ersetzen Sie in Athena-Engine-Version 3 den Bindestrich zwischen Datum und Uhrzeit durch ein Leerzeichen, wie im folgenden Beispiel.

SELECT CAST('2021-06-06 23:38:46' AS timestamp) AS this_time

Änderung des Zeitstempel-Rückgabewerts von to_iso8601 ()

Fehlermeldung: Keine.

Ursache: In Athena-Engine-Version 2 gibt die to_iso8601-Funktion einen Zeitstempel mit Zeitzone zurück, auch wenn der an die Funktion übergebene Wert die Zeitzone nicht enthält. In Athena-Engine-Version 3 gibt die to_iso8601-Funktion nur dann einen Zeitstempel mit Zeitzone zurück, wenn das übergebene Argument die Zeitzone enthält.

Die folgende Abfrage übergibt beispielsweise das aktuelle Datum zweimal an die to_iso8601-Funktion: zuerst als Zeitstempel mit Zeitzone und dann als Zeitstempel.

SELECT TO_ISO8601(CAST(CURRENT_DATE AS TIMESTAMP WITH TIME ZONE)), TO_ISO8601(CAST(CURRENT_DATE AS TIMESTAMP))

Die folgende Ausgabe zeigt das Ergebnis der Abfrage in jeder Engine.

Athena-Engine-Version 2:

# _col0 _col1
1

2023-02-24T00:00:00.000Z

2023-02-24T00:00:00.000Z

Athena-Engine-Version 3

# _col0 _col1
1

2023-02-24T00:00:00.000Z

2023-02-24T00:00:00.000

Lösungsvorschlag: Um das vorherige Verhalten zu replizieren, können Sie den Zeitstempelwert an die with_timezone-Funktion übergeben, bevor Sie ihn an to_iso8601 übergeben, wie im folgenden Beispiel:

SELECT to_iso8601(with_timezone(TIMESTAMP '2023-01-01 00:00:00.000', 'UTC'))

Ergebnis

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

Der erste Parameter at_timezone () muss ein Datum angeben

Problem: In Athena-Engine-Version 3 kann die at_timezone-Funktion keinen time_with_timezone-Wert als ersten Parameter annehmen.

Ursache: Ohne Datumsinformationen kann nicht festgestellt werden, ob es sich bei dem übergebenen Wert um Sommerzeit oder Normalzeit handelt. at_timezone('12:00:00 UTC', 'America/Los_Angeles')Ist beispielsweise mehrdeutig, da nicht bestimmt werden kann, ob es sich bei dem übergebenen Wert um Pacific Daylight Time (PDT) oder Pacific Standard Time (PST) handelt.

Einschränkungen

Athena-Engine-Version 3 weist die folgenden Einschränkungen auf.

  • Abfrageleistung – Viele Abfragen werden mit der Athena-Engine-Version 3 schneller ausgeführt, aber einige Abfragepläne können sich von denen der Athena-Engine-Version 2 unterscheiden. Daher können sich einige Abfragen in Bezug auf Latenz oder Kosten unterscheiden.

  • Trino- und Presto-Konnektoren – Weder Trino- noch Presto-Konnektoren werden unterstützt. Sie können mit Amazon Athena Federated Query verbinden. Weitere Informationen finden Sie unter Verwenden Sie Amazon Athena Federated Query.

  • Fehlertolerante Ausführung – Die fehlertolerante Ausführung von Trino (Trino Tardigrade) wird nicht unterstützt.

  • Grenzwert für Funktionsparameter – Funktionen können nicht mehr als 127 Parameter annehmen. Weitere Informationen finden Sie unter Zu viele Argumente für den Funktionsaufruf.

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.