AWS Glue + Iceberg で電力データを取り込み、処理時間を計測してみた

公開日

2026-01-29

掲載

ENECHANGE Developer Blog

出典

https://tech.enechange.co.jp/entry/2026/01/29/131005

はじめに

以下の記事で、AWS Glue と Iceberg を用いて分析基盤を作成してみました。 本記事では、この分析基盤に対して 1万〜15万件 のデータを取り込み、以下の観点で検証します。

  • Glue Job の処理時間（XML パース → Iceberg MERGE）の計測

  • データ量に対する処理時間のスケーリング傾向の把握

  • ワーカー数（並列度）による効果の確認

tech.enechange.co.jp

電力使用量データ量 と AWS Glue ワーカー数

1. 電力使用量データ量（ファイル数）

  • 1日分の需要家数を1万件、2万件、5万件、10万件、15万件と変動させます。

  • 1ファイル = 1万需要家（重複なし）分の 1日の電力使用量を保存しています。

ファイル数

需要家数

1

1万

2

2万

5

5万

10

10万

15

15万

2. Glue ワーカー数

Glueのワーカータイプ と バージョンを以下のように設定して、3回ずつ処理時間を計測していきます。

  • Glue ワーカータイプ : G.1X（4 vCPU , 16GB RAM ）

  • Glue バージョン : 5.0

ワーカー数

DPU (G.1X)

2

2

5

5

10

10

テストケース

  • 上記の電力使用量データ量とAWS Glue ワーカー数のパターンを組み合わせると15個のテストケースができます。

  • 1テストケースごとに、3回ずつ処理時間を計測していきます。

#

需要家数

ファイル数

ワーカー数

1

1万

1

2

2

1万

1

5

3

1万

1

10

4

2万

2

2

5

2万

2

5

6

2万

2

10

7

5万

5

2

8

5万

5

5

9

5万

5

10

10

10万

10

2

11

10万

10

5

12

10万

10

10

13

15万

15

2

14

15万

15

5

15

15万

15

10

処理時間の取得方法

  • AWS Glue コンソールで実行時間を確認

  • または AWS CLI で取得:

aws glue get-job-runs --job-name consumption-xml-to-iceberg --max-results 10

検証手順

1. サンプルデータ生成

  • 以下の構造で、1万件分の電力使用量データを含むXMLファイルを生成します。

<?xml version="1.0" encoding="UTF-8"?>
<electricity_usage_report>
  <record>
    <external_id>CUST-001234</external_id>
    <target_date>2024-01-15</target_date>
    <updated_at>2024-01-16T06:30:00+09:00</updated_at>
    <usage_kwh>
      <slot time="00:00">1.2</slot>
      <slot time="00:30">1.1</slot>
      <!-- ... 48コマ ... -->
      <slot time="23:30">1.3</slot>
    </usage_kwh>
  </record>
  <record>
    <external_id>CUST-001235</external_id>
    <target_date>2024-01-15</target_date>
    <updated_at>2024-01-16T06:30:00+09:00</updated_at>
    <usage_kwh>
      <slot time="00:00">1.2</slot>
      <slot time="00:30">1.1</slot>
      <!-- ... 48コマ ... -->
      <slot time="23:30">1.3</slot>
    </usage_kwh>
  </record>
</electricity_usage_report>

2. テスト実行

テストは以下の手順で進めます。

  • S3 へアップロード

  • Iceberg テーブルのクリーンアップ

  • Glue Job 実行（ワーカー数を指定）

  • 処理時間の計測

3. 結果記録

処理時間を記録し、結果記録テーブルを更新します。

手順1〜3を各テストケースで繰り返します。

結果記録

#

需要家数

ワーカー数

1回目

2回目

3回目

平均

1

1万

2

122s

63s

65s

83s

2

1万

5

126s

138s

133s

132s

3

1万

10

133s

169s

176s

159s

4

2万

