# Athena エンジンのバージョニング
Athena は、パフォーマンスと機能の改善、およびコードの修正を反映するために、新しいエンジンバージョンをリリースすることがあります。新しいエンジンバージョンが利用可能になると、Athena がコンソールと [AWS Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) で通知を行います。AWS Health Dashboard は、AWS のサービス、またはアカウントに影響を及ぼす可能性があるイベントについて通知します。AWS Health Dashboard の詳細については、「[AWS Health Dashboard の使用開始](https://docs.aws.amazon.com/health/latest/ug/getting-started-phd.html)」を参照してください。
エンジンのバージョン管理は、[ワークグループ](workgroups-manage-queries-control-costs.md)ごとに設定されます。ワークグループを使用して、クエリが使用するクエリエンジンと、Athena がワークグループを自動的にアップグレードできるかどうかを制御できます。使用中のクエリエンジンは、クエリエディタとワークグループの詳細ページに表示され、Athena API を使用して取得することもできます。
+ デフォルトで、ワークグループは自動アップグレードするように設定されています。自動アップグレードするようにワークグループを設定すると、非互換性を検出した場合を除き、Athena がワークグループをアップグレードします。
+ 特定のバージョンを使用するようにワークグループを設定すると、Athena はワークグループのバージョンを変更しません。
どちらの場合も、Athena はバージョンが利用できなくなった時点でワークグループをアップグレードします。Athena は、エンジンバージョンが提供されなくなる時期に関する通知を、[AWS Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) 経由で行います。Health Dashboard は、AWS のサービス、またはアカウントに影響を及ぼす可能性があるイベントについて通知します。AWS Health Dashboard の詳細については、「[AWS Health Dashboard の使用開始](https://docs.aws.amazon.com/health/latest/ug/getting-started-phd.html)」を参照してください。
新しいエンジンバージョンの使用を開始すると、非互換が原因でクエリの小さなサブセットが破損する場合があります。下位互換性のない変更は、新しい Athena バージョンのリリース時に発表されます。新しいエンジンを使用するテストワークグループを作成する、または既存のワークグループを試験的にアップグレードすることによって、アップグレード前にワークグループを使用してクエリをテストするようにしてください。詳細については、「[エンジンバージョンをアップグレードする前にクエリをテストする](engine-versions-changing.md#engine-versions-testing)」を参照してください。
**Topics**
+ [Athena エンジンバージョンを変更する](engine-versions-changing.md)
+ [Athena エンジンバージョン 3](engine-versions-reference-0003.md)
# Athena エンジンバージョンを変更する
Athena は、パフォーマンスと機能の改善、およびコードの修正を反映するために、新しいエンジンバージョンをリリースすることがあります。新しいエンジンバージョンが利用可能になると、Athena はコンソールで通知を行います。ユーザーは、アップグレードするタイミングを Athena に決定させる、またはワークグループごとに Athena エンジンのバージョンを手動で指定する選択ができます。
## ワークグループのエンジンバージョンを確認する
**[Workgroups]** (ワークグループ) ページから、任意のワークグループの現在のエンジンバージョンを確認することができます。
**ワークグループの現在のエンジンバージョンを確認する**
1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。
1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。
![\[展開メニューを選択します。\]](http://docs.aws.amazon.com/ja_jp/athena/latest/ug/images/nav-pane-expansion.png)
1. Athena コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。
1. **[Workgroups]** (ワークグループ) ページで、目的のワークグループを探します。ワークグループの **[Query engine version]** (クエリエンジンのバージョン) 列には、クエリエンジンのバージョンが表示されています。
## Athena コンソールを使用してエンジンバージョンを変更する
新しいエンジンバージョンが利用可能になると、アップグレードするタイミングを Athena に決定させる、またはワークグループが使用する Athena のエンジンバージョンを手動で指定することを選択できます。使用できるバージョンが 1 つしかない場合は、別のバージョンを指定できません。
**注記**
ワークグループのエンジンバージョンを変更するには、ワークグループで `athena:ListEngineVersions` アクションを実行する許可が必要です。IAM ポリシーの例については、「[ワークグループのポリシーの例](example-policies-workgroup.md)」を参照してください。
**Athena にワークグループをアップグレードするタイミングを決定させる**
1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。
1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。
1. コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。
1. ワークグループのリストで、設定するワークグループへのリンクを選択します。
1. **[編集]** を選択します。
1. **[Query engine version]** (クエリエンジンのバージョン) セクションにある **[Update query engine]** (クエリエンジンを更新) で、**[Automatic]** (自動) を選択し、ワークグループのアップグレードタイミングを Athena が選択できるようにします。これはデフォルトの設定です。
1. **[Save changes]** (変更の保存) をクリックします。
ワークグループのリストでは、ワークグループの **[Query engine update status]** (クエリエンジンの更新ステータス) に **[Automatic]** (自動) と表示されます。
**エンジンのバージョンを手動で選択する**
1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。
1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。
1. コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。
1. ワークグループのリストで、設定するワークグループへのリンクを選択します。
1. **[編集]** を選択します。
1. 手動でエンジンバージョンを選択するには、**[Query engine version]** (クエリエンジンのバージョン) セクションにある **[Update query engine]** (クエリエンジンを更新) で、**[Manual]** (手動) を選択します。
1. ワークグループで使用するエンジンのバージョンを自分で選択する場合は、**[Query engine version]** (クエリエンジンのバージョン) オプションを使用します。他に使用できるエンジンバージョンがない場合は、別のエンジンバージョンを指定することはできません。
1. **[Save changes]** (変更の保存) をクリックします。
ワークグループのリストでは、ワークグループの **[Query engine update status]** (クエリエンジンの更新ステータス) に **[Manual]** (手動) と表示されます。
## AWS CLI を使用してエンジンバージョンを変更する
AWS CLI を使用してエンジンバージョンを変更するには、次の例にある構文を使用します。
```
aws athena update-work-group --work-group workgroup-name --configuration-updates EngineVersion={SelectedEngineVersion='Athena engine version 3'}
```
## ワークグループの作成時にエンジンバージョンを指定する
ワークグループを作成するときは、ワークグループが使用するエンジンバージョンを指定する、または Athena にワークグループをアップグレードするタイミングを決定させることができます。利用可能な新しいエンジンバージョンがある場合のベストプラクティスは、他のワークグループをアップグレードする前に、別にワークグループを作成して新しいエンジンのテストを行うことです。ワークグループのエンジンバージョンを指定するには、ワークグループに対する `athena:ListEngineVersions` 許可が必要です。IAM ポリシーの例については、「[ワークグループのポリシーの例](example-policies-workgroup.md)」を参照してください。
**ワークグループの作成時にエンジンバージョンを指定する**
1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home) で Athena コンソールを開きます。
1. コンソールのナビゲーションペインが表示されない場合は、左側の展開メニューをクリックします。
1. コンソールのナビゲーションペインで、**[Workgroups]** (ワークグループ) をクリックします。
1. **[Workgroups]** (ワークグループ) ページで、**[Create workgroup]** (ワークグループを作成する) をクリックします。
1. **[Create workgroup]** (ワークグループの作成) ページにある **[Query engine version]** (クエリエンジンのバージョン) セクションで、以下のいずれかを実行します。
+ ワークグループをアップグレードするタイミングを Athena に選択させる場合は、**[Automatic]** (自動) を選択します。これはデフォルトの設定です。
+ 別の使用可能なエンジンバージョンを手動で選択する場合は、**[Manual]** (手動) を選択します。
1. 必要に応じて、他のフィールドに情報を入力します。他のフィールドについては、「[ワークグループの作成](creating-workgroups.md)」を参照してください。
1. **[Create workgroup]** (ワークグループの作成) を選択します。
## エンジンバージョンをアップグレードする前にクエリをテストする
ワークグループが新しいエンジンバージョンにアップグレードされると、互換性の問題が原因となり一部のクエリが破損する場合があります。エンジンバージョンのアップグレードがスムーズに行われることを確実にするには、事前にクエリをテストすることができます。
**エンジンバージョンのアップグレード前にクエリをテストする**
1. 使用しているワークグループのエンジンバージョンを確認します。使用しているエンジンのバージョンが、**[Workgroups]** (ワークグループ) ページで、対象のワークグループの **[Query engine version]** (クエリエンジンのバージョン) 列に表示されます。詳細については、「[ワークグループのエンジンバージョンを確認する](#engine-versions-changing-finding-the-query-engine-version-for-a-workgroup)」を参照してください。
1. 新しいエンジンバージョンを使用するテストワークグループを作成します。詳細については、「」を参照してください[ワークグループの作成時にエンジンバージョンを指定する](#engine-versions-changing-specifying-the-engine-version-when-you-create-a-workgroup)
1. 新しいワークグループを使用して、テストするクエリを実行します。
1. クエリが失敗した場合は、クエリに影響を及ぼしている可能性がある、新しいエンジン内の破壊的変更をチェックします。変更には、クエリ構文の更新が必要になるものもあります。
1. それでもクエリが失敗する場合は、AWS サポート に連絡してサポートを受けてください。Adding a change AWS マネジメントコンソール で、**[Support]** (サポート)、**[Support Center]** (サポートセンター) の順にクリックします。または、**[Amazon Athena]** タグを使用して [AWS re:Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) に質問します。
## エンジンバージョンのアップグレード後に失敗したクエリをトラブルシューティングする
エンジンバージョンのアップグレード後にクエリが失敗した場合は、クエリの構文に影響を及ぼす可能性がある変更を含めた破壊的変更をチェックしてください。
それでもクエリが失敗する場合は、AWS サポート に連絡してサポートを受けてください。Adding a change AWS マネジメントコンソール で、**[Support]** (サポート)、**[Support Center]** (サポートセンター) の順にクリックします。または、**[Amazon Athena]** タグを使用して [AWS re:Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) に質問します。
# Athena エンジンバージョン 3
エンジンバージョン 3 では、Athena はオープンソースのソフトウェア管理に継続的な統合アプローチを導入しました。これにより、[Trino](https://trino.io/) および [Presto](https://prestodb.io/) プロジェクトでの同時実行性が向上するため、Athena エンジン内で統合およびチューニングされたコミュニティの改善にすばやくアクセスできるようになります。
Athena エンジンバージョン 3 のこのリリースでは、以前のエンジンバージョンのすべての機能がサポートされています。このドキュメントでは、以前のエンジンバージョンと Athena エンジンバージョン 3 の主な違いについて説明します。詳細については、AWS Big Data Blog の記事、「[Upgrade to Athena engine version 3 to increase query performance and access more analytics features](https://aws.amazon.com/blogs/big-data/upgrade-to-athena-engine-version-3-to-increase-query-performance-and-access-more-analytics-features/)」を参照してください。
+ [はじめに](#engine-versions-reference-0003-getting-started)
+ [改善点と新機能](#engine-versions-reference-0003-improvements-and-new-features)
+ [追加された機能](#engine-versions-reference-0003-added-features)
+ [追加された関数](#engine-versions-reference-0003-added-functions)
+ [フォーマンスの向上](#engine-versions-reference-0003-performance-improvements)
+ [信頼性の強化](#engine-versions-reference-0003-reliability-enhancements)
+ [クエリ構文の機能強化](#engine-versions-reference-0003-query-syntax-enhancements)
+ [データ形式およびデータ型の機能強化](#engine-versions-reference-0003-data-format-and-data-type-enhancements)
+ [重要な変更](#engine-versions-reference-0003-breaking-changes)
+ [クエリ構文の変更](#engine-versions-reference-0003-syntax-changes)
+ [データ処理の変更](#engine-versions-reference-0003-data-processing-changes)
+ [タイムスタンプの変更](#engine-versions-reference-0003-timestamp-changes)
+ [制限事項](#engine-versions-reference-0003-known-limitations)
## はじめに
はじめに、Athena エンジンバージョン 3 を使用する新しい Athena ワークグループを作成するか、バージョン 3 を使用するように既存のワークグループを設定するかを選択します。
詳細については、「[Athena エンジンバージョンの変更](https://docs.aws.amazon.com/athena/latest/ug/engine-versions-changing.html)」を参照してください。
## 改善点と新機能
記載されている機能や更新には、Athena 自体の改善点と、オープンソースの Trino から組み込まれた機能性の改善点が含まれています。SQL クエリの演算子および関数を網羅するリストについては、「[Trino documentation](https://trino.io/docs/current/functions.html)」(Trino ドキュメント) を参照してください。
### 追加された機能
#### Apache Spark バケットアルゴリズムのサポート
Athena は Spark ハッシュアルゴリズムによって生成されたバケットを読み込むことができます。データが元々 Spark ハッシュアルゴリズムによって書き込まれたものであることを指定するには、`CREATE TABLE` ステートメントの `TBLPROPERTIES` 句に `('bucketing_format'='spark')` を入れます。このプロパティが指定されていない場合は、Hive ハッシュアルゴリズムが使用されます。
```
CREATE EXTERNAL TABLE `spark_bucket_table`(
`id` int,
`name` string
)
CLUSTERED BY (`name`)
INTO 8 BUCKETS
STORED AS PARQUET
LOCATION
's3://amzn-s3-demo-bucket/to/bucketed/table/'
TBLPROPERTIES ('bucketing_format'='spark')
```
### 追加された関数
このセクションの関数は、Athena エンジンバージョン 3 で新たに追加されました。
#### 集計関数
**listagg(x, separator)** – 連結された入力値を区切り文字列で区切って返します。
```
SELECT listagg(value, ',') WITHIN GROUP (ORDER BY value) csv_value
FROM (VALUES 'a', 'c', 'b') t(value);
```
#### 配列関数
**contains\$1sequence(x, seq)** – 配列 x にすべての配列シーケンスが (すべての値が同じ順序で) シーケンシャルサブセットとして含まれている場合、true を返します。
```
SELECT contains_sequence(ARRAY [1,2,3,4,5,6], ARRAY[1,2]);
```
#### バイナリ関数
**murmur3(binary)** – バイナリの 128 ビット MurmurHash3 ハッシュを計算します。
```
SELECT murmur3(from_base64('aaaaaa'));
```
#### 変換関数
**format\$1number(number)** – 単位記号を使用してフォーマットされた文字列を返します。
```
SELECT format_number(123456); -- '123K'
```
```
SELECT format_number(1000000); -- '1M'
```
#### 日付および時刻関数
**timezone\$1hour(timestamp)** – タイムスタンプからオフセットされたタイムゾーンの時間を返します。
```
SELECT EXTRACT(TIMEZONE_HOUR FROM TIMESTAMP '2020-05-10 12:34:56 +08:35');
```
**timezone\$1minute(timestamp)** – タイムスタンプからオフセットされたタイムゾーンの分数を返します。
```
SELECT EXTRACT(TIMEZONE_MINUTE FROM TIMESTAMP '2020-05-10 12:34:56 +08:35');
```
#### 地理空間関数
**to\$1encoded\$1polyline(Geometry)** – ライン文字列またはマルチポイントをポリラインにエンコードします。
```
SELECT to_encoded_polyline(ST_GeometryFromText(
'LINESTRING (-120.2 38.5, -120.95 40.7, -126.453 43.252)'));
```
**from\$1encoded\$1polyline(varchar)** – ポリラインをライン文字列にデコードします。
```
SELECT ST_AsText(from_encoded_polyline('_p~iF~ps|U_ulLnnqC_mqNvxq`@'));
```
**to\$1geojson\$1geometry(SphericalGeography)** – 指定された球面ジオグラフィを GeoJSON 形式で返します。
```
SELECT to_geojson_geometry(to_spherical_geography(ST_GeometryFromText(
'LINESTRING (0 0, 1 2, 3 4)')));
```
**from\$1geojson\$1geometry(varchar)** – 非ジオメトリのキー/値を取り除いて、GeoJSON 表現から球面ジオグラフィ型のオブジェクトを返します。`Feature` および `FeatureCollection` はサポートされていません。
```
SELECT from_geojson_geometry(to_geojson_geometry(to_spherical_geography(ST_GeometryFromText(
'LINESTRING (0 0, 1 2, 3 4)'))));
```
**geometry\$1nearest\$1points(Geometry, Geometry)** – 各ジオメトリ上の互いに最も近いポイントを返します。いずれかのジオメトリが空の場合は NULL を返します。それ以外の場合は、ジオメトリ上にある任意の 2 つのポイント間の距離が最小となる 2 つの `Point` オブジェクトを含む行を返します。最初のポイントは Geometry の 1 番目の引数から、2 番目のポイントは Geometry の 2 番目の引数からのものです。最小距離が同じペアが複数ある場合は、任意に 1 つのペアが選択されます。
```
SELECT geometry_nearest_points(ST_GeometryFromText(
'LINESTRING (50 100, 50 200)'), ST_GeometryFromText(
'LINESTRING (10 10, 20 20)'));
```
#### ダイジェスト関数の設定
**make\$1set\$1digest(x)** – x のすべての入力値を setdigest にまとめます。
```
SELECT make_set_digest(value) FROM (VALUES 1, 2, 3) T(value);
```
#### 文字列関数
**soundex(char)** – char の発音表現を含む文字列を返します。
```
SELECT name
FROM nation
WHERE SOUNDEX(name) = SOUNDEX('CHYNA'); -- CHINA
```
**concat\$1ws(string0, string1,..., stringN)** –`string0` を区切り文字として使用し、`string1, string2, ..., stringN` の結果を返します。`string0` が null である場合、戻り値は null です。区切り文字の後の引数に指定された null 値は、すべてスキップされます。
```
SELECT concat_ws(',', 'def', 'pqr', 'mno');
```
#### Window 関数
**GROUPS** – グループに基づくウィンドウフレームのサポートが追加されました。
```
SELECT array_agg(a) OVER(
ORDER BY a ASC NULLS FIRST GROUPS BETWEEN 1 PRECEDING AND 2 FOLLOWING)
FROM (VALUES 3, 3, 3, 2, 2, 1, null, null) T(a);
```
### フォーマンスの向上
Athena エンジンバージョン 3 でのパフォーマンスの向上には、次のものが含まれています。
+ **AWS Glue テーブルメタデータの取得の高速化** - 複数のテーブルを含むクエリでは、クエリ計画時間を短縮できます。
+ **RIGHT JOIN の動的フィルタリング** – 次の例のように、等価結合条件を持つ右結合に対して動的フィルタリングが有効になりました。
```
SELECT *
FROM lineitem RIGHT JOIN tpch.tiny.supplier
ON lineitem.suppkey = supplier.suppkey
WHERE supplier.name = 'abc';
```
+ **大きいサイズのプリペアドステートメント** - デフォルトの HTTP リクエスト/レスポンスヘッダーのサイズを 2 MB に増やし、大きいサイズのプリペアドステートメントを使用できるようにしました。
+ **approx\$1percentile()** — この `approx_percentile` 関数は、分布から近似分位値を取得するために `qdigest` の代わりに `tdigest` を使用するようになりました。その結果、パフォーマンスが向上し、メモリ使用量が少なくなります。この変更により、この関数は以前のエンジンバージョンとは異なる結果を返しますので、ご注意してください。詳細については、「[prox\$1percentile 関数は異なる結果を返します。](#engine-versions-reference-0003-approx-percentile-function)」を参照してください。
### 信頼性の強化
Athena エンジンバージョン 3 の一般的なエンジンメモリ使用量および追跡が改善されました。クエリの規模が大きい場合でも、ノードクラッシュによる障害の影響を受けにくくなります。
### クエリ構文の機能強化
**INTERSECT ALL** – `INTERSECT ALL` のサポートが追加されました。
```
SELECT * FROM (VALUES 1, 2, 3, 4) INTERSECT ALL SELECT * FROM (VALUES 3, 4);
```
**EXCEPT ALL** – `EXCEPT ALL` のサポートが追加されました。
```
SELECT * FROM (VALUES 1, 2, 3, 4) EXCEPT ALL SELECT * FROM (VALUES 3, 4);
```
**RANGE PRECEDING** – ウィンドウ関数の `RANGE PRECEDING` のサポートが追加されました。
```
SELECT sum(x) over (order by x range 1 preceding)
FROM (values (1), (1), (2), (2)) t(x);
```
**MATCH\$1RECOGNIZE** – 次の例のように、行パターン照合のサポートが追加されました。
```
SELECT m.id AS row_id, m.match, m.val, m.label
FROM (VALUES(1, 90),(2, 80),(3, 70),(4, 70)) t(id, value)
MATCH_RECOGNIZE (
ORDER BY id
MEASURES match_number() AS match,
RUNNING LAST(value) AS val,
classifier() AS label
ALL ROWS PER MATCH
AFTER MATCH SKIP PAST LAST ROW
PATTERN (() | A) DEFINE A AS true
) AS m;
```
### データ形式およびデータ型の機能強化
Athena エンジンバージョン 3 では、次のデータ形式とデータ型の機能が強化されています。
+ **LZ4 および ZSTD** – LZ4 および ZSTD で圧縮した Parquet データを読み込むためのサポートが追加されました。ZSTD で圧縮した ORC データを書き込むためのサポートが追加されました。
+ **Symlink ベースのテーブル** – Avro ファイルで Symlink ベースのテーブルを作成するためのサポートが追加されました。以下に例を示します。
```
CREATE TABLE test_avro_symlink
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.avro.AvroSerDe'
...
INPUTFORMAT 'org.apache.hadoop.hive.ql.io.SymlinkTextInputFormat'
```
+ **SphericalGeography** – SphericalGeography 型は、地理座標 (測地座標、緯度/経度、または経度/緯度とも呼ばれる) で表される空間機能のネイティブサポートを提供します。地理座標は、角度単位 (度) で表される球面座標です。
`to_spherical_geography` 関数は、次の例のように、地理 (平面) 座標から地理 (球面) 座標を返します。
```
SELECT to_spherical_geography(ST_GeometryFromText(
'LINESTRING (-40.2 28.9, -40.2 31.9, -37.2 31.9)'));
```
## 重要な変更
以前のエンジンバージョンから Athena エンジンバージョン 3 に移行すると、特定の変更がテーブルスキーマ、構文、またはデータ型の使用に影響を及ぼす可能性があります。このセクションでは、関連するエラーメッセージを一覧表示し、推奨される回避策を示します。
### クエリ構文の変更
#### IGNORE NULLS は value 以外のウィンドウ関数では使用できません
**エラーメッセージ**: [`bool_or` 関数の null treatment 句を指定できません。]
**原因**: `IGNORE NULLS` は、[value 関数](https://trino.io/docs/current/functions/window.html#value-functions)の `first_value`、`last_value`、`nth_value`、`lead`、および `lag` でのみ使用できるようになりました。この変更は ANSI SQL 仕様に準拠するために行われました。
**推奨される解決策**: クエリ文字列で、value 以外のウィンドウ関数から `IGNORE NULLS` を削除します。
#### CONCAT 関数には 2 つ以上の引数が必要です
**エラーメッセージ**:「INVALID\$1FUNCTION\$1ARGUMENT: There must be two or more concatenation arguments」(INVALID\$1FUNCTION\$1ARGUMENT: 2 つ以上の連結引数が必要です)
**原因**: 以前は、`CONCAT` 文字列関数は 1 つの引数を受け入れていました。Athena エンジンバージョン 3 では、`CONCAT` 関数には最低 2 つの引数が必要です。
**推奨される解決策**: `CONCAT(str)` の出現箇所を `CONCAT(str, '')` に変更してください。
Athena エンジンバージョン 3 では、関数に含められる引数は最大 127 個です。詳細については、「[関数呼び出しの引数が多すぎます](troubleshooting-athena.md#troubleshooting-athena-too-many-arguments)」を参照してください。
#### prox\$1percentile 関数は異なる結果を返します。
Athena エンジンバージョン 3 では、`approx_percentile` 関数が以前のエンジンバージョンとは異なる結果を返します。
**エラーメッセージ**: なし
**原因**: この `approx_percentile` 関数はバージョンが変更される可能性があります。
**重要**
`approx_percentile` 関数の出力は近似値であり、その近似値はバージョンごとに変更される可能性があるため、重要なアプリケーションでは `approx_percentile` 関数に依存しないでください。
**推奨される解決策**: `approx_percentile` の以前のエンジンバージョンの動作に近づけるには、Athena エンジンバージョン 3 の別の関数セットを使用できます。例えば、以前のエンジンバージョンでは次のクエリがあるとします。
```
SELECT approx_percentile(somecol, 2E-1)
```
Athena エンジンバージョン 3 の出力に近似させるには、次の例のように `qdigest_agg` 関数と `value_at_quantile` 関数を試すことができます。ただし、この回避策を使用しても、同じ動作が保証されるわけではないことに注意してください。
```
SELECT value_at_quantile(qdigest_agg(somecol, 1), 2E-1)
```
#### 地理空間関数では、varbinary 入力がサポートされていません
**エラーメッセージ**:「FUNCTION\$1NOT\$1FOUND for st\$1XXX」(st\$1XXX に対応する関数が見つかりませんでした)
**原因**: 一部の地理空間関数では、従来の `VARBINARY` 入力の型やテキスト関連の関数シグネチャがサポートされなくなりました。
**推奨される解決策**: 地理空間関数を使用して、入力の型をサポートされているタイプに変換してください。サポートされている入力の型は、エラーメッセージに示されています。
#### GROUP BY 句では、ネストされた列は二重引用符で囲む必要があります
**エラーメッセージ**: ["*column\$1name*"。"*nested\$1column*" は集計式であるか GROUP BY 句に表示される必要があります]
**原因**: Athena エンジンバージョン 3 では、`GROUP BY` 句内のネストされた列名を二重引用符で囲む必要があります。例えば、次のクエリでは、`GROUP BY` 句で `user.name` が二重引用符で囲まれていないためエラーが発生します。
```
SELECT "user"."name" FROM dataset
GROUP BY user.name
```
**推奨される解決策**: 次の例のように、`GROUP BY` 句内のネストされた列名を二重引用符で囲みます。
```
SELECT "user"."name" FROM dataset
GROUP BY "user"."name"
```
#### Iceberg テーブルで OPTIMIZE を使用すると予期しない FilterNode エラーが発生する
**エラーメッセージ**:「Unexpected FilterNode found in plan; probably connector was not able to handle provided WHERE expression」
**原因**: Iceberg テーブルで実行された `OPTIMIZE` ステートメントで、フィルター式に非パーティション列を含む `WHERE` 句が使用されていました。
**推奨される解決策**: `OPTIMIZE` ステートメントは、パーティションによるフィルタリングのみをサポートします。パーティションテーブルで `OPTIMIZE` を実行する場合、`WHERE` 句にはパーティション列のみを含めてください。非パーティションテーブルで `OPTIMIZE` を実行する場合は、`WHERE` 句を指定しないでください。
#### Log() 関数の引数の順序
Athena エンジンバージョン 3 では、SQL 標準に従って `log()` 関数の引数の順序が `log(base, value)` に変更されました。
#### Minute() 関数では、間隔値 year to month がサポートされていません
**エラーメッセージ**:「Unexpected parameters (interval year to month) for function minute.」(関数 minute の予期しないパラメータ (間隔値 year to month)) 期待パラメータ: minute(timestamp with time zone)、minute(time with time zone)、minute(timestamp)、minute(time)、minute(interval day to second)。
**原因**: Athena エンジンバージョン 3 では、ANSI SQL 仕様に従って `EXTRACT` の型チェックがより正確に行われました。
**推奨される解決策**: クエリを更新して、型が推奨された関数シグネチャと一致することを確認してください。
#### ORDER BY 式は SELECT リストに表示する必要があります。
**エラーメッセージ**:「For SELECT DISTINCT, ORDER BY expressions must appear in SELECT list」(SELECT DISTINCT、ORDER BY 式は SELECT リストに表示する必要があります)
**原因**: `SELECT` 句に不適切なテーブルエイリアスが使われています。
**推奨される解決策**: `ORDER BY` 式のすべての列に `SELECT DISTINCT` 句の適切なリファレンスが含まれていることを再確認してください。
#### サブクエリから返された複数の列を比較するとクエリが失敗する
**エラーメッセージの例**: [サブクエリの値式と結果は次と同じタイプであることが必要です: row(varchar, varchar) と row(row(varchar, varchar))]
**原因**: Athena エンジンバージョン 3 における構文の更新により、クエリがサブクエリから返された複数の値を比較しようとした際にサブクエリ `SELECT` のステートメントが列のリストを括弧で囲んでいる場合に、このエラーが発生します。次の例をご覧ください。
```
SELECT *
FROM table1
WHERE (t1_col1, t1_col2)
IN (SELECT (t2_col1, t2_col2) FROM table2)
```
**解決策**: Athena エンジンバージョン 3 では、次の更新されたクエリ例のように、サブクエリ `SELECT` のステートメントにある列リストの周りの括弧を削除します。
```
SELECT *
FROM table1
WHERE (t1_col1, t1_col2)
IN (SELECT t2_col1, t2_col2 FROM table2)
```
#### SKIP は、DML クエリの予約語です。
この単語 `SKIP` は、`SELECT` のような DML クエリの予約語になりました。DML クエリの識別子として `SKIP` を使用するには、二重引用符で囲みます。
Athena の予約語の詳細については、「[クエリで予約キーワードをエスケープする](reserved-words.md)」を参照してください。
#### SYSTEM\$1TIME および SYSTEM\$1VERSION 句は、タイムトラベルのために非推奨となりました。
**エラーメッセージ**:「mismatched input 'SYSTEM\$1TIME'.」(入力 'SYSTEM\$1TIME' が一致しません) 「Expecting: 'TIMESTAMP', 'VERSION'」(期待値: 'TIMESTAMP'、'VERSION')
**原因**: 以前のエンジンバージョンでは、Iceberg テーブルがタイムスタンプとバージョンのタイムトラベルに `FOR SYSTEM_TIME AS OF` および `FOR SYSTEM_VERSION AS OF` 句を使用していました。Athena エンジンバージョン 3 では、`FOR TIMESTAMP AS OF` および `FOR VERSION AS OF` 句が使用されています。
**推奨される解決策**: 次の例のように、タイムトラベルオペレーションに `TIMESTAMP AS OF` および `VERSION AS OF` 句を使用するように SQL クエリを更新してください。
タイムスタンプによるタイムトラベル:
```
SELECT * FROM TABLE FOR TIMESTAMP AS OF (current_timestamp - interval '1' day)
```
バージョンによるタイムトラベル:
```
SELECT * FROM TABLE FOR VERSION AS OF 949530903748831860
```
#### 配列コンストラクターの引数が多すぎる
**エラーメッセージ**: TOO\$1MANY\$1ARGUMENTS: 配列コンストラクターの引数が多すぎます。
**原因**: 配列コンストラクターの最大要素数が 254 に設定されています。
**推奨される解決策**: 次の例のように、要素をそれぞれ 254 以下の要素を持つ複数の配列に分割し、`CONCAT` 関数を使用して配列を連結してください。
```
CONCAT(
ARRAY[x1,x2,x3...x254],
ARRAY[y1,y2,y3...y254],
...
)
```
#### 長さがゼロの区切り記号付き識別子は使用できません
**エラーメッセージ**:「Zero-length delimited identifier not allowed.」(長さがゼロの区切り記号付き識別子は使用できません)
**原因**: クエリが列のエイリアスとして空の文字列を使用しました。
**推奨される解決策**: クエリを更新して、列に空でないエイリアスを使用してください。
### データ処理の変更
#### バケット検証
**エラーメッセージ**: HIVE\$1INVALID\$1BUCKET\$1FILES: Hive テーブルが壊れています。
**原因**: テーブルが破損している可能性があります。バケット化されたテーブルについてのクエリの正確性を確保するために、Athena エンジンバージョン 3 ではバケット化されたテーブルに対する追加の検証が有効になっています。これにより、クエリの正確性を確保し、ランタイムにおける予期しないエラーを回避できます。
**推奨される解決策**: Athena エンジンバージョン 3 を使用してテーブルを再作成してください。
#### 構造体を JSON にキャストするとフィールド名が返されるようになりました
Athena エンジンバージョン 3 の `SELECT` クエリで `struct` を JSON にキャストすると、キャストによって値 (例: `null`) だけでなく、フィールド名と値 (例: `useragent":null`) の両方が返されるようになりました。
#### Iceberg テーブルの列レベルのセキュリティ強制の変更
**エラーメッセージ**:「Access Denied: Cannot select from columns」(アクセスが拒否されました: 列から選択できません)
**原因**: Iceberg テーブルは Athena の外部で作成され、0.13.0 より前のバージョンの [Apache Iceberg SDK](https://iceberg.apache.org/releases/) を使用しています。以前の SDK バージョンでは、AWS Glue に列が入力されないため、Lake Formation はアクセスが許可されている列を特定できませんでした。
**推奨される解決策**: Athena [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) ステートメントを使用して更新を実行するか、最新の Iceberg SDK を使用してテーブルを修正し、AWS Glue の列情報を更新してください。
#### データ型 List の Nulls が UDF に反映されるようになりました
**エラーメッセージ**:「Null Pointer Exception」(Null ポインタ例外)
**原因**: UDF コネクタを使用しており、ユーザー定義の Lambda 関数を実装している場合に、この問題が発生する可能性があります。
以前のエンジンバージョンでは、ユーザー定義の関数に渡されたデータ型 List の nulls が除外されました。Athena エンジンバージョン 3 では、nulls が保持されて UDF に渡されるようになりました。これにより、UDF がチェックすることなく null 要素を逆参照しようとすると、null ポインタ例外が発生する可能性があります。
たとえば、DynamoDB などの元のデータソースにデータ `[null, 1, null, 2, 3, 4]` がある場合、次のデータがユーザー定義の Lambda 関数に渡されます。
**Athena エンジンバージョン 3**: `[null, 1, null, 2, 3, 4]`
**推奨される解決策**: ユーザー定義の Lambda 関数がデータ型 list の null 要素を処理するようにしてください。
#### 文字配列の部分文字列に埋め込みスペースが含まれなくなりました
**エラーメッセージ**: エラーはスローされませんでしたが、返された文字列には埋め込みスペースが含まれていません。たとえば、`substr(char[20],1,100)` は 100 文字ではなく 20 文字の長さの文字列を返すようになりました。
**推奨される解決策**: アクションは不要です。
#### サポートされていない列型 decimal の強制
**エラーメッセージ**: HIVE\$1CURSOR\$1ERROR: Parquet ファイル: s3://amzn-s3-demo-bucket/*path*/*file\$1name*.parquet の読み取りに失敗、または Parquet 列 ([*column\$1name*]) でサポートされていない列タイプ (varchar) です
**原因**: Athena エンジンバージョン 2 は、`varchar` から 10 進数へのデータ型の強制変換を試みた際に、時々成功しました (しかし、頻繁に失敗しました)。Athena エンジンバージョン 3 は、値の読み取りを試みる前に型に互換性があるかどうかをチェックする型検証機能を備えているため、このような強制変換の試みは常に失敗するようになりました。
**推奨される解決策**: Athena エンジンバージョン 3 で、Parquet ファイル内の 10 進数列について `varchar` ではなく数値データ型を使用するように AWS Glue のスキーマを変更してください。データを再クロールして新しい列のデータ型が 10 進数型であることを確認するか、Athena でテーブルを手動で再作成し、構文 `decimal(precision, scale)` を使用して列のデータ型として [decimal](data-types.md#data-types-decimal) を指定します。
#### 浮動小数点数または倍精度浮動小数点数の NaN 値を bigint にキャストできなくなりました
**エラーメッセージ**:INVALID\$1CAST\$1ARGUMENT: Cannot cast real/double NaN to bigint
**原因**: Athena エンジンバージョン 3 では、`bigint` として `NaN` を 0 にキャストできなくなりました。
**推奨される解決策**: `bigint` にキャストする場合は、`NaN` の値が `float` 列または `double` 列に存在しないことを確認してください。
#### uuid() 関数の戻り型に関する変更
次の問題は、テーブルとビューの両方に影響します。
**エラーメッセージ**:[サポート対象外の Hive タイプ: uuid]
**原因**: 以前のエンジンバージョンでは、`uuid()` 関数は文字列を返しましたが、Athena エンジンバージョン 3 では UUID (タイプ 4) をランダムに生成した疑似文字列を返します。Athena では UUID 列のデータ型はサポートされていないため、Athena エンジンバージョン 3 では `uuid()` 関数を CTAS クエリで直接使用して UUID 列を生成することはできなくなりました。
例えば、次の `CREATE TABLE` ステートメントは以前のエンジンバージョンでは正常に完了しますが、Athena エンジンバージョン 3 では [NOT\$1SUPPORTED: サポート対象外の Hive タイプ: uuid] が返されます。
```
CREATE TABLE uuid_table AS
SELECT uuid() AS myuuid
```
例えば、次の `CREATE VIEW` ステートメントは Athena エンジンバージョン 2 では正常に完了しましたが、Athena エンジンバージョン 3 では [myuuid 列に無効な列タイプ: サポート対象外の Hive タイプ: uuid] が返されます。
```
CREATE VIEW uuid_view AS
SELECT uuid() AS myuuid
```
以前のエンジンバージョンで作成されたビューを Athena エンジンバージョン 3 でクエリすると、次のようなエラーが発生します。
[VIEW\$1IS\$1STALE: 1:15 行目:ビュー 「awsdatacatalog.mydatabase.uuid\$1view」が古くなっているか無効な状態です: クエリビューから位置 0 に射影された uuid 型の列 [muuid] を、ビュー定義に保存されている varcharar 型の列 [muuid] に強制変換できません]
**推奨される解決方法**: テーブルまたはビューを作成するときには、次の例のように、`cast()` 関数を使用して `uuid()` の出力を`varchar` に変換します。
```
CREATE TABLE uuid_table AS
SELECT CAST(uuid() AS VARCHAR) AS myuuid
```
```
CREATE VIEW uuid_view AS
SELECT CAST(uuid() AS VARCHAR) AS myuuid
```
#### CHAR と VARCHAR の強制に関する問題
Athena エンジンバージョン 3 の `varchar` および `char` で強制上の問題が発生した場合は、このセクションにある回避策を使用してください。これらの回避策を使用できない場合は、「サポート」にお問い合わせください。
##### CHAR 入力と VARCHAR 入力の混在による CONCAT 関数の失敗
**問題**: 次のクエリは Athena エンジンバージョン 2 では成功します。
```
SELECT concat(CAST('abc' AS VARCHAR(20)), '12', CAST('a' AS CHAR(1)))
```
しかしながら、Athena エンジンバージョン 3 では、同じクエリが次のように失敗します。
**エラーメッセージ**: FUNCTION\$1NOT\$1FOUND: 1:8 行目:concat 関数に予期しないパラメータ (varchar (20)、varchar (2)、char (1))。期待値: concat(char(x), char(y))、concat(array(E), E) E、concat(E, array(E)) E、concat(array(E)) E、concat(varchar)、concat(varbinary)
**推奨される解決方法**: `concat` 関数を使用するときは、`char` または `varchar` にキャストし、両方を混合しないでください。
##### CHAR 入力と VARCHAR 入力による SQL \$1\$1 連結の失敗
Athena エンジンバージョン 3 では、二重の縦線 `||` 連結演算子では、入力が `varchar` である必要があります。入力に、`varchar` と `char` タイプを組み合わせて使用することはできません。
**エラーメッセージ**: [TYPE\$1NOT\$1FOUND: 1:26 行目:不明なタイプ:char (65537) ]
**原因**: `||` を使用して `char` と `varchar` を連結するクエリで、次の例のようなエラーが発生する可能性があります。
```
SELECT CAST('a' AS CHAR) || CAST('b' AS VARCHAR)
```
**推奨される解決方法**: 次の例のようにして `varchar` と `varchar` を連結します。
```
SELECT CAST('a' AS VARCHAR) || CAST('b' AS VARCHAR)
```
##### CHAR および VARCHAR UNION クエリの失敗
**エラーメッセージ**: NOT\$1SUPPORTED: サポート対象外の Hive の型: char(65536)。サポートされている CHAR タイプ: CHAR (<= 255)
**原因**: 次の例のように、クエリが `char` と `varchar` を組み合わせようとしています。
```
CREATE TABLE t1 (c1) AS SELECT CAST('a' as CHAR) as c1 UNION ALL SELECT CAST('b' AS VARCHAR) AS c1
```
**推奨される解決方法**: このクエリ例では、`'a'` を `char` ではなく `varchar` にキャストします。
##### CHAR または VARCHAR の強制による不要な空白スペース
Athena エンジンバージョン 3 では、配列または単一の列の構成で `char(X)` と `varchar` のデータが単一の型に強制的に変換される場合、ターゲットの型は `char(65535)` になり各フィールドの末尾には不要なスペースが多く含まれます。
**原因**: Athena エンジンバージョン 3 では、強制的に `varchar` と `char(X)` を `char(65535)` に変換し、その後データの右にスペースを埋め込みます。
**推奨される解決策**: 明示的に各フィールドを `varchar` にキャストします。
### タイムスタンプの変更
#### Date タイムスタンプのオーバーフローでエラーがスローされます
**エラーメッセージ**:「Millis overflow: XXX」(Millis オーバーフロー: XXX)
**原因**: 以前のエンジンバージョンでは ISO 8601 の日付のオーバーフローがチェックされなかったため、一部の日付では負のタイムスタンプが生成されました。Athena エンジンバージョン 3 では、このオーバーフローがチェックされ、例外がスローされます。
**推奨される解決策**: タイムスタンプが範囲内にあることを確認してください。
#### TIME では政治タイムゾーンはサポートされていません
**エラーメッセージ**:「INVALID LITERAL」(リテラルが無効です)
**原因**: `SELECT TIME '13:21:32.424 America/Los_Angeles'` などのクエリ。
**推奨される解決策**: `TIME` を含む政治タイムゾーンの使用を避けてください。
#### Timestamp 列の精度の不一致により、シリアル化エラーが発生します
**エラーメッセージ**:「SERIALIZATION\$1ERROR: Could not serialize column '*COLUMNZ*' of type 'timestamp(3)' at position *X*:*Y*」(型 'timestamp(3)' の列 'COLUMNZ' を位置 X:Y でシリアル化できませんでした)
*COLUMNZ* は、問題の原因となる列の出力名です。*X*:*Y* という数字は、出力内の列の位置を示します。
**原因**: Athena エンジンバージョン 3 では、データ内のタイムスタンプの精度が、テーブル仕様の列のデータ型に指定されている精度と同じかどうかがチェックされます。現在、この精度は常に 3 です。データの精度が 3 より大きい場合、クエリは失敗し、記載されているエラーが表示されます。
**推奨される解決策**: データをチェックして、タイムスタンプの精度がミリ秒であることを確認してください。
#### Iceberg テーブルの UNLOAD クエリと CTAS クエリにあるタイムスタンプの精度が正しくない
**エラーメッセージ**: [timestamp(6) のタイムスタンプの精度が正しくありません。設定されている精度はミリ秒単位です]
**原因**: Athena エンジンバージョン 3 では、データ内のタイムスタンプの精度が、テーブル仕様の列のデータ型に指定されている精度と同じかどうかがチェックされます。現在、この精度は常に 3 です。データの精度がこれより大きい場合 (たとえば、ミリ秒ではなくマイクロ秒)、記載されているエラーが表示されてクエリが失敗する可能性があります。
**解決策**: この問題を回避するには、次の Iceberg テーブルを作成する CTAS の例のように、まずタイムスタンプの精度を 6 に `CAST` (キャスト) します。Iceberg で Timestamp precision (3) がサポートされていないというエラーを回避するために、精度を 3 ではなく 6 に指定する必要があることに注意してください。
```
CREATE TABLE my_iceberg_ctas
WITH (table_type = 'ICEBERG', location = 's3://amzn-s3-demo-bucket/table_ctas/',
format = 'PARQUET')
AS SELECT id, CAST(dt AS timestamp(6)) AS "dt"
FROM my_iceberg
```
次に、Athena はタイムスタンプ 6 をサポートしていないので、その値を (例えば、ビュー内の) タイムスタンプに再度キャストします。次の例では、`my_iceberg_ctas` テーブルからビューを作成します。
```
CREATE OR REPLACE VIEW my_iceberg_ctas_view AS
SELECT cast(dt AS timestamp) AS dt
FROM my_iceberg_ctas
```
#### ORC ファイルで Long 型をタイムスタンプとして読み込む、または書き込むと誤った形式の ORC ファイルとしてエラーが発生するようになりました
**エラーメッセージ**:「Error opening Hive split 'FILE (SPLIT POSITION)' Malformed ORC file.」(Hive 分割 'FILE (SPLIT POSITION)' を開く際のエラー。不正な ORC ファイル) Cannot read SQL type timestamp from ORC stream .long\$1type of type LONG (Hive で分割された「FILE (SPLIT POSITION)」を開くときにエラーが発生しました。誤った形式の ORC ファイルです。LONG 型の ORC ストリーム .long\$1type から SQL 型のタイムスタンプを読み込むことができません)」
**原因**: Athena エンジンバージョン 3 では、データ型が `Long` から `Timestamp` または `Timestamp` から `Long` への暗黙的な強制を拒否するようになりました。以前は、`Long` 値はあたかもエポックミリ秒であるかのように、暗黙的にタイムスタンプに変換されていました。
**推奨される解決策**: `from_unixtime` 関数を使用して列を明示的にキャストするか、`from_unixtime` 関数を使用して将来のクエリで追加の列を作成してください。
#### 時刻と間隔値 year to month はサポートされていません
**エラーメッセージ**:「TYPE MISMATCH」(型の不一致)
**原因**: Athena エンジンバージョン 3 では、時刻と間隔値 year to month がサポートされていません (例: `SELECT TIME '01:00' + INTERVAL '3' MONTH`)。
#### int96 Parquet 形式のタイムスタンプのオーバーフロー
**エラーメッセージ**:「Invalid timeOfDayNanos」(timeOfDayNanos が無効です)
**原因**: `int96` Parquet 形式のタイムスタンプのオーバーフロー。
**推奨される解決策**: 問題のある特定のファイルを特定してください。次に、よく知られている最新の Parquet ライブラリを使用してデータファイルを再度生成するか、Athena CTAS を使用してください。問題が解決しない場合は、Athena サポートに連絡して、データファイルの生成方法をお知らせください。
#### 文字列からタイムスタンプにキャストする際に日付と時刻の値の間に必要なスペース
**エラーメッセージ**: [INVALID\$1CAST\$1ARGUMENT: 値はタイムスタンプにキャストできません。]
**原因**: Athena エンジンバージョン 3 では、`cast` (キャスト) する入力文字列にある日付と時刻の値の間の有効な区切り記号としてハイフンを使用できなくなりました。例えば、Athena エンジンバージョン 3 では次のクエリは機能しません。
```
SELECT CAST('2021-06-06-23:38:46' AS timestamp) AS this_time
```
**推奨される解決策**: Athena エンジンバージョン 3 では、次の例のように、日付と時刻の間にあるハイフンをスペースに置き換えます。
```
SELECT CAST('2021-06-06 23:38:46' AS timestamp) AS this_time
```
#### to\$1iso8601() タイムスタンプの戻り値に関する変更
**エラーメッセージ**: なし
**原因**: 以前のエンジンバージョンでは、`to_iso8601` 関数は、関数に渡された値にタイムゾーンが含まれていなくてもタイムゾーンを含むタイムスタンプを返します。Athena エンジンバージョン 3 では、`to_iso8601` 関数は、渡された引数にタイムゾーンが含まれている際にのみタイムゾーンを含むタイムスタンプを返します。
たとえば、次のクエリは現在の日付を `to_iso8601` 関数に 2 回渡します。1 回目はタイムゾーンを含むタイムスタンプとして、2 回目はタイムスタンプとして渡します。
```
SELECT TO_ISO8601(CAST(CURRENT_DATE AS TIMESTAMP WITH TIME ZONE)), TO_ISO8601(CAST(CURRENT_DATE AS TIMESTAMP))
```
次の出力は、Athena エンジンバージョン 3 におけるクエリの結果を示しています。
以前のエンジンバージョンでは:
****
| \$1 | \$1col0 | \$1col1 |
| --- | --- | --- |
| 1 | `2023-02-24T00:00:00.000Z ` | `2023-02-24T00:00:00.000Z` |
Athena エンジンバージョン 3:
****
| \$1 | \$1col0 | \$1col1 |
| --- | --- | --- |
| 1 | `2023-02-24T00:00:00.000Z` | `2023-02-24T00:00:00.000` |
**推奨される解決策**: 前述の動作を再現するには、次の例のように、タイムスタンプ値を `to_iso8601` に渡す前に `with_timezone` 関数に渡します:
```
SELECT to_iso8601(with_timezone(TIMESTAMP '2023-01-01 00:00:00.000', 'UTC'))
```
結果
****
| \$1 | \$1col0 |
| --- | --- |
| 1 | 2023-01-01T00:00:00.000Z |
#### at\$1timezone() の最初のパラメータに日付を指定する必要がある
**問題**: Athena エンジンバージョン 3 では、`at_timezone` 関数は `time_with_timezone` の値を最初のパラメータとして受け取れません。
**原因**: 日付情報がないと、渡された値が夏時間か標準時かを判断できません。たとえば、渡された値が太平洋夏時間 (PDT) か太平洋標準時 (PST) かを判断する方法がないため、`at_timezone('12:00:00 UTC', 'America/Los_Angeles')` はあいまいです。
## 制限事項
Athena エンジンバージョン 3 には次の制約事項があります。
+ **クエリパフォーマンス** – Athena エンジンバージョン 3 ではクエリの多くが高速に実行されますが、一部のクエリ計画は以前のエンジンバージョンとは異なる場合があります。その結果、一部のクエリではレイテンシーやコストが異なる場合があります。
+ **Trino および Presto コネクタ** – [Trino](https://trino.io/docs/current/connector.html) コネクタも [Presto](https://prestodb.io/docs/current/connector.html) コネクタもサポートされていません。データソースの接続には Amazon Athena のフェデレーティッドクエリを使用します。詳細については、「[Amazon Athena フェデレーティッドクエリを使用する](federated-queries.md)」を参照してください。
+ **フォールトトレラントの実行** – Trino [フォールトトレラントの実行](https://trino.io/docs/current/admin/fault-tolerant-execution.html) (Trino Tardigrade) はサポートされていません。
+ **関数パラメータの制限** — 関数は 127 個を超えるパラメータを取れません。詳細については、「[関数呼び出しの引数が多すぎます](troubleshooting-athena.md#troubleshooting-athena-too-many-arguments)」を参照してください。
リソース制限によるクエリの失敗が発生しないことを確実にするため、Athena エンジンバージョン 2 に以下の制限が導入されました。これらの制限は、ユーザー設定可能な制限ではありません。
+ **結果要素の数** – `min(col, n)`、`max(col, n)`、`min_by(col1, col2, n)`、および `max_by(col1, col2, n)` 関数では、結果要素 `n` の数が 10,000 以下に制限されます。
+ **GROUPING SETS** – グループ化セット内のスライスの最大数は 2,048 です。
+ **テキストファイルの最大行長** — テキストファイルのデフォルト最大行長は 200 MB です。
+ **シーケンス関数の最大結果サイズ** – シーケンス関数の最大結果サイズは 50,000 エントリです。例えば、`SELECT sequence(0,45000,1)` は成功しますが、`SELECT sequence(0,55000,1)` は「The result of the sequence function must not have more than 50000 entries」というエラーメッセージを伴って失敗します。この制限は、タイムスタンプを含むシーケンス関数のすべての入力タイプに適用されます。