Amazon S3 Tables の Iceberg テーブルに Amazon Athenaから更新クエリを試す!(今更だったらゴメンね)
クラウド事業本部コンサルティング部の石川です。本日は、Amazon S3 TablesのIcebergテーブルに対するAmazon Athenaからの更新クエリの実行可能性と、Amazon S3 TablesとIceberg Tables on Amazon S3のパフォーマンス比較について解説します。
Amazon Athenaから更新クエリを試す!って今更?
re:Invent2024で Amazon S3 Tablesが発表になった直後は、ワクワクして一番最初にAmazon Athenaで様々なクエリの実行を試していたはずでした。私の記憶が正しければ、Amazon S3 Tables の Iceberg テーブルに Amazon Athenaから更新クエリはエラーになっていたと思います。
ところが、亀田さんが、「Amazon S3 Tables のハンズオンを今度やるので簡単な手順をまとめた。...」というXの投稿の中で、insert into ...
をやっていてるのを目にしました。
「亀田さん、insert into できるわけがなっ、、、、、、で、き、る、や、ないかい!」
ということで、どこまでできるか試してみます。
まずはテーブルまで作成
私は、CloudShell上のAWS CLIを使って、Table bucket、Namespace、Tableを順に作成しました。
[cloudshell-user@ip-10-130-84-16 ~]$ aws s3tables create-table-bucket --name cm-sample --region us-east-1
{
"arn": "arn:aws:s3tables:us-east-1:123456789012:bucket/cm-sample"
}
[cloudshell-user@ip-10-130-84-16 ~]$ aws s3tables create-namespace --table-bucket-arn arn:aws:s3tables:us-east-1:123456789012:bucket/cm-sample --namespace cm_ssb
{
"tableBucketARN": "arn:aws:s3tables:us-east-1:123456789012:bucket/cm-sample",
"namespace": [
"cm_ssb"
]
}
aws s3tables delete-table --table-bucket-arn arn:aws:s3tables:us-east-1:123456789012:bucket/cm-sample --namespace cm_ssb --name lineorder
# s3tablescatalog/cm-sample
# cm_ssb
# lineorder_s3tables
# SELECT * FROM "s3tablescatalog/cm-sample"."cm_ssb"."lineorder_s3tables" limit 10;
[cloudshell-user@ip-10-130-84-16 ~]$ aws s3tables create-table --table-bucket-arn arn:aws:s3tables:us-east-1:123456789012:bucket/cm-sample --namespace cm_ssb --name lineorder_s3tables --format ICEBERG --metadata '{
> "iceberg": {
> "schema": {
> "fields": [
> {"name": "lo_orderkey", "type": "int", "required": true},
> {"name": "lo_linenumber", "type": "int", "required": true},
> {"name": "lo_custkey", "type": "int", "required": true},
> {"name": "lo_partkey", "type": "int", "required": true},
> {"name": "lo_suppkey", "type": "int", "required": true},
> {"name": "lo_orderdate", "type": "int", "required": true},
> {"name": "lo_orderpriority", "type": "string", "required": true},
> {"name": "lo_shippriority", "type": "string", "required": true},
> {"name": "lo_quantity", "type": "int", "required": true},
> {"name": "lo_extendedprice", "type": "int", "required": true},
> {"name": "lo_ordertotalprice", "type": "int", "required": true},
> {"name": "lo_discount", "type": "int", "required": true},
> {"name": "lo_revenue", "type": "int", "required": true},
> {"name": "lo_supplycost", "type": "int", "required": true},
> {"name": "lo_tax", "type": "int", "required": true},
> {"name": "lo_commitdate", "type": "int", "required": true},
> {"name": "lo_shipmode", "type": "string", "required": true}
> ]
> }
> }
> }'
{
"tableARN": "arn:aws:s3tables:us-east-1:123456789012:bucket/cm-sample/table/e80b8220-55ad-459a-9f5f-a61c3ad11e0b",
"versionToken": "b72c22cdffe346cd6c3d"
}
なお、テーブルの削除は、以下のとおりです。
[cloudshell-user@ip-10-130-84-16 ~]$ aws s3tables delete-table --table-bucket-arn arn:aws:s3tables:us-east-1:123456789012:bucket/cm-sample --namespace cm_ssb --name lineorder_s3tables
詳しくは、こちらのブログをご覧ください。
Amazon Athenaから更新クエリを試す!
テーブルの作成
Amazon S3 Tables の IcebergテーブルのLOCATION指定の構文の記載がありません。また、上記のAWS CLIで作成したテーブルから、Generate Table DDL
でDDLを取得できませんでした。DDLはサポートされていないようです。
テーブルの削除
上記のAWS CLIで作成したテーブルの削除を試みましたが、DDL queries are not supported for this catalog
というメッセージの通り、DDLはサポートされていないようです。
レコードの追加
レコードの追加は、成功しました。
レコードの削除
レコードの削除は、成功しました。
レコードの更新
レコードの更新は、成功しました。
テーブルのマージ
テーブルのマージは、成功しました。
DDLとDMLのサポート状況
DDLはサポートしていませんが、DMLに関してはほぼサポートしていると考えられます。
Amazon S3 Tables と Iceberg Tables on Amazon S3 のパフォーマンスの比較
過去に以下のようなブログを書きましたが、今回は読み書きともにAmazon Athenaによるクエリで計測しました。
今回も、データは以下のブログで紹介したssbサンプルデータのlineorder(約6億レコード)を用います。
あくまでも、AWSアナリティクス統合がプレビューの段階ですので計測値は参考値となります。
ロード時間の計測
事前に作成したssbサンプルデータのlineorder(約6億レコード)を用意しました。
最初は、INSERT INTOで10レコードのみロードします。Iceberg Tables on Amazon S3の方が速く終わりました。
Iceberg Tables on Amazon S3(10レコード)
ロード時間は、2.289秒でした。
Amazon S3 Tables (10レコード)
ロード時間は、16.214秒でした。
事前に作成したssbサンプルデータのlineorder(約6億レコード)を全てのレコードをINSERT INTOでロードします。ロード時間はほぼ同じでした。
Iceberg Tables on Amazon S3(約6億レコード)
ロード時間は、4分53秒でした。
Amazon S3 Tables (約6億レコード)
ロード時間は、4分50秒でした。
参照系クエリの実行
年度ごとに売上を集計するクエリです。スキャンするデータ量が少なかったため、Iceberg Tables on Amazon S3の方が速く終わりました。
Iceberg Tables on Amazon S3
クエリの実行時間は、4.321秒でした。
Amazon S3 Tables
クエリの実行時間は、12.899秒でした。
更新系クエリの実行
1995年より前の売上を0に更新するクエリを実行しました。更新対象は約半分程度でした。Iceberg Tables on Amazon S3の方が若干早い結果でした。
Iceberg Tables on Amazon S3
クエリの実行時間は、80.998秒でした。
Amazon S3 Tables
クエリの実行時間は、85.754秒でした。
パフォーマンス比較の結果
時間の長いワークロードでは大きな差がありませんが、ショートクエリではAmazon S3 Tablesに10秒程度のオーバーヘッドが見られました。
最後に
実験結果から、Amazon S3 TablesのIcebergテーブルでは、レコードの追加、削除、更新、およびテーブルのマージなどのDML操作が可能であることが確認されました。一方で、DDL操作はサポートされていないことも明らかになりました。
パフォーマンス比較では、大規模なデータセットを使用した場合、両者のロード時間にはほとんど差がないことが示されましたが、小規模なデータセットや短時間のクエリでは、Amazon S3 Tablesに若干のオーバーヘッドが見られました。今後のAmazon S3 Tablesの進化と、さらなる最適化に期待が高まります。