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. # DML-Abfragen, -Funktionen und -Operatoren Die Athena-DML-Abfrage-Engine unterstützt im Allgemeinen die Trino- und Presto-Syntax und fügt eigene Verbesserungen hinzu. Nicht alle Trino- oder Presto-Features werden von Athena unterstützt. Weitere Informationen finden Sie in den Themen für spezifische Anweisungen in diesem Abschnitt und [Überlegungen und Einschränkungen](other-notable-limitations.md). Informationen zu Funktionen finden Sie unter [Funktionen in Amazon Athena](functions.md). Weitere Informationen über Athena-Engine-Versionen finden Sie unter [Athena-Engine-Versionierung](engine-versions.md). Informationen zu DDL-Anweisungen finden Sie unter [DDL-Anweisungen](ddl-reference.md). Eine Liste der nicht unterstützten DDL-Anweisungen finden Sie unter [Nicht unterstützte DDLs](unsupported-ddl.md). **Topics** + [SELECT](select.md) + [INSERT INTO](insert-into.md) + [VALUES](values-statement.md) + [DELETE](delete-statement.md) + [UPDATE](update-statement.md) + [MERGE INTO](merge-into-statement.md) + [OPTIMIZE](optimize-statement.md) + [VACUUM](vacuum-statement.md) + [EXPLAIN und EXPLAIN ANALYZE](athena-explain-statement.md) + [PREPARE](sql-prepare.md) + [UNLOAD](unload.md) + [Funktionen](functions.md) + [Unterstützte Zeitzonen verwenden](athena-supported-time-zones.md) # SELECT Ruft Datenzeilen aus null oder mehr Tabellen ab. **Anmerkung** Dieses Thema enthält zusammenfassende Informationen zur Referenz. Umfassende Informationen über die Verwendung von `SELECT` und der SQL-Sprache gehen über den Rahmen dieser Dokumentation hinaus. Weitere Informationen zur Verwendung von SQL speziell für Athena finden Sie unter [Überlegungen und Einschränkungen für SQL-Abfragen in Amazon Athena](other-notable-limitations.md) und [Ausführen von SQL-Abfragen in Amazon Athena](querying-athena-tables.md). Für ein Beispiel für das Erstellen einer Datenbank, das Erstellen einer Tabelle und das Ausführen einer `SELECT`-Abfrage auf dem Tisch in Athena siehe [Erste Schritte](getting-started.md). ## Syntax ``` [ WITH with_query [, ...] ] SELECT [ ALL | DISTINCT ] select_expression [, ...] [ FROM from_item [, ...] ] [ WHERE condition ] [ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ] [ HAVING condition ] [ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ] [ ORDER BY expression [ ASC | DESC ] [ NULLS FIRST | NULLS LAST] [, ...] ] [ OFFSET count [ ROW | ROWS ] ] [ LIMIT [ count | ALL ] ] ``` **Anmerkung** Reservierte Wörter in SQL SELECT-Anweisungen müssen in doppelte Anführungszeichen eingeschlossen werden. Weitere Informationen finden Sie unter [Reservierte Schlüsselwörter, die in SQL-SELECT-Anweisungen umgegangen werden müssen](reserved-words.md#list-of-reserved-words-sql-select). ## Parameters **[ WITH with\$1query [, ....] ]** Mit `WITH` können Sie verschachtelte Abfragen reduzieren oder Unterabfragen vereinfachen. Die Verwendung der `WITH`-Klausel zur Erstellung rekursiver Abfragen wird ab der Athena-Engine-Version 3 unterstützt. Die maximale Rekursionstiefe beträgt 10. Die Klausel `WITH` geht der `SELECT`-Liste in einer Abfrage voraus und legt eine oder mehrere Unterabfragen für die Verwendung in der `SELECT`-Abfrage fest. Jede Unterabfrage definiert eine temporäre Tabelle ähnlich wie eine Ansichtdefinition, die mit der `FROM`-Klausel referenziert werden kann. Die Tabellen werden nur verwendet, wenn die Abfrage ausgeführt wird. Die Syntax von `with_query` lautet: ``` subquery_table_name [ ( column_name [, ...] ) ] AS (subquery) ``` Wobei Folgendes gilt: + `subquery_table_name` ist ein eindeutiger Name für eine temporäre Tabelle, die die Ergebnisse der Unterabfrage mit `WITH`-Klausel definiert. Jede `subquery` muss einen Tabellennamen erhalten, der in der `FROM`-Klausel referenziert werden kann. + `column_name [, ...]` ist eine optionale Liste der ausgegebenen Spaltennamen. Die Anzahl der Spaltennamen muss größer als oder gleich der Anzahl der Spalten sein, die von der `subquery` definiert wird. + `subquery` ist eine Abfrageanweisung. **[ ALL \$1 DISTINCT ] select\$1expression** `select_expression` legt die auszuwählenden Zeilen fest. Ein `select_expression` kann eines der folgenden Formate verwenden: ``` expression [ [ AS ] column_alias ] [, ...] ``` ``` row_expression.* [ AS ( column_alias [, ...] ) ] ``` ``` relation.* ``` ``` * ``` + Die `expression [ [ AS ] column_alias ]` Syntax gibt eine Ausgabespalte an. Die optionale `[AS] column_alias`-Syntax gibt einen benutzerdefinierten Überschriftennamen an, der für die Spalte in der Ausgabe verwendet werden soll. + Für `row_expression.* [ AS ( column_alias [, ...] ) ]`, `row_expression` ist ein beliebiger Ausdruck eines Datentyps `ROW`. Die Felder der Zeile definieren die Ausgabespalten, die im Ergebnis enthalten sein sollen. + Für `relation.*`, die Spalten von `relation` sind im Ergebnis enthalten. Diese Syntax erlaubt nicht die Verwendung von Spaltenaliasnamen. + Das Sternchen `*` gibt an, dass alle Spalten in die Ergebnismenge aufgenommen werden. + In der Ergebnismenge entspricht die Reihenfolge der Spalten der Reihenfolge ihrer Angabe durch den Auswahlausdruck. Gibt ein Auswahlausdruck mehrere Spalten gibt, folgt die Spaltenreihenfolge der Reihenfolge, die in der Quellrelation oder im Zeilentypausdruck verwendet wurde. + Sind Spaltenaliase angegeben, überschreiben die Aliase bereits vorhandene Spalten- oder Zeilenfeldnamen. Enthält der Auswahlausdruck keine Spaltennamen, werden anonyme Spaltennamen (`_col0`, `_col1`, `_col2, ...`) mit einem Nullindex in der Ausgabe angezeigt. + `ALL` ist die Standardeinstellung. Bei Verwendung von `ALL` wird dies so behandelt, als wäre kein Wert angegeben worden. Alle Zeilen aller Spalten werden einschließlich Duplikaten ausgewählt. + Verwenden Sie `DISTINCT`, um nur eindeutige Werte zurückzugeben, wenn eine Spalte Duplikatwerte enthält. **FROM from\$1item [,...]** Gibt die Eingabe der Abfrage an, wobei `from_item` eine Ansicht, ein JOIN-Konstrukt oder eine Unterabfrage wie unten beschrieben sein kann. `from_item` kann eines der Folgenden sein: + `table_name [ [ AS ] alias [ (column_alias [, ...]) ] ]` Hier ist `table_name` der Name der Zieltabelle, aus der Zeilen ausgewählt werden. `alias` ist der Name für die Ausgabe der `SELECT`-Anweisung und `column_alias` definiert die Spalten für den angegebenen `alias`. **-ODER-** + `join_type from_item [ ON join_condition | USING ( join_column [, ...] ) ]` Hierbei ist `join_type` eines der Folgenden: + `[ INNER ] JOIN` + `LEFT [ OUTER ] JOIN` + `RIGHT [ OUTER ] JOIN` + `FULL [ OUTER ] JOIN` + `CROSS JOIN` + `ON join_condition | USING (join_column [, ...])` Wobei Sie durch Verwenden von `join_condition` die Spaltennamen für JOIN-Schlüssel in mehreren Tabellen angeben können. Für die Verwendung von `join_column` muss `join_column` in beiden Tabellen vorhanden sein. **[ WHERE condition ]** Filtert Ergebnisse nach dem von Ihnen angegebenen `condition`, wobei `condition` im Allgemeinen die folgende Syntax hat. ``` column_name operator value [[[AND | OR] column_name operator value] ...] ``` Das *operator* kann einer der Komparatoren sein`=`,,`>`,`<`,`>=`, `<=``<>`,`!=`. Die folgenden Unterabfrageausdrücke können auch in der `WHERE`-Klausel verwendet werden. + `[NOT] BETWEEN integer_A AND integer_B` – Gibt einen Bereich zwischen zwei Ganzzahlen an, wie im folgenden Beispiel. Wenn der Spaltendatentyp `varchar` ist, muss die Spalte zuerst in eine Ganzzahl umgewandelt werden. ``` SELECT DISTINCT processid FROM "webdata"."impressions" WHERE cast(processid as int) BETWEEN 1500 and 1800 ORDER BY processid ``` + `[NOT] LIKE value` – Sucht nach dem angegebenen Muster. Verwenden Sie das Prozentzeichen (`%`) als Platzhalterzeichen, wie im folgenden Beispiel. ``` SELECT * FROM "webdata"."impressions" WHERE referrer LIKE '%.org' ``` + `[NOT] IN (value[, value[, ...])` – Gibt eine Liste möglicher Werte für eine Spalte an, wie im folgenden Beispiel gezeigt. ``` SELECT * FROM "webdata"."impressions" WHERE referrer IN ('example.com','example.net','example.org') ``` **[ GROUP BY [ ALL \$1 DISTINCT ] grouping\$1expressions [, ...] ]** Teilt die Ausgabe der `SELECT`-Anweisung in Zeilen mit passenden Werten. Über `ALL` und `DISTINCT` wird festgelegt, ob für Duplikate jeweils eine eigene Ausgabezeile angelegt wird. Wenn nichts angegeben ist, wird von `ALL` ausgegangen. `grouping_expressions` ermöglicht Ihnen, komplexe Gruppierungsoperationen auszuführen. Sie können komplexe Gruppierungsvorgänge verwenden, um Analysen durchzuführen, die eine Aggregation mehrerer Spaltengruppen in einer einzigen Abfrage erfordern. Das `grouping_expressions`-Element kann eine beliebige Funktion sein, z. B. `SUM`, `AVG` oder `COUNT`, die auf Eingabespalten ausgeführt wird. Mithilfe von `GROUP BY`-Ausdrücken kann die Ausgabe nach Eingabespaltennamen gruppiert werden, die nicht in der Ausgabe der `SELECT`-Anweisung auftauchen. Alle Ausgabeausdrücke müssen entweder Aggregatfunktionen oder Spalten sein, die in der `GROUP BY`-Klausel vorhanden sind. Sie können mit einer einzelnen Abfrage eine Analyse durchführen, für die mehrere Spaltensätze zusammengefasst werden müssen. Athena unterstützt komplexe Aggregationen mit `GROUPING SETS`, `CUBE` und `ROLLUP`. `GROUP BY GROUPING SETS` gibt mehrere Spaltenlisten an, nach denen gruppiert werden soll. `GROUP BY CUBE` generiert alle möglichen Gruppierungssätze für einen gegebenen Satz von Spalten. `GROUP BY ROLLUP` generiert alle möglichen Zwischensummen für einen gegebenen Satz von Spalten. Komplexe Gruppierungsoperationen unterstützen keine Gruppierung von Ausdrücken, die aus Eingabespalten bestehen. Es sind nur Spaltennamen zulässig. Oft können Sie mit `UNION ALL` dieselben Ergebnisse erzielen wie mit diesen `GROUP BY`-Operationen. Abfragen, in denen `GROUP BY` verwendet wird, haben jedoch den Vorteil, dass die Daten einmalig ausgelesen werden, wohingegen bei `UNION ALL` die zugrunde liegenden Daten dreimal ausgelesen werden, was zu uneinheitlichen Ergebnissen führen kann, wenn die Datenquelle sich geändert hat. **[ HAVING condition ]** Wird in Aggregatfunktionen und der `GROUP BY`-Klausel verwendet. Kontrolliert, welche Gruppen ausgewählt werden und schließt Gruppen aus, die die `condition` nicht erfüllen. Diese Filterung wird nach der Berechnung der Gruppierungs- und Aggregatfunktionen ausgeführt. **[ \$1 UNION \$1 INTERSECT \$1 EXCEPT \$1 [ ALL \$1 DISTINCT ] union\$1query] ]** `UNION`, `INTERSECT` und`EXCEPT` kombinieren die Ergebnisse mehrerer `SELECT`-Anweisungen in eine einzelne Abfrage. `ALL` oder `DISTINCT` steuern die Eindeutigkeit der Zeilen, die in der endgültigen Ergebnismenge enthalten sind. `UNION` kombiniert die Zeilen, die sich aus der ersten Abfrage ergeben, mit den Zeilen, die aus der zweiten Abfrage resultieren. Um Duplikate zu eliminieren, erstellt `UNION` eine Hash-Tabelle, die Speicher verbraucht. Ziehen Sie für eine bessere Leistung die Verwendung von `UNION ALL` in Betracht, wenn Ihre Abfrage die Eliminierung von Duplikaten nicht erfordert. Mehrere `UNION`-Klauseln werden von links nach rechts verarbeitet, sofern Sie keine Klammern verwenden, um die Verarbeitungsreihenfolge explizit festzulegen. `INTERSECT` gibt nur die Zeilen zurück, die in den Ergebnissen der ersten und der zweiten Abfrage vorhanden sind. `EXCEPT` gibt die Zeilen aus den Ergebnissen der ersten Abfrage zurück, ausgenommen die Zeilen, die von der zweiten Abfrage gefunden wurden. `ALL` bewirkt, dass alle Zeilen aufgenommen werden, auch wenn die Zeilen identisch sind. `DISTINCT` bewirkt, dass nur eindeutige Zeilen in die kombinierte Ergebnismenge aufgenommen werden. **[ ORDER BY expression [ ASC \$1 DESC ] [ NULLS FIRST \$1 NULLS LAST] [, ...] ]** Sortiert eine Ergebnisgruppe nach einem oder mehreren Ausgabe-`expression`. Wenn die Klausel mehrere Ausdrücke enthält, wird die Ergebnisgruppe nach dem ersten `expression` sortiert. Danach wird der zweite `expression` auf die Zeilen mit passenden Werten aus dem ersten Ausdruck angewendet usw. Jeder `expression` kann Ausgabespalten aus `SELECT` oder eine Ordinalzahl für eine Ausgabespalte nach Position (beginnend mit 1) festlegen. `ORDER BY` wird im letzten Schritt nach `GROUP BY`- und `HAVING`-Klauseln ausgewertet. Über `ASC` und `DESC` wird festgelegt, ob die Ergebnisse in auf- oder absteigender Reihenfolge sortiert werden. Standardmäßig ist die Sortierreihenfolge aufsteigend (`ASC`). Die Standardnullsortierung ist `NULLS LAST` unabhängig von auf- oder absteigender Sortierreihenfolge. **[ OFFSET count [ ROW \$1 ROWS ] ]** Verwenden Sie die `OFFSET`-Klausel, um eine Reihe führender Zeilen aus der Ergebnismenge zu verwerfen. Wenn die `ORDER BY`-Klausel vorhanden ist, wird die `OFFSET`-Klausel über eine sortierte Ergebnismenge ausgewertet und die Menge bleibt sortiert, nachdem die übersprungenen Zeilen verworfen wurden. Wenn die Abfrage keine `ORDER BY`-Klausel hat, ist es willkürlich, welche Zeilen verworfen werden. Wenn die durch `OFFSET` angegebene Anzahl der Größe der Ergebnismenge entspricht oder diese überschreitet, ist das Endergebnis leer. **LIMIT [ count \$1 ALL ]** Beschränkt die Anzahl der Zeilen in der Ergebnisgruppe auf `count`. `LIMIT ALL` entspricht dem Weglassen der `LIMIT`-Klausel. Wenn die Abfrage keine `ORDER BY`-Klausel enthält, werden die Ergebnisse zufällig angezeigt. **TABLESAMPLE [ BERNOULLI \$1 SYSTEM ] (percentage)** Optionaler Operator zur Auswahl von Zeilen aus einer Tabelle basierend auf einer Stichprobenmethode. Mit `BERNOULLI` wird jede Zeile mit einer Wahrscheinlichkeit von `percentage` als Teil der Stichprobe ausgewählt. Alle physischen Blöcke der Tabelle werden gescannt und bestimmte Zeilen werden basierend auf einem Vergleich zwischen dem `percentage` der Stichproben und einem zufälligen, zur Laufzeit berechneten Wert übersprungen. Mit `SYSTEM` wird die Tabelle in logische Datensegmente unterteilt. Aus der Tabelle werden Stichproben mit dieser Granularität entnommen. Es werden entweder alle Zeilen aus einem bestimmten Segment ausgewählt oder das Segment wird basierend auf einem Vergleich zwischen dem `percentage` der Stichprobe und einem zufälligen, während der Laufzeit berechneten Wert übersprungen. `SYSTEM`-Stichproben sind abhängig vom Connector. Mit dieser Methode kann keine unabhängige Stichprobenwahrscheinlichkeit garantiert werden. **[ UNNEST (array\$1or\$1map) [WITH ORDINALITY] ]** Erweitert ein Array oder eine Zuordnung in eine Beziehung. Arrays werden in eine einzelne Spalte erweitert. Zuordnungen werden in zwei Spalten (*Schlüssel* und *Wert*) erweitert. Sie können `UNNEST` mit mehreren Argumenten verwenden, die in mehrere Spalten mit so vielen Zeilen wie das höchste Kardinalitätsargument erweitert werden. Andere Spalten werden mit Nullen aufgefüllt. Die `WITH ORDINALITY`-Klausel fügt eine Ordinalitätsspalte am Ende hinzu. `UNNEST` wird normalerweise mit einem `JOIN` verwendet und kann auf Spalten von Beziehungen links des `JOIN` verweisen. ## Abrufen der Dateispeicherorte für Quelldaten in Amazon S3 Um den Speicherort der Amazon-S3-Datei für die Daten in einer Tabellenzeile anzuzeigen, können Sie `"$path"` in einer `SELECT`-Abfrage verwenden, wie im folgenden Beispiel: ``` SELECT "$path" FROM "my_database"."my_table" WHERE year=2019; ``` Dies gibt ein Ergebnis wie das folgende zurück: ``` s3://amzn-s3-demo-bucket/datasets_mytable/year=2019/data_file1.json ``` Um eine sortierte, eindeutige Liste der S3-Dateinamenspfade für die Daten in einer Tabelle zurückzugeben, können Sie wie im folgenden Beispiel `SELECT DISTINCT` und `ORDER BY` verwenden. ``` SELECT DISTINCT "$path" AS data_source_file FROM sampledb.elb_logs ORDER By data_source_file ASC ``` Um nur die Dateinamen ohne Pfad zurückzugeben, können Sie `"$path"` wie im folgenden Beispiel als Parameter an eine `regexp_extract`-Funktion übergeben. ``` SELECT DISTINCT regexp_extract("$path", '[^/]+$') AS data_source_file FROM sampledb.elb_logs ORDER By data_source_file ASC ``` Um die Daten aus einer bestimmten Datei zurückzugeben, geben Sie die Datei in der `WHERE`-Klausel an, wie im folgenden Beispiel. ``` SELECT *,"$path" FROM my_database.my_table WHERE "$path" = 's3://amzn-s3-demo-bucket/my_table/my_partition/file-01.csv' ``` Weitere Informationen und Beispiele finden Sie im Wissenscenter-Artikel [Wie kann ich die Amazon-S3-Quelldatei für eine Zeile in einer Athena-Tabelle anzeigen?](https://aws.amazon.com/premiumsupport/knowledge-center/find-s3-source-file-athena-table-row/). **Anmerkung** In Athena, Hive oder Iceberg werden die versteckten Metadatenspalten `$bucket`, `$file_modified_time`, `$file_size` und `$partition` für Ansichten nicht unterstützt. ## Maskieren von einfachen Anführungszeichen mit Escape Um ein einzelnes Anführungszeichen mit Escape zu maskieren, stellen Sie ihm ein weiteres einfaches Anführungszeichen voran, wie im folgenden Beispiel. Verwechseln Sie dies nicht mit einem doppelten Anführungszeichen. ``` Select 'O''Reilly' ``` **Ergebnisse** `O'Reilly` ## Weitere Ressourcen Weitere Informationen zur Verwendung von `SELECT`-Anweisungen in Athena finden Sie in den folgenden Ressourcen. | Weitere Informationen darüber | Sehen Sie dies an | | --- | --- | | Ausführen von Abfragen in Athena | [Ausführen von SQL-Abfragen in Amazon Athena](querying-athena-tables.md) | | Mit SELECT eine Tabelle erstellen | [Erstellen einer Tabelle aus Abfrageergebnissen (CTAS)](ctas.md) | | Einfügen von Daten aus einer SELECT-Abfrage in eine andere Tabelle | [INSERT INTO](insert-into.md) | | Integrierte Funktionen in SELECT-Anweisungen verwenden | [Funktionen in Amazon Athena](functions.md) | | Verwenden von benutzerdefinierten Funktionen in SELECT-Anweisungen | [Abfragen mit benutzerdefinierten Funktionen](querying-udf.md) | | Metadaten des Datenkatalogs abfragen | [Fragen Sie die ab AWS Glue Data Catalog](querying-glue-catalog.md) | # INSERT INTO Fügt neue Zeilen in eine Zieltabelle ein, basierend auf einer `SELECT`-Abfrageanweisung, die in einer Quelltabelle ausgeführt wird, oder basierend auf einem Satz von `VALUES`, der als Teil der Anweisung bereitgestellt wird. Wenn die Quelltabelle auf zugrunde liegenden Daten in einem Format wie CSV oder JSON basiert und die Zieltabelle auf einem anderen Format wie Parquet oder ORC basiert, können Sie `INSERT INTO`-Abfragen verwenden, um ausgewählte Daten in das Format der Zieltabelle zu transformieren. ## Überlegungen und Einschränkungen Beachten Sie Folgendes, wenn Sie `INSERT`-Abfragen mit Athena verwenden. + Wenn Sie eine `INSERT`-Abfrage für eine Tabelle mit zugrunde liegenden Daten ausführen, die in Amazon S3 verschlüsselt sind, werden die Ausgabedateien, die die `INSERT`-Abfrage schreibt, standardmäßig nicht verschlüsselt. Wir empfehlen, `INSERT`-Abfrageergebnisse zu verschlüsseln, wenn Sie in Tabellen mit verschlüsselten Daten einfügen. Weitere Informationen zum Verschlüsseln von Abfrageergebnissen mithilfe der Konsole finden Sie unter [Verschlüsseln Sie die in Amazon S3 gespeicherten Athena-Abfrageergebnisse](encrypting-query-results-stored-in-s3.md). Um die Verschlüsselung mit der AWS CLI oder der Athena-API zu aktivieren, verwenden Sie die `EncryptionConfiguration` Eigenschaften der [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html)Aktion, um Amazon S3 S3-Verschlüsselungsoptionen gemäß Ihren Anforderungen festzulegen. + Für `INSERT INTO`-Anweisungen gilt die erwartete Bucket-Eigentümereinstellung nicht für den Speicherort der Zieltabelle in Amazon S3. Die erwartete Bucket-Eigentümereinstellung gilt nur für den Amazon-S3-Ausgabespeicherort, den Sie für Athena-Abfrageergebnisse angeben. Weitere Informationen finden Sie unter [Angeben eines Speicherorts des Abfrageergebnisses mithilfe der Athena-Konsole](query-results-specify-location-console.md). + ACID-konforme `INSERT INTO`-Anweisungen finden Sie im `INSERT INTO`-Abschnitt von [Iceberg-Tabellendaten aktualisieren](querying-iceberg-updating-iceberg-table-data.md). ### Unterstützte Formate und SerDes Sie können eine `INSERT` Abfrage für Tabellen ausführen, die aus Daten mit den folgenden Formaten und erstellt wurden SerDes. | Data format (Datenformat) | SerDe | | --- | --- | | Avro | org.apache.hadoop.hive.serde2.avro. AvroSerDe | | Ion | com.amazon.ionhiveserde. IonHiveSerDe | | JSON | org.apache.hive.hcatalog.data. JsonSerDe | | ORC | org.apache.hadoop.hive.ql.io.orc. OrcSerde | | Parquet | org.apache.hadoop.hive.ql.io.parquet.serde. ParquetHiveSerDe | | Textdatei | org.apache.hadoop.hive.serde2.lazy. LazySimpleSerDe TSV- und benutzerdefinierte, durch Trennzeichen getrennte Dateien werden unterstützt. | | CSV | org.apache.hadoop.hive.serde2.open CSVSerde Schreibvorgänge werden nur für String-Typen unterstützt. Von Athena aus können Sie nicht in Tabellen schreiben, die Nicht-String-Typen im Glue-Schema enthalten. [Weitere Informationen finden Sie unter CSV. SerDe](csv-serde.md#csv-serde-opencsvserde-considerations-non-string) | ### Bucket-Tabellen werden nicht unterstützt `INSERT INTO` wird für Bucket-Tabellen nicht unterstützt. Weitere Informationen finden Sie unter [Partitionierung und Bucketing verwenden](ctas-partitioning-and-bucketing.md). ### Verbundabfragen werden nicht unterstützt `INSERT INTO` wird für Verbundabfragen nicht unterstützt. Ein Versuch, dies zu tun, kann zur Fehlermeldung führen: Dieser Vorgang wird derzeit für externe Kataloge nicht unterstützt. Weitere Informationen zu Verbundabfragen finden Sie unter [Nutzung von Amazon-Athena-Verbundabfrage](federated-queries.md). ### Partitionierung Beachten Sie die Punkte in diesem Abschnitt, wenn Sie die Partitionierung mit `INSERT INTO`- oder `CREATE TABLE AS SELECT`-Abfragen verwenden. #### Einschränkungen Die Anweisung `INSERT INTO` unterstützt das Schreiben von maximal 100 Partitionen in die Zieltabelle. Wenn Sie die `SELECT`-Klausel für eine Tabelle mit mehr als 100 Partitionen ausführen, schlägt die Abfrage fehl, es sei denn, die `SELECT`-Abfrage ist auf 100 Partitionen oder weniger beschränkt. Hinweise zum Umgehen dieser Einschränkung finden Sie unter [Verwenden von CTAS und INSERT INTO zum Umgehen des Limits von 100 Partitionen](ctas-insert-into.md). #### Spalten-Reihenfolge `INSERT INTO`- oder `CREATE TABLE AS SELECT`-Anweisungen erwarten, dass die partitionierte Spalte die letzte Spalte in der Liste der projizierten Spalten in einer `SELECT`-Anweisung ist. Wenn die Quelltabelle nicht partitioniert ist oder im Vergleich zur Zieltabelle auf verschiedene Spalten partitioniert ist, betrachten Abfragen wie `INSERT INTO destination_table SELECT * FROM source_table` die Werte in der letzten Spalte der Quelltabelle als Werte für eine Partitionsspalte in der Zieltabelle. Beachten Sie dies beim Versuch, eine partitionierte Tabelle aus einer nicht partitionierten Tabelle zu erstellen. #### Ressourcen Weitere Informationen zur Verwendung von `INSERT INTO` mit Partitionierung finden Sie in den folgenden Ressourcen. + Hinweise zum Einfügen von partitionierten Daten in eine partitionierte Tabelle finden Sie unter [Verwenden von CTAS und INSERT INTO zum Umgehen des Limits von 100 Partitionen](ctas-insert-into.md). + Hinweise zum Einfügen von nicht-partitionierten Daten in eine partitionierte Tabelle finden Sie unter [Verwenden von CTAS und INSERT INTO für ETL und Datenanalyse](ctas-insert-into-etl.md). ### In Amazon S3 geschriebene Dateien Athena schreibt Dateien in die Quelldatenspeicherorte in Amazon S3 als Ergebnis des `INSERT`-Befehls. Jede `INSERT`-Operation erstellt eine neue Datei, anstatt an eine vorhandene Datei anzuhängen. Die Dateispeicherorte hängen von der Struktur der Tabelle und ggf. der `SELECT`-Abfrage ab. Athena generiert für jede `INSERT`-Abfrage eine Daten-Manifest-Datei. Das Manifest verfolgt die Dateien, die die Abfrage geschrieben hat. Es wird im Verzeichnis der Athena-Abfrageergebnisse in Amazon S3 gespeichert. Weitere Informationen finden Sie unter [Identifizieren von Abfrageausgabedateien](querying-finding-output-files.md#querying-identifying-output-files). ### Transaktionsintensive Aktualisierungen vermeiden Wenn Sie `INSERT INTO` verwenden um Zeilen zu einer Tabelle in Amazon S3 hinzufügen, schreibt Athena keine vorhandenen Dateien neu und nimmt auch keine Änderungen daran vor. Stattdessen schreibt es die Zeilen als eine oder mehrere neue Dateien. Da Tabellen mit [vielen kleinen Dateien zu einer geringeren Abfrageleistung führen](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files) und Schreib- und Lesevorgänge wie `PutObject` und `GetObject` zu höheren Kosten von Amazon S3 führen, sollten Sie bei der Verwendung von `INSERT INTO` die folgenden Optionen in Betracht ziehen: + Führen Sie `INSERT INTO`-Operationen seltener für größere Stapel von Zeilen aus. + Bei großen Datenerfassungsmengen sollten Sie einen Service wie [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) in Betracht ziehen. + Vermeiden Sie gänzlich die Verwendung von `INSERT INTO`. Sammeln Sie stattdessen Zeilen in größeren Dateien und laden Sie sie direkt auf Amazon S3 hoch, wo sie von Athena abgefragt werden können. ### Suchen verwaister Dateien Wenn eine `CTAS` oder `INSERT INTO`-Anweisung fehlschlägt, können verwaiste Daten an dem Datenspeicherort verbleiben und möglicherweise in nachfolgenden Abfragen gelesen werden. Zur Suche nach verwaisten Dateien zwecks Überprüfung oder Löschung können Sie die Daten-Manifest-Datei verwenden, die Athena zur Verfügung stellt, um die Liste der zu schreibenden Dateien zu verfolgen. Weitere Informationen erhalten Sie unter [Identifizieren von Abfrageausgabedateien](querying-finding-output-files.md#querying-identifying-output-files) und [DataManifestLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_QueryExecutionStatistics.html#athena-Type-QueryExecutionStatistics-DataManifestLocation). ## INSERT INTO...SELECT Gibt die Abfrage an, die für eine Tabelle ausgeführt werden soll, `source_table`, die festlegt, welche Zeilen in eine zweite Tabelle eingefügt werden sollen, `destination_table`. Wenn die `SELECT`-Abfrage Spalten in der `source_table` angibt, müssen die Spalten genau mit denen in der `destination_table` übereinstimmen. Weitere Informationen zu `SELECT`-Abfragen finden Sie unter [SELECT](select.md). ### Syntax ``` INSERT INTO destination_table SELECT select_query FROM source_table_or_view ``` ### Beispiele Wählen Sie alle Zeilen in der `vancouver_pageviews`-Tabelle aus und fügen Sie sie in die `canada_pageviews`-Tabelle ein: ``` INSERT INTO canada_pageviews SELECT * FROM vancouver_pageviews; ``` Wählen Sie nur die Zeilen in der `vancouver_pageviews`-Tabelle aus, in denen die `date`-Spalte einen Wert zwischen `2019-07-01` und `2019-07-31` hat, und fügen Sie sie dann in `canada_july_pageviews` ein: ``` INSERT INTO canada_july_pageviews SELECT * FROM vancouver_pageviews WHERE date BETWEEN date '2019-07-01' AND '2019-07-31'; ``` Wählen Sie die Werte in den Spalten `city` und `state` in der `cities_world`-Tabelle nur aus den Zeilen mit dem Wert `usa` in der Spalte `country` aus und fügen Sie sie in die Spalten `city` und `state` in der `cities_usa`-Tabelle ein: ``` INSERT INTO cities_usa (city,state) SELECT city,state FROM cities_world WHERE country='usa' ``` ## INSERT INTO...VALUES Fügt Zeilen in eine vorhandene Tabelle ein, indem Spalten und Werte angegeben werden. Angegebene Spalten und zugehörige Datentypen müssen genau mit den Spalten und Datentypen in der Zieltabelle übereinstimmen. **Wichtig** Wir raten davon ab, Zeilen mit `VALUES` einzufügen, da Athena Dateien für jede `INSERT`-Operation generiert. Dies kann dazu führen, dass viele kleine Dateien erstellt werden und die Abfrageleistung der Tabelle beeinträchtigen. Um Dateien zu identifizieren, die eine `INSERT`-Abfrage erstellt, überprüfen Sie die Daten-Manifest-Datei. Weitere Informationen finden Sie unter [Arbeiten mit Abfrageergebnissen und aktuellen Abfragen](querying.md). ### Syntax ``` INSERT INTO destination_table [(col1,col2,...)] VALUES (col1value,col2value,...)[, (col1value,col2value,...)][, ...] ``` ### Beispiele In den folgenden Beispielen hat die Tabelle "cities" drei Spalten: `id`, `city`, `state`, `state_motto`. Die `id`-Spalte hat den Typ `INT` und alle anderen Spalten haben den Typ `VARCHAR`. Fügen Sie eine einzelne Zeile in die `cities`-Tabelle ein, wobei alle Spaltenwerte angegeben sind: ``` INSERT INTO cities VALUES (1,'Lansing','MI','Si quaeris peninsulam amoenam circumspice') ``` Fügen Sie zwei Zeilen in die `cities`-Tabelle ein: ``` INSERT INTO cities VALUES (1,'Lansing','MI','Si quaeris peninsulam amoenam circumspice'), (3,'Boise','ID','Esto perpetua') ``` # VALUES Erzeugt eine literale Inlinetabelle. Die Tabelle kann anonym sein, oder Sie können die `AS`-Klausel verwenden, um einen Tabellennamen, Spaltennamen oder beides anzugeben. ## Syntax ``` VALUES row [, ...] ``` ## Parameters **Zeile** Der `row`-Parameter kann ein einzelner Ausdruck oder `( column_expression [, ...] )` sein. ## Beispiele Gibt eine Tabelle mit einer Spalte und drei Zeilen zurück: ``` VALUES 1, 2, 3 ``` Gibt eine Tabelle mit zwei Spalten und drei Zeilen zurück: ``` VALUES (1, 'a'), (2, 'b'), (3, 'c') ``` Gibt eine Tabelle mit den Spalten `id` und`name` zurück: ``` SELECT * FROM ( VALUES (1, 'a'), (2, 'b'), (3, 'c') ) AS t (id, name) ``` Erstellen Sie eine Tabelle namens `customers` mit den Spalten `id` und `name`: ``` CREATE TABLE customers AS SELECT * FROM ( VALUES (1, 'a'), (2, 'b'), (3, 'c') ) AS t (id, name) ``` ## Weitere Informationen finden Sie auch unter [INSERT INTO...VALUES](insert-into.md#insert-into-values) # DELETE Löscht Zeilen in einer Apache-Iceberg-Tabelle. `DELETE` ist transaktionsbasiert und wird nur für Apache-Iceberg-Tabellen unterstützt. ## Syntax Verwenden Sie die folgende Syntax, um die Zeilen in einer Iceberg-Tabelle zu löschen. ``` DELETE FROM [db_name.]table_name [WHERE predicate] ``` Weitere Informationen und Beispiele finden Sie im `DELETE`-Abschnitt von [Iceberg-Tabellendaten aktualisieren](querying-iceberg-updating-iceberg-table-data.md). # UPDATE Aktualisiert Zeilen in einer Apache-Iceberg-Tabelle. `UPDATE` ist transaktionsbasiert und wird nur für Apache-Iceberg-Tabellen unterstützt. Die Anweisung funktioniert nur für bestehende Zeilen und kann nicht zum Einfügen oder Anhängen einer Zeile verwendet werden. ## Syntax Verwenden Sie die folgende Syntax, um die Zeilen in einer Iceberg-Tabelle zu aktualisieren. ``` UPDATE [db_name.]table_name SET xx=yy[,...] [WHERE predicate] ``` Weitere Informationen und Beispiele finden Sie im `UPDATE`-Abschnitt von [Iceberg-Tabellendaten aktualisieren](querying-iceberg-updating-iceberg-table-data.md). # MERGE INTO Aktualisiert, löscht oder fügt Zeilen in eine Apache-Iceberg-Tabelle ein. Eine einzige Anweisung kann Aktionen zum Aktualisieren, Löschen und Einfügen kombinieren. **Anmerkung** `MERGE INTO` ist transaktionsbasiert und wird nur für Apache-Iceberg-Tabellen in Athena-Engine-Version 3 unterstützt. ## Syntax Verwenden Sie die folgende Syntax, um Zeilen in einer Iceberg-Tabelle bedingt zu aktualisieren, zu löschen oder einzufügen. ``` MERGE INTO target_table [ [ AS ] target_alias ] USING { source_table | query } [ [ AS ] source_alias ] ON search_condition when_clause [...] ``` Das *when\$1clause* ist einer der folgenden: ``` WHEN MATCHED [ AND condition ] THEN DELETE ``` ``` WHEN MATCHED [ AND condition ] THEN UPDATE SET ( column = expression [, ...] ) ``` ``` WHEN NOT MATCHED [ AND condition ] THEN INSERT (column_name[, column_name ...]) VALUES (expression, ...) ``` `MERGE` unterstützt eine beliebige Anzahl von `WHEN`-Klauseln mit unterschiedlichen `MATCHED`-Bedingungen. Die Bedingungsklauseln führen die `DELETE`, `UPDATE` oder `INSERT`-Operation in der ersten `WHEN`-Klausel aus, die durch den `MATCHED`-Zustand und die Übereinstimmungsbedingung ausgewählt wurde. Für jede Quellzeile werden die `WHEN`-Klauseln der Reihe nach verarbeitet. Nur die erste übereinstimmende `WHEN`-Klausel wird ausgeführt. Nachfolgende Klauseln werden ignoriert. Ein Benutzerfehler wird ausgegeben, wenn eine einzelne Zeile der Zieltabelle mit mehr als einer Quellzeile übereinstimmt. Wenn eine Quellzeile mit keiner `WHEN`-Klausel übereinstimmt und es keine `WHEN NOT MATCHED`-Klausel gibt, wird die Quellzeile ignoriert. In `WHEN`-Klauseln mit `UPDATE`-Operationen können sich die Spaltenwertausdrücke auf jedes Feld des Ziels oder der Quelle beziehen. Im `NOT MATCHED`-Fall können sich die `INSERT`-Ausdrücke auf ein beliebiges Feld der Quelle beziehen. **Beispiel** Im folgenden Beispiel werden Zeilen aus der zweiten Tabelle mit der ersten Tabelle zusammengeführt, wenn die Zeilen in der ersten Tabelle nicht vorhanden sind. Beachten Sie, dass den in der `VALUES`-Klausel aufgeführten Spalten der Alias der Quelltabelle vorangestellt werden muss. Den in der `INSERT`-Klausel aufgeführten Zielspalten darf *kein* solches Präfix vorangestellt werden. ``` MERGE INTO iceberg_table_sample as ice1 USING iceberg2_table_sample as ice2 ON ice1.col1 = ice2.col1 WHEN NOT MATCHED THEN INSERT (col1) VALUES (ice2.col1) ``` Weitere `MERGE INTO`-Beispiele finden Sie unter [Iceberg-Tabellendaten aktualisieren](querying-iceberg-updating-iceberg-table-data.md). # OPTIMIZE Optimiert Zeilen in einer Apache-Iceberg-Tabelle durch Umschreiben von Datendateien in ein optimiertes Layout basierend auf deren Größe und der Anzahl der zugeordneten Löschdateien. **Anmerkung** `OPTIMIZE` ist transaktionsbasiert und wird nur für Apache-Iceberg-Tabellen unterstützt. ## Syntax Die folgende Syntaxzusammenfassung zeigt, wie das Datenlayout für eine Iceberg-Tabelle optimiert wird. ``` OPTIMIZE [db_name.]table_name REWRITE DATA USING BIN_PACK [WHERE predicate] ``` **Anmerkung** In der `WHERE` Klausel sind nur Partitionsspalten zulässig*predicate*. Wenn Sie eine Spalte angeben, die nicht partitioniert ist, schlägt die Abfrage fehl. Die Verdichtungsaktion wird durch die Datenmenge berechnet, die während des Umschreibungsvorgangs gescannt wurde. Die `REWRITE DATA`-Aktion verwendet Prädikate zur Auswahl für Dateien, die übereinstimmende Zeilen enthalten. Wenn eine Zeile in der Datei mit dem Prädikat übereinstimmt, wird die Datei zur Optimierung ausgewählt. Um also die Anzahl der von der Verdichtungsoperation betroffenen Dateien zu steuern, können Sie eine `WHERE`-Klausel angeben. ## Konfigurieren von Komprimierungs-Eigenschaften Um die Größe der für die Verdichtung zu wählenden Dateien und die resultierende Dateigröße nach der Verdichtung zu steuern, können Sie Tabelleneigenschaftsparameter verwenden. Sie können den [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md)-Befehl verwenden, um die zugehörigen [Tabelleneigenschaften](querying-iceberg-creating-tables.md#querying-iceberg-table-properties) zu konfigurieren. ## Weitere Ressourcen [Iceberg-Tabellen optimieren](querying-iceberg-data-optimization.md) # VACUUM Die `VACUUM`-Anweisung führt Wartung von Apache-Iceberg-Tabellen durch, indem sie das [Ablaufen von Snapshots](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) und [Entfernen verwaister Dateien](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files) durchführt . **Anmerkung** `VACUUM` ist transaktionsbasiert und wird nur für Apache-Iceberg-Tabellen in Athena-Engine-Version 3 unterstützt. Die `VACUUM`-Anweisung optimiert Iceberg-Tabellen, indem sie den Speicherverbrauch reduziert. Weitere Informationen zur Verwendung von `VACUUM` finden Sie unter [Iceberg-Tabellen optimieren](querying-iceberg-data-optimization.md). Beachten Sie, dass für die damit verbundenen Anfragen an Amazon S3 Gebühren anfallen, da die `VACUUM`-Anweisung API-Aufrufe an Amazon S3 tätigt. **Warnung** Wenn Sie einen Snapshot-Ablauf ausführen, können Sie nicht mehr zu abgelaufenen Snapshots reisen. ## Syntax Verwenden Sie die folgende Syntax, um Datendateien zu entfernen, die für eine Iceberg-Tabelle nicht mehr benötigt werden. ``` VACUUM [database_name.]target_table ``` + `VACUUM` erwartet, dass sich die Iceberg-Daten in einem Amazon-S3-Ordner und nicht in einem Amazon-S3-Bucket befinden. Wenn sich Ihre Iceberg-Daten beispielsweise auf `s3://amzn-s3-demo-bucket`/ statt auf `s3://amzn-s3-demo-bucket/myicebergfolder/` befinden, schlägt die `VACUUM`-Anweisung mit der Fehlermeldung GENERIC\$1INTERNAL\$1ERROR: Pfad fehlt im Dateisystem: `s3://amzn-s3-demo-bucket` fehl. + Damit `VACUUM` Datendateien löschen kann, muss Ihre Rolle zur Abfrageausführung über `s3:DeleteObject`-Berechtigungen für den Bucket verfügen, in dem sich Ihre Iceberg-Tabellen, Metadaten, Snapshots und Datendateien befinden. Wenn die Berechtigung nicht vorhanden ist, ist die `VACUUM`-Abfrage erfolgreich, aber die Dateien werden nicht gelöscht. + Um `VACUUM` auf eine Tabelle auszuführen, deren Name mit einem Unterstrich beginnt (z. B. `_mytable`), schließen Sie den Tabellennamen in umgekehrte Anführungszeichen ein, wie im folgenden Beispiel. Wenn Sie dem Tabellennamen einen Datenbanknamen voranstellen, schließen Sie den Datenbanknamen nicht in umgekehrte Anführungszeichen ein. Beachten Sie, dass doppelte Anführungszeichen nicht anstelle von umgekehrte Anführungszeichen funktionieren. Dieses Verhalten ist spezifisch für `VACUUM`. Die `CREATE` und `INSERT INTO`-Anweisungen erfordern keine umgekehrte Anführungszeichen für Tabellennamen, die mit Unterstrichen beginnen. ``` VACUUM `_mytable` VACUUM my_database.`_mytable` ``` ## Durchgeführte Operationen `VACUUM` führt die folgenden Operationen aus: + Entfernt Snapshots, die älter sind als die durch die `vacuum_max_snapshot_age_seconds`-Tabelleneigenschaft angegebene Zeitdauer. Standardmäßig ist diese Eigenschaft auf 432 000 Sekunden (5 Tage) festgelegt. + Entfernt Snapshots, die nicht innerhalb des Aufbewahrungszeitraums liegen und die die in der `vacuum_min_snapshots_to_keep`-Tabelleneigenschaft angegebene Anzahl überschreiten. Der Standardwert ist 1. Sie können diese Tabelleneigenschaften in Ihrer `CREATE TABLE`-Anweisung angeben. Nachdem die Tabelle erstellt wurde, können Sie diese mit der [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md)-Anweisung aktualisieren. + Entfernt alle Metadaten und Datendateien, die aufgrund des Entfernens des Snapshots nicht mehr erreichbar sind. Sie können die Anzahl der alten Metadatendateien, die beibehalten werden sollen, konfigurieren, indem Sie die `vacuum_max_metadata_files_to_keep`-Tabelleneigenschaft festlegen. Der Standardwert lautet 100. + Entfernt verwaiste Dateien, die älter sind als die in der `vacuum_max_snapshot_age_seconds`-Tabelleneigenschaft angegebene Zeit. Verwaiste Dateien sind Dateien im Datenverzeichnis der Tabelle, die nicht mehr Teil des Tabellenstatus sind. Weitere Informationen zur Erstellung und Verwaltung von Apache-Iceberg-Tabellen in Athena finden Sie unter [Iceberg-Tabellen erstellen](querying-iceberg-creating-tables.md) und [Iceberg-Tabellen verwalten](querying-iceberg-managing-tables.md). # Verwenden von EXPLAIN und EXPLAIN ANALYZE in Athena Die `EXPLAIN`-Anweisung zeigt den logischen oder verteilten Ausführungsplan einer angegebenen SQL-Anweisung oder validiert die SQL-Anweisung. Sie können die Ergebnisse im Textformat oder in einem Datenformat für das Rendern in einem Diagramm ausgeben. **Anmerkung** Sie können grafische Darstellungen logischer und verteilter Pläne für Ihre Abfragen in der Athena-Konsole anzeigen, ohne die `EXPLAIN`-Dateisyntax zu verwenden. Weitere Informationen finden Sie unter [Anzeigen von Ausführungsplänen für SQL-Abfragen](query-plans.md). Die `EXPLAIN ANALYZE`-Anweisung zeigt sowohl den verteilten Ausführungsplan einer angegebenen SQL-Anweisung als auch die Rechenkosten jeder Operation in einer SQL-Abfrage an. Sie können die Ergebnisse im Text- oder JSON-Format ausgeben. ## Überlegungen und Einschränkungen Die `EXPLAIN`- und `EXPLAIN ANALYZE`-Anweisungen in Athena unterliegen den folgenden Einschränkungen. + Da `EXPLAIN`-Abfragen keine Daten scannen, berechnet Athena keine Gebühren. Da `EXPLAIN`-Abfragen jedoch AWS Glue aufrufen, um Tabellen-Metadaten abzurufen, können Gebühren von Glue anfallen, wenn die Anrufe das [kostenlose Kontingent für Glue](https://aws.amazon.com/free/?all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Categories=categories%23analytics&all-free-tier.q=glue&all-free-tier.q_operator=AND) überschreiten. + Weil `EXPLAIN ANALYZE`-Abfragen ausgeführt werden, scannen sie Daten und Athena berechnet die gescannte Datenmenge. + Die in Lake Formation definierten Zeilen- oder Zellenfilterinformationen und die Abfragestatistikinformationen werden in der Ausgabe von `EXPLAIN` und `EXPLAIN ANALYZE` nicht angezeigt. ## EXPLAIN-Syntax ``` EXPLAIN [ ( option [, ...]) ] statement ``` *option* kann einer der folgenden sein: ``` FORMAT { TEXT | GRAPHVIZ | JSON } TYPE { LOGICAL | DISTRIBUTED | VALIDATE | IO } ``` Wenn die Option `FORMAT` nicht angegeben ist, wird standardmäßig das `TEXT`-Format ausgegeben. Der `IO`-Typ stellt Informationen zu den Tabellen und Schemas bereit, die die Abfrage liest. ## EXPLAIN-ANALYZE-Syntax Zusätzlich zu der in `EXPLAIN` enthaltenen Ausgabe enthält die `EXPLAIN ANALYZE`-Ausgabe auch Laufzeitstatistiken für die angegebene Abfrage, z. B. die CPU-Auslastung, die Anzahl der Eingabezeilen und die Anzahl der Ausgabezeilen. ``` EXPLAIN ANALYZE [ ( option [, ...]) ] statement ``` *option* kann einer der folgenden sein: ``` FORMAT { TEXT | JSON } ``` Wenn die Option `FORMAT` nicht angegeben ist, wird standardmäßig das `TEXT`-Format ausgegeben. Weil alle Abfragen für `EXPLAIN ANALYZE` `DISTRIBUTED` sind, ist die Option `TYPE` für `EXPLAIN ANALYZE` nicht verfügbar. *statement* kann einer der folgenden sein: ``` SELECT CREATE TABLE AS SELECT INSERT UNLOAD ``` ## EXPLAIN-Beispiele Die folgenden Beispiele für `EXPLAIN` entwickeln sich von den einfacheren zu den komplexeren Beispielen. ### Beispiel 1: Verwenden Sie die EXPLAIN-Anweisung, um einen Abfrageplan im Textformat anzuzeigen Das folgende Beispiel `EXPLAIN` zeigt den Ausführungsplan für eine `SELECT`-Abfrage für Elastic-Load-Balancing-Protokolle. Das Format ist standardmäßig die Textausgabe. ``` EXPLAIN SELECT request_timestamp, elb_name, request_ip FROM sampledb.elb_logs; ``` #### Ergebnisse ``` - Output[request_timestamp, elb_name, request_ip] => [[request_timestamp, elb_name, request_ip]] - RemoteExchange[GATHER] => [[request_timestamp, elb_name, request_ip]] - TableScan[awsdatacatalog:HiveTableHandle{schemaName=sampledb, tableName=elb_logs, analyzePartitionValues=Optional.empty}] => [[request_timestamp, elb_name, request_ip]] LAYOUT: sampledb.elb_logs request_ip := request_ip:string:2:REGULAR request_timestamp := request_timestamp:string:0:REGULAR elb_name := elb_name:string:1:REGULAR ``` ### Beispiel 2: Verwenden Sie EXPLAIN um einen Abfrageplan grafisch darstellen Sie können mit der Athena-Konsole einen Abfrageplan grafisch darstellen. Geben Sie eine `SELECT`-Anweisung wie die folgende im Athena-Abfrage-Editor ein und wählen Sie dann **EXPLAIN** (Erklären) aus. ``` SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.customer c JOIN tpch100.orders o ON c.c_custkey = o.o_custkey ``` Die **Explain**-Seite des Athena-Abfrage-Editors wird geöffnet und zeigt Ihnen einen verteilten Plan und einen logischen Plan für die Abfrage. Das folgende Diagramm zeigt den logischen Plan für das Beispiel. ![\[Diagramm des vom Athena-Abfrage-Editor gerenderten Abfrageplans.\]](http://docs.aws.amazon.com/de_de/athena/latest/ug/images/athena-explain-statement-tpch.png) **Wichtig** Derzeit sind einige Partitionsfilter im verschachtelten Operator-Baumdiagramm möglicherweise nicht sichtbar, obwohl Athena sie auf Ihre Abfrage anwendet. Um die Wirkung solcher Filter zu überprüfen, führen Sie `EXPLAIN` oder `EXPLAIN ANALYZE` auf Ihre Anfrage aus und sehen Sie sich die Ergebnisse an. Weitere Informationen zur Verwendung der Abfrageplan-Diagrammfeatures in der Athena-Konsole finden Sie unter [Anzeigen von Ausführungsplänen für SQL-Abfragen](query-plans.md). ### Beispiel 3. Verwenden Sie die EXPLAIN-Anweisung, um das Partition Pruning zu überprüfen Wenn Sie ein Filterprädikat für einen partitionierten Schlüssel verwenden, um eine partitionierte Tabelle abzufragen, wendet das Abfragemodul das Prädikat auf den partitionierten Schlüssel an, um die Menge der gelesenen Daten zu reduzieren. Im folgenden Beispiel wird eine `EXPLAIN`-Abfrage verwendet, um die Partitionsbereinigung für eine `SELECT`-Abfrage in einer partitionierten Tabelle zu überprüfen. Zuerst erstellt eine `CREATE TABLE`-Anweisung die `tpch100.orders_partitioned`-Tabelle. Die Tabelle ist nach Spalte `o_orderdate` partitioniert. ``` CREATE TABLE `tpch100.orders_partitioned`( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_totalprice` double, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string) PARTITIONED BY ( `o_orderdate` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket//' ``` Die `tpch100.orders_partitioned`-Tabelle hat mehrere Partitionen auf `o_orderdate`, wie der Befehl `SHOW PARTITIONS` zeigt. ``` SHOW PARTITIONS tpch100.orders_partitioned; o_orderdate=1994 o_orderdate=2015 o_orderdate=1998 o_orderdate=1995 o_orderdate=1993 o_orderdate=1997 o_orderdate=1992 o_orderdate=1996 ``` Die folgende `EXPLAIN`-Abfrage überprüft die Partitionsbereinigung für die angegebene `SELECT`-Anweisung. ``` EXPLAIN SELECT o_orderkey, o_custkey, o_orderdate FROM tpch100.orders_partitioned WHERE o_orderdate = '1995' ``` #### Ergebnisse ``` Query Plan - Output[o_orderkey, o_custkey, o_orderdate] => [[o_orderkey, o_custkey, o_orderdate]] - RemoteExchange[GATHER] => [[o_orderkey, o_custkey, o_orderdate]] - TableScan[awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=orders_partitioned, analyzePartitionValues=Optional.empty}] => [[o_orderkey, o_custkey, o_orderdate]] LAYOUT: tpch100.orders_partitioned o_orderdate := o_orderdate:string:-1:PARTITION_KEY :: [[1995]] o_custkey := o_custkey:int:1:REGULAR o_orderkey := o_orderkey:int:0:REGULAR ``` Der fett gedruckte Text im Ergebnis zeigt, dass das Prädikat `o_orderdate = '1995'` auf den `PARTITION_KEY` angewendet wurde. ### Beispiel 4. Verwenden Sie eine EXPLAIN-Abfrage, um die Join-Reihenfolge und den Join-Typ zu überprüfen Die folgende `EXPLAIN`-Abfrage überprüft die Join-Reihenfolge und den Join-Typ der `SELECT`-Anweisung. Verwenden Sie eine Abfrage wie diese, um die Speicherauslastung der Abfrage zu untersuchen, um die Wahrscheinlichkeit eines `EXCEEDED_LOCAL_MEMORY_LIMIT`-Fehlers zu verringern. ``` EXPLAIN (TYPE DISTRIBUTED) SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.customer c JOIN tpch100.orders o ON c.c_custkey = o.o_custkey WHERE c.c_custkey = 123 ``` #### Ergebnisse ``` Query Plan Fragment 0 [SINGLE] Output layout: [c_custkey, o_orderkey, o_orderstatus] Output partitioning: SINGLE [] Stage Execution Strategy: UNGROUPED_EXECUTION - Output[c_custkey, o_orderkey, o_orderstatus] => [[c_custkey, o_orderkey, o_orderstatus]] - RemoteSource[1] => [[c_custkey, o_orderstatus, o_orderkey]] Fragment 1 [SOURCE] Output layout: [c_custkey, o_orderstatus, o_orderkey] Output partitioning: SINGLE [] Stage Execution Strategy: UNGROUPED_EXECUTION - CrossJoin => [[c_custkey, o_orderstatus, o_orderkey]] Distribution: REPLICATED - ScanFilter[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=customer, analyzePartitionValues=Optional.empty}, grouped = false, filterPredicate = ("c_custkey" = 123)] => [[c_custkey]] LAYOUT: tpch100.customer c_custkey := c_custkey:int:0:REGULAR - LocalExchange[SINGLE] () => [[o_orderstatus, o_orderkey]] - RemoteSource[2] => [[o_orderstatus, o_orderkey]] Fragment 2 [SOURCE] Output layout: [o_orderstatus, o_orderkey] Output partitioning: BROADCAST [] Stage Execution Strategy: UNGROUPED_EXECUTION - ScanFilterProject[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=orders, analyzePartitionValues=Optional.empty}, grouped = false, filterPredicate = ("o_custkey" = 123)] => [[o_orderstatus, o_orderkey]] LAYOUT: tpch100.orders o_orderstatus := o_orderstatus:string:2:REGULAR o_custkey := o_custkey:int:1:REGULAR o_orderkey := o_orderkey:int:0:REGULAR ``` Die Beispielabfrage wurde für eine bessere Leistung zu einem Cross-Join optimiert. Die Ergebnisse zeigen, dass `tpch100.orders` als `BROADCAST`-Verteilungstyp verteilt wird. Dies impliziert, dass die `tpch100.orders`-Tabelle an alle Knoten verteilt wird, die den Join-Vorgang ausführen. Der `BROADCAST`-Verteilungstyp erfordert, dass alle gefilterten Ergebnisse der `tpch100.orders`-Tabelle in den Speicher jedes Knotens passen, der die Join-Operation ausführt. Die `tpch100.customer`-Tabelle ist jedoch kleiner als `tpch100.orders`. Da `tpch100.customer` weniger Speicher benötigt, können Sie die Abfrage in `BROADCAST tpch100.customer` statt in `tpch100.orders` umschreiben. Dies verringert die Wahrscheinlichkeit, dass die Abfrage den `EXCEEDED_LOCAL_MEMORY_LIMIT`-Fehler erhält. Diese Strategie setzt folgende Punkte voraus: + Das `tpch100.customer.c_custkey` ist in der `tpch100.customer`-Tabelle eindeutig. + Es besteht eine one-to-many Mapping-Beziehung zwischen `tpch100.customer` und`tpch100.orders`. Im folgenden Beispiel wird die neu geschriebene Abfrage dargestellt. ``` SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.orders o JOIN tpch100.customer c -- the filtered results of tpch100.customer are distributed to all nodes. ON c.c_custkey = o.o_custkey WHERE c.c_custkey = 123 ``` ### Beispiel 5: Verwenden Sie eine EXPLAIN-Abfrage zum Entfernen von Prädikaten, die keine Auswirkungen haben Sie können eine `EXPLAIN`-Abfrage verwenden, um die Wirksamkeit des Filterns von Prädikaten zu überprüfen. Sie können die Ergebnisse verwenden, um Prädikate zu entfernen, die keine Auswirkung haben, wie im folgenden Beispiel. ``` EXPLAIN SELECT c.c_name FROM tpch100.customer c WHERE c.c_custkey = CAST(RANDOM() * 1000 AS INT) AND c.c_custkey BETWEEN 1000 AND 2000 AND c.c_custkey = 1500 ``` #### Ergebnisse ``` Query Plan - Output[c_name] => [[c_name]] - RemoteExchange[GATHER] => [[c_name]] - ScanFilterProject[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=customer, analyzePartitionValues=Optional.empty}, filterPredicate = (("c_custkey" = 1500) AND ("c_custkey" = CAST(("random"() * 1E3) AS int)))] => [[c_name]] LAYOUT: tpch100.customer c_custkey := c_custkey:int:0:REGULAR c_name := c_name:string:1:REGULAR ``` Das `filterPredicate` in den Ergebnissen zeigt, dass der Optimierer die ursprünglichen drei Prädikate zu zwei Prädikaten zusammengeführt und ihre Anwendungsreihenfolge geändert hat. ``` filterPredicate = (("c_custkey" = 1500) AND ("c_custkey" = CAST(("random"() * 1E3) AS int))) ``` Da die Ergebnisse zeigen, dass das Prädikat `AND c.c_custkey BETWEEN 1000 AND 2000` keine Auswirkung hat, können Sie dieses Prädikat entfernen, ohne die Abfrageergebnisse zu ändern. Informationen zu den in den Ergebnissen von `EXPLAIN`-Abfragen verwendeten Begriffen finden Sie unter [Die Ergebnisse der Athena-EXPLAIN-Anweisung verstehen](athena-explain-statement-understanding.md). ## EXPLAIN-ANALYZE-Beispiele In den nachstehenden Beispielen wird ein Beispiel für `EXPLAIN ANALYZE`-Abfragen und Ausgaben gezeigt. ### Beispiel 1. Verwenden Sie EXPLAIN ANALYZE, um einen Abfrageplan und Rechenkosten im Textformat anzuzeigen Das folgende Beispiel `EXPLAIN ANALYZE` zeigt den Ausführungsplan und die Rechenkosten für eine `SELECT` Abfrage von CloudFront Protokollen. Das Format ist standardmäßig die Textausgabe. ``` EXPLAIN ANALYZE SELECT FROM cloudfront_logs LIMIT 10 ``` #### Ergebnisse ``` Fragment 1 CPU: 24.60ms, Input: 10 rows (1.48kB); per task: std.dev.: 0.00, Output: 10 rows (1.48kB) Output layout: [date, time, location, bytes, requestip, method, host, uri, status, referrer,\ os, browser, browserversion] Limit[10] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 1.00ms (0.03%), Output: 10 rows (1.48kB) Input avg.: 10.00 rows, Input std.dev.: 0.00% LocalExchange[SINGLE] () => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 0.00ns (0.00%), Output: 10 rows (1.48kB) Input avg.: 0.63 rows, Input std.dev.: 387.30% RemoteSource[2] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 1.00ms (0.03%), Output: 10 rows (1.48kB) Input avg.: 0.63 rows, Input std.dev.: 387.30% Fragment 2 CPU: 3.83s, Input: 998 rows (147.21kB); per task: std.dev.: 0.00, Output: 20 rows (2.95kB) Output layout: [date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion] LimitPartial[10] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 5.00ms (0.13%), Output: 20 rows (2.95kB) Input avg.: 166.33 rows, Input std.dev.: 141.42% TableScan[awsdatacatalog:HiveTableHandle{schemaName=default, tableName=cloudfront_logs,\ analyzePartitionValues=Optional.empty}, grouped = false] => [[date, time, location, bytes, requestip, method, host, uri, st CPU: 3.82s (99.82%), Output: 998 rows (147.21kB) Input avg.: 166.33 rows, Input std.dev.: 141.42% LAYOUT: default.cloudfront_logs date := date:date:0:REGULAR referrer := referrer:string:9:REGULAR os := os:string:10:REGULAR method := method:string:5:REGULAR bytes := bytes:int:3:REGULAR browser := browser:string:11:REGULAR host := host:string:6:REGULAR requestip := requestip:string:4:REGULAR location := location:string:2:REGULAR time := time:string:1:REGULAR uri := uri:string:7:REGULAR browserversion := browserversion:string:12:REGULAR status := status:int:8:REGULAR ``` ### Beispiel 2. Verwenden Sie EXPLAIN ANALYZE, um einen Abfrageplan im JSON-Format anzuzeigen Das folgende Beispiel zeigt den Ausführungsplan und die Rechenkosten für eine `SELECT` CloudFront Protokollabfrage. Im Beispiel wird JSON als Ausgabeformat angegeben. ``` EXPLAIN ANALYZE (FORMAT JSON) SELECT * FROM cloudfront_logs LIMIT 10 ``` #### Ergebnisse ``` { "fragments": [{ "id": "1", "stageStats": { "totalCpuTime": "3.31ms", "inputRows": "10 rows", "inputDataSize": "1514B", "stdDevInputRows": "0.00", "outputRows": "10 rows", "outputDataSize": "1514B" }, "outputLayout": "date, time, location, bytes, requestip, method, host,\ uri, status, referrer, os, browser, browserversion", "logicalPlan": { "1": [{ "name": "Limit", "identifier": "[10]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 10.0, "nodeInputRowsStdDev": 0.0 }] }, "children": [{ "name": "LocalExchange", "identifier": "[SINGLE] ()", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 0.625, "nodeInputRowsStdDev": 387.2983346207417 }] }, "children": [{ "name": "RemoteSource", "identifier": "[2]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 0.625, "nodeInputRowsStdDev": 387.2983346207417 }] }, "children": [] }] }] }] } }, { "id": "2", "stageStats": { "totalCpuTime": "1.62s", "inputRows": "500 rows", "inputDataSize": "75564B", "stdDevInputRows": "0.00", "outputRows": "10 rows", "outputDataSize": "1514B" }, "outputLayout": "date, time, location, bytes, requestip, method, host, uri, status,\ referrer, os, browser, browserversion", "logicalPlan": { "1": [{ "name": "LimitPartial", "identifier": "[10]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host", "uri",\ "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 83.33333333333333, "nodeInputRowsStdDev": 223.60679774997897 }] }, "children": [{ "name": "TableScan", "identifier": "[awsdatacatalog:HiveTableHandle{schemaName=default,\ tableName=cloudfront_logs, analyzePartitionValues=Optional.empty},\ grouped = false]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host", "uri",\ "status", "referrer", "os", "browser", "browserversion"], "details": "LAYOUT: default.cloudfront_logs\ndate := date:date:0:REGULAR\nreferrer :=\ referrer: string:9:REGULAR\nos := os:string:10:REGULAR\nmethod := method:string:5:\ REGULAR\nbytes := bytes:int:3:REGULAR\nbrowser := browser:string:11:REGULAR\nhost :=\ host:string:6:REGULAR\nrequestip := requestip:string:4:REGULAR\nlocation :=\ location:string:2:REGULAR\ntime := time:string:1: REGULAR\nuri := uri:string:7:\ REGULAR\nbrowserversion := browserversion:string:12:REGULAR\nstatus :=\ status:int:8:REGULAR\n", "distributedNodeStats": { "nodeCpuTime": "1.62s", "nodeOutputRows": 500, "nodeOutputDataSize": "75564B", "operatorInputRowsStats": [{ "nodeInputRows": 83.33333333333333, "nodeInputRowsStdDev": 223.60679774997897 }] }, "children": [] }] }] } }] } ``` ## Weitere Ressourcen Weitere Informationen finden Sie in den folgenden Ressourcen. + [Die Ergebnisse der Athena-EXPLAIN-Anweisung verstehen](athena-explain-statement-understanding.md) + [Anzeigen von Ausführungsplänen für SQL-Abfragen](query-plans.md) + [Anzeigen von Statistiken und Ausführungsdetails für abgeschlossene Abfragen](query-stats.md) + Trino-Dokumentation [https://trino.io/docs/current/sql/explain.html](https://trino.io/docs/current/sql/explain.html) + Trino-Dokumentation [https://trino.io/docs/current/sql/explain-analyze.html](https://trino.io/docs/current/sql/explain-analyze.html) + [Optimieren Sie die Leistung von Verbundabfragen mit EXPLAIN und EXPLAIN ANALYZE in Amazon Athena](https://aws.amazon.com/blogs/big-data/optimize-federated-query-performance-using-explain-and-explain-analyze-in-amazon-athena/) im *AWS -Big-Data-Blog*. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/7JUyTqglmNU/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/7JUyTqglmNU) # Die Ergebnisse der Athena-EXPLAIN-Anweisung verstehen Dieses Thema bietet eine kurze Anleitung zu den operativen Begriffen, die in den Athena-`EXPLAIN`-Anweisungsergebnissen verwendet werden. ## EXPLAIN-Anweisungs-Ausgabetypen `EXPLAIN`-Ausgabetypen können zwei Typen haben: + **Logischer Plan** – Zeigt den logischen Plan an, den die SQL-Engine zum Ausführen einer Anweisung verwendet. Die Syntax für diese Option lautet `EXPLAIN` oder `EXPLAIN (TYPE LOGICAL)`. + **Verteilter Plan** – Zeigt einen Ausführungsplan in einer verteilten Umgebung an. Die Ausgabe zeigt Fragmente, die Verarbeitungsschritte sind. Jedes Planfragment wird von einem oder mehreren Knoten verarbeitet. Daten können zwischen den Knoten ausgetauscht werden, die die Fragmente verarbeiten. Die Syntax für diese Option lautet `EXPLAIN (TYPE DISTRIBUTED)` In der Ausgabe für einen verteilten Plan werden Fragmente (Verarbeitungsphasen) durch `Fragment` *number* [*fragment\$1type*] gekennzeichnet, wobei *number* es sich um eine auf Null basierende Ganzzahl handelt, die *fragment\$1type* angibt, wie das Fragment von den Knoten ausgeführt wird. Die Fragmenttypen, die Einblicke in das Layout des Datenaustauschs geben, werden in der folgenden Tabelle beschrieben. **Fragment-Typen für verteilte Pläne** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/athena/latest/ug/athena-explain-statement-understanding.html) ## Exchange Die austauschbezogenen Begriffe beschreiben, wie Daten zwischen Worker-Knoten ausgetauscht werden. Übertragungen können entweder lokal oder remote erfolgen. **LocalExchange [*exchange\$1type*] ** Überträgt Daten lokal innerhalb von Worker-Knoten für verschiedene Phasen einer Abfrage. Der Wert für *exchange\$1type* kann einer der logischen oder verteilten Austauschtypen sein, wie weiter unten in diesem Abschnitt beschrieben. **RemoteExchange [*exchange\$1type*] ** Überträgt Daten zwischen Worker-Knoten für verschiedene Phasen einer Abfrage. Der Wert für *exchange\$1type* kann einer der logischen oder verteilten Austauschtypen sein, wie weiter unten in diesem Abschnitt beschrieben. ### Logische Austausch-Typen Die folgenden Austausch-Typen beschreiben Aktionen, die während der Austauschphase eines logischen Plans durchgeführt wurden. + **`GATHER`** – Ein einzelner Worker-Knoten sammelt die Ausgabe von allen anderen Worker-Knoten. Beispielsweise sammelt die letzte Stufe einer Auswahlabfrage Ergebnisse von allen Knoten und schreibt die Ergebnisse in Amazon S3. + **`REPARTITION`** – Sendet die Zeilendaten an einen bestimmten Worker basierend auf dem Partitionierungsschema, das für den nächsten Operator erforderlich ist. + **`REPLICATE`** – Kopiert die Zeilendaten in alle Worker. ### Verteilte Austausch-Typen Die folgenden Austauschtypen geben das Layout der Daten an, wenn sie zwischen Knoten in einem verteilten Plan ausgetauscht werden. + **`HASH`** – Der Austausch verteilt Daten an mehrere Ziele mithilfe einer Hash-Funktion. + **`SINGLE`** – Der Austausch verteilt Daten an ein einzelnes Ziel. ## Scanning Die folgenden Bedingungen beschreiben, wie Daten während einer Abfrage gescannt werden. **TableScan ** Scannt die Quelldaten einer Tabelle von Amazon S3 oder einem Apache-Hive-Connector und wendet die aus dem Filterprädikat generierte Partitionsbereinigung an. **ScanFilter ** Scannt die Quelldaten einer Tabelle von Amazon S3 oder einem Hive-Connector und wendet die Partitionsbereinigung an, die aus dem Filterprädikat und aus zusätzlichen Filterprädikaten generiert wurde, die nicht durch die Partitionsbereinigung angewendet wurden. **ScanFilterProject ** Scannt zunächst die Quelldaten einer Tabelle von Amazon S3 oder einem Hive-Connector und wendet die Partitionsbereinigung an, die aus dem Filterprädikat und aus zusätzlichen Filterprädikaten generiert wurde, die nicht durch die Partitionsbereinigung angewendet wurden. Ändert dann das Speicherlayout der Ausgabedaten in eine neue Projektion, um die Leistung späterer Phasen zu verbessern. ## Join Verknüpft Daten zwischen zwei Tabellen. Verknüpfungen können nach Verknüpfungstyp und nach Verteilungstyp kategorisiert werden. ### JOIN-Typen Verknüpfungstypen definieren die Art und Weise, in der der Join-Vorgang ausgeführt wird. **CrossJoin**— Erzeugt das kartesische Produkt der beiden verbundenen Tabellen. **InnerJoin**— Wählt Datensätze mit übereinstimmenden Werten in beiden Tabellen aus. **LeftJoin**— Wählt alle Datensätze aus der linken Tabelle und die passenden Datensätze aus der rechten Tabelle aus. Wenn keine Übereinstimmung auftritt, ist das Ergebnis auf der rechten Seite NULL. **RightJoin**— Wählt alle Datensätze aus der rechten Tabelle und die passenden Datensätze aus der linken Tabelle aus. Wenn keine Übereinstimmung auftritt, ist das Ergebnis auf der linken Seite NULL. **FullJoin**— Wählt alle Datensätze aus, bei denen es eine Übereinstimmung in den linken oder rechten Tabellendatensätzen gibt. Die verknüpfte Tabelle enthält alle Datensätze aus beiden Tabellen und füllt fehlende Treffer auf beiden Seiten aus. NULLs **Anmerkung** Aus Leistungsgründen kann das Abfragemodul eine Join-Abfrage in einen anderen Join-Typ umschreiben, um dieselben Ergebnisse zu erzielen. Beispielsweise kann eine Inner-Join-Abfrage mit einem Prädikat für eine Tabelle in ein `CrossJoin` umgeschrieben werden. Dadurch wird das Prädikat in die Scanphase der Tabelle verschoben, sodass weniger Daten gescannt werden. ### Join-Verteilungs-Typen Verteilungstypen definieren, wie Daten zwischen Worker-Knoten ausgetauscht werden, wenn der Join-Vorgang ausgeführt wird. **Partitioniert** – Sowohl die linke als auch die rechte Tabelle sind über alle Worker-Knoten hinweg hashpartitioniert. Partitionierte Verteilung verbraucht weniger Speicher in jedem Knoten. Partitionierte Verteilung kann viel langsamer sein als replizierte Joins. Partitionierte Joins eignen sich, wenn Sie zwei große Tabellen verbinden. **Repliziert** – Eine Tabelle wird über alle Worker-Knoten hinweg hashpartitioniert, und die andere Tabelle wird auf alle Worker-Knoten repliziert, um den Join-Vorgang auszuführen. Die replizierte Verteilung kann viel schneller sein als partitionierte Joins, verbraucht jedoch mehr Speicher in jedem Worker-Knoten. Wenn die replizierte Tabelle zu groß ist, kann es im Worker-Knoten zu einem out-of-memory Fehler kommen. Replizierte Joins sind geeignet, wenn eine der verknüpften Tabellen klein ist. # PREPARE Erstellt eine SQL-Anweisung mit dem Namen `statement_name`, die zu einem späteren Zeitpunkt ausgeführt werden soll. Die Anweisung kann Parameter enthalten, die durch Fragezeichen dargestellt werden. Um Werte für die Parameter bereitzustellen und die vorbereitete Anweisung auszuführen, verwenden Sie [EXECUTE](sql-execute.md). ## Syntax ``` PREPARE statement_name FROM statement ``` Die folgende Tabelle beschreibt diese Parameter. **** | Parameter | Description | | --- | --- | | statement\$1name | Der Name der zu erstellenden Anweisung. Der Name muss innerhalb der Arbeitsgruppe eindeutig sein. | | statement | SELECT-, CTAS- oder INSERT INTO-Abfrage. | **Anmerkung** Die maximale Anzahl von vorbereiteten Anweisungen in einer Arbeitsgruppe liegt bei 1 000. ## Beispiele Das folgende Beispiel bereitet eine ausgewählte Abfrage ohne Parameter vor. ``` PREPARE my_select1 FROM SELECT * FROM nation ``` Das folgende Beispiel bereitet eine ausgewählte Abfrage mit Parametern vor. Die Werte für `productid` und `quantity` werden von der `USING`-Klausel einer `EXECUTE`-Aussage bereitgestellt: ``` PREPARE my_select2 FROM SELECT order FROM orders WHERE productid = ? and quantity < ? ``` Im folgenden Beispiel wird eine Einfügeabfrage vorbereitet. ``` PREPARE my_insert FROM INSERT INTO cities_usa (city, state) SELECT city, state FROM cities_world WHERE country = ? ``` ## Weitere Ressourcen [Vorbereitete Anweisungen verwenden](querying-with-prepared-statements-querying.md) [EXECUTE](sql-execute.md) [DEALLOCATE PREPARE](sql-deallocate-prepare.md) [INSERT INTO](insert-into.md) # EXECUTE Führt eine vorbereitete Anweisung mit dem Namen `statement_name` aus. Parameterwerte für die Fragezeichen in der vorbereiteten Anweisung sind in der`USING`-Klausel in einer kommagetrennten Liste definiert. Um eine vorbereitete Anweisung zu erstellen, verwenden Sie [PREPARE](sql-prepare.md). ## Syntax ``` EXECUTE statement_name [ USING parameter1[, parameter2, ... ] ] ``` ## Beispiele Das folgende Beispiel bereitet eine Abfrage ohne Parameter vor und führt sie aus. ``` PREPARE my_select1 FROM SELECT name FROM nation EXECUTE my_select1 ``` Das folgende Beispiel bereitet eine Abfrage mit einem einzigen Parameter vor und führt sie aus. ``` PREPARE my_select2 FROM SELECT * FROM "my_database"."my_table" WHERE year = ? EXECUTE my_select2 USING 2012 ``` Dies entspricht: ``` SELECT * FROM "my_database"."my_table" WHERE year = 2012 ``` Das folgende Beispiel bereitet eine Abfrage mit zwei Parametern vor und führt sie aus. ``` PREPARE my_select3 FROM SELECT order FROM orders WHERE productid = ? and quantity < ? EXECUTE my_select3 USING 346078, 12 ``` ## Weitere Ressourcen [Vorbereitete Anweisungen verwenden](querying-with-prepared-statements-querying.md) [PREPARE](sql-prepare.md) [INSERT INTO](insert-into.md) # DEALLOCATE PREPARE Entfernt die vorbereitete Anweisung mit dem angegebenen Namen aus den vorbereiteten Anweisungen in der aktuellen Arbeitsgruppe. ## Syntax ``` DEALLOCATE PREPARE statement_name ``` ## Beispiele Im folgenden Beispiel wird die vorbereitete Anweisung `my_select1` aus der aktuellen Arbeitsgruppe entfernt. ``` DEALLOCATE PREPARE my_select1 ``` ## Weitere Ressourcen [Vorbereitete Anweisungen verwenden](querying-with-prepared-statements-querying.md) [PREPARE](sql-prepare.md) # UNLOAD Schreibt Abfrageergebnisse aus einer `SELECT`-Anweisung in das angegebene Datenformat. Zu den unterstützten Formaten für `UNLOAD` gehören Apache Parquet, ORC, Apache Avro und JSON. CSV ist das einzige Ausgabeformat, das vom dem Athena `SELECT`-Befehl unterstützt wird, aber Sie können den `UNLOAD`-Befehl, der eine Vielzahl von Ausgabeformaten unterstützt, verwenden, um Ihre `SELECT`-Abfrage einzuschließen und ihre Ausgabe in eines der Formate die `UNLOAD` unterstützt umzuschreiben. Obwohl Sie die `CREATE TABLE AS`-(CTAS)-Anweisung verwenden können, um Daten in anderen Formaten als CSV auszugeben, erfordern CTAS-Anweisungen die Erstellung einer Tabelle in Athena. Die `UNLOAD`-Anweisung ist nützlich, wenn Sie die Ergebnisse einer `SELECT`-Abfrage in einem Nicht-CSV-Format ausgeben möchten, aber die zugehörige Tabelle nicht benötigen. Beispielsweise kann eine nachgelagerte Anwendung erfordern, dass die Ergebnisse einer `SELECT`-Abfrage im JSON-Format vorliegen, und Parquet oder ORC können einen Leistungsvorteil gegenüber CSV bieten, wenn Sie die Ergebnisse der `SELECT`-Abfrage für zusätzliche Analysen verwenden möchten. ## Überlegungen und Einschränkungen Beachten Sie bei der Verwendung der `UNLOAD`-Anweisung in Athena die folgenden Punkte: + **Keine globale Reihenfolge von Dateien** – `UNLOAD`-Ergebnisse werden parallel in mehrere Dateien geschrieben. Wenn die `SELECT`-Abfrage in der `UNLOAD`-Anweisung eine Sortierreihenfolge angibt, wird der Inhalt jeder Datei sortiert, aber die Dateien werden nicht relativ zueinander sortiert. + **Verwaiste Daten nicht gelöscht** – Im Falle eines Fehlers versucht Athena nicht, verwaiste Daten zu löschen. Dieses Verhalten ist das gleiche wie bei CTAS und `INSERT INTO`-Anweisungen. + **Maximale Partitionen** – Die maximale Anzahl von Partitionen, die mit `UNLOAD` verwendet werden können, beträgt 100. + **Metadaten- und Manifestdateien**– Athena generiert für jede `UNLOAD`-Abfrage eine Metadatendatei und eine Datenmanifestdatei. Das Manifest verfolgt die Dateien, die die Abfrage geschrieben hat. Beide Dateien werden in Ihrem Athena-Abfrageergebnisspeicherort in Amazon S3 gespeichert. Weitere Informationen finden Sie unter [Identifizieren von Abfrageausgabedateien](querying-finding-output-files.md#querying-identifying-output-files). + **Verschlüsselung** – `UNLOAD`-Ausgabedateien werden gemäß der für Amazon S3 verwendeten Verschlüsselungskonfiguration verschlüsselt. Um die Verschlüsselungskonfiguration für die Verschlüsselung Ihres `UNLOAD` Ergebnisses einzurichten, können Sie die [EncryptionConfiguration API](https://docs.aws.amazon.com/athena/latest/APIReference/API_EncryptionConfiguration.html) verwenden. + **Vorbereitete Anweisungen** – `UNLOAD`kann mit vorbereiteten Anweisungen verwendet werden. Informationen zu vorbereiteten Anweisungen in Athena finden Sie unter [Parametrisierte Abfragen verwenden](querying-with-prepared-statements.md). + **Service Quotas** – `UNLOAD` verwendet DML-Abfragekontingente. Kontigentinformationen finden Sie unter [Service Quotas](service-limits.md). + **Erwarteter Bucket-Eigentümer** – Die Einstellung für den erwarteten Bucket-Eigentümer gilt nicht für den Amazon-S3-Speicherort, der in der `UNLOAD`-Abfrage angegeben wurde. Die erwartete Bucket-Eigentümereinstellung gilt nur für den Amazon-S3-Ausgabespeicherort, den Sie für Athena-Abfrageergebnisse angeben. Weitere Informationen finden Sie unter [Angeben eines Speicherorts des Abfrageergebnisses mithilfe der Athena-Konsole](query-results-specify-location-console.md). ## Syntax Die `UNLOAD`-Anweisung verwendet die folgende Syntax. ``` UNLOAD (SELECT col_name[, ...] FROM old_table) TO 's3://amzn-s3-demo-bucket/my_folder/' WITH ( property_name = 'expression' [, ...] ) ``` Außer beim Schreiben auf Partitionen, muss das `TO`-Ziel einen Standort in Amazon S3 angeben, der keine Daten enthält. Bevor die `UNLOAD`-Abfrage in den angegebenen Speicherort schreibt, überprüft sie, ob der Bucket-Speicherort leer ist. Da `UNLOAD` keine Daten an den angegebenen Speicherort schreibt, wenn der Speicherort bereits Daten enthält, überschreibt `UNLOAD` keine vorhandenen Daten. Um einen Bucket-Speicherort als Ziel für `UNLOAD` wiederzuverwenden, löschen Sie die Daten am Bucket-Speicherort und führen Sie die Abfrage dann erneut aus. Beachten Sie, dass dieses Verhalten anders ist, wenn `UNLOAD` in Partitionen schreibt. Wenn Sie dieselbe `UNLOAD`-Abfrage mehrmals ausführen, die dieselbe `SELECT`-Anweisung, denselben `TO`-Speicherort und dieselben Partitionen hat, entlädt jede `UNLOAD`-Abfrage die Daten an dem angegebenen Speicherort und den angegebenen Partitionen in Amazon S3. ### Parameters Die möglichen Werte für *property\$1name* sind wie folgt. ** format = '' *file\$1format* ** Erforderlich Gibt das Dateiformat der Ausgabe an. Mögliche Werte für *file\$1format* sind `ORC``PARQUET`,`AVRO`,`JSON`, oder`TEXTFILE`. ** Komprimierung = '*compression\$1format*' ** Optional. Diese Option ist spezifisch für die Formate ORC und Parquet. Für ORC ist der Standardwert `zlib` und für Parquet der Standardwert `gzip`. Informationen über unterstützte Komprimierungsformate finden Sie unter [Unterstützung der Athena-Komprimierung](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html). Diese Option gilt nicht für das Format `AVRO`. Athena verwendet `gzip` für `JSON`- und `TEXTFILE`-Formate. **Kompressionsstufe = *compression\$1level* ** Optional. Die Komprimierungsstufe, die für die ZSTD-Komprimierung verwendet werden soll. Diese Eigenschaft gilt nur für die ZSTD-Komprimierung. Weitere Informationen finden Sie unter [ZSTD-Komprimierungsstufen verwenden](compression-support-zstd-levels.md). ** Feldtrennzeichen = '' *delimiter* ** Optional. Gibt ein Feldtrennzeichen aus einem einzigen Zeichen für Dateien in CSV, TSV und anderen Textformaten an. Das folgende Beispiel verwendet ein Komma als Trennzeichen: ``` WITH (field_delimiter = ',') ``` Derzeit werden mehrzeilige Feldtrennzeichen nicht unterstützt. Wenn Sie kein Feldtrennzeichen angeben, wird das Oktalzeichen `\001` (^A) verwendet. ** partitioniert\$1nach = ARRAY [[,...]] *col\$1name* ** Optional. Eine Array-Liste der Spalten, nach denen die Ausgabe partitioniert ist. Stellen Sie in Ihrer `SELECT`-Anweisung sicher, dass die Namen der partitionierten Spalten in Ihrer Spaltenliste an letzter Stelle stehen. ## Beispiele Im folgenden Beispiel wird die Ausgabe einer `SELECT`-Abfrage im JSON-Format an den Amazon-S3-Speicherort `s3://amzn-s3-demo-bucket/unload_test_1/` geschrieben. ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/unload_test_1/' WITH (format = 'JSON') ``` Im folgenden Beispiel wird die Ausgabe einer `SELECT`-Abfrage im Parquet-Format mithilfe der Snappy-Komprimierung geschrieben. ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET',compression = 'SNAPPY') ``` Im folgenden Beispiel werden vier Spalten im Textformat geschrieben, wobei die Ausgabe durch die letzte Spalte partitioniert ist. ``` UNLOAD (SELECT name1, address1, comment1, key1 FROM table1) TO 's3://amzn-s3-demo-bucket/ partitioned/' WITH (format = 'TEXTFILE', partitioned_by = ARRAY['key1']) ``` Im folgenden Beispiel werden die Abfrageergebnisse unter Verwendung des Parquet-Dateiformats, der ZSTD-Komprimierung und der ZSTD-Komprimierungsstufe 4 an den angegebenen Speicherort entladen. ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET', compression = 'ZSTD', compression_level = 4) ``` ## Weitere Ressourcen + [Vereinfachen Sie Ihre ETL- und ML-Pipelines mithilfe des Amazon Athena UNLOAD-Features](https://aws.amazon.com/blogs/big-data/simplify-your-etl-and-ml-pipelines-using-the-amazon-athena-unload-feature/) im *AWS -Big-Data-Blog*. # Funktionen in Amazon Athena Weitere Informationen über Versionen des Athena-Engines finden Sie in [Athena-Engine-Versionierung](engine-versions.md). Eine Liste der Zeitzonen, die mit dem `AT TIME ZONE`-Operator verwendet werden können, finden Sie unter [Unterstützte Zeitzonen verwenden](athena-supported-time-zones.md). **Topics** + [Athena-Engine-Version 3](functions-env3.md) # Funktionen der Athena-Engine Version 3 Funktionen in Athena-Engine-Version 3 basieren auf Trino. Informationen zu Funktionen, Operatoren und Ausdrücken von Trino finden Sie unter [Funktionen und Operatoren](https://trino.io/docs/current/functions.html) und in den folgenden Unterabschnitten der Trino-Dokumentation. + [Aggregate](https://trino.io/docs/current/functions/aggregate.html) + [Array](https://trino.io/docs/current/functions/array.html) + [Binary](https://trino.io/docs/current/functions/binary.html) + [Bitweise](https://trino.io/docs/current/functions/bitwise.html) + [Farbe](https://trino.io/docs/current/functions/color.html) + [Vergleich](https://trino.io/docs/current/functions/comparison.html) + [Bedingt](https://trino.io/docs/current/functions/conditional.html) + [Konvertierung](https://trino.io/docs/current/functions/conversion.html) + [Datum und Uhrzeit](https://trino.io/docs/current/functions/datetime.html) + [Dezimal](https://trino.io/docs/current/functions/decimal.html) + [Geodaten](https://trino.io/docs/current/functions/geospatial.html) + [HyperLogLog](https://trino.io/docs/current/functions/hyperloglog.html) + [IP-Adresse](https://trino.io/docs/current/functions/ipaddress.html) + [JSON](https://trino.io/docs/current/functions/json.html) + [Lambda](https://trino.io/docs/current/functions/lambda.html) + [Logisch](https://trino.io/docs/current/functions/logical.html) + [Machine Learning](https://trino.io/docs/current/functions/ml.html) + [Zuordnung](https://trino.io/docs/current/functions/map.html) + [Math (Mathematik)](https://trino.io/docs/current/functions/math.html) + [Quantil-Digest](https://trino.io/docs/current/functions/qdigest.html) + [Regulärer Ausdruck](https://trino.io/docs/current/functions/regexp.html) + [Sitzung](https://trino.io/docs/current/functions/session.html) + [Digest festlegen](https://trino.io/docs/current/functions/setdigest.html) + [Zeichenfolge](https://trino.io/docs/current/functions/string.html) + [Tabelle](https://trino.io/docs/current/functions/table.html) + [Teradata](https://trino.io/docs/current/functions/teradata.html) + [T-Digest](https://trino.io/docs/current/functions/tdigest.html) + [URL](https://trino.io/docs/current/functions/url.html) + [UUID](https://trino.io/docs/current/functions/uuid.html) + [Window](https://trino.io/docs/current/functions/window.html) ## invoker\$1principal() function Die `invoker_principal`-Funktion ist nur in der Athena-Engine Version 3 verfügbar und in Trino nicht zu finden. Gibt ein `VARCHAR` zurück, das den ARN des Prinzipals (IAM-Rolle oder Identity Center-Identität) enthält, der die Abfrage ausgeführt hat, die die Funktion aufgerufen hat. Wenn der Abfrageaufrufer beispielsweise die Berechtigungen einer IAM-Rolle verwendet, um die Abfrage auszuführen, gibt die Funktion den ARN der IAM-Rolle zurück. Die Rolle, die die Abfrage ausführt, muss die `LakeFormation:GetDataLakePrincipal`-Aktion zulassen. ### Usage ``` SELECT invoker_principal() ``` Die folgende Tabelle zeigt ein Beispielergebnis. **** | \$1 | \$1col0 | | --- | --- | | 1 | arn:aws:iam: ::role/admin 111122223333 | # Unterstützte Zeitzonen verwenden Sie können den Operator `AT TIME ZONE` in einer `SELECT timestamp`-Anweisung verwenden, um die Zeitzone für den zurückgegebenen Zeitstempel anzugeben, wie im folgenden Beispiel: ``` SELECT timestamp '2012-10-31 01:00 UTC' AT TIME ZONE 'America/Los_Angeles' AS la_time; ``` **Ergebnisse** ``` la_time 2012-10-30 18:00:00.000 America/Los_Angeles ``` Eine Liste der unterstützten Zeitzonen in Athena finden Sie in der Erweiterung des [Liste der unterstützten Zeitzonen](#athena-supported-time-zones-list) am Ende dieses Themas. ## Funktionen und Beispiele für Zeitzonen Im Folgenden finden Sie weitere Funktionen und Beispiele für Zeitzonen. + **at\$1timezone (*timestamp*,*zone*)** — Gibt den Wert von *timestamp* in der entsprechenden Ortszeit für zurück. *zone* **Beispiel** ``` SELECT at_timezone(timestamp '2021-08-22 00:00 UTC', 'Canada/Newfoundland') ``` **Ergebnis** ``` 2021-08-21 21:30:00.000 Canada/Newfoundland ``` + **timezone\$1hour (*timestamp*) — Gibt die Stunde** des Zeitzonen-Offsets vom Zeitstempel als a zurück. `bigint` **Beispiel** ``` SELECT timezone_hour(timestamp '2021-08-22 04:00 UTC' AT TIME ZONE 'Canada/Newfoundland') ``` **Ergebnis** ``` -2 ``` + **timezone\$1minute (*timestamp*) — Gibt die Minute** des Zeitzonen-Offsets von als a zurück. *timestamp* `bigint` **Beispiel** ``` SELECT timezone_minute(timestamp '2021-08-22 04:00 UTC' AT TIME ZONE 'Canada/Newfoundland') ``` **Ergebnis** ``` -30 ``` + **with\$1timezone (*timestamp*,*zone*)** — Gibt einen Zeitstempel mit einer Zeitzone aus den angegebenen Werten zurück. *timestamp* *zone* **Beispiel** ``` SELECT with_timezone(timestamp '2021-08-22 04:00', 'Canada/Newfoundland') ``` **Ergebnis** ``` 2021-08-22 04:00:00.000 Canada/Newfoundland ``` ## Liste der unterstützten Zeitzonen Die folgende Liste enthält die Zeitzonen, die mit dem `AT TIME ZONE`-Operator in Athena verwendet werden können. Weitere Funktionen und Beispiele für die Zeitzone finden Sie unter [Funktionen und Beispiele für Zeitzonen](#athena-supported-time-zones-functions-examples). ``` Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers Africa/Asmara Africa/Asmera Africa/Bamako Africa/Bangui Africa/Banjul Africa/Bissau Africa/Blantyre Africa/Brazzaville Africa/Bujumbura Africa/Cairo Africa/Casablanca Africa/Ceuta Africa/Conakry Africa/Dakar Africa/Dar_es_Salaam Africa/Djibouti Africa/Douala Africa/El_Aaiun Africa/Freetown Africa/Gaborone Africa/Harare Africa/Johannesburg Africa/Juba Africa/Kampala Africa/Khartoum Africa/Kigali Africa/Kinshasa Africa/Lagos Africa/Libreville Africa/Lome Africa/Luanda Africa/Lubumbashi Africa/Lusaka Africa/Malabo Africa/Maputo Africa/Maseru Africa/Mbabane Africa/Mogadishu Africa/Monrovia Africa/Nairobi Africa/Ndjamena Africa/Niamey Africa/Nouakchott Africa/Ouagadougou Africa/Porto-Novo Africa/Sao_Tome Africa/Timbuktu Africa/Tripoli Africa/Tunis Africa/Windhoek America/Adak America/Anchorage America/Anguilla America/Antigua America/Araguaina America/Argentina/Buenos_Aires America/Argentina/Catamarca America/Argentina/ComodRivadavia America/Argentina/Cordoba America/Argentina/Jujuy America/Argentina/La_Rioja America/Argentina/Mendoza America/Argentina/Rio_Gallegos America/Argentina/Salta America/Argentina/San_Juan America/Argentina/San_Luis America/Argentina/Tucuman America/Argentina/Ushuaia America/Aruba America/Asuncion America/Atikokan America/Atka America/Bahia America/Bahia_Banderas America/Barbados America/Belem America/Belize America/Blanc-Sablon America/Boa_Vista America/Bogota America/Boise America/Buenos_Aires America/Cambridge_Bay America/Campo_Grande America/Cancun America/Caracas America/Catamarca America/Cayenne America/Cayman America/Chicago America/Chihuahua America/Coral_Harbour America/Cordoba America/Costa_Rica America/Creston America/Cuiaba America/Curacao America/Danmarkshavn America/Dawson America/Dawson_Creek America/Denver America/Detroit America/Dominica America/Edmonton America/Eirunepe America/El_Salvador America/Ensenada America/Fort_Nelson America/Fort_Wayne America/Fortaleza America/Glace_Bay America/Godthab America/Goose_Bay America/Grand_Turk America/Grenada America/Guadeloupe America/Guatemala America/Guayaquil America/Guyana America/Halifax America/Havana America/Hermosillo America/Indiana/Indianapolis America/Indiana/Knox America/Indiana/Marengo America/Indiana/Petersburg America/Indiana/Tell_City America/Indiana/Vevay America/Indiana/Vincennes America/Indiana/Winamac America/Indianapolis America/Inuvik America/Iqaluit America/Jamaica America/Jujuy America/Juneau America/Kentucky/Louisville America/Kentucky/Monticello America/Knox_IN America/Kralendijk America/La_Paz America/Lima America/Los_Angeles America/Louisville America/Lower_Princes America/Maceio America/Managua America/Manaus America/Marigot America/Martinique America/Matamoros America/Mazatlan America/Mendoza America/Menominee America/Merida America/Metlakatla America/Mexico_City America/Miquelon America/Moncton America/Monterrey America/Montevideo America/Montreal America/Montserrat America/Nassau America/New_York America/Nipigon America/Nome America/Noronha America/North_Dakota/Beulah America/North_Dakota/Center America/North_Dakota/New_Salem America/Ojinaga America/Panama America/Pangnirtung America/Paramaribo America/Phoenix America/Port-au-Prince America/Port_of_Spain America/Porto_Acre America/Porto_Velho America/Puerto_Rico America/Punta_Arenas America/Rainy_River America/Rankin_Inlet America/Recife America/Regina America/Resolute America/Rio_Branco America/Rosario America/Santa_Isabel America/Santarem America/Santiago America/Santo_Domingo America/Sao_Paulo America/Scoresbysund America/Shiprock America/Sitka America/St_Barthelemy America/St_Johns America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Swift_Current America/Tegucigalpa America/Thule America/Thunder_Bay America/Tijuana America/Toronto America/Tortola America/Vancouver America/Virgin America/Whitehorse America/Winnipeg America/Yakutat America/Yellowknife Antarctica/Casey Antarctica/Davis Antarctica/DumontDUrville Antarctica/Macquarie Antarctica/Mawson Antarctica/McMurdo Antarctica/Palmer Antarctica/Rothera Antarctica/South_Pole Antarctica/Syowa Antarctica/Troll Antarctica/Vostok Arctic/Longyearbyen Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr Asia/Aqtau Asia/Aqtobe Asia/Ashgabat Asia/Ashkhabad Asia/Atyrau Asia/Baghdad Asia/Bahrain Asia/Baku Asia/Bangkok Asia/Barnaul Asia/Beirut Asia/Bishkek Asia/Brunei Asia/Calcutta Asia/Chita Asia/Choibalsan Asia/Chongqing Asia/Chungking Asia/Colombo Asia/Dacca Asia/Damascus Asia/Dhaka Asia/Dili Asia/Dubai Asia/Dushanbe Asia/Gaza Asia/Harbin Asia/Hebron Asia/Ho_Chi_Minh Asia/Hong_Kong Asia/Hovd Asia/Irkutsk Asia/Istanbul Asia/Jakarta Asia/Jayapura Asia/Jerusalem Asia/Kabul Asia/Kamchatka Asia/Karachi Asia/Kashgar Asia/Kathmandu Asia/Katmandu Asia/Khandyga Asia/Kolkata Asia/Krasnoyarsk Asia/Kuala_Lumpur Asia/Kuching Asia/Kuwait Asia/Macao Asia/Macau Asia/Magadan Asia/Makassar Asia/Manila Asia/Muscat Asia/Nicosia Asia/Novokuznetsk Asia/Novosibirsk Asia/Omsk Asia/Oral Asia/Phnom_Penh Asia/Pontianak Asia/Pyongyang Asia/Qatar Asia/Qyzylorda Asia/Rangoon Asia/Riyadh Asia/Saigon Asia/Sakhalin Asia/Samarkand Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Srednekolymsk Asia/Taipei Asia/Tashkent Asia/Tbilisi Asia/Tehran Asia/Tel_Aviv Asia/Thimbu Asia/Thimphu Asia/Tokyo Asia/Tomsk Asia/Ujung_Pandang Asia/Ulaanbaatar Asia/Ulan_Bator Asia/Urumqi Asia/Ust-Nera Asia/Vientiane Asia/Vladivostok Asia/Yakutsk Asia/Yangon Asia/Yekaterinburg Asia/Yerevan Atlantic/Azores Atlantic/Bermuda Atlantic/Canary Atlantic/Cape_Verde Atlantic/Faeroe Atlantic/Faroe Atlantic/Jan_Mayen Atlantic/Madeira Atlantic/Reykjavik Atlantic/South_Georgia Atlantic/St_Helena Atlantic/Stanley Australia/ACT Australia/Adelaide Australia/Brisbane Australia/Broken_Hill Australia/Canberra Australia/Currie Australia/Darwin Australia/Eucla Australia/Hobart Australia/LHI Australia/Lindeman Australia/Lord_Howe Australia/Melbourne Australia/NSW Australia/North Australia/Perth Australia/Queensland Australia/South Australia/Sydney Australia/Tasmania Australia/Victoria Australia/West Australia/Yancowinna Brazil/Acre Brazil/DeNoronha Brazil/East Brazil/West CET CST6CDT Canada/Atlantic Canada/Central Canada/Eastern Canada/Mountain Canada/Newfoundland Canada/Pacific Canada/Saskatchewan Canada/Yukon Chile/Continental Chile/EasterIsland Cuba EET EST5EDT Egypt Eire Europe/Amsterdam Europe/Andorra Europe/Astrakhan Europe/Athens Europe/Belfast Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Bucharest Europe/Budapest Europe/Busingen Europe/Chisinau Europe/Copenhagen Europe/Dublin Europe/Gibraltar Europe/Guernsey Europe/Helsinki Europe/Isle_of_Man Europe/Istanbul Europe/Jersey Europe/Kaliningrad Europe/Kiev Europe/Kirov Europe/Lisbon Europe/Ljubljana Europe/London Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Mariehamn Europe/Minsk Europe/Monaco Europe/Moscow Europe/Nicosia Europe/Oslo Europe/Paris Europe/Podgorica Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/San_Marino Europe/Sarajevo Europe/Simferopol Europe/Skopje Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Tiraspol Europe/Ulyanovsk Europe/Uzhgorod Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Vilnius Europe/Volgograd Europe/Warsaw Europe/Zagreb Europe/Zaporozhye Europe/Zurich GB GB-Eire Hongkong Iceland Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguelen Indian/Mahe Indian/Maldives Indian/Mauritius Indian/Mayotte Indian/Reunion Iran Israel Jamaica Japan Kwajalein Libya MET MST7MDT Mexico/BajaNorte Mexico/BajaSur Mexico/General NZ NZ-CHAT Navajo PRC PST8PDT Pacific/Apia Pacific/Auckland Pacific/Bougainville Pacific/Chatham Pacific/Chuuk Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Johnston Pacific/Kiritimati Pacific/Kosrae Pacific/Kwajalein Pacific/Majuro Pacific/Marquesas Pacific/Midway Pacific/Nauru Pacific/Niue Pacific/Norfolk Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Pohnpei Pacific/Ponape Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Samoa Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Truk Pacific/Wake Pacific/Wallis Pacific/Yap Poland Portugal ROK Singapore Turkey US/Alaska US/Aleutian US/Arizona US/Central US/East-Indiana US/Eastern US/Hawaii US/Indiana-Starke US/Michigan US/Mountain US/Pacific US/Pacific-New US/Samoa W-SU WET ```