AWSで実現する大規模データ保存・分散処理 ―IcebergとSparkの仕組みと実践― Part1

2026-05-26 AWSランチセッション 第18回 AWSで実現する大規模データ保存・分散処理 ― IcebergとSparkの仕組みと実践 ― Part 1 山崎 拓也

山崎 拓也 所属: SIer 仕事: • AWS案件のアプリやインフラのリード • 社内AWSサポート 好き: 低レイヤ、SF、AWS AWSアワード: • 2026 AWS Community Builder (Serverless) • 2024～2025 Japan AWS Top Engineer • 2022～2025 Japan All AWS Certifications Engineer

アジェンダ Part1 • 要件とアーキテクチャ • Icebergの仕組み • S3 Tablesの実践的なポイント Part2 • Sparkの仕組み • Glue Spark Jobの実践的なポイント • まとめ

要件とアーキテクチャ

沢山のデバイスから沢山のイベントデータが流れてくる ❶ 1レコード5000カラム

デバイス毎にソートやレコードを跨ぐ変換、分岐、演算など複雑な処 理を行い、BI用データを作る ❶ ❷ ❸ • • • • • 100デバイス 5000カラム 600万レコード 1レコード25kB wide table問題 ❹ ❺

データはdevice_idごとにevent_timeでソートして処理する ❶ ❷ ❸ ❹ ❺ device_id event_time status data_0001 data_0002 … data_5000 device-001 2026-05-24 12:19:59.625769 UTC on 11.9006 29.5572 … 83.8366 device-001 2026-05-24 12:19:59.622365 UTC off 83.8306 74.4484 … 19.9301 device-001 2026-05-24 12:19:59.613774 UTC off 4.4936 26.4307 … 6.6576 device-002 2026-05-24 12:22:19.437531 UTC off 17.351 42.7808 … 59.7419 device-002 2026-05-24 12:22:19.436117 UTC on 69.2087 28.331 … 2.6499

生データはCSVで取得したい ❶ ❷ ❸ ❹ ❺

Iceberg、Sparkの大まかな仕組みを通して、 各部分の実践的なポイントを紹介 ❶

Icebergの仕組み

Apache Iceberg とは • 大規模な分析向けの高性能テーブルフォーマット • データ配置を最適化し、大規模データをSQLで効率的にクエリ • メタデータでテーブル情報や統計情報を管理 • カタログのメタデータポインタから、各ファイルを辿って物理データファイ ルにアクセスする Iceberg Table Spec：https://iceberg.apache.org/spec/

• https://iceberg.apache.org/spec/

データ操作の度にファイルが増えていく • データ挿入の度に各種メタデータファイルとデータファイルが作成される • データ削除はバージョンや戦略で異なる。更新は削除と挿入で行う 1データ目書き込み 1データ目データ 2データ目書き込み 2データ目データ 1データ目データ

メタデータポインタの楽観的同時実行制御により原子性を担保 • 複数のデータ操作が同時に行われた場合、各種メタデータファイルとデータ ファイルがそれぞれ独立に作成される • メタデータポインタの更新をcommitできるのは同時に1つの操作のみ • commitできなかった操作は失敗するが、作成した各種ファイルは残る Aの書き込み によりファイル作成 同時 Bの書き込み によりファイル作成 メタデータポインタを 更新できるのは同時に1操作のみ （今回は操作B。Aは失敗） 後述の孤立ファイル削除にて削除

データの物理配置はパーティションとソート順で設定できる • 列の値に関数を適用してパーティション作成できる • パーティション列はテーブルには不要（隠しパーティション） • クエリ時もパーティションの指定不要 パーティション 含まれるデータの統計情報 event_time_day=2026-05-24, device_id_bucket=9 device_id= {min=device-013, max=device-083}, event_time= {min=2026-05-24 02:42:14… , max=2026-05-24 15:34:15…}, etc event_time_day=2026-05-24, device_id_bucket=8 device_id= {min=device-015, max=device-071}, event_time= {min=2026-05-24 02:42:14…, max=2026-05-24 15:34:15…}, etc device_idをHash関数で32分割

テーブルの状態把握でよく使うクエリ • select * from "device_events$snapshots"; • スナップショット情報 • $manifests • マニフェストファイル情報 • $partitions • パーティション情報 • $files • データファイル情報

パフォーマンスを保つためのメンテナンス機能 No. 機能名 内容 ❶ コンパクション 指定した戦略に基づいてデータをマージ・再配置する ❷ スナップショット削除 古いスナップショットを削除する ❸ 孤立ファイル削除 参照されなくなったファイルを削除する ❷ ❶ ❸

Icebergの特徴的な機能 機能名 内容 隠しパーティション パーティション列を意識せずにクエリ最適化できる仕組み コンパクション 小さなファイルを再編成し読み取り効率を改善する機能 スキーマ進化 既存データを壊さずにテーブル定義を変更できる仕組み パーティション変更・データ型拡張など タイムトラベル 過去のスナップショット時点のデータをクエリできる機能 ブランチ Gitのブランチのようにスナップショットを分岐できる機能

おすすめ書籍 • 実践Apache Iceberg https://gihyo.jp/book/2025/978-4-297-15074-7 • ISBN • 978-4-297-15074-7（紙） • 978-4-297-15075-4（電子）

• https://gihyo.jp/book/2025/978-4-297-15074-7

S3 Tablesの実践的なポイント

AWSでIcebergを使う際の選択肢 • S3 Tables or 自分で構築 S3 Tables Glue DataCatalog & S3 Bucket 管理方式 フルマネージド 自分で構築 設定の柔軟性 制限あり 高い パフォーマンス クエリが3倍高速 トランザクションは秒あたり10倍処理可能 - コスト メンテナンス 条件次第。比較が難しい。 （個人的にはそこまで変わらない気がする） 自動 • 比較はAWS Builder Centerの記事「Amazon S3 Tables vs Self-Managed Apache Iceberg on S3: A Technical Deep-Dive for Startups」が非常に詳細 https://builder.aws.com/content/39n7WU54TBsV3OlKwtJsnL54PVL/amazon-s3-tables-vs-self-managedapache-iceberg-on-s3-a-technical-deep-dive-for-startups

• https://builder.aws.com/content/39n7WU54TBsV3OlKwtJsnL54PVL/amazon-s3-tables-vs-self-managed-apache-iceberg-on-s3-a-technical-deep-dive-for-startups

S3 Tablesの料金体系 小さなオブジェクト作成は避けると良い • StandardとIntelligent Tieringがある • モニタリングやコンパクションはオブジェクトごと課金 課金項目（Standard） ストレージ （月ごと） 種類 料金 最初の50TB 0.0288 USD/GB 次の450TB 0.0276 USD/GB 500TB以上 0.0265 USD/GB リクエスト （1000リクエストごと） PUT, POST, LIST 0.0047 USD GET, その他 0.00037 USD モニタリング （1000オブジェクトごと） - 0.025 USD コンパクション オブジェクト数 （処理された1000オブジェクトごと） - 0.002 USD コンパクション データ量 （処理されたGBごと） Binpack 0.005 USD Sort, Z-order 0.01 USD Amazon S3 料金表：https://aws.amazon.com/jp/s3/pricing/

• https://aws.amazon.com/jp/s3/pricing/

Firehoseを使って小さなファイル作成を避ける • 小さなファイルが多いとパフォーマンス低下 • オブジェクト数で課金されるため、ファイルを大きく作ることでコスト削減 • Firehoseのバッファ設定を最大にする • 15分 • 128 MiB • Firehoseでの挿入でもIcebergパーティションどおり分割される $snapshots の summary項目から抜粋 added-data-files=29, added-records=37999, total-records=54271500, FIREHOSE-DELIVERY-STREAM-ID=…, changed-partition-count=29, FIREHOSE-INTERNAL-CHECKPOINT=… 1度の書き込みで、 37999レコードを 29パーティションに分け、 29ファイルとして作成

運用用にGlue Spark Jobを1つ用意すると良い • Athenaはサポートしていない機能がある • テーブル作成時のソート順（致命的） • TRUNCATEやメンテナンスプロシージャなど • テーブル情報などの表示がSparkと比べて限定的 • ログに実行SQLと結果を出力して残すと良い • SHOW TBLPROPERTIES の結果比較 Athena Glue Spark Job ソート順も出る

