Athena エンジンバージョン 3

エンジンバージョン 3 では、Athena はオープンソースのソフトウェア管理に継続的な統合アプローチを導入しました。これにより、Trino および Presto プロジェクトでの同時実行性が向上するため、Athena エンジン内で統合およびチューニングされたコミュニティの改善にすばやくアクセスできるようになります。

Athena エンジンバージョン 3 のこのリリースでは、Athena エンジンバージョン 2 のすべての機能がサポートされています。このドキュメントでは、Athena エンジンバージョン 2 と Athena エンジンバージョン 3 の主な違いについて説明します。詳細については、AWS Big Data Blog の記事、「Upgrade to Athena engine version 3 to increase query performance and access more analytics features」を参照してください。

使用を開始する

はじめに、Athena エンジンバージョン 3 を使用する新しい Athena ワークグループを作成するか、バージョン 3 を使用するように既存のワークグループを設定するかを選択します。Athena のどのワークグループでも、クエリの送信を中断することなく、エンジンバージョン 2 からエンジンバージョン 3 にアップグレードできます。

詳細については、「Athena エンジンバージョンの変更」を参照してください。

改善点と新機能

記載されている機能や更新には、Athena 自体の改善点と、オープンソースの Trino から組み込まれた機能性の改善点が含まれています。SQL クエリの演算子および関数を網羅するリストについては、「Trino documentation」(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_sequence(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_number(number) – 単位記号を使用してフォーマットされた文字列を返します。

SELECT format_number(123456); -- '123K'

SELECT format_number(1000000); -- '1M'

日付および時刻関数

timezone_hour(timestamp) – タイムスタンプからオフセットされたタイムゾーンの時間を返します。

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

timezone_minute(timestamp) – タイムスタンプからオフセットされたタイムゾーンの分数を返します。

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

地理空間関数

to_encoded_polyline(Geometry) – ライン文字列またはマルチポイントをポリラインにエンコードします。

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

from_encoded_polyline(varchar) – ポリラインをライン文字列にデコードします。

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

to_geojson_geometry(SphericalGeography) – 指定された球面ジオグラフィを GeoJSON 形式で返します。

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

from_geojson_geometry(varchar) – 非ジオメトリのキー/値を取り除いて、GeoJSON 表現から球面ジオグラフィ型のオブジェクトを返します。Feature および FeatureCollection はサポートされていません。

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

geometry_nearest_points(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_set_digest(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_ws(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 でのパフォーマンスの向上には、次のものが含まれています。

信頼性の強化

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_RECOGNIZE – 次の例のように、行パターン照合のサポートが追加されました。

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 では、次のデータ形式とデータ型の機能が強化されています。

重要な変更

Athena エンジンバージョン 2 から Athena エンジンバージョン 3 に移行すると、特定の変更がテーブルスキーマ、構文、またはデータ型の使用に影響を及ぼす可能性があります。このセクションでは、関連するエラーメッセージを一覧表示し、推奨される回避策を示します。

クエリ構文の変更

IGNORE NULLS は value 以外のウィンドウ関数では使用できません

エラーメッセージ: [bool_or 関数の null treatment 句を指定できません。]

原因: IGNORE NULLS は、value 関数の first_value、last_value、nth_value、lead、および lag でのみ使用できるようになりました。この変更は ANSI SQL 仕様に準拠するために行われました。

推奨される解決策: クエリ文字列で、value 以外のウィンドウ関数から IGNORE NULLS を削除します。

CONCAT 関数には 2 つ以上の引数が必要です

エラーメッセージ:「INVALID_FUNCTION_ARGUMENT: There must be two or more concatenation arguments」(INVALID_FUNCTION_ARGUMENT: 2 つ以上の連結引数が必要です)

原因: 以前は、CONCAT 文字列関数は 1 つの引数を受け入れていました。Athena エンジンバージョン 3 では、CONCAT 関数には最低 2 つの引数が必要です。

推奨される解決策: CONCAT(str) の出現箇所を CONCAT(str, '') に変更してください。

Athena エンジンバージョン 3 では、関数に含められる引数は最大 127 個です。詳細については、「関数呼び出しの引数が多すぎます」を参照してください。

prox_percentile 関数は異なる結果を返します。

Athena エンジンバージョン 3 では、approx_percentile 関数が Athena エンジンバージョン 2 とは異なる結果を返します。

エラーメッセージ: なし

原因: この approx_percentile 関数はバージョンが変更される可能性があります。

推奨される解決策: approx_percentile の Athena エンジンバージョン 2 の動作に近づけるには、Athena エンジンバージョン 3 の別の関数セットを使用できます。例えば、Athena エンジンバージョン 2 では次のクエリがあるとします。

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_NOT_FOUND for st_XXX」(st_XXX に対応する関数が見つかりませんでした)

原因: 一部の地理空間関数では、従来の VARBINARY 入力の型やテキスト関連の関数シグネチャがサポートされなくなりました。

推奨される解決策: 地理空間関数を使用して、入力の型をサポートされているタイプに変換してください。サポートされている入力の型は、エラーメッセージに示されています。

GROUP BY 句では、ネストされた列は二重引用符で囲む必要があります

エラーメッセージ: ["column_name"。"nested_column" は集計式であるか 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 エンジンバージョン 2 では、log() 関数の引数の順序は log(value, base) でした。Athena エンジンバージョン 3 では、これは SQL 標準に準拠するように 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 の予約語の詳細については、「クエリで予約キーワードをエスケープする」を参照してください。

SYSTEM_TIME および SYSTEM_VERSION 句は、タイムトラベルのために非推奨となりました。

エラーメッセージ:「mismatched input 'SYSTEM_TIME'.」(入力 'SYSTEM_TIME' が一致しません) 「Expecting: 'TIMESTAMP', 'VERSION'」(期待値: 'TIMESTAMP'、'VERSION')

原因: Athena エンジンバージョン 2 では、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_MANY_ARGUMENTS: 配列コンストラクターの引数が多すぎます。

原因: 配列コンストラクターの最大要素数が 254 に設定されています。

推奨される解決策: 次の例のように、要素をそれぞれ 254 以下の要素を持つ複数の配列に分割し、CONCAT 関数を使用して配列を連結してください。

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

長さがゼロの区切り記号付き識別子は使用できません

エラーメッセージ:「Zero-length delimited identifier not allowed.」(長さがゼロの区切り記号付き識別子は使用できません)

原因: クエリが列のエイリアスとして空の文字列を使用しました。

推奨される解決策: クエリを更新して、列に空でないエイリアスを使用してください。

データ処理の変更

バケット検証

エラーメッセージ: HIVE_INVALID_BUCKET_FILES: 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 を使用しています。以前の SDK バージョンでは、AWS Glue に列が入力されないため、Lake Formation はアクセスが許可されている列を特定できませんでした。

推奨される解決策: Athena ALTER TABLE SET TBLPROPERTIES ステートメントを使用して更新を実行するか、最新の Iceberg SDK を使用してテーブルを修正し、AWS Glue の列情報を更新してください。

データ型 List の Nulls が UDF に反映されるようになりました

エラーメッセージ:「Null Pointer Exception」(Null ポインタ例外)

原因: UDF コネクタを使用しており、ユーザー定義の Lambda 関数を実装している場合に、この問題が発生する可能性があります。

Athena エンジンバージョン 2 では、ユーザー定義の関数に渡されたデータ型 List の nulls が除外されました。Athena エンジンバージョン 3 では、nulls が保持されて UDF に渡されるようになりました。これにより、UDF がチェックすることなく null 要素を逆参照しようとすると、null ポインタ例外が発生する可能性があります。

たとえば、DynamoDB などの元のデータソースにデータ [null, 1, null, 2, 3, 4] がある場合、次のデータがユーザー定義の Lambda 関数に渡されます。

Athena エンジンバージョン 2: [1,2,3,4]

Athena エンジンバージョン 3: [null, 1, null, 2, 3, 4]

推奨される解決策: ユーザー定義の Lambda 関数がデータ型 list の null 要素を処理するようにしてください。

文字配列の部分文字列に埋め込みスペースが含まれなくなりました

エラーメッセージ: エラーはスローされませんでしたが、返された文字列には埋め込みスペースが含まれていません。たとえば、substr(char[20],1,100) は 100 文字ではなく 20 文字の長さの文字列を返すようになりました。

推奨される解決策: アクションは不要です。

サポートされていない列型 decimal の強制

エラーメッセージ: HIVE_CURSOR_ERROR: Parquet ファイル: s3://amzn-s3-demo-bucket/path/file_name.parquet の読み取りに失敗、または Parquet 列 ([column_name]) でサポートされていない列タイプ (varchar) です

原因: Athena エンジンバージョン 2 は、varchar から 10 進数へのデータ型の強制変換を試みた際に、時々成功しました (しかし、頻繁に失敗しました)。Athena エンジンバージョン 3 は、値の読み取りを試みる前に型に互換性があるかどうかをチェックする型検証機能を備えているため、このような強制変換の試みは常に失敗するようになりました。

推奨される解決策: Athena エンジンバージョン 2 と Athena エンジンバージョン 3 の両方で、Parquet ファイル内の 10 進数列について varchar ではなく数値データ型を使用するように AWS Glue のスキーマを変更してください。データを再クロールして新しい列のデータ型が 10 進数型であることを確認するか、Athena でテーブルを手動で再作成し、構文 decimal(precision, scale) を使用して列のデータ型として decimal を指定します。

浮動小数点数または倍精度浮動小数点数の NaN 値を bigint にキャストできなくなりました

エラーメッセージ:INVALID_CAST_ARGUMENT: Cannot cast real/double NaN to bigint

原因: Athena エンジンバージョン 3 では、bigint として NaN を 0 にキャストできなくなりました。

推奨される解決策: bigint にキャストする場合は、NaN の値が float 列または double 列に存在しないことを確認してください。

uuid() 関数の戻り型に関する変更

次の問題は、テーブルとビューの両方に影響します。

エラーメッセージ:[サポート対象外の Hive タイプ: uuid]

原因: Athena エンジンバージョン 2 では uuid() 関数は文字列を返しましたが、Athena エンジンバージョン 3 では UUID (タイプ 4) をランダムに生成した疑似文字列を返します。Athena では UUID 列のデータ型はサポートされていないため、Athena エンジンバージョン 3 では uuid() 関数を CTAS クエリで直接使用して UUID 列を生成することはできなくなりました。

たとえば、次の CREATE TABLE ステートメントは Athena エンジンバージョン 2 では正常に完了しますが、Athena エンジンバージョン 3 では [NOT_SUPPORTED: サポート対象外の 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 エンジンバージョン 2 で作成されたビューを Athena エンジンバージョン 3 でクエリすると、次のようなエラーが発生します。

[VIEW_IS_STALE: 1:15 行目:ビュー 「awsdatacatalog.mydatabase.uuid_view」が古くなっているか無効な状態です: クエリビューから位置 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 で強制上の問題が発生した場合は、このセクションにある回避策を使用してください。これらの回避策を使用できない場合は、「AWS Support」にお問い合わせください。

CHAR 入力と VARCHAR 入力の混在による CONCAT 関数の失敗

問題: 次のクエリは Athena エンジンバージョン 2 では成功します。

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

しかしながら、Athena エンジンバージョン 3 では、同じクエリが次のように失敗します。

エラーメッセージ: FUNCTION_NOT_FOUND: 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 || 連結の失敗

Athena エンジンバージョン 3 では、二重の縦線 || 連結演算子では、入力が varchar である必要があります。入力に、varchar と char タイプを組み合わせて使用することはできません。

エラーメッセージ: [TYPE_NOT_FOUND: 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_SUPPORTED: サポート対象外の 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 にキャストします。

タイムスタンプの変更

タイムゾーン付きの Timestamp を varchar の動作変更にキャストしています

Athena エンジンバージョン 2 では、タイムゾーン付きの Timestamp を varchar にキャストすると、一部のタイムゾーンリテラルが変更されました (例: US/Eastern が America/New_York に変更)。この動作は、Athena エンジンバージョン 3 では発生しません。

Date タイムスタンプのオーバーフローでエラーがスローされます

エラーメッセージ:「Millis overflow: XXX」(Millis オーバーフロー: XXX)

原因: Athena エンジンバージョン 2 では ISO 8601 の日付のオーバーフローがチェックされなかったため、一部の日付では負のタイムスタンプが生成されました。Athena エンジンバージョン 3 では、このオーバーフローがチェックされ、例外がスローされます。

推奨される解決策: タイムスタンプが範囲内にあることを確認してください。

TIME では政治タイムゾーンはサポートされていません

エラーメッセージ:「INVALID LITERAL」(リテラルが無効です)

原因: SELECT TIME '13:21:32.424 America/Los_Angeles' などのクエリ。

推奨される解決策: TIME を含む政治タイムゾーンの使用を避けてください。

Timestamp 列の精度の不一致により、シリアル化エラーが発生します

エラーメッセージ:「SERIALIZATION_ERROR: 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_type of type LONG (Hive で分割された「FILE (SPLIT POSITION)」を開くときにエラーが発生しました。誤った形式の ORC ファイルです。LONG 型の ORC ストリーム .long_type から 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_CAST_ARGUMENT: 値はタイムスタンプにキャストできません。]

原因: Athena エンジンバージョン 3 では、cast (キャスト) する入力文字列にある日付と時刻の値の間の有効な区切り記号としてハイフンを使用できなくなりました。たとえば、次のクエリは Athena エンジンバージョン 2 では動作しますが、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_iso8601() タイムスタンプの戻り値に関する変更

エラーメッセージ: なし

原因: Athena エンジンバージョン 2 では、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 エンジンバージョン 2:

Athena エンジンバージョン 3:

推奨される解決策: 前述の動作を再現するには、次の例のように、タイムスタンプ値を to_iso8601 に渡す前に with_timezone 関数に渡します:

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

結果

at_timezone() の最初のパラメータに日付を指定する必要がある

問題: Athena エンジンバージョン 3 では、at_timezone 関数は time_with_timezone の値を最初のパラメータとして受け取れません。

原因: 日付情報がないと、渡された値が夏時間か標準時かを判断できません。たとえば、渡された値が太平洋夏時間 (PDT) か太平洋標準時 (PST) かを判断する方法がないため、at_timezone('12:00:00 UTC', 'America/Los_Angeles') はあいまいです。

制約事項

Athena エンジンバージョン 3 には次の制約事項があります。

リソース制限によるクエリの失敗が発生しないことを確実にするため、Athena エンジンバージョン 2 に以下の制限が導入されました。これらの制限は、ユーザー設定可能な制限ではありません。