2

148s

140s

137s

142s

5

2万

5

132s

141s

130s

134s

6

2万

10

123s

137s

184s

148s

7

5万

2

190s

188s

191s

190s

8

5万

5

158s

156s

162s

159s

9

5万

10

149s

201s

154s

168s

10

10万

2

533s

544s

548s

542s

11

10万

5

260s

261s

268s

263s

12

10万

10

267s

269s

232s

256s

13

15万

2

753s

777s

749s

760s

14

15万

5

280s

325s

283s

296s

15

15万

10

259s

220s

225s

235s

結果サマリー

  • 需要家数が増えるほど処理時間が増加しますが、ワーカー数を増やすことで処理時間を短縮できます。特に10万件以上ではワーカー2と、ワーカー5・10の差が顕著になります。

  • 以下のグラフは、需要家数の増加に伴う処理時間の変化を可視化したものです。

_images/20260129131006.png

需要家数

ファイル数

ワーカー2

ワーカー5

ワーカー10

最速

1万

1

83s

132s

159s

ワーカー2

2万

2

142s

134s

148s

ワーカー5

5万

5

190s

159s

168s

ワーカー5

10万

10

542s

263s

256s

ワーカー10

15万

15

760s

296s

235s

ワーカー10

考察

ファイル数とワーカー数の関係

  • ファイル数 < ワーカー数 → 効果が出にくい

  • ファイル数 ≥ ワーカー数 → 並列処理の効果が発揮される

推奨設定（ファイル分割あり前提）

データ規模

推奨ワーカー数

〜2万件

2

2〜5万件

5

10万件以上

10

追加検証: ファイル分割 vs 1ファイル

検証目的

同じ需要家数でファイル数を変えた場合の処理時間を比較し、処理時間にどのような差が出るか観察する。

テストケース

#

需要家数

ファイル数

ワーカー数

1

2万

1

2

2

2万

1

5

3

2万

1

10

4

5万

1

2

5

5万

1

5

6

5万

1

10

7

10万

1

2

8

10万

1

5

9

10万

1

10

10

15万

1

2

11

15万

1

5

12

15万

1

10

結果記録

#

需要家数

ファイル数

ワーカー数

1回目

2回目

3回目

平均

1

2万

1

2

163s

164s

215s

181s

2

2万

1

5

156s

234s

145s

178s

3

2万

1

10

205s

153s

158s

172s

4

5万

1

2

312s

223s

274s

270s

5

5万

1

5

231s

221s

208s

220s

6

5万

1

10

209s

211s

234s

218s

7

10万

1

2

365s

353s

376s

365s

8

10万

1

5

320s

319s

317s

319s

9

10万

1

10

312s

319s

356s

329s

10

15万

1

2

502s

454s

468s

475s

11

15万

1

5

419s

427s

450s

432s

12

15万

1

10

448s

428s

440s

439s

比較結果

  • ファイル分割ありの場合、ワーカー5・10で処理時間が大きく短縮されています。一方、1ファイルの場合はワーカー数を増やしても処理時間の改善が限定的になります。

  • 以下のグラフは、同じ需要家数での「ファイル分割あり」と「1ファイル」の処理時間を比較したものです。

    • 青がファイル分割、赤が1ファイル です。

_images/20260129131009.png

需要家数

ファイル数

ワーカー2

ワーカー5

ワーカー10

最速

2万

1

181s

178s

172s

ワーカー10

2万

2

142s

134s

148s

ワーカー5

5万

1

270s

220s

218s

ワーカー10

5万

5

190s

159s

168s

ワーカー5

10万

1

365s

319s

329s

ワーカー5

10万

10

542s

263s

256s

ワーカー10

15万

1

475s

432s

439s

ワーカー5

15万

15

760s

296s

235s

ワーカー10

追加検証のまとめ

