3.2標準
数TBの売上データと数MBの店舗マスタを結合する。
大表のシャッフルを減らし、Executorメモリに収まる範囲で高速化したい。
最も適切な分析方法はどれか。
× 不正解
小表が各Executorのメモリへ収まることを確認してbroadcast joinを使い、サイズ増加時は自動適用を見直す。
詳細解説
正しい小表をbroadcast joinする
小表を各Executorへ配布し、大表の全体シャッフルを避けられる。
小表を各Executorへ配布し、大表の全体シャッフルを避けられる。
誤り両方の表を必ず全シャッフルする
小表までネットワーク移動し、不要なコストと遅延が増える。
小表までネットワーク移動し、不要なコストと遅延が増える。
誤り小表をS3 Glacierへ移す
アーカイブはSpark結合のメモリ配置を改善しない。
アーカイブはSpark結合のメモリ配置を改善しない。
誤りLambdaで大表を1行ずつ結合する
分散処理を失い、実行制限に達する可能性がある。
分散処理を失い、実行制限に達する可能性がある。
実際に確かめる
一時的な検証環境で実行できる例です。
Apache Spark broadcast joins、Spark SQL autoBroadcastJoinThresholdの公式説明を確認する。期待される結果
broadcast joinとshuffle joinのメモリ・ネットワーク特性を説明できる。理解のポイント
- Broadcast join
- Shuffle
- Executor memory
- サイズ閾値
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 3・Task 3.2と各サービスの公式ドキュメントを確認する。
基礎のおさらい
適用条件
小表の実サイズ、Executor数、GC、データ偏りを測定する。
安全策
マスタが閾値を超えた場合に自動で別計画へ切り替わることを確認する。
問題IDAWS-DEA-203
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告