通信会社のMLエンジニアは、Amazon S3に蓄積された60TBのネットワークログデータから解約予測モデル用の特徴量を週次バッチ処理で作成しています。
特徴量エンジニアリングには、セッション集計・スライディングウィンド

Question

通信会社のMLエンジニアは、Amazon S3に蓄積された60TBのネットワークログデータから解約予測モデル用の特徴量を週次バッチ処理で作成しています。
特徴量エンジニアリングには、セッション集計・スライディングウィンドウ関数・複数テーブルの結合を含む複雑なカスタムPySparkロジックが必要です。
コストを最小化しながらこの処理を実行するために最も適切な方法はどれか。

Accepted Answer

正解: Amazon EMRクラスターでマスターにオンデマンドインスタンス、コア・タスクノードにSpotインスタンスを使用してPySparkジョブを実行し、処理完了後にクラスターを自動終了する。Amazon EMRは、60TBの大規模データ処理に最適化されたフルマネージドHadoop/Sparkプラットフォームです。コアノードにSpotインスタンスを使用することでオンデマンドと比べて最大90%のコスト削減が可能で、週次バッチ処理のようなフォールトトレラントなワークロードに適しています。

マスターノードをオンデマンドで安定性を確保しつつ、処理完了後にクラスターを自動終了（Transient Cluster）することでアイドル時間のコストをゼロにできます。60TBのカスタムPySparkロジックのような大規模処理において、EMR Spotは最もコスト効率の高いSparkプラットフォームです。

選択肢AのSageMaker Processing JobのSparkコンテナは中規模処理（数TBまで）に適していますが、60TBに対してインスタンス台数とコストが最適化しにくく、EMR Spotと比較してコスト効率が劣ります。
選択肢BのAWS Glue ETLはサーバーレスで運用負荷が低いですが、DPU課金はEMR Spotより高コストになりやすく、60TBの大規模処理ではコスト面で不利です。
選択肢DのSageMaker Data WranglerのカスタムPySpark変換は小〜中規模の変換向けGUIツールで、60TBの複雑なカスタムロジックには処理性能とスケーラビリティが不十分です。

Answer

SageMaker Processing Jobのマネージド Sparkコンテナ（ml.m5.4xlarge × 20台）でPySparkスクリプトを実行し、ジョブ完了後インスタンスを自動停止させる — SageMaker Processing JobのSparkコンテナはマネージドSparkを提供しますが、60TBの大規模データ処理においてはEMR Spotインスタンスよりもコストパフォーマンスが低く、クラスター構成の柔軟性も制限されます。

Answer

AWS Glue ETLジョブのPySparkモードでロジックを実装し、ワーカータイプG.2Xのオートスケーリングを設定してジョブを実行する — AWS Glue ETLはサーバーレスで運用コストが低いですが、DPU単価はEMR Spotインスタンスより高く、60TBの大量データを週次処理する場合はEMRの方がコスト効率が高くなります。

Answer

SageMaker Data WranglerのカスタムPySpark変換でロジックを実装し、SageMaker Pipelinesでスケジュール管理してProcessing Jobとして週次実行する — SageMaker Data WranglerのカスタムPySpark変換はGUIベースの特徴量設計ツールで、60TB規模のカスタムSparkロジックに必要なクラスタースケールの処理性能とスケーラビリティを持ちません。

解説

解説