S3 Tablesのコンパクション戦略はソート順が使われる • 選択できるコンパクション戦略は３つ コンパクション戦略 内容 Binpack ファイルサイズのみで最適化 Sort ソート順の1カラムでソートしつつ最適化 Z-order ソート順の複数カラムを加味しつつ最適化 Athenaはソート順未サポートなので Glue Spark Jobからテーブル作成する • コンパクション前後のデータ構造変化（$snapshotsより抜粋） committed_at operation summary 2026-05-24 18:04:21.235 UTC replace added-data-files=2, added-records=4280151, deleteddata-files=344, deleted-records=4280151, totalrecords=50994000, changed-partition-count=2, totalfiles-size=944817544, total-data-files=58 … 2026-05-24 18:03:42.855 UTC append added-data-files=29, records=38499, totalrecords=50994000, changed-partition-count=29, totalfiles-size=995207031, total-data-files=5470,

timestamp型のz-orderはタイムゾーン必須 • タイムゾーン無しtimestamp_ntzの場合、コンパクション時にエラーとなる • Glue Spark Jobではtimestamp型は暗黙的にtimestamp_ltzとなる

コンパクション実行履歴はメトリクスや$snapshotsから確認 • メトリクス • CompactionObjectsCount_z-order （処理されたオブジェクト数） • CompactionBytesProcessed_z-order （処理されたデータサイズ） • コンソールで成功でも、コンパクション不要な場合は実行されていない 成功でも処理実行されていないため、 課金されない

カラム数によるパフォーマンス検証 7カラム vs 5003カラム • カラム数が多い場合、データ処理が平均32秒遅かった • Icebergからのデータ読み込み時のSparkパーティション数に大きな差 7カラム 必要カラムのみ Select パーティション ソート順 コンパクション戦略 同じ （コンパクション済み） レコード数 repartitionして データ処理 5003カラム 6,000,000レコード 平均データ処理時間 2分8秒 2分40秒 Icebergパーティション数 58 87 読み込み時 Sparkパーティション数 37 1694

カラム数が多い場合、Icebergからのデータ読み込みが34秒遅い • Selectカラム数が同じでもパーティションが多くなり、読み込みタスクが細 切れになるため時間が多くかかる • repartition後のデータ処理時間は同じため、カラムが多くても全体影響はほ とんどない 7カラム 2026-05-28T14:35:18,113 34810 2026-05-28T14:35:32,359 49056 Starting task 0.0 in stage 0.0 Finished task 28.0 in stage 0.0 (executor 2) (37/37) 5003カラム 2026-05-28T14:30:20,146 34306 2026-05-28T14:31:08,347 82507 Starting task 0.0 in stage 0.0 Finished task 1691.0 in stage 0.0 (executor 4) (1694/1694)

生データ保存用とデータ処理用でテーブルを分ける選択肢もある • データ処理では必要列のみ利用するケースが多い • クエリパターンに応じたパーティションやコンパクション戦略をとれる データ処理用テーブル 生データテーブル 7 5003 パーティション days(event_tme), bucket(32, device_id) days(event_time) ソート順 device_id, event_time device_id コンパクション戦略 Z-order Sort カラム数

用途に応じてAthenaとGlue Spark Jobを使い分ける • 生データテーブルからの単一CSVファイル作成はAthenaを使う • データ処理や運用作業にはGlue Spark Jobを使う 検証では23.5GBのクエリ結果でも 1つのCSVファイルとして作成された

Iceberg バージョン3を使用するには format-version を指定する • デフォルトはIcebergバージョン2 • バージョン3は新しい仕組みや機能が利用できる Apache Iceberg V3 の使用：https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/working-with-apache-iceberg-v3.html

• https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/working-with-apache-iceberg-v3.html

Part 2 へ続きます Part1 • 要件とアーキテクチャ • Icebergの仕組み • S3 Tablesの実践的なポイント Part2 • Sparkの仕組み • Glue Spark Jobの実践的なポイント • まとめ