発見事項

  • ワーカー2: 10万件以上で1ファイルの方が速い

  • ワーカー5: 全データサイズでファイル分割が優位

  • ワーカー10: 大規模データでファイル分割の効果が顕著

推奨設定（総合判断）

条件

推奨ワーカー数

理由

通常運用（ファイル分割あり）

5

コストと速度のバランス最良

大量データ急ぎ（10万件+、分割あり）

10

並列効果最大

1ファイルのみ

5

10にしても速度向上しない

Spark UI 分析

Stage 比較: 1ファイル vs 15ファイル分割

1ファイル (総処理時間: 440s)

Stage

時間

タスク数

処理内容

0

316.0s

1

XMLパース (repartition)

1

6.9s

20

count

3

3.6s

20

DynamicFrame変換

6

7.2s

20

SQL処理

7

10.8s

20

SQL処理

10

1.8s

36

SQL処理

14

4.4s

1

MERGE書き込み

15ファイル分割 (総処理時間: 259s)

Stage

時間

タスク数

処理内容

0

52.6s

15

XMLパース (count)

1

32.2s

15

DynamicFrame変換

3

53.4s

15

SQL処理

4

56.3s

15

SQL処理

6

2.2s

36

SQL処理

9

4.2s

1

MERGE書き込み

分析結果

項目

1ファイル

15ファイル

改善率

XMLパース時間

316s

53s

6倍高速

XMLパースタスク数

1

15

15並列化

総処理時間

440s

259s

41%短縮

ボトルネックの特定

  1. 1ファイルの場合: Stage 0 (XMLパース) が316秒で全体の72%を占める。タスク数が1のため、ワーカーを増やしても並列化できない。

  2. 15ファイル分割の場合: Stage 0 が15タスクで並列実行され、52.6秒に短縮。各ワーカーが独立してファイルを処理できる。

  3. 根本原因: glueContext.create_dynamic_frame.from_options でのXMLパースは、ファイル単位でしか並列化されない。1ファイル内のレコードは順次処理される。

参考: タスク分散の仕組み

  • G.1X ワーカー = 4 vCPU = 4 cores (4並列スロット)

  • 10ワーカー = 1 Driver + 9 Executor = 36並列スロット

  • 15ファイル → 15タスク → 4 Executor × 4 cores で同時実行

結論

  • ファイル分割が最重要: ワーカー数を増やすより、ファイル分割の方が効果大

  • ワーカー数はファイル数に合わせる: ワーカー数 ≤ ファイル数 が基本（余剰ワーカーは効果が出にくい）

  • ワーカー5が汎用的: ほとんどのケースで最適またはそれに近い性能

  • ワーカー10は条件付き: 10ファイル以上 × 10万件以上の場合のみ有効

本番運用に向けて

今回の検証はワーカー数（2/5/10）とファイル数（1〜15）の限られた範囲で実施しました。本番環境では、実際のデータ量・ファイル数・処理時間の要件に応じて、ワーカー数やワーカータイプのチューニングが必要です。

特に以下の点を考慮してください：

  • コストと速度のトレードオフ: ワーカー数やワーカータイプを上げれば速くなるがDPUコストも増加

  • ファイル数との関係: ファイル数以上にワーカーを増やしても効果は限定的

  • SLA要件: 処理時間の制約がある場合は、それに合わせた設定が必要

今後の課題

今回はSpark UIを用いてStage単位での処理時間を確認しましたが、正直なところSpark自体を触り始めたばかりで、まだまだ理解が浅い部分があります。

以下の点は今後学びながら深掘りしていきたいです。

  • Spark UIの詳細メトリクス（Scheduler Delay、GC Time、Shuffle Read/Write など）の読み方

  • ワーカー2で逆転現象が起きる原因の特定

  • ワーカータイプによる違い

  • Icebergのデータファイル形式（Parquet vs Avro）によるパフォーマンス差

引き続き検証を進めて、分かったことがあれば記事にしていきたいと思います。