データアナリティクス事業本部のコンサルティングチームの石川です。現在のG.1XとG.2Xに加え、AWS Glueの大規模インスタンスタイプG.4X および G.8Xが一般提供されたことをお知らせします。すでに東京リージョンでも利用可能です！
大規模インスタンスタイプG.4X および G.8Xとは
Glue G.4X および G.8X Workerは、G.1Xの Glue Workerのそれぞれ4倍、8倍の高いコンピューティング、メモリ、およびストレージリソースを提供します。なお、DPUとは、Data Processing Unitsの略で、東京リージョンでは１DPU/時が0.44USD(2023/05時点)です。
- G.4X Worker：ノードごとに 16 vCPU、64GBのメモリ、および 256GBのディスクを備えた4DPU
- G.8X Worker：ノードあたり 32 vCPU、128GBのメモリ、および 512GBのディスクを備えた8DPU
| AWS Glue Worker Type | ノードあたりの DPU | vCPU | メモリ (GB) | ディスク (GB) | ノードごとの Spark Executor の数 | Spark Executor ごとのコア数 |
|---|---|---|---|---|---|---|
| G.1X | 1 | 4 | 16 | 64 | 1 | 4 |
| G.2X | 2 | 8 | 32 | 128 | 1 | 8 |
| G.4X (New) | 4 | 16 | 64 | 256 | 1 | 16 |
| G.8X (New) | 8 | 32 | 128 | 512 | 1 | 32 |
G.4X および G.8Xの導入する何が嬉しいか？
これらの新しいWorker Typeは、メモリを大量に消費するデータ変換、偏った集計、機械学習変換、ペタバイト規模のデータによるエンティティ検出チェックなど、最も要求の厳しいデータ統合ワークロードを拡張して実行するのに有効です。
集計、結合、ユーザー定義関数 (UDF) を使用した独自のカスタム ロジックなどの一部の変換では、より大きなメモリフットプリントが消費されます。下記のブログでは、新しい G.4X Worker および G.8X Workerを使用すると、メモリやディスクを大量に消費する大規模な変換においても線形スケールする例が紹介されています。
どのように指定するのか？
Worker TypeをG.4XやG.8Xを選択するだけです。
最後に
join、groupByKey、reduceByKey、repartitionのようにシャッフルを引き起こす可能性のある大規模な変換では、データはディスクに書き込み、ネットワーク上で転送され、結果として利用可能なローカルディスクの容量やデータスキューによって制約を受けることが多く、Executorが混乱する原因になります。Sparkでは、Executorがディスク容量不足に陥り、回復できない場合、No space left on deviceまたはMetadataFetchFailedExceptionエラーをスローします。
このワークアラウンドとして、これまでは、--write-shuffle-files-to-s3や--write-shuffle-spills-to-s3 を有効にすることで、Spark のシャッフルおよびスピル データをS3に保存することで対処していました。当時、このアップデートは画期的で、今後も有効なワークアラウンドであることは変わりません。
しかし、線形スケールするには、インメモリやローカルディスクで処理することが望ましく、スケールアップ戦略するには、EMRの利用も検討する必要がありました。今回のアップデートでは、GlueのETLサービスに特化したビルトイン機能やETL関連機能を活かしつつ、より高いコンピューティング、メモリ、およびストレージリソースを利用できる、選択肢が広がるアップデートです。
0
