こんにちは、開発グループの寺田です。
本記事では、Amazon Athenaを使用して、INSERT・DELETE・UPDATE・MERGEクエリを実行し、S3 Tablesのデータ変更を検証します。
INSERT INTO
Athena IcebergのINSERT INTOは、Icebergテーブルに複数件のデータ登録が可能で、 スキャンしたデータ量に応じて課金されます。
INSERT INTO [db_name.]table_name [(col1, col2, …)] query
それではレコードを数件登録します。
クエリが成功したので、SELECTを実行してデータが登録されたか確認します。
S3 Tablesのテーブルバケットでは内部のデータ構造を直接確認できないため、
汎用バケットを使用したセルフマネージドのIceberg テーブルで検証します。
同様のテーブルを作成し、INSERT INTOクエリを実行します。
汎用バケットを確認すると、以下のフォルダが作成されていました。
- data : Parquet ファイルが格納
- metadata : Jsonファイルが格納
今回のテーブルはパーティションを設定せずに作成しました。
その結果、4レコードが1つのParquetファイルに格納され、
メタデータがJsonファイルに格納されていました。
Parquetファイル
Jsonファイル（一部抜粋）
DELETE
Athena IcebergのDELETEを実行すると、位置削除ファイルが作成され、データは直接書き換えられません。 この仕組みは「読み込み時マージ削除」と呼ばれ、コピーオンライト削除よりも効率的です。
AthenaはIcebergのデータを読み込む際に データファイルと削除ファイルをマージして最新のビューを生成します。
不要な位置削除ファイルを削除するには、REWRITE DATA圧縮アクションを実行します。
※DELETEの実行には、スキャンしたデータ量に応じた課金が発生します。
DELETE FROM [db_name.]table_name [WHERE predicate]
先ほど登録したレコードから1レコード削除します。
クエリが成功したので、SELECTを実行してデータが削除されたか確認します。
セルフマネージドのIcebergテーブルで内部を確認します。
登録時のParquet内のデータは直接削除されず、以下のParquetファイルとmetadataファイルが追加されていました。
Parquetファイル（INSERT INTO 実行時に作成）
Parquetファイル（DELETE 実行時に作成）
Jsonファイル（一部抜粋）
UPDATE
Athena IcebergのUPDATEを実行すると、位置削除ファイルと更新後のデータを同じトランザクション内のデータとして書き込みます。
実質的にINSERT INTOとDELETEを組み合わせた処理となり、スキャンしたデータ量に応じて課金されます。
UPDATE [db_name.]table_name SET xx=yy[,...] [WHERE predicate]
先ほど登録したレコードから1レコード更新します。
クエリが成功したので、SELECTを実行してデータが更新されたか確認します。
セルフマネージドのIcebergテーブルで内部を見てみると、登録時のParquet内のデータに変更はなく、
INSERT INTOとDELETEを組み合わせた処理が行われていることを確認できました。
Parquetファイル
Jsonファイル（一部抜粋）
MERGE INTO
Athena IcebergのMERGE INTOを実行すると、条件付きでレコードの更新・削除・挿入を 1 つのステートメントで実行できます。
MERGE INTO target_table [ [ AS ] target_alias ] USING { source_table | query } [ [ AS ] source_alias ] ON search_condition when_clause [...]
MERGE INTOを使用することでUPSERTが可能です。
まとめ
Iceberg テーブルのデータ更新について、INSERT・DELETE・UPDATE・MERGE の動作を検証しました！
実際に検証を進める中で、REWRITE DATA 圧縮アクションの仕組み や S3 Tablesでメタデータを確認する方法の有無が気になりました。
今後、これらのポイントについてさらに調査し、掘り下げていきたいと思います。
