# DML クエリ、関数、および演算子 Athena DML クエリエンジンは、基本的に Trino と Presto の構文をサポートし、独自の改良が加えられています。Athena は Trino と Presto のすべての機能をサポートしているわけではありません。詳細については、このセクション、および「[考慮事項と制限事項](other-notable-limitations.md)」で特定のステートメントに関するトピックを参照してください。関数の詳細については、「[Amazon Athena の関数](functions.md)」を参照してください。Athena エンジンバージョンの詳細については、「[Athena エンジンのバージョニング](engine-versions.md)」を参照してください。 DDL ステートメントの詳細については、「[DDL ステートメント](ddl-reference.md)」を参照してください。サポートされていない DDL ステートメントのリストについては、「[サポートされない DDL](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 と EXPLAIN ANALYZE](athena-explain-statement.md) + [PREPARE](sql-prepare.md) + [UNLOAD](unload.md) + [関数](functions.md) + [サポートされているタイムゾーンを使用する](athena-supported-time-zones.md) # SELECT 0 個以上のテーブルからデータの行を取得します。 **注記** このトピックでは、参照用に概要情報を提供します。`SELECT` と SQL 言語の使用に関する包括的な情報は、このドキュメントでは説明しません。Athena に固有の SQL の使用については、「[Amazon Athena での SQL クエリに関する考慮事項と制約事項](other-notable-limitations.md)」および「[Amazon Athena で SQL クエリを実行する](querying-athena-tables.md)」を参照してください。データベースの作成、テーブルの作成、および Athena のテーブルに対する `SELECT` クエリの実行の例については、[はじめに](getting-started.md) を参照してください。 ## 概要 ``` [ 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 ] ] ``` **注記** SQL SELECT ステートメントの予約語は、二重引用符で囲む必要があります。詳細については、「[SQL SELECT ステートメントでエスケープする予約語](reserved-words.md#list-of-reserved-words-sql-select)」を参照してください。 ## パラメータ **[ WITH with\$1query [, ....]]** `WITH` を使用すると、ネストされたクエリをフラット化したり、サブクエリを簡素化できます。 `WITH` 句を使用した再帰クエリの作成は、Athena エンジンバージョン 3 以降でサポートされています。最大再帰深度は 10 です。 `WITH` 句はクエリの `SELECT` リストに先行し、`SELECT` クエリ内で使用する 1 つ以上のサブクエリを定義します。 各サブクエリは、ビュー定義と同じように、一時テーブルを定義します。一時テーブルは `FROM` 句で参照できます。このテーブルはクエリを実行時のみに使用します。 `with_query` 構文は次のとおりです。 ``` subquery_table_name [ ( column_name [, ...] ) ] AS (subquery) ``` 各パラメータの意味は次のとおりです。 + `subquery_table_name` は、`WITH` 句のサブクエリの結果を定義する一時テーブルの一意な名前です。各 `subquery` には、`FROM` 句で参照可能なテーブル名を付ける必要があります。 + `column_name [, ...]` は、出力列名の省略可能なリストです。列名の数は、`subquery` で定義した列数以下でなければなりません。 + `subquery` は、任意のクエリステートメントです。 **[ ALL \$1 DISTINCT ] select\$1expression** `select_expression` は、選択する行を決定します。`select_expression` には、次のいずれかの形式が使用されます。 ``` expression [ [ AS ] column_alias ] [, ...] ``` ``` row_expression.* [ AS ( column_alias [, ...] ) ] ``` ``` relation.* ``` ``` * ``` + `expression [ [ AS ] column_alias ]` 構文は出力列を指定します。オプションの `[AS] column_alias` 構文は、出力の列に使用されるカスタム見出し名を指定します。 + `row_expression.* [ AS ( column_alias [, ...] ) ]` の場合、`row_expression` は データ型 `ROW` の任意の式です。行のフィールドは、結果に含まれる出力列を定義します。 + `relation.*` の場合、`relation` の列が結果に含まれます。この構文では列のエイリアスは使用できません。 + アスタリスク `*` は、すべての列を結果セットに含めることを指定します。 + 結果セット内の列の順序は、select 式による指定の順序と同じです。select 式が複数の列を返す場合、列の順序はソースリレーションまたは行タイプの式で使用されている順序に従います。 + 列のエイリアスを指定すると、そのエイリアスは既存の列または行のフィールド名よりも優先されます。select 式に列名がない場合は、インデックスが 0 の匿名の列名 (`_col0`、`_col1`、`_col2, ...`) が出力に表示されます。 + `ALL` はデフォルトです。`ALL` は、それを省略した場合と同じように扱われます。すべての列のすべての行が選択され、重複も含まれます。 + `DISTINCT` は、列に重複する値が含まれているときに、個別の値のみを返すために使用します。 **FROM from\$1item [, ...]** クエリへの入力を示します。`from_item` は、以下に示すように、ビュー、結合コンストラクト、サブクエリのいずれかです。 `from_item` は以下のいずれかです。 + `table_name [ [ AS ] alias [ (column_alias [, ...]) ] ]` `table_name` は行の選択元であるターゲットテーブルの名前であり、`alias` は `SELECT` ステートメントの出力に渡す名前です。`column_alias` は指定した `alias` の列を定義します。 **-または-** + `join_type from_item [ ON join_condition | USING ( join_column [, ...] ) ]` `join_type` は以下のいずれかです。 + `[ INNER ] JOIN` + `LEFT [ OUTER ] JOIN` + `RIGHT [ OUTER ] JOIN` + `FULL [ OUTER ] JOIN` + `CROSS JOIN` + `ON join_condition | USING (join_column [, ...])`。`join_condition` では、複数のテーブルにおいて結合キーの列名を指定できます。`join_column` を使用するには、`join_column` が両方のテーブルに存在している必要があります。 **[ WHERE condition ]** 指定した `condition` に従って結果をフィルタリングします。通常、`condition` には次の構文が含まれています。 ``` column_name operator value [[[AND | OR] column_name operator value] ...] ``` *演算子*は、比較演算子 `=`、`>`、`<`、`>=`、`<=`、`<>`、`!=` のいずれかになります。 次のサブクエリ式も、`WHERE` 句で使用できます。 + `[NOT] BETWEEN integer_A AND integer_B` - 次の例のように、2 つの整数間の範囲を指定します。列のデータ型が `varchar` の場合、最初に列を整数にキャストする必要があります。 ``` SELECT DISTINCT processid FROM "webdata"."impressions" WHERE cast(processid as int) BETWEEN 1500 and 1800 ORDER BY processid ``` + `[NOT] LIKE value` - 指定したパターンを検索します。次の例のように、パーセント記号 (`%`) をワイルドカード文字として使用します。 ``` SELECT * FROM "webdata"."impressions" WHERE referrer LIKE '%.org' ``` + `[NOT] IN (value[, value[, ...])` - 次の例のように、列で使用できる値のリストを指定します。 ``` SELECT * FROM "webdata"."impressions" WHERE referrer IN ('example.com','example.net','example.org') ``` **[ GROUP BY [ ALL \$1 DISTINCT ] grouping\$1expressions [, ...]]** `SELECT` ステートメントの出力を、一致する値を持つ行に分割します。 `ALL` と `DISTINCT` は、重複したグループ化セットごとに個別の出力行を生成するかどうかを決定します。省略すると、`ALL` が使用されます。 `grouping_expressions` では、複雑なグループ化オペレーションを実行できます。複雑なグループ化オペレーションを使用して、複数の列セットの集計を必要とする分析を単一のクエリで実行できます。 `grouping_expressions` 要素には、`SUM`、`AVG`、`COUNT` など、入力列に対して実行される任意の関数を指定できます。 `GROUP BY` 式は、`SELECT` ステートメントの出力に表示されない入力列名で出力をグループ化できます。 すべての出力式は、集計関数であるか、`GROUP BY` 句に存在する列であることが必要です。 単一のクエリを使用して、複数の列セットの集計を必要とする分析を実行できます。 Athena は、`GROUPING SETS`、`CUBE`、および `ROLLUP` を使用する複雑な集計をサポートしています。`GROUP BY GROUPING SETS` で、グループ化する列の複数のリストを指定します。`GROUP BY CUBE` で、特定の列のセットに対して、すべての可能なグループ化セットを生成します。`GROUP BY ROLLUP` で、特定の列のセットに対して、すべての可能な小計を生成します。複雑なグループ化オペレーションでは、入力列で構成される式でのグループ化がサポートされていません。列名のみが許可されます。 通常、`UNION ALL` を使用しても、これらの `GROUP BY` オペレーションと同じ結果を達成できます。ただし、`GROUP BY` を使用するクエリでは、データの読み取りが 1 回で済むという利点があります。`UNION ALL` は基となるデータを 3 回読み取るため、データソースが変わりやすい場合は、不整合な結果が生成されることがあります。 **[ HAVING condition ]** 集計関数と `GROUP BY` 句で使用します。どのグループを選択するかを制御します。`condition` を満たさないグループは排除されます。このフィルタ処理は、グループや集計の計算後に行われます。 **[ \$1 UNION \$1 INTERSECT \$1 EXCEPT \$1 [ ALL \$1 DISTINCT ] union\$1query] ]** `UNION`、`INTERSECT`、および `EXCEPT` は、複数の `SELECT` ステートメントの結果を 1 つのクエリに結合します。`ALL` または `DISTINCT` は、最終的な結果セットに含められる行の一意性を制御します。 `UNION` は、最初のクエリから得られた行と、2 番目のクエリから得られた行を結合します。重複を排除するため、`UNION` はメモリを消費するハッシュテーブルを構築します。パフォーマンス向上のため、クエリに重複を排除する必要がない場合は `UNION ALL` の使用を検討してください。複数の `UNION` 句は左から右に処理されます。ただし、括弧を使用して処理の順序を明示的に定義することもできます。 `INTERSECT` は、最初のクエリと 2 番目のクエリ両方の結果に存在する行のみを返します。 `EXCEPT` は、最初のクエリの結果からの行を返し、2 番目のクエリで見つかった行は排除されます。 `ALL` は、行が同一の場合でも、すべての行が含まれる処理を実行します。 `DISTINCT` は、統合された結果セットに一意の行のみが含まれるようにします。 **[ ORDER BY expression [ ASC \$1 DESC ] [ NULLS FIRST \$1 NULLS LAST] [, ...]]** 結果セットを 1 つ以上の出力 `expression` でソートします。 句に複数の式が含まれている場合、結果セットは最初の `expression` に従ってソートされます。次に、最初の式で一致した値がある行に 2 番目の `expression` が適用されます。以下、同様です。 各 `expression` では、`SELECT` の出力列を指定するか、出力列の位置を 1 から始まる序数で指定できます。 `ORDER BY` は、`GROUP BY` または `HAVING` 句の後で、最後のステップとして評価されます。`ASC` と `DESC` は、結果のソートを昇順にするか、降順にするかを決定します。デフォルトの並べ替え順序は昇順 (`ASC`) です。デフォルトの null 順序は、昇順または降順のソート順に関係なしに `NULLS LAST` です。 **[ OFFSET count [ ROW \$1 ROWS ] ]** `OFFSET` 句を使用して、結果セットの先頭の行をいくつか破棄します。`ORDER BY` 句が存在する場合、`OFFSET` 句はソートされた結果セットに対して評価されます。スキップされた行が破棄された後もセットはソートされたままになります。クエリに `ORDER BY` 句がない場合、破棄される行は任意です。`OFFSET` で指定したカウントが結果セットのサイズに等しいかそれを超える場合、最終結果は空になります。 **LIMIT [ count \$1 ALL ]** 結果セットの行数を `count` に制限します。`LIMIT ALL` は `LIMIT` 句を省略した場合と同じです。クエリに `ORDER BY` 句がない場合は、任意の結果になります。 **TABLESAMPLE [BERNOULLI \$1 SYSTEM] (percentage)** サンプリング方法に基づいてテーブルから行を選択する演算子 (オプション) です。 `BERNOULLI` は、`percentage` の確率でテーブルサンプルに存在する各行を選択します。テーブルのすべての物理ブロックがスキャンされ、サンプルの `percentage` とランタイムに計算されるランダム値の比較に基づいて、特定の行がスキップされます。 `SYSTEM` では、テーブルがデータの論理セグメントに分割され、この詳細度でテーブルがサンプリングされます。 特定のセグメントのすべての行が選択されるか、サンプルの `percentage` とランタイムに計算されたランダム値の比較に基づいて当該セグメントがスキップされます。`SYSTEM` サンプリングはコネクタに依存します。この方法では、独立したサンプリング確率は保証されません。 **[ UNNEST (array\$1or\$1map) [WITH ORDINALITY] ]** 配列またはマップをリレーションに展開します。配列は単一の列に展開されます。マップは 2 つの列 (*キー*、*値*) に展開されます。 `UNNEST` に複数の引数を使用できます。これらの引数は、複数の列に展開され、各列の行数は最大の基数引数と同じになります。 その他の列には NULL が埋め込まれます。 `WITH ORDINALITY` 句は、序数列を末尾に追加します。 通常、`UNNEST` は `JOIN` と一緒に使用し、`JOIN` の左側のリレーションの列を参照できます。 ## Amazon S3 内にあるソースデータのファイルの場所の取得 テーブル行にあるデータの Amazon S3 ファイルの場所を確認するには、以下の例にあるように、`SELECT` クエリで `"$path"` を使用できます。 ``` SELECT "$path" FROM "my_database"."my_table" WHERE year=2019; ``` このクエリは以下のような結果を返します。 ``` s3://amzn-s3-demo-bucket/datasets_mytable/year=2019/data_file1.json ``` テーブル内にあるデータについて S3 ファイル名パスのソートされた一意のリストを返すには、以下の例にあるように、`SELECT DISTINCT` と `ORDER BY` を使用できます。 ``` SELECT DISTINCT "$path" AS data_source_file FROM sampledb.elb_logs ORDER By data_source_file ASC ``` パスなしでファイル名のみを返すには、以下の例にあるように、`"$path"` をパラメータとして `regexp_extract` 関数に渡すことができます。 ``` SELECT DISTINCT regexp_extract("$path", '[^/]+$') AS data_source_file FROM sampledb.elb_logs ORDER By data_source_file ASC ``` 特定のファイルからのデータを返すには、以下の例にあるように、`WHERE` 句でそのファイルを指定します。 ``` SELECT *,"$path" FROM my_database.my_table WHERE "$path" = 's3://amzn-s3-demo-bucket/my_table/my_partition/file-01.csv' ``` 詳細と例については、ナレッジセンターの記事、「[Athena テーブルの行の Amazon S3 ソースファイルを表示する方法を教えてください](https://aws.amazon.com/premiumsupport/knowledge-center/find-s3-source-file-athena-table-row/)」を参照してください。 **注記** Athena では、Hive または Iceberg の非表示のメタデータ列 `$bucket`、`$file_modified_time`、`$file_size`、および `$partition` は、ビューでサポートされていません。 ## 一重引用符のエスケープ 一重引用符をエスケープするには、以下の例のように、その前に別の一重引用符を付けます。これを二重引用符と混同しないでください。 ``` Select 'O''Reilly' ``` **結果** `O'Reilly` ## その他のリソース Athena で `SELECT` ステートメントを使用する方法の詳細については、以下のリソースを参照してください。 | 詳細情報の内容 | 参照先 | | --- | --- | | Athena でクエリを実行する | [Amazon Athena で SQL クエリを実行する](querying-athena-tables.md) | | SELECT を使用してテーブルを作成する | [クエリ結果からテーブルを作成する (CTAS)](ctas.md) | | SELECT クエリからのデータを別のテーブルに挿入する | [INSERT INTO](insert-into.md) | | SELECT ステートメントで組み込みの関数を使用する | [Amazon Athena の関数](functions.md) | | SELECT ステートメントでユーザー定義の関数を使用する | [ユーザー定義関数を使用してクエリする](querying-udf.md) | | データカタログのメタデータをクエリする | [AWS Glue Data Catalog をクエリする](querying-glue-catalog.md) | # INSERT INTO ソーステーブルで実行される `SELECT` クエリステートメント、またはステートメントの一部として提供される `VALUES` のセットに基づいて、送信先テーブルに新しい行を挿入します。ソーステーブルが CSV や JSON などの形式の基盤データに基づくもので、宛先テーブルが Parquet や ORC など別の形式に基づいている場合は、`INSERT INTO` クエリを使用して、選択したデータを宛先テーブルの形式に変換できます。 ## 考慮事項と制限事項 Athena で `INSERT` クエリを使用するときは、以下の点を考慮してください。 + Amazon S3 で暗号化された基盤データがあるテーブルに対して `INSERT` クエリを実行する場合、`INSERT` クエリが書き込む出力ファイルはデフォルトで暗号化されません。暗号化されたデータを含むテーブルに挿入する場合は、`INSERT` クエリの結果を暗号化することをお勧めします。 コンソールを使用したクエリ結果の暗号化の詳細については、「[Amazon S3 に保存された Athena クエリ結果を暗号化する](encrypting-query-results-stored-in-s3.md)」を参照してください。AWS CLI または Athena API を使用した暗号化を有効にするには、[StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html) アクションの `EncryptionConfiguration` プロパティを使用して、要件に沿った Amazon S3 暗号化オプションを指定します。 + `INSERT INTO` ステートメントの場合、予想されるバケット所有者の設定は、Amazon S3 内の送信先テーブルのロケーションには適用されません。予期されるバケット所有者の設定は、Athena クエリの結果の出力先として指定した Amazon S3 内の場所にのみ適用されます。詳細については、「[Athena コンソールを使用してクエリ結果の場所を指定する](query-results-specify-location-console.md)」を参照してください。 + ACID 準拠の `INSERT INTO` ステートメントについては、[Iceberg テーブルデータを更新する](querying-iceberg-updating-iceberg-table-data.md) の `INSERT INTO` セクションを参照してください。 ### サポートされる形式と SerDes 次の形式と SerDes を使用して、データから作成されたテーブルに対して `INSERT` クエリを実行できます。 | データ形式 | 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 | | テキストファイル | org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe TSV、およびカスタム区切りファイルがサポートされています。 | | CSV | org.apache.hadoop.hive.serde2.OpenCSVSerde 書き込みは文字列型でのみサポートされます。Athena から、Glue スキーマに文字列以外の型を含むテーブルに書き込むことはできません。詳細については、「[CSV SerDe](csv-serde.md#csv-serde-opencsvserde-considerations-non-string)」を参照してください。 | ### バケット化されたテーブルはサポートされていません `INSERT INTO` はバケット化されたテーブルではサポートされていません。詳細については、「[パーティショニングとバケット化を使用する](ctas-partitioning-and-bucketing.md)」を参照してください。 ### フェデレーティッドクエリはサポートされていません 横串検索では、`INSERT INTO` はサポートされていません。これを試みた場合、「This operation is currently not supported for external catalogs (この操作は現在、外部カタログではサポートされていません)」というエラーメッセージが表示されることがあります。横串検索の詳細については、「[Amazon Athena フェデレーティッドクエリを使用する](federated-queries.md)」を参照してください。 ### パーティション `INSERT INTO` または `CREATE TABLE AS SELECT` クエリでパーティションを使用するときは、このセクションのポイントを考慮してください。 #### 制限 この `INSERT INTO` ステートメントは、送信先テーブルへの最大 100  個のパーティションの書き込みをサポートします。100 個を超えるパーティションを持つテーブルから `SELECT` 句を使用して行を追加する場合、`SELECT` クエリは、100 個以下のパーティションに制限されない限り失敗します。 この制限を回避する方法については、「[CTAS および INSERT INTO を使用して 100 パーティションの制限を回避する](ctas-insert-into.md)」を参照してください。 #### 列の順序 `INSERT INTO` または `CREATE TABLE AS SELECT` ステートメントは、`SELECT` ステートメントで射影された列のリストの最後の列がパーティションされた列であることを期待します。 ソーステーブルがパーティションされていない場合、または宛先テーブルとは異なる列でパーティションされている場合、`INSERT INTO destination_table SELECT * FROM source_table` のようなクエリは、ソーステーブルの最後の列の値が宛先テーブルのパーティション列の値であると見なします。パーティションされていないテーブルからパーティションテーブルを作成するときは、この点に留意してください。 #### リソース パーティションでの `INSERT INTO` の使用に関する詳細については、以下のリソースを参照してください。 + パーティションされたデータをパーティションテーブルに挿入する方法については、「[CTAS および INSERT INTO を使用して 100 パーティションの制限を回避する](ctas-insert-into.md)」を参照してください。 + パーティションされていないデータをパーティションテーブルに挿入する方法については、「[ETL およびデータ分析での CTAS および INSERT INTO を使用する](ctas-insert-into-etl.md)」を参照してください。 ### Amazon S3 に書き込まれるファイル Athena は、`INSERT` コマンドの結果として、Amazon S3 のソースデータの場所にファイルを書き込みます。`INSERT` オペレーションごとに、既存のファイルを追加するのではなく、新しいファイルが作成されます。ファイルの場所は、テーブルの構造と `SELECT` クエリ (存在する場合) に応じて異なります。Athena は、`INSERT` クエリごとにデータマニフェストファイルを生成します。マニフェストは、クエリが書き込んだファイルを追跡します。これは、Amazon S3 にある Athena のクエリ結果の場所に保存されます。詳細については、「[クエリ出力ファイルを識別する](querying-finding-output-files.md#querying-identifying-output-files)」を参照してください。 ### トランザクション集約型更新の回避 `INSERT INTO` を使用して Amazon S3 内のテーブルに行を追加しても、Athena は既存のファイルの書き換えや変更を行いません。その代わりに、Athena は 1 つ、または複数の新しいファイルとして行を書き込みます。[小さなファイルが多数存在するテーブルはクエリパフォーマンスの低下につながり](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files)、`PutObject` や `GetObject` などの書き込みおよび読み取り操作は Amazon S3 のコスト増加につながるため、`INSERT INTO` を使用するときは以下のオプションを検討してください。 + 行の大規模なバッチに対する `INSERT INTO` 操作の実行頻度を減らす。 + データインジェスト量が多い場合は、[Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) といったサービスの使用を検討する。 + もとより `INSERT INTO` を使用しないようにする。その代わりに、より大きなファイルに行を蓄積し、Athena が行をクエリできる Amazon S3 に直接アップロードします。 ### 孤立したファイルの検索 `CTAS` または `INSERT INTO` ステートメントが失敗すると、孤立したデータがデータの場所に残され、後続のクエリで読み取られる場合があります。検査または削除する孤立したファイルを見つけるには、Athena に用意されているデータマニフェストファイルを使用して、書き込まれるファイルのリストを追跡できます。詳細については、「[クエリ出力ファイルを識別する](querying-finding-output-files.md#querying-identifying-output-files)」および「[DataManifestLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_QueryExecutionStatistics.html#athena-Type-QueryExecutionStatistics-DataManifestLocation)」を参照してください。 ## INSERT INTO...SELECT 1 つのテーブル、`source_table` に対して実行するクエリを指定します。これにより、2 番目のテーブル、`destination_table` に挿入する行が決定されます。`SELECT` クエリが `source_table` での列を指定する場合、その列は `destination_table` の列と正確に一致する必要があります。 `SELECT` クエリの詳細については、「[SELECT](select.md)」を参照してください。 ### 概要 ``` INSERT INTO destination_table SELECT select_query FROM source_table_or_view ``` ### 例 `vancouver_pageviews` テーブル内のすべての行を選択し、`canada_pageviews` テーブルに挿入します。 ``` INSERT INTO canada_pageviews SELECT * FROM vancouver_pageviews; ``` `date` 列の値が `2019-07-01`～`2019-07-31` の `vancouver_pageviews` テーブル内の行のみを選択し、`canada_july_pageviews` に挿入します。 ``` INSERT INTO canada_july_pageviews SELECT * FROM vancouver_pageviews WHERE date BETWEEN date '2019-07-01' AND '2019-07-31'; ``` `cities_world` テーブルの `city` と `state` 列で、`country` 列の値が `usa` の行だけを選択して、`cities_usa` テーブルの `city` と `state` 列に挿入します。 ``` INSERT INTO cities_usa (city,state) SELECT city,state FROM cities_world WHERE country='usa' ``` ## INSERT INTO...VALUES 列と値を指定して、既存のテーブルに行を挿入します。指定された列と関連するデータ型は、宛先テーブルの列およびデータ型と正確に一致する必要があります。 **重要** Athena は `INSERT` オペレーションごとにファイルを生成するため、`VALUES` を使用した行の挿入は推奨されません。これにより、多数の小さなファイルが作成され、テーブルのクエリパフォーマンスが低下する可能性があります。`INSERT` クエリが作成するファイルを識別するには、データマニフェストファイルを調べます。詳細については、「[クエリ結果と最近のクエリを操作する](querying.md)」を参照してください。 ### 概要 ``` INSERT INTO destination_table [(col1,col2,...)] VALUES (col1value,col2value,...)[, (col1value,col2value,...)][, ...] ``` ### 例 次の例では、都市テーブルには、`id`、`city`、`state`、`state_motto` の 3 つの列があります。`id` 列は `INT` 型で、他のすべての列は `VARCHAR` 型です。 `cities` テーブルに 1 つの行を挿入し、すべての列の値を指定します。 ``` INSERT INTO cities VALUES (1,'Lansing','MI','Si quaeris peninsulam amoenam circumspice') ``` `cities` テーブルに 2 行を挿入します。 ``` INSERT INTO cities VALUES (1,'Lansing','MI','Si quaeris peninsulam amoenam circumspice'), (3,'Boise','ID','Esto perpetua') ``` # VALUES リテラルインラインテーブルを作成します。テーブルは匿名にすることも、 `AS` 句を使用してテーブル名、列名、またはその両方を指定することもできます。 ## 概要 ``` VALUES row [, ...] ``` ## パラメータ **行** `row` パラメータは、単一の式または `( column_expression [, ...] )` にすることができます。 ## 例 1 列 3 行のテーブルを返します。 ``` VALUES 1, 2, 3 ``` 2 列 3 行のテーブルを返します。 ``` VALUES (1, 'a'), (2, 'b'), (3, 'c') ``` 列 `id` と `name` を含むテーブルを返します。 ``` SELECT * FROM ( VALUES (1, 'a'), (2, 'b'), (3, 'c') ) AS t (id, name) ``` 列 `id` と `name` を含む `customers` というテーブルを作成します。 ``` CREATE TABLE customers AS SELECT * FROM ( VALUES (1, 'a'), (2, 'b'), (3, 'c') ) AS t (id, name) ``` ## 以下も参照してください。 [INSERT INTO...VALUES](insert-into.md#insert-into-values) # DELETE Apache Iceberg テーブルの行を削除します。`DELETE` はトランザクション型で、Apache Iceberg テーブルでのみサポートされています。 ## 概要 Iceberg テーブルから行を削除するには、次の構文を使用します。 ``` DELETE FROM [db_name.]table_name [WHERE predicate] ``` 詳細と例については、[Iceberg テーブルデータを更新する](querying-iceberg-updating-iceberg-table-data.md) の `DELETE` セクションを参照してください。 # UPDATE Apache Iceberg テーブルの行を更新します。`UPDATE` はトランザクションであり、Apache Iceberg テーブルでのみサポートされています。ステートメントは既存の行でのみ機能し、行の挿入や追加には使用できません。 ## 概要 Iceberg テーブルの行を更新するには、次の構文を使用します。 ``` UPDATE [db_name.]table_name SET xx=yy[,...] [WHERE predicate] ``` 詳細と例については、[Iceberg テーブルデータを更新する](querying-iceberg-updating-iceberg-table-data.md) の `UPDATE` セクションを参照してください。 # MERGE INTO Apache Iceberg テーブルに条件付きで行を更新、削除、または挿入します。単一のステートメントで、更新、削除、挿入のアクションを組み合わせることができます。 **注記** `MERGE INTO` はトランザクションで、Athena エンジンバージョン 3 の Apache Iceberg テーブルでのみサポートされています。 ## 概要 Iceberg テーブルから条件付きで行を更新、削除、または挿入するには、次の構文を使用します。 ``` MERGE INTO target_table [ [ AS ] target_alias ] USING { source_table | query } [ [ AS ] source_alias ] ON search_condition when_clause [...] ``` *when\$1clause* は次のいずれかです。 ``` 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` は、異なる `MATCHED` の条件を持つ任意の数の `WHEN` 句をサポートします。条件句は、`MATCHED` ステートと一致条件によって選択された最初の `WHEN` 句の `DELETE`、`UPDATE` または `INSERT` 演算を実行します。 ソース行ごとに、`WHEN` 句が順番に処理されます。最初に一致した `WHEN` 句のみが実行されます。後続の句は無視されます。1 つのターゲットテーブル行が複数のソース行と一致すると、ユーザーエラーが発生します。 ソース行がどの `WHEN` 句にも一致せず、`WHEN NOT MATCHED` 句がない場合、そのソース行は無視されます。 `UPDATE` 演算を含む `WHEN` 句では、列値の式はターゲットまたはソースの任意のフィールドを参照できます。`NOT MATCHED` の場合、`INSERT` の式はソースの任意のフィールドを参照できます。 **例** 次の例では、行が最初のテーブルに存在しない場合、2 番目のテーブルの行を最初のテーブルにマージしています。`VALUES` 句にリストされている列の先頭には、ソーステーブルのエイリアスを付ける必要があることに注意してください。`INSERT` 句にリストされているターゲット列には、このプレジックスを付けないでください。 ``` 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) ``` その他の `MERGE INTO` 例については、「[Iceberg テーブルデータを更新する](querying-iceberg-updating-iceberg-table-data.md)」を参照してください。 # OPTIMIZE 関連する削除ファイルのサイズと数に基づいて、データファイルをより最適化されたレイアウトに書き換えることにより、Apache Iceberg テーブル内の行を最適化します。 **注記** `OPTIMIZE` は Apache Iceberg テーブルでのみサポートされているトランザクションです。 ## 構文 次の構文の概要は、Iceberg テーブルのデータレイアウトを最適化する方法を示しています。 ``` OPTIMIZE [db_name.]table_name REWRITE DATA USING BIN_PACK [WHERE predicate] ``` **注記** `WHERE` 句の*述語*にはパーティション列のみを使用できます。非パーティション列を指定すると、クエリは失敗します。 圧縮アクションは、書き換えプロセス中にスキャンしたデータ量の分だけ課金されます。`REWRITE DATA` アクションは、述語を使用して、一致する行を含むファイルを選択します。ファイル内のいずれかの行が述語と一致する場合、ファイルは最適化のために選択されます。したがって、`WHERE` 句を指定することで、圧縮オペレーションの影響を受けるファイルの数を制御できます。 ## 圧縮のプロパティの設定 圧縮用に選択するファイルのサイズと、圧縮後の結果のファイルサイズを制御するには、テーブルプロパティパラメータを使用します。[ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) コマンドを使用して、関連する[テーブルプロパティ](querying-iceberg-creating-tables.md#querying-iceberg-table-properties)を設定できます。 ## その他のリソース [Iceberg テーブルを最適化する](querying-iceberg-data-optimization.md) # VACUUM `VACUUM` ステートメントは、[スナップショットの有効期限切れ](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots)と[孤立ファイルの削除](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files)を実行して、Apache Iceberg テーブルのテーブルメンテナンスを実行します。 **注記** `VACUUM` はトランザクションで、Athena エンジンバージョン 3 の Apache Iceberg テーブルでのみサポートされています。 `VACUUM` ステートメントは、ストレージの消費量を減らすことで Iceberg テーブルを最適化します。`VACUUM` の使用の詳細については、「[Iceberg テーブルを最適化する](querying-iceberg-data-optimization.md)」を参照してください。`VACUUM` ステートメントは Amazon S3 に API 呼び出しを行うため、Amazon S3 への関連するリクエストに対して料金がかかることに注意してください。 **警告** スナップショット有効期限切れオペレーションを実行すると、期限切れのスナップショットへのタイムトラベルができなくなります。 ## 概要 Iceberg テーブルで不要になったデータファイルを削除するには、次の構文を使用します。 ``` VACUUM [database_name.]target_table ``` + `VACUUM` は、Iceberg データが Amazon S3 バケットではなく Amazon S3 フォルダに格納されることを想定しています。例えば、Iceberg データが `s3://amzn-s3-demo-bucket/myicebergfolder/` ではなく `s3://amzn-s3-demo-bucket`/ に格納されている場合、`VACUUM` ステートメントは「GENERIC\$1INTERNAL\$1ERROR: ファイルシステムロケーション: `s3://amzn-s3-demo-bucket` にパスがありません」というエラーで失敗します。 + `VACUUM` がデータファイルを削除できるようにするには、クエリ実行ロールに、Iceberg テーブル、メタデータ、スナップショット、およびデータファイルが配置されているバケットに対する `s3:DeleteObject` 許可が必要です。許可が存在しない場合、`VACUUM` クエリは成功しますが、ファイルは削除されません。 + アンダースコアで始まる名前 (例: `_mytable`) を持つテーブルで `VACUUM` を実行するには、次の例にあるようにテーブル名をバックティックで囲みます。テーブル名の前にデータベース名を付ける場合は、データベース名をバックティックで囲まないでください。バックティックの代わりに二重引用符を使用しても機能しないことに注意してください。 この動作は `VACUUM` に固有の動作です。`CREATE` および `INSERT INTO` ステートメントでは、アンダースコアで始まるテーブル名にバックティックは必要ありません。 ``` VACUUM `_mytable` VACUUM my_database.`_mytable` ``` ## 実行されたオペレーション `VACUUM` では以下のオペレーションを実行します。 + `vacuum_max_snapshot_age_seconds` テーブルプロパティで指定された時間よりも古いスナップショットを削除します。デフォルトでは、このプロパティは 432,000 秒 (5 日間) に設定されています。 + 保持期間に含まれていないスナップショットのうち、`vacuum_min_snapshots_to_keep` テーブルプロパティで指定された数を超えているスナップショットを削除します。デフォルト は 1 です。 これらのテーブルプロパティは `CREATE TABLE` ステートメントで指定できます。テーブルを作成した後、[ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) ステートメントを使用してテーブルを更新できます。 + スナップショットを削除した結果としてアクセスできなかったメタデータおよびデータファイルをすべて削除します。`vacuum_max_metadata_files_to_keep` テーブルプロパティを設定すると、保持する古いメタデータファイルの数を設定できます。デフォルト値は 100 です。 + `vacuum_max_snapshot_age_seconds` テーブルプロパティで指定された時間より古い孤立ファイルを削除します。孤立ファイルとは、テーブルのデータディレクトリにある、テーブルステートの一部ではないファイルです。 Athena で Apache Iceberg テーブルを作成および管理する方法については、「[Iceberg テーブルを作成する](querying-iceberg-creating-tables.md)」および「[Iceberg テーブルを管理する](querying-iceberg-managing-tables.md)」を参照してください。 # Athena での EXPLAIN および EXPLAIN ANALYZE の使用 `EXPLAIN` ステートメントは、指定された SQL ステートメントの論理実行または分散実行プランを表示、または SQL ステートメントを検証します。結果はテキスト形式での出力、またはグラフへのレンダリングのためのデータ形式での出力が可能です。 **注記** `EXPLAIN` 構文を使用せずに、Athena コンソールでクエリの論理プランと分散プランのグラフィック表現を表示できます。詳細については、「[SQL クエリの実行プランを表示する](query-plans.md)」を参照してください。 `EXPLAIN ANALYZE` ステートメントでは、指定した SQL ステートメントの分散実行プランと、SQL クエリ内の各オペレーションに関する計算コストの両方を表示します。結果はテキスト形式または JSON 形式で出力することができます。 ## 考慮事項と制限事項 Athena の `EXPLAIN` および `EXPLAIN ANALYZE` ステートメントには、以下の制限があります。 + `EXPLAIN` クエリはデータをスキャンしないため、Athena はそれらに対する料金を請求しません。ただし、`EXPLAIN` クエリはテーブルメタデータの取得のために AWS Glue を呼び出すので、呼び出し回数が [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)を超える場合に料金が発生する可能性があります。 + この理由は、`EXPLAIN ANALYZE` クエリが実行されデータをスキャンすると、Athena は、そのスキャンされたデータ量に対して課金をするためです。 + Lake Formation で定義されている行またはセルのフィルタリング情報、およびクエリの統計情報は、`EXPLAIN` および `EXPLAIN ANALYZE` の出力には表示されません。 ## EXPLAIN 構文 ``` EXPLAIN [ ( option [, ...]) ] statement ``` *option* は以下のいずれかにすることができます。 ``` FORMAT { TEXT | GRAPHVIZ | JSON } TYPE { LOGICAL | DISTRIBUTED | VALIDATE | IO } ``` `FORMAT` オプションを指定しない場合、出力はデフォルトで `TEXT` 形式となります。`IO` タイプは、クエリが読み取るテーブルとスキーマに関する情報を提供します。 ## EXPLAIN ANALYZE 構文 `EXPLAIN` からの出力に加えて、`EXPLAIN ANALYZE` では、CPU 使用率、入力された行数、出力された行数など、指定したクエリの実行時に関する統計情報も出力します。 ``` EXPLAIN ANALYZE [ ( option [, ...]) ] statement ``` *option* は以下のいずれかにすることができます。 ``` FORMAT { TEXT | JSON } ``` `FORMAT` オプションを指定しない場合、出力はデフォルトで `TEXT` 形式となります。`EXPLAIN ANALYZE` によるすべてのクエリは `DISTRIBUTED` なので、`EXPLAIN ANALYZE` では `TYPE` オプションを使用することはできません。 *ステートメント*は以下のいずれかになります。 ``` SELECT CREATE TABLE AS SELECT INSERT UNLOAD ``` ## EXPLAIN での例 以下の `EXPLAIN` に関する例では、まず端的なものを示し、その後に、複合型のものへと進みます。 ### 例 1: テキスト形式でクエリプランを表示するために、EXPLAIN ステートメントを使用する 次の例の `EXPLAIN` では、Elastic Load Balancing ログでの `SELECT` クエリについて、その実行プランを表示します 使用される形式はデフォルトのテキスト出力です。 ``` EXPLAIN SELECT request_timestamp, elb_name, request_ip FROM sampledb.elb_logs; ``` #### 結果 ``` - 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 ``` ### 例 2: EXPLAIN を使用してクエリプランをグラフ化する Athena コンソールを使用してクエリプランをグラフ化できます。次のような `SELECT` ステートメントを Athena クエリエディタに入力し、**[EXPLAIN]** を選択します。 ``` 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 ``` Athena クエリエディタの **[Explain]** ページが開き、クエリの分散プランと論理プランが表示されます。次のグラフは、この例の論理プランを示します。 ![\[Athena クエリエディタによってレンダリングされたクエリプランのグラフ。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/athena-explain-statement-tpch.png) **重要** 現在、一部のパーティションフィルターは、Athena がクエリに適用しても、ネストされたオペレーターツリーグラフに表示されない場合があります。このようなフィルターの効果を検証するには、クエリで `EXPLAIN` または `EXPLAIN ANALYZE` を実行し、結果を表示します。 Athena コンソールでクエリプランのグラフ機能を使用する方法の詳細については、「[SQL クエリの実行プランを表示する](query-plans.md)」を参照してください。 ### 例 3: EXPLAIN ステートメントを使用してパーティションプルーニングを検証する パーティションされたキーにフィルタリング述語を使用してパーティションテーブルをクエリする場合、クエリエンジンはパーティションされたキーにこの述語を適用して、読み込むデータの量を減らします。 以下の例では、パーティションテーブルでの `SELECT` クエリについてパーティションプルーニングを検証するために `EXPLAIN` クエリを使用します。まず、`CREATE TABLE` ステートメントが `tpch100.orders_partitioned` テーブルを作成します。テーブルは、列 `o_orderdate` でパーティションされます。 ``` 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//' ``` `SHOW PARTITIONS` コマンドによる表示にあるように、`tpch100.orders_partitioned` テーブルには `o_orderdate` にいくつかのパーティションがあります。 ``` 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 ``` 以下の `EXPLAIN` クエリは、指定された `SELECT` ステートメントでパーティションプルーニングを検証します。 ``` EXPLAIN SELECT o_orderkey, o_custkey, o_orderdate FROM tpch100.orders_partitioned WHERE o_orderdate = '1995' ``` #### 結果 ``` 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 ``` 結果にある太字のテキストは、`PARTITION_KEY` に述語 `o_orderdate = '1995'` が適用されたことを示しています。 ### 例 4: EXPLAIN クエリを使用して結合順序と結合タイプをチェックする 以下の `EXPLAIN` クエリは、`SELECT` ステートメントの結合順序と結合タイプをチェックします。`EXCEEDED_LOCAL_MEMORY_LIMIT` エラーが発生する確率を減らすことができるように、このようなクエリを使用してクエリのメモリ使用量を調べます。 ``` 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 ``` #### 結果 ``` 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 ``` このクエリ例は、パフォーマンスを向上させるためにクロス結合に最適化されています。結果は、`tpch100.orders` が `BROADCAST` 分散タイプとして分散されることを示しています。これは、結合オペレーションを実行するすべてのノードに `tpch100.orders` テーブルが分散されることを意味します。`BROADCAST` 分散タイプでは、`tpch100.orders` テーブルのフィルタリングされた結果のすべてが、結合操作を実行する各ノードのメモリに収まることが必要とされています。 ただし、`tpch100.customer` テーブルは `tpch100.orders` よりも小さくなります。`tpch100.customer` に必要なメモリは少ないため、クエリを `tpch100.orders` ではなく `BROADCAST tpch100.customer` に書き直すことができます。これにより、クエリが `EXCEEDED_LOCAL_MEMORY_LIMIT` エラーを受け取る確率が低くなります。この戦略では、以下の点を前提としています。 + `tpch100.customer.c_custkey` が `tpch100.customer` テーブルで一意である。 + `tpch100.customer` と `tpch100.orders` の間に 1 対多のマッピング関係がある。 以下の例は、書き直されたクエリを示しています。 ``` 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 ``` ### 例 5: EXPLAIN クエリを使用して効果がない述語を削除する `EXPLAIN` クエリを使用して、フィルタリング述語の有効性をチェックすることができます。以下の例にあるように、結果を使用して効果がない述語を削除できます。 ``` 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 ``` #### 結果 ``` 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 ``` 結果にある `filterPredicate` は、オプティマイザが元の 3 つの述語を 2 つの述語にマージし、それらの適用順序を変更したことを示しています。 ``` filterPredicate = (("c_custkey" = 1500) AND ("c_custkey" = CAST(("random"() * 1E3) AS int))) ``` 結果が述語 `AND c.c_custkey BETWEEN 1000 AND 2000` に効果がないことを示しているので、クエリ結果を変更することなくこの述語を削除できます。 `EXPLAIN` クエリの結果で使用された用語については、「[Athena EXPLAIN ステートメントの結果を理解する](athena-explain-statement-understanding.md)」を参照してください。 ## EXPLAIN ANALYZE での例 次に、`EXPLAIN ANALYZE` クエリとその出力に関する例を示します。 ### 例 1: クエリプランとコンピューティングのコストをテキスト形式で表示するために、EXPLAIN ANALYZE を使用する 次の例の `EXPLAIN ANALYZE` は、CloudFront ログでの `SELECT` クエリについて、その実行プランとコンピューティングコストを表示します。使用される形式はデフォルトのテキスト出力です。 ``` EXPLAIN ANALYZE SELECT FROM cloudfront_logs LIMIT 10 ``` #### 結果 ``` 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 ``` ### 例 2: クエリプランを JSON 形式で表示するために、EXPLAIN ANALYZE を使用する 次の例は、CloudFront ログでの `SELECT` クエリについて、その実行プランとコンピューティングコストを表示します。この例では、出力形式として JSON を指定しています。 ``` EXPLAIN ANALYZE (FORMAT JSON) SELECT * FROM cloudfront_logs LIMIT 10 ``` #### 結果 ``` { "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": [] }] }] } }] } ``` ## その他のリソース 詳細については、次のリソースを参照してください。 + [Athena EXPLAIN ステートメントの結果を理解する](athena-explain-statement-understanding.md) + [SQL クエリの実行プランを表示する](query-plans.md) + [完了したクエリの統計と実行の詳細を表示する](query-stats.md) + Trino の「[https://trino.io/docs/current/sql/explain.html](https://trino.io/docs/current/sql/explain.html)」ドキュメント + Trino の「[https://trino.io/docs/current/sql/explain-analyze.html](https://trino.io/docs/current/sql/explain-analyze.html)」ドキュメント + *AWS Big Data Blog* の「[Optimize Federated Query Performance using EXPLAIN and EXPLAIN ANALYZE in Amazon Athena](https://aws.amazon.com/blogs/big-data/optimize-federated-query-performance-using-explain-and-explain-analyze-in-amazon-athena/)」。 [![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) # Athena EXPLAIN ステートメントの結果を理解する このトピックでは、Athena `EXPLAIN` ステートメントの結果で使用されるオペレーション用語の概要を説明します。 ## EXPLAIN ステートメントの出力タイプ `EXPLAIN` ステートメントの出力は、以下の 2 つのタイプのいずれかになります。 + **論理プラン** – SQL エンジンがステートメントの実行に使用する論理プランを表示します。このオプションの構文は `EXPLAIN` または `EXPLAIN (TYPE LOGICAL)` です。 + **分散プラン** – 分散環境での実行プランを表示します。出力には、処理ステージであるフラグメントが表示されます。各プランフラグメントは、1 つ、または複数のノードによって処理されます。データは、フラグメントを処理するノード間で交換できます。このオプションの構文は `EXPLAIN (TYPE DISTRIBUTED)` です。 分散プランの出力では、フラグメント (処理ステージ) は `Fragment` *number* [*fragment\$1type*] により表されます。この時、*number* はゼロから始まる整数であり、*fragment\$1type* はフラグメントがノードによってどのように実行されるかを指定します。以下の表では、データ交換のレイアウトに関する洞察を提供するフラグメントタイプが説明されています。 **分散プランのフラグメントタイプ** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/athena-explain-statement-understanding.html) ## Exchange Exchange 関連の用語は、データがワーカーノード間でどのように交換されるかを表します。転送はローカルまたはリモートのいずれかです。 **LocalExchange [*exchange\$1type*] ** クエリのさまざまなステージで、データをワーカーノード内でローカルに転送します。*exchange\$1type* の値は、このセクションで後ほど説明する論理交換タイプまたは分散交換タイプのいずれかになります。 **RemoteExchange [*exchange\$1type*] ** クエリのさまざまなステージで、データをワーカーノード間で転送します。*exchange\$1type* の値は、このセクションで後ほど説明する論理交換タイプまたは分散交換タイプのいずれかになります。 ### 論理交換タイプ 以下の交換タイプは、論理プランの交換フェーズで実行されるアクションを説明します。 + **`GATHER`** – 単一のワーカーノードが、他のすべてのワーカーノードからの出力を収集します。例えば、選択クエリの最後のステージでは、すべてのノードから結果が収集され、その結果が Amazon S3 に書き込まれます。 + **`REPARTITION`** – 次の演算子への適用に必要なパーティショニングスキームに基づいて、行データを特定のワーカーに送信します。 + **`REPLICATE`** – 行データをすべてのワーカーにコピーします。 ### 分散交換タイプ 以下の交換タイプは、データが分散プラン内のノード間で交換されるときのデータのレイアウトを示します。 + **`HASH`** – この交換は、ハッシュ関数を使用して複数の宛先にデータを分散します。 + **`SINGLE`** – この交換は、データを単一の宛先に分散します。 ## スキャニング 以下の用語は、クエリ中にデータがどのようにスキャンされるかを説明します。 **TableScan ** Amazon S3 または Apache Hive コネクタからテーブルのソースデータをスキャンし、フィルタ述語から生成されたパーティションプルーニングを適用します。 **ScanFilter ** Amazon S3 または Hive コネクタからテーブルのソースデータをスキャンし、フィルタ述語から生成されたパーティションプルーニングと、パーティションプルーニング経由で適用されない追加のフィルタ述語から生成されたパーティションプルーニングを適用します。 **ScanFilterProject ** 最初に、Amazon S3 または Hive コネクタからテーブルのソースデータをスキャンし、フィルタ述語から生成されたパーティションプルーニングと、パーティションプルーニング経由で適用されない追加のフィルタ述語から生成されたパーティションプルーニングを適用します。次に、出力データのメモリレイアウトを新しい射影に変更して、後続ステージのパフォーマンスを向上させます。 ## 結合 2 つのテーブル間でデータを結合します。結合は、結合タイプおよび分散タイプ別に分類できます。 ### 結合の種類 結合タイプは、結合オペレーションの実行方法を定義します。 **CrossJoin** – 結合された 2 つのテーブルのデカルト積を生成します。 **InnerJoin** – 両方のテーブルに一致する値を持つレコードを選択します。 **LeftJoin** – 左側のテーブルからのすべてのレコードと、右側のテーブルからの一致するレコードを選択します。一致するレコードがない場合、右側の結果は NULL になります。 **RightJoin** – 右側のテーブルからのすべてのレコードと、左側のテーブルからの一致するレコードを選択します。一致するレコードがない場合、左側の結果は NULL になります。 **FullJoin** – 左または右のテーブルのレコードに一致するものがあるすべてのレコードを選択します。結合されたテーブルには両方のテーブルからのすべてのレコードが含まれ、どちらかのテーブルで一致するレコードが欠落していれば NULL が入力されます。 **注記** パフォーマンス上の理由から、クエリエンジンは、結合クエリを異なる結合タイプに書き直して、同じ結果を生成することができます。例えば、1 つのテーブルでの述語を使用した内部結合クエリは、`CrossJoin` に書き直すことができます。これは、スキャンされるデータを少なくするために、述語をテーブルのスキャンフェーズにプッシュダウンします。 ### 結合の分散タイプ 分散タイプは、結合オペレーションの実行時に、データがワーカーノード間でどのように交換されるかを定義します。 **パーティション** – 左と右の両方のテーブルが、すべてのワーカーノード全体でハッシュパーティション分割されます。パーティション分散では、各ノードで消費されるメモリが少なくなります。パーティション分散は、レプリケート結合よりもはるかに遅くなる可能性があります。パーティション結合は、2 つの大きなテーブルを結合する場合に適しています。 **レプリケート** – 一方のテーブルがすべてのワーカーノード全体でハッシュパーティション分割され、もう一方のテーブルは、結合操作を実行するために、すべてのワーカーノードにレプリケートされます。レプリケート分散はパーティション結合よりもはるかに高速ですが、各ワーカーノードで消費されるメモリが多くなります。レプリケートされたテーブルが大きすぎる場合は、ワーカーノードでメモリ不足エラーが発生する可能性があります。レプリケート結合は、結合されたテーブルの 1 つが小さい場合に適しています。 # PREPARE 後で実行するために、名前 `statement_name` で SQL ステートメントを作成します。ステートメントには、疑問符で表されるパラメータを含めることができます。パラメータの値を指定してプリペアドステートメントを実行するには、[EXECUTE](sql-execute.md) を使用します。 ## 概要 ``` PREPARE statement_name FROM statement ``` 次の表は、パラメータの説明です。 **** | パラメータ | 説明 | | --- | --- | | statement\$1name | 準備されるステートメントの名前です。この名前は、ワークグループ内で一意である必要があります。 | | statement | SELECT、CTAS、または INSERT INTO クエリです。 | **注記** ワークグループ内の準備済みステートメントの最大数は 1,000 です。 ## 例 次の例では、パラメータなしで選択クエリを準備します。 ``` PREPARE my_select1 FROM SELECT * FROM nation ``` 次の例では、パラメータを含む選択クエリを準備します。`productid` および `quantity` の値は、`EXECUTE` ステートメントの `USING` 句によって指定されます。 ``` PREPARE my_select2 FROM SELECT order FROM orders WHERE productid = ? and quantity < ? ``` 次の例では、挿入クエリを準備します。 ``` PREPARE my_insert FROM INSERT INTO cities_usa (city, state) SELECT city, state FROM cities_world WHERE country = ? ``` ## 追加リソース [プリペアドステートメントを使用する](querying-with-prepared-statements-querying.md) [EXECUTE](sql-execute.md) [DEALLOCATE PREPARE](sql-deallocate-prepare.md) [INSERT INTO](insert-into.md) # EXECUTE `statement_name` という名前のプリペアドステートメントを実行します。プリペアドステートメントの疑問符のパラメータ値は、カンマ区切りのリストの `USING` 句で定義されています。プリペアドステートメントを作成するには、[PREPARE](sql-prepare.md) を使用します。 ## 概要 ``` EXECUTE statement_name [ USING parameter1[, parameter2, ... ] ] ``` ## 例 次の例は、パラメータがないクエリを準備し、実行します。 ``` PREPARE my_select1 FROM SELECT name FROM nation EXECUTE my_select1 ``` 次の例は、単一のパラメータがあるクエリを準備し、実行します。 ``` PREPARE my_select2 FROM SELECT * FROM "my_database"."my_table" WHERE year = ? EXECUTE my_select2 USING 2012 ``` これは次に相当します: ``` SELECT * FROM "my_database"."my_table" WHERE year = 2012 ``` 次の例は、2 つのパラメータを持つクエリを準備し、実行します。 ``` PREPARE my_select3 FROM SELECT order FROM orders WHERE productid = ? and quantity < ? EXECUTE my_select3 USING 346078, 12 ``` ## 追加リソース [プリペアドステートメントを使用する](querying-with-prepared-statements-querying.md) [PREPARE](sql-prepare.md) [INSERT INTO](insert-into.md) # DEALLOCATE PREPARE 現在のワークグループの準備済みステートメントから、指定された名前を持つ準備済みステートメントを削除します。 ## 概要 ``` DEALLOCATE PREPARE statement_name ``` ## 例 以下の例では、現在のワークグループから `my_select1` 準備済みステートメントを削除しています。 ``` DEALLOCATE PREPARE my_select1 ``` ## 追加リソース [プリペアドステートメントを使用する](querying-with-prepared-statements-querying.md) [PREPARE](sql-prepare.md) # UNLOAD `SELECT` ステートメントからのクエリ結果を指定したデータ形式に書き込みます。`UNLOAD` でサポートされる形式には Apache Parquet、ORC、Apache Avro、および JSON が含まれます。CSV は Athena `SELECT` コマンドがサポートする唯一の出力形式ですが、さまざまな出力形式をサポートする `UNLOAD` コマンドを使用して `SELECT` クエリを囲み、クエリの出力を `UNLOAD` がサポートする形式のいずれかに書き換えることができます。 `CREATE TABLE AS` (CTAS) ステートメントを使用して CSV 以外の形式でデータを出力できますが、CTAS ステートメントでは Athena でテーブルを作成する必要があります。`UNLOAD` ステートメントは、`SELECT` クエリの結果を非 CSV 形式で出力したいが、関連付けられたテーブルを必要としない場合に便利です。たとえば、ダウンストリームアプリケーションでは、`SELECT` クエリの結果を JSON 形式にする必要があります。また、`SELECT` クエリの結果を追加の分析に使用する場合は、Parquet や ORC の方が CSV よりもパフォーマンス面での利点を得られる可能性があります。 ## 考慮事項と制限事項 Athena で `UNLOAD` ステートメント使用するときは、次の点に注意してください。 + **ファイルのグローバルな順序付けがありません** - `UNLOAD` 結果が複数のファイルに並行して書き込まれます。`UNLOAD` ステートメントの `SELECT` クエリでソート順序が指定されている場合、各ファイルの内容はソート順序になりますが、ファイル同士は互いにソートされません。 + **孤立したデータが削除されません** - 障害が発生した場合、Athena は孤立したデータの削除を試みません。この動作は、CTAS および `INSERT INTO` ステートメントの動作と同じです。 + **最大パーティション数** - `UNLOAD` で使用できるパーティションの最大数は 100 です。 + **メタデータおよびマニフェストファイル** - Athena が、`UNLOAD` クエリごとにメタデータファイルとデータマニフェストファイルを生成します。マニフェストは、クエリが書き込んだファイルを追跡します。両方のファイルが、Amazon S3 の Athena クエリ結果の場所に保存されます。詳細については、「[クエリ出力ファイルを識別する](querying-finding-output-files.md#querying-identifying-output-files)」を参照してください。 + **暗号化** - `UNLOAD` 出力ファイルが、Amazon S3 で使用される暗号化設定に従って暗号化されます。暗号化設定を設定して `UNLOAD` 結果を暗号化するには、[EncryptionConfiguration API](https://docs.aws.amazon.com/athena/latest/APIReference/API_EncryptionConfiguration.html) を使用します。 + **準備済みステートメント** - `UNLOAD` は、準備済みステートメントで使用できます。Athena での準備済みステートメントの詳細については、「[パラメータ化されたクエリを使用する](querying-with-prepared-statements.md)」を参照してください。 + **サービスクォータ** - `UNLOAD` は、DML クエリクォータを使用します。クオータの詳細については、「[サービスクォータ](service-limits.md)」を参照してください。 + **予想されるバケット所有者** — 予想されるバケット所有者の設定は、`UNLOAD` クエリで指定された送信先の Amazon S3 の場所には適用されません。予期されるバケット所有者の設定は、Athena クエリの結果の出力先として指定した Amazon S3 内の場所にのみ適用されます。詳細については、「[Athena コンソールを使用してクエリ結果の場所を指定する](query-results-specify-location-console.md)」を参照してください。 ## 構文 `UNLOAD` ステートメントでは、次の構文を使用します。 ``` UNLOAD (SELECT col_name[, ...] FROM old_table) TO 's3://amzn-s3-demo-bucket/my_folder/' WITH ( property_name = 'expression' [, ...] ) ``` パーティションに書き込む場合を除き、`TO` 書き込み先にはデータのない Amazon S3 ロケーションを指定する必要があります。`UNLOAD` クエリが、指定された場所に書き込む前に、バケットの場所が空であることを確認します。`UNLOAD` は、指定された場所にデータがすでに存在する場合、その場所にデータを書き込まないので、`UNLOAD`が既存のデータを上書きすることはありません。バケットの場所を `UNLOAD` の送信先として再利用するには、バケットの場所にあるデータを削除して、クエリを再度実行します。 `UNLOAD` がパーティションにき込む場合、これとは異なる動作になることに注意してください。同じ `SELECT` ステートメント、同じ `TO` ロケーション、および同じパーティションを持つ同一の `UNLOAD` クエリを複数回実行する場合、各 `UNLOAD` クエリはそのロケーションにある Amazon S3 と指定されたパーティションにデータをアンロードします。 ### パラメータ *property\$1name* に使用できる値は次のとおりです。 ** 形式 =「*file\$1format*」 ** 必須。出力のファイル形式を指定します。*file\$1format* に使用できる値は、`ORC`、`PARQUET`、`AVRO`、`JSON`、 または`TEXTFILE` です。 ** 圧縮 =「*compression\$1format*」 ** オプション。このオプションは、ORC および Parquet 形式に固有のものです。ORC の場合、デフォルトは `zlib` で、Parquet の場合、デフォルトは `gzip` です。サポートされている圧縮形式については、「[Athena 圧縮サポート](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)」を参照してください。 このオプションは、`AVRO` 形式には適用されません。Athena が、`JSON` および `TEXTFILE` 形式に `gzip` を使用します。 **compression\$1level = *compression\$1level* ** オプション。ZSTD 圧縮に使用する圧縮レベル。このプロパティは、ZSTD 圧縮にのみ適用されます。詳細については、「[ZSTD 圧縮レベルを使用する](compression-support-zstd-levels.md)」を参照してください。 ** field\$1delimiter =「*delimiter*」 ** オプション。CSV、TSV、およびその他のテキスト形式のファイルのための単一文字のフィールド区切り文字を指定します。次に示す例では、カンマ区切り文字を指定しています。 ``` WITH (field_delimiter = ',') ``` 現在、複数文字のフィールド区切り文字はサポートされていません。フィールド区切り文字を指定しない場合、8 進文字 `\001` (^A) が使用されます。 ** partitioned\$1by = ARRAY[ *col\$1name*[,...]] ** オプション。出力をパーティション化する列の配列リスト。 `SELECT` ステートメントでは、パーティション化された列の名前は、列のリストの最後に記述されていることを確認してください。 ## 例 次の例では、JSON 形式を使用して `SELECT` クエリの出力を Amazon S3 の場所 `s3://amzn-s3-demo-bucket/unload_test_1/` に書き込みます。 ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/unload_test_1/' WITH (format = 'JSON') ``` 次の例では、Snappy 圧縮を使用して `SELECT` クエリの出力を Parquet 形式で書き込みます。 ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET',compression = 'SNAPPY') ``` 次の例では、出力が最後の列でパーティション化された状態で、4 つの列をテキスト形式で書き込みます。 ``` UNLOAD (SELECT name1, address1, comment1, key1 FROM table1) TO 's3://amzn-s3-demo-bucket/ partitioned/' WITH (format = 'TEXTFILE', partitioned_by = ARRAY['key1']) ``` 次の例では、Parquet ファイル形式、ZSTD 圧縮、および ZSTD 圧縮レベル 4 を使用して、クエリ結果を指定された場所にアンロードします。 ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET', compression = 'ZSTD', compression_level = 4) ``` ## その他のリソース + *AWS Big Data Blog* の「[Simplify your ETL and ML pipelines using the Amazon Athena UNLOAD feature](https://aws.amazon.com/blogs/big-data/simplify-your-etl-and-ml-pipelines-using-the-amazon-athena-unload-feature/)」。 # Amazon Athena の関数 Athena エンジンのバージョンに関する詳細については、「[Athena エンジンのバージョニング](engine-versions.md)」を参照してください。`AT TIME ZONE` 演算子で使用できるタイムゾーンのリストについては、「[サポートされているタイムゾーンを使用する](athena-supported-time-zones.md)」を参照してください。 **Topics** + [Athena エンジンバージョン 3](functions-env3.md) # Athena エンジンバージョン 3 の関数 Athena エンジンバージョン 3 の関数は Trino に基づいています。Trino の関数、演算子、および式については、Trino ドキュメントの「[Functions and operators](https://trino.io/docs/current/functions.html)」(関数と演算子) とそのサブセクションを参照してください。 + [Aggregate](https://trino.io/docs/current/functions/aggregate.html) + [配列](https://trino.io/docs/current/functions/array.html) + [バイナリ](https://trino.io/docs/current/functions/binary.html) + [ビット操作](https://trino.io/docs/current/functions/bitwise.html) + [Color](https://trino.io/docs/current/functions/color.html) + [比較](https://trino.io/docs/current/functions/comparison.html) + [条件付き](https://trino.io/docs/current/functions/conditional.html) + [変換](https://trino.io/docs/current/functions/conversion.html) + [日付および時間](https://trino.io/docs/current/functions/datetime.html) + [10 進数](https://trino.io/docs/current/functions/decimal.html) + [地理空間](https://trino.io/docs/current/functions/geospatial.html) + [HyperLogLog](https://trino.io/docs/current/functions/hyperloglog.html) + [IP アドレス](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) + [論理](https://trino.io/docs/current/functions/logical.html) + [機械学習](https://trino.io/docs/current/functions/ml.html) + [マッピング](https://trino.io/docs/current/functions/map.html) + [数値演算](https://trino.io/docs/current/functions/math.html) + [分位点ダイジェスト](https://trino.io/docs/current/functions/qdigest.html) + [正規表現](https://trino.io/docs/current/functions/regexp.html) + [セッション](https://trino.io/docs/current/functions/session.html) + [セットダイジェスト](https://trino.io/docs/current/functions/setdigest.html) + [文字列](https://trino.io/docs/current/functions/string.html) + [[テーブル]](https://trino.io/docs/current/functions/table.html) + [Teradata](https://trino.io/docs/current/functions/teradata.html) + [T ダイジェスト](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() 関数 この `invoker_principal` 関数は Athena エンジンバージョン 3 に固有のもので、Trino にはありません。 関数を呼び出すクエリを実行したプリンシパル (IAM ロールまたは アイデンティティセンター ID) の ARN を含む `VARCHAR` を返します。例えば、クエリ呼び出し元が IAM ロールのアクセス許可を使用してクエリを実行する場合、関数は IAM ロールの ARN を返します。クエリを実行するロールは、`LakeFormation:GetDataLakePrincipal` アクションを許可する必要があります。 ### 使用方法 ``` SELECT invoker_principal() ``` 次の表は結果の例を示しています。 **** | \$1 | \$1col0 | | --- | --- | | 1 | arn:aws:iam::111122223333:role/Admin | # サポートされているタイムゾーンを使用する 次の例にあるように、`AT TIME ZONE` 演算子を `SELECT timestamp` ステートメントで使用して、返されるタイムスタンプのタイムゾーンを指定します。 ``` SELECT timestamp '2012-10-31 01:00 UTC' AT TIME ZONE 'America/Los_Angeles' AS la_time; ``` **結果** ``` la_time 2012-10-30 18:00:00.000 America/Los_Angeles ``` Athena でサポートされているタイムゾーンのリストについては、このトピックの最後にある [サポートされているタイムゾーンを一覧表示する](#athena-supported-time-zones-list) を展開してください。 ## タイムゾーン関数と例 追加のタイムゾーン関連の関数と例を次に示します。 + **at\$1timezone(*timestamp*、*zone*)** – *zone* について、対応する現地時間の *timestamp* の値を返します。 **例** ``` SELECT at_timezone(timestamp '2021-08-22 00:00 UTC', 'Canada/Newfoundland') ``` **結果** ``` 2021-08-21 21:30:00.000 Canada/Newfoundland ``` + **timezone\$1hour(*timestamp*)** – timestamp からオフセットされたタイムゾーンの時間を `bigint` として返します。 **例** ``` SELECT timezone_hour(timestamp '2021-08-22 04:00 UTC' AT TIME ZONE 'Canada/Newfoundland') ``` **結果** ``` -2 ``` + **timezone\$1minute(*timestamp*)** – *timestamp* からオフセットされたタイムゾーンの分を `bigint` として返します。 **例** ``` SELECT timezone_minute(timestamp '2021-08-22 04:00 UTC' AT TIME ZONE 'Canada/Newfoundland') ``` **結果** ``` -30 ``` + **with\$1timezone(*timestamp*, *zone*)** – 指定された *timestamp* と *zone* の値からタイムゾーン付きのタイムスタンプを返します。 **例** ``` SELECT with_timezone(timestamp '2021-08-22 04:00', 'Canada/Newfoundland') ``` **結果** ``` 2021-08-22 04:00:00.000 Canada/Newfoundland ``` ## サポートされているタイムゾーンを一覧表示する 以下のリストには、Athena で `AT TIME ZONE` 演算子に使用できるタイムゾーンが記載されています。その他のタイムゾーン関連の関数および例については、「[タイムゾーン関数と例](#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 ```