背景・目的
こちらの記事にて、AthenaがACIDトランザクションを一般提供したとのことで気になったので調べてみました。（以前は、Previewでした。）
サマリ
- AthenaでACIDを実現するために、Apache Icebergを利用している。
- タイムトラベル機能により、以前の状態を確認できる。
- INSERT、UPDATE、DELETEが利用できることで、GlueなどのETLをつかって洗い替えの仕組みを用意しなくて済むのはありがたい。
- 以下については、今後確認したい。
- 気のせいか、SELECTや更新系のクエリが若干遅い気がする。性能を計測する。
- REWRITE DATA Compaction Action圧縮が確認できなかったため、あらためて仕様を確認する。
概要
Athena ACIDトランザクションとは？
- 複数同時ユーザからの更新（挿入、更新、削除、タイムトラベル操作（後述））に対して、行レベルの変更を行えるようです。
- Apache Icebergテーブル形式を利用して、S3用に最適化され、他のAWSサービス（EMR、Spark）、ApacheFlinkなどのIcebergテーブル形式をサポートしているエンジン間でアトミック操作を保証するようです。
- Athenaコンソール、API操作、ODBC/JDBCドライバーを介して利用可能です。
- Lake FormationのGoverned Tablesを使用した方式でも実現可能らしい。
Apache Icebergとは？
-
巨大な分析データセット用のオープンテーブル形式です。
-
SQLテーブルと同様に機能する形式を使用して、以下のコンピューティングエンジンにテーブルを追加するようです。
- Spark
- Trino
- PrestDB
- Flink
- Hive
-
結果整合性のあるクラウドオブジェクトストアの正確性の問題を解決するために設計されたとのこと。
-
単一のテーブルに数十PBのデータを含めることができる。
-
リストや名前の変更を回避することで、あらゆるクラウドストアと連携し、HDFSでのNN（NameNode）の混雑を軽減します。
-
データファイルは、テーブルメタデータを使用して、パーティションおよび列レベルの統計で整理されます。
Icebergを使用したAthena ACIDトランザクション
- 2022/4/6現在、以下の考慮事項と制限があります。
- Glueカタログに対して作成されたicebergテーブルのみサポート
- テーブルロックはGlueのみサポート。（Athenaではできない。）
- Parquetファイルのみサポート
- Iceberg v2テーブルのみサポート（v1はサポートされていない）
- タイムゾーンの指定がない日時型について、デフォルトUTCが使用される。
- タイムスタンプの精度については、ミリ秒まで（Iceberg自体は、マイクロ秒までサポートされている）
- Lake Formationとの統合はサポートされていない
- 以下のAthenaの操作は、Icebergテーブルではサポートされていない。
- CREATE TABLE AS
- ALTER TABLE SET LOCATION
- CREATE VIEW
- SHOW CREATE VIEW
- DROP VIEW
- DESCRIBE VIEW
実践
こちらに基づいて、試してみます。
Creating Iceberg Tables
S3バケットの作成
- 事前にIcebergで参照するバケットとフォルダ(iceberg)を用意します。
スキーマの作成
1.データベースを作成します。
- 事前に、「iceberg_db」という名前でデータベースを作成します。
create database iceberg_db;
2.テーブルを作成します。
CREATE TABLE iceberg_table (
id int,
data string,
category string)
PARTITIONED BY (category, bucket(16,id))
LOCATION 's3://{バケット名}/iceberg'
TBLPROPERTIES (
'table_type'='ICEBERG',
'format'='parquet',
'write_target_data_file_size_bytes'='536870912',
'optimize_rewrite_delete_file_threshold'='10'
)
- PARTITIONED BYに指定しているbucket(16,id)は、ハッシュ値（idを16で割った余り）で分割します。
- optimize_rewrite_delete_file_thresholdは、データファイルに関連付けられている削除ファイルの数が、閾値より少ない場合に、データファイルは書き換えられないらしい。（最適化が目的。）
- 自分の理解が足りてない無いかもだが、消したつもりがファイルは削除されていないような、バグの温床にならないのか？？
- write_target_data_file_size_bytesは、Athenaによって生成されたファイルのターゲットサイズのバイト単位で指定します。
- 1ファイルあたりのサイズ？
3.作成したテーブルをdescで確認します。
desc iceberg_table
===
# Table schema:
# col_name data_type comment
id int
data string
category string
# Partition spec:
# field_name field_transform column_name
category identity category
id_bucket bucket[16] id
データ操作(1)
INSERT
1.以下のSQLを実行します。
INSERT INTO iceberg_table(id,data,category) VALUES (1,'a','c1')
2.SELECTを実行します。
select * from iceberg_table;
===
# id data category
1 1 a c1
3.S3を確認します。
$ aws s3 ls {バケット名}/iceberg/ --recursive
2022-04-06 18:33:58 0 iceberg/
2022-04-06 18:50:37 388 iceberg/data/112fc32a//iceberg/category=c1/id_bucket=4/XXXXXXXXXXXXXXXXXX.gz.parquet
2022-04-06 18:50:16 1525 iceberg/metadata/00000-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.metadata.json
2022-04-06 18:50:38 2442 iceberg/metadata/00001-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.metadata.json
2022-04-06 18:50:38 7019 iceberg/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.avro
2022-04-06 18:50:38 4262 iceberg/metadata/snap-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.avro
$
- dataフォルダには、parquetファイルができている。
- metadataフォルダには、metadataファイルが2つ、avroファイルが2つ（うち、1つがsnapショット？）
4.metaデータを確認してみる。（1つ目）
$ aws s3 cp s3://{バケット名}/iceberg/metadata/00000-d83f57b4-62e2-4810-8a26-be8540c09b5e.metadata.json -
{
"format-version" : 2,
"table-uuid" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"location" : "s3://{バケット名}/iceberg",
"last-sequence-number" : 0,
"last-updated-ms" : 1649238615847,
"last-column-id" : 3,
"current-schema-id" : 0,
"schemas" : [ {
"type" : "struct",
"schema-id" : 0,
"fields" : [ {
"id" : 1,
"name" : "id",
"required" : false,
"type" : "int"
}, {
"id" : 2,
"name" : "data",
"required" : false,
"type" : "string"
}, {
"id" : 3,
"name" : "category",
"required" : false,
"type" : "string"
} ]
} ],
"default-spec-id" : 0,
"partition-specs" : [ {
"spec-id" : 0,
"fields" : [ {
"name" : "category",
"transform" : "identity",
"source-id" : 3,
"field-id" : 1000
}, {
"name" : "id_bucket",
"transform" : "bucket[16]",
"source-id" : 1,
"field-id" : 1001
} ]
} ],
"last-partition-id" : 1001,
"default-sort-order-id" : 0,
"sort-orders" : [ {
"order-id" : 0,
"fields" : [ ]
} ],
"properties" : {
"write.format.default" : "parquet",
"athena.optimize.rewrite.delete-file-threshold" : "10",
"write.binpack.delete-file-threshold" : "10",
"write.target-file-size-bytes" : "536870912",
"write.object-storage.enabled" : "true",
"write.object-storage.path" : "s3://{バケット名}/iceberg/data"
},
"current-snapshot-id" : -1,
"snapshots" : [ ],
"snapshot-log" : [ ],
"metadata-log" : [ ]
}% azumaha@3c22fb223340 ~ %
5.メタデータを確認する（2つ目）
}%
$ aws s3 cp s3://{バケット名}/iceberg/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXX.json -
{
"format-version" : 2,
"table-uuid" : "XXXXXXXXXXXXXXXXXXXXXXXXXXX",
"location" : "s3://{バケット名}/iceberg",
"last-sequence-number" : 1,
"last-updated-ms" : 1649238637352,
"last-column-id" : 3,
"current-schema-id" : 0,
"schemas" : [ {
"type" : "struct",
"schema-id" : 0,
"fields" : [ {
"id" : 1,
"name" : "id",
"required" : false,
"type" : "int"
}, {
"id" : 2,
"name" : "data",
"required" : false,
"type" : "string"
}, {
"id" : 3,
"name" : "category",
"required" : false,
"type" : "string"
} ]
} ],
"default-spec-id" : 0,
"partition-specs" : [ {
"spec-id" : 0,
"fields" : [ {
"name" : "category",
"transform" : "identity",
"source-id" : 3,
"field-id" : 1000
}, {
"name" : "id_bucket",
"transform" : "bucket[16]",
"source-id" : 1,
"field-id" : 1001
} ]
} ],
"last-partition-id" : 1001,
"default-sort-order-id" : 0,
"sort-orders" : [ {
"order-id" : 0,
"fields" : [ ]
} ],
"properties" : {
"write.format.default" : "parquet",
"athena.optimize.rewrite.delete-file-threshold" : "10",
"write.binpack.delete-file-threshold" : "10",
"write.target-file-size-bytes" : "536870912",
"write.object-storage.enabled" : "true",
"write.object-storage.path" : "s3://{バケット名}/iceberg/data"
},
"current-snapshot-id" : XXXXXXXXXXXXXXXXXXX,
"snapshots" : [ {
"sequence-number" : 1,
"snapshot-id" : XXXXXXXXXXXXXXXXX,
"timestamp-ms" : 1649238637352,
"summary" : {
"operation" : "append",
"added-data-files" : "1",
"added-records" : "1",
"added-files-size" : "388",
"changed-partition-count" : "1",
"total-records" : "1",
"total-files-size" : "388",
"total-data-files" : "1",
"total-delete-files" : "0",
"total-position-deletes" : "0",
"total-equality-deletes" : "0"
},
"manifest-list" : "s3://{バケット名}/iceberg/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.avro",
"schema-id" : 0
} ],
"snapshot-log" : [ {
"timestamp-ms" : 1649238637352,
"snapshot-id" : XXXXXXXXXXXXXXXXX
} ],
"metadata-log" : [ {
"timestamp-ms" : 1649238615847,
"metadata-file" : "s3://{バケット名}/iceberg/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.metadata.json"
} ]
}%
$
- 2つ目のmetaデータファイルでは、snapshotsに関する定義が書かれていました。
- 中身については、次回以降調査する。
UPDATE
1.以下のクエリで更新します。
UPDATE iceberg_table SET category='c2' WHERE category='c1'
2.以下のクエリでデータを確認します。
select * from iceberg_table
===
# id data category
1 1 a c2
3.S3を確認します。
$aws s3 ls {バケット名}/iceberg/ --recursive
2022-04-06 18:33:58 0 iceberg/
2022-04-06 18:50:37 388 iceberg/data/112fc32a//iceberg/category=c1/id_bucket=4/XXXXXX.gz.parquet
2022-04-06 19:09:26 897 iceberg/data/20ff636b//iceberg/category=c1/id_bucket=4/delete/position/XXXXXXX.gz.parquet
2022-04-06 19:09:27 388 iceberg/data/327ffaf9//iceberg/category=c2/id_bucket=4/XXXXXXX.gz.parquet
2022-04-06 18:50:16 1525 iceberg/metadata/00000-XXXXXXXXX.metadata.json
2022-04-06 18:50:38 2442 iceberg/metadata/00001-XXXXXXXXX.metadata.json
2022-04-06 19:09:27 3470 iceberg/metadata/00002-XXXXXXXXX.metadata.json
2022-04-06 18:50:38 7019 iceberg/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-m0.avro
2022-04-06 19:09:27 7020 iceberg/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-m0.avro
2022-04-06 19:09:27 7084 iceberg/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-m1.avro
2022-04-06 19:09:27 4355 iceberg/metadata/snap-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.avro
2022-04-06 18:50:38 4262 iceberg/metadata/snap-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.avro
$
- ファイルの状態は以下の通りだが、各ファイルの役割や仕組みは、やはりドキュメントを確認しないとわからない。
- categoryをc1からc2に変更したが、S3のディレクトリはcategory=c1が残ったまま。
- category=c1ディレクトリで、deleteディレクトリが作成されている。
- meta.jsonが1つ増えた。どうやら履歴的に管理されているらしい。
スキーマを変更する
- こちらによると、Icebergでは、スキーマを変更してもメタデータだけ更新され、データファイルは変更されないらしいです。
列追加
1.以下のクエリで列を追加します。
ALTER TABLE iceberg_table ADD COLUMNS (value bigint)
2.以下のクエリで、テーブル定義を確認します。
desc iceberg_table
====
# Table schema:
# col_name data_type comment
id int
data string
category string
value bigint
# Partition spec:
# field_name field_transform column_name
category identity category
id_bucket bucket[16] id
3.以下のクエリで、データを確認してみます。
select * from iceberg_table
===
# id data category value
1 1 a c2
- 当然だが、valueには値が入っていない。
データ操作(2)
INSERT
1.以下のクエリで、データを新しく登録します。
insert into iceberg_table(id,data,category,value) values(2,'b','c3',1)
2.以下のクエリで、データを確認します。
select * from iceberg_table
===
# id data category value
1 1 a c2
2 2 b c3 1
3.S3の状態を確認してみます。
$ aws s3 ls {バケット名}/iceberg/ --recursive
2022-04-06 18:33:58 0 iceberg/
2022-04-06 18:50:37 388 iceberg/data/112fc32a//iceberg/category=c1/id_bucket=4/170eaccf-96d6-43a0-9906-1ba3a8d40394.gz.parquet
2022-04-06 19:09:26 897 iceberg/data/20ff636b//iceberg/category=c1/id_bucket=4/delete/position/c9eac7ee-90ea-4701-9c92-bbba5f9e6601.gz.parquet
2022-04-06 19:09:27 388 iceberg/data/327ffaf9//iceberg/category=c2/id_bucket=4/0920551b-2f33-48a8-a749-79ff502ae524.gz.parquet
2022-04-06 21:45:40 524 iceberg/data/5336b1cc//iceberg/category=c3/id_bucket=4/c95a6bfe-e44a-44bf-bca1-5c9b32d2bcd5.gz.parquet
2022-04-06 18:50:16 1525 iceberg/metadata/00000-d83f57b4-62e2-4810-8a26-be8540c09b5e.metadata.json
2022-04-06 18:50:38 2442 iceberg/metadata/00001-052d92a9-eedb-4983-b5e8-ba0f1149704e.metadata.json
2022-04-06 19:09:27 3470 iceberg/metadata/00002-2e9a9bbf-b972-4e1c-8e3d-0528bbf2a958.metadata.json
2022-04-06 21:41:05 4092 iceberg/metadata/00003-fff4d46b-0b9c-4c6a-8f82-fb90dd18f68d.metadata.json
2022-04-06 21:45:41 5044 iceberg/metadata/00004-b0d8030c-453d-4817-b931-aa92f0ea109d.metadata.json
2022-04-06 18:50:38 7019 iceberg/metadata/5289499b-9483-4fba-a38f-86462702f336-m0.avro
2022-04-06 19:09:27 7020 iceberg/metadata/b9a8cec7-407f-4f44-b90b-b7f24c901674-m0.avro
2022-04-06 19:09:27 7084 iceberg/metadata/b9a8cec7-407f-4f44-b90b-b7f24c901674-m1.avro
2022-04-06 21:45:41 7082 iceberg/metadata/bff15d5f-12ca-4278-9fd0-c711477bc4be-m0.avro
2022-04-06 21:45:41 4404 iceberg/metadata/snap-2163518510344320267-1-bff15d5f-12ca-4278-9fd0-c711477bc4be.avro
2022-04-06 19:09:27 4355 iceberg/metadata/snap-4596782769550515733-1-b9a8cec7-407f-4f44-b90b-b7f24c901674.avro
2022-04-06 18:50:38 4262 iceberg/metadata/snap-4783172734858844302-1-5289499b-9483-4fba-a38f-86462702f336.avro
$
- 特段理由もなく、ハッシュ値をマスク化していましたが、意味ないのでやめました。（汗）
DELETE
1.以下のクエリで、データを削除します。
delete from iceberg_table where id=1
2.以下のクエリで、データを確認します。
select * from iceberg_table
===
# id data category value
1 2 b c3 1
3.S3を確認します。
$ aws s3 ls {バケット名}/iceberg/ --recursive
2022-04-06 18:33:58 0 iceberg/
2022-04-06 18:50:37 388 iceberg/data/112fc32a//iceberg/category=c1/id_bucket=4/170eaccf-96d6-43a0-9906-1ba3a8d40394.gz.parquet
2022-04-06 19:09:26 897 iceberg/data/20ff636b//iceberg/category=c1/id_bucket=4/delete/position/c9eac7ee-90ea-4701-9c92-bbba5f9e6601.gz.parquet
2022-04-06 19:09:27 388 iceberg/data/327ffaf9//iceberg/category=c2/id_bucket=4/0920551b-2f33-48a8-a749-79ff502ae524.gz.parquet
2022-04-06 21:45:40 524 iceberg/data/5336b1cc//iceberg/category=c3/id_bucket=4/c95a6bfe-e44a-44bf-bca1-5c9b32d2bcd5.gz.parquet
2022-04-06 22:01:57 897 iceberg/data/76230559//iceberg/category=c2/id_bucket=4/delete/position/1ba11a5a-6f94-49ba-b2a7-fcb3b9d56924.gz.parquet
2022-04-06 18:50:16 1525 iceberg/metadata/00000-d83f57b4-62e2-4810-8a26-be8540c09b5e.metadata.json
2022-04-06 18:50:38 2442 iceberg/metadata/00001-052d92a9-eedb-4983-b5e8-ba0f1149704e.metadata.json
2022-04-06 19:09:27 3470 iceberg/metadata/00002-2e9a9bbf-b972-4e1c-8e3d-0528bbf2a958.metadata.json
2022-04-06 21:41:05 4092 iceberg/metadata/00003-fff4d46b-0b9c-4c6a-8f82-fb90dd18f68d.metadata.json
2022-04-06 21:45:41 5044 iceberg/metadata/00004-b0d8030c-453d-4817-b931-aa92f0ea109d.metadata.json
2022-04-06 22:01:58 6010 iceberg/metadata/00005-801822fc-5525-4dde-86a7-74f5ff74d5f1.metadata.json
2022-04-06 18:50:38 7019 iceberg/metadata/5289499b-9483-4fba-a38f-86462702f336-m0.avro
2022-04-06 22:01:58 7135 iceberg/metadata/5e8353df-6473-486a-a091-284760510b0e-m0.avro
2022-04-06 19:09:27 7020 iceberg/metadata/b9a8cec7-407f-4f44-b90b-b7f24c901674-m0.avro
2022-04-06 19:09:27 7084 iceberg/metadata/b9a8cec7-407f-4f44-b90b-b7f24c901674-m1.avro
2022-04-06 21:45:41 7082 iceberg/metadata/bff15d5f-12ca-4278-9fd0-c711477bc4be-m0.avro
2022-04-06 21:45:41 4404 iceberg/metadata/snap-2163518510344320267-1-bff15d5f-12ca-4278-9fd0-c711477bc4be.avro
2022-04-06 19:09:27 4355 iceberg/metadata/snap-4596782769550515733-1-b9a8cec7-407f-4f44-b90b-b7f24c901674.avro
2022-04-06 18:50:38 4262 iceberg/metadata/snap-4783172734858844302-1-5289499b-9483-4fba-a38f-86462702f336.avro
2022-04-06 22:01:58 4454 iceberg/metadata/snap-7112419636718873392-1-5e8353df-6473-486a-a091-284760510b0e.avro
$
- ファイルがまた増えた。（0005-のファイル。）
-
iceberg/data/76230559//iceberg/category=c2/id_bucket=4/delete/position/1ba11a5a-6f94-49ba-b2a7-fcb3b9d56924.gz.parquetを確認すると、delete/positionというディレクトリが掘られている。これで削除を表しているのかもしれません。
タイムトラベル機能
- こちらによると、Icebergでは、データをマニフェスト（スナップショット）で管理しており、日時指定または、バージョンID指定により、その状態を参照できるようです。
タイムトラベルの履歴を確認
1.以下のクエリを実行し、バージョンIDと日時を確認します。
select * from "iceberg_table$iceberg_history"
===
# made_current_at snapshot_id parent_id is_current_ancestor
1 2022-04-06 09:50:37.352 UTC 4783172734858844302 true
2 2022-04-06 10:09:26.659 UTC 4596782769550515733 4783172734858844302 true
3 2022-04-06 12:45:40.532 UTC 2163518510344320267 4596782769550515733 true
4 2022-04-06 13:01:57.735 UTC 7112419636718873392 2163518510344320267 true
- テーブル名$iceberg_historyにてテーブルごとの履歴が確認できるとのこと。（出典:PORTABLECODE.INFO）
- 履歴を見るとsnapshot_idというデータがあり、こちらは、S3の
metadata/snap-{ID}-XXXXXと一致している。 - また、parent_idには、一つ前のsnapshot_idが入っており、これを利用して順番を管理しているのかもしれない。
タイムトラベルを利用する（日時指定）
1.以下のクエリを実行し、一番最初の状態を確認してみます。
SELECT * FROM iceberg_table FOR SYSTEM_TIME AS OF TIMESTAMP '2022-04-06 09:50:37.352 UTC'
===
# id data category
1 1 a c1
- 一番最初にINSERTした時の状態が確認できました。
タイムトラベルを利用する（バージョンID指定）
1.以下のクエリを実行し、#2の状態を確認してみます。
SELECT * FROM iceberg_table FOR SYSTEM_VERSION AS OF 4596782769550515733
===
# id data category
1 1 a c2
- categoryをc1→c2に更新した状態が確認できました。
OPTIMIZE機能
- Optimizing Iceberg Tablesによると、データが増えてくるとファイルを開くのに時間がかかり、クエリの効率が悪くなるらしいです。
- 上記のパフォーマンスを最適化するために、手動圧縮をサポートしています。
REWRITE DATA Compaction Action
1.事前にS3の状態を確認しておきます。
$ aws s3 ls {バケット名}/iceberg/ --recursive
2022-04-06 18:33:58 0 iceberg/
2022-04-06 18:50:37 388 iceberg/data/112fc32a//iceberg/category=c1/id_bucket=4/170eaccf-96d6-43a0-9906-1ba3a8d40394.gz.parquet
2022-04-06 19:09:26 897 iceberg/data/20ff636b//iceberg/category=c1/id_bucket=4/delete/position/c9eac7ee-90ea-4701-9c92-bbba5f9e6601.gz.parquet
2022-04-06 19:09:27 388 iceberg/data/327ffaf9//iceberg/category=c2/id_bucket=4/0920551b-2f33-48a8-a749-79ff502ae524.gz.parquet
2022-04-06 21:45:40 524 iceberg/data/5336b1cc//iceberg/category=c3/id_bucket=4/c95a6bfe-e44a-44bf-bca1-5c9b32d2bcd5.gz.parquet
2022-04-06 22:01:57 897 iceberg/data/76230559//iceberg/category=c2/id_bucket=4/delete/position/1ba11a5a-6f94-49ba-b2a7-fcb3b9d56924.gz.parquet
2022-04-06 18:50:16 1525 iceberg/metadata/00000-d83f57b4-62e2-4810-8a26-be8540c09b5e.metadata.json
2022-04-06 18:50:38 2442 iceberg/metadata/00001-052d92a9-eedb-4983-b5e8-ba0f1149704e.metadata.json
2022-04-06 19:09:27 3470 iceberg/metadata/00002-2e9a9bbf-b972-4e1c-8e3d-0528bbf2a958.metadata.json
2022-04-06 21:41:05 4092 iceberg/metadata/00003-fff4d46b-0b9c-4c6a-8f82-fb90dd18f68d.metadata.json
2022-04-06 21:45:41 5044 iceberg/metadata/00004-b0d8030c-453d-4817-b931-aa92f0ea109d.metadata.json
2022-04-06 22:01:58 6010 iceberg/metadata/00005-801822fc-5525-4dde-86a7-74f5ff74d5f1.metadata.json
2022-04-06 18:50:38 7019 iceberg/metadata/5289499b-9483-4fba-a38f-86462702f336-m0.avro
2022-04-06 22:01:58 7135 iceberg/metadata/5e8353df-6473-486a-a091-284760510b0e-m0.avro
2022-04-06 19:09:27 7020 iceberg/metadata/b9a8cec7-407f-4f44-b90b-b7f24c901674-m0.avro
2022-04-06 19:09:27 7084 iceberg/metadata/b9a8cec7-407f-4f44-b90b-b7f24c901674-m1.avro
2022-04-06 21:45:41 7082 iceberg/metadata/bff15d5f-12ca-4278-9fd0-c711477bc4be-m0.avro
2022-04-06 21:45:41 4404 iceberg/metadata/snap-2163518510344320267-1-bff15d5f-12ca-4278-9fd0-c711477bc4be.avro
2022-04-06 19:09:27 4355 iceberg/metadata/snap-4596782769550515733-1-b9a8cec7-407f-4f44-b90b-b7f24c901674.avro
2022-04-06 18:50:38 4262 iceberg/metadata/snap-4783172734858844302-1-5289499b-9483-4fba-a38f-86462702f336.avro
2022-04-06 22:01:58 4454 iceberg/metadata/snap-7112419636718873392-1-5e8353df-6473-486a-a091-284760510b0e.avro
$
2.以下のクエリを実行し、圧縮します。
- 今回は、対象を全てにします。
- WHERE句をつけることで、圧縮対象を絞り込む事が可能なようです。
OPTIMIZE iceberg_table REWRITE DATA
USING BIN_PACK
3.圧縮後のS3の状態を確認します。
$ aws s3 ls {バケット名}/iceberg/ --recursive
2022-04-06 18:33:58 0 iceberg/
2022-04-06 18:50:37 388 iceberg/data/112fc32a//iceberg/category=c1/id_bucket=4/170eaccf-96d6-43a0-9906-1ba3a8d40394.gz.parquet
2022-04-06 19:09:26 897 iceberg/data/20ff636b//iceberg/category=c1/id_bucket=4/delete/position/c9eac7ee-90ea-4701-9c92-bbba5f9e6601.gz.parquet
2022-04-06 19:09:27 388 iceberg/data/327ffaf9//iceberg/category=c2/id_bucket=4/0920551b-2f33-48a8-a749-79ff502ae524.gz.parquet
2022-04-06 21:45:40 524 iceberg/data/5336b1cc//iceberg/category=c3/id_bucket=4/c95a6bfe-e44a-44bf-bca1-5c9b32d2bcd5.gz.parquet
2022-04-06 22:01:57 897 iceberg/data/76230559//iceberg/category=c2/id_bucket=4/delete/position/1ba11a5a-6f94-49ba-b2a7-fcb3b9d56924.gz.parquet
2022-04-06 18:50:16 1525 iceberg/metadata/00000-d83f57b4-62e2-4810-8a26-be8540c09b5e.metadata.json
2022-04-06 18:50:38 2442 iceberg/metadata/00001-052d92a9-eedb-4983-b5e8-ba0f1149704e.metadata.json
2022-04-06 19:09:27 3470 iceberg/metadata/00002-2e9a9bbf-b972-4e1c-8e3d-0528bbf2a958.metadata.json
2022-04-06 21:41:05 4092 iceberg/metadata/00003-fff4d46b-0b9c-4c6a-8f82-fb90dd18f68d.metadata.json
2022-04-06 21:45:41 5044 iceberg/metadata/00004-b0d8030c-453d-4817-b931-aa92f0ea109d.metadata.json
2022-04-06 22:01:58 6010 iceberg/metadata/00005-801822fc-5525-4dde-86a7-74f5ff74d5f1.metadata.json
2022-04-06 18:50:38 7019 iceberg/metadata/5289499b-9483-4fba-a38f-86462702f336-m0.avro
2022-04-06 22:01:58 7135 iceberg/metadata/5e8353df-6473-486a-a091-284760510b0e-m0.avro
2022-04-06 19:09:27 7020 iceberg/metadata/b9a8cec7-407f-4f44-b90b-b7f24c901674-m0.avro
2022-04-06 19:09:27 7084 iceberg/metadata/b9a8cec7-407f-4f44-b90b-b7f24c901674-m1.avro
2022-04-06 21:45:41 7082 iceberg/metadata/bff15d5f-12ca-4278-9fd0-c711477bc4be-m0.avro
2022-04-06 21:45:41 4404 iceberg/metadata/snap-2163518510344320267-1-bff15d5f-12ca-4278-9fd0-c711477bc4be.avro
2022-04-06 19:09:27 4355 iceberg/metadata/snap-4596782769550515733-1-b9a8cec7-407f-4f44-b90b-b7f24c901674.avro
2022-04-06 18:50:38 4262 iceberg/metadata/snap-4783172734858844302-1-5289499b-9483-4fba-a38f-86462702f336.avro
2022-04-06 22:01:58 4454 iceberg/metadata/snap-7112419636718873392-1-5e8353df-6473-486a-a091-284760510b0e.avro
$
- ファイル数も変わらなければ、サイズも変わっていない。ファイルのマージを期待していたが。。
- サイズが小さいのでできなかったのか？ドキュメントなど確認して原因を究明したい。
参考