---
title: AWSで実現する大規模データ保存・分散処理 ―IcebergとSparkの仕組みと実践― Part1
tags: 
author: [Takuya Yamazaki](https://image.docswell.com/user/kkmtyyz)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/L73WVZD175.jpg?width=480
description: AWSでS3 Tables・Glue Spark Jobを上手く使いこなすには、元となっているIceberg・Sparkの仕組みを理解することが大切です。 この資料ではAWSで大規模データを保存・分散処理する際の実践的なポイントを紹介しています。 Part1ではIceberg・S3 Tablesについて、Part2ではSpark・Glue Spark Jobについて紹介しています。
published: May 31, 26
canonical: https://image.docswell.com/s/kkmtyyz/Z4NJ7L-2026-05-31-161801
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/L73WVZD175.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/87DK8RPKJG.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VJPK8WN3E8.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/2EVVN8KNEQ.jpg)

要件とアーキテクチャ


# Page. 5

![Page Image](https://bcdn.docswell.com/page/57GLK5Q5EL.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4EQYNZKLJP.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/KJ4WG3P571.jpg)

データは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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LE1YD1927G.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GEWGY8Q2J2.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/47ZLX8W4J3.jpg)

Icebergの仕組み


# Page. 11

![Page Image](https://bcdn.docswell.com/page/YJ6W4PGGJV.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/GJ5MQKVXJ4.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/9E29PW3Q7R.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/D7Y45L1YEM.jpg)

データの物理配置はパーティションとソート順で設定できる
• 列の値に関数を適用してパーティション作成できる
• パーティション列はテーブルには不要（隠しパーティション）
• クエリ時もパーティションの指定不要
パーティション
含まれるデータの統計情報
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分割


# Page. 15

![Page Image](https://bcdn.docswell.com/page/VENYN42RJ8.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/Y79PRQ1ZE3.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/G78DWG3Y7D.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/L7LMNGV9JR.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4EMYXQGVEW.jpg)

S3 Tablesの実践的なポイント


# Page. 20

![Page Image](https://bcdn.docswell.com/page/PER9N8ZWJ9.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/P7XQN89VEX.jpg)

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/


# Page. 22

![Page Image](https://bcdn.docswell.com/page/37K9NKP57D.jpg)

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ファイルとして作成


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LJ3WVZX1J5.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/8JDK8R2KEG.jpg)

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,


# Page. 25

![Page Image](https://bcdn.docswell.com/page/VEPK8W1378.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/27VVN8YN7Q.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/5JGLK5957L.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/47QYNZWLEP.jpg)

カラム数が多い場合、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)


# Page. 29

![Page Image](https://bcdn.docswell.com/page/KE4WG3K5J1.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/L71YD1X2JG.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/G7WGY8N2E2.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4JZLX834E3.jpg)

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