MLA機械学習のためのデータ準備
データサイエンスチームが Amazon S3 に Parquet 形式で格納された顧客行動ログ(累積 500GB、日次追加)から ML 用の特徴量候補を探索的に分析しています。特定のユーザーセグメントや期間でフィルタリングした集計クエリを対話的に実行し、Jupyter Notebook から結果を直接取得したいと考えています。専用クラスターを持たず、管理負荷とコストを最小化する最も適切な方法はどれですか。
AAmazon EMR クラスターを常時稼働させ、SageMaker Studio から Spark SQL で S3 上の Parquet に対してアドホッククエリを実行する
Amazon EMR は強力な Spark クラスターだが、クラスターの起動・設定・スケーリング・終了を管理する必要がある。専用クラスターを持たない環境で常時稼働させるとアドホッククエリのためだけに大きなコストが発生し、管理負荷最小化の要件に反する。
BAmazon Athena と AWS Glue データカタログで S3 上の Parquet を直接 SQL クエリし、boto3 経由で Notebook から対話的に結果を取得する
✓ 正解
Amazon Athena はサーバーレスでクラスター管理不要、S3 上の Parquet を直接 SQL クエリでき、boto3 経由で Notebook から対話的に結果を取得できる。スキャンデータ量の従量課金でコストを抑えられ、管理負荷とコストの最小化要件に最も適合する。
CS3 のデータを全件 Amazon Redshift クラスターにロードして集計クエリを実行し、結果を Jupyter Notebook に取り込む
Amazon Redshift はクラスターのプロビジョニング・管理が必要で、500GB の全データをロードするための ETL パイプライン構築にも時間とコストがかかる。探索的分析フェーズには初期投資が過大で管理負荷最小化に反する。
DAWS Glue ETL ジョブを都度実行して集計データを S3 に出力し、SageMaker Studio Notebook に CSV としてロードして分析する
AWS Glue ETL ジョブはバッチ処理向けであり、分析条件を変えるたびにジョブのスクリプト修正・再実行が必要になる。対話的なフィルタリング・集計クエリの繰り返し実行には適しておらず、生産性が低い。
解説
Amazon Athena はサーバーレスのインタラクティブクエリサービスで、S3 上の Parquet・CSV・JSON ファイルに対して標準 SQL を直接実行できる。AWS Glue データカタログでスキーマを管理し、クエリ結果は S3 に格納されて boto3 の Athena API(start_query_execution / get_query_results)を使って Jupyter Notebook から直接取得可能。スキャンしたデータ量の従量課金(1TB あたり約 5 ドル)で、クラスター管理は一切不要。
選択肢Aの Amazon EMR は強力な分散処理基盤だが、クラスターの起動・設定・スケーリング管理が必要で、アドホッククエリのために常時稼働させるとコストが大幅に増加する。
選択肢Cの Amazon Redshift は全件ロードのための ETL パイプラインとクラスター管理が必要であり、探索フェーズでは初期コストと管理負荷が過大になる。
選択肢Dの AWS Glue ETL ジョブはバッチ処理用途であり、フィルタ条件を変えるたびにジョブの修正・再実行が必要となるためインタラクティブな探索的分析には適していない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでMLAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →