WEB問題集
あるEC企業は、過去5年分のクリックストリームデータ（数TB、CSV形式）をS3に保存しています。データサイエンティストがAthenaで頻繁にユーザーIDと日付で集計クエリを実行しますが、スキャン量が多く料金が高騰しています。データ品質の劣化なくクエリコストとレイテンシを最小化する方法はどれですか。
解説
正解の根拠
Athena のスキャン量課金を最小化するには、列指向フォーマット (Parquet/ORC) への変換と、頻繁なフィルタ列でのパーティション分割が最も効果的です。CTAS (CREATE TABLE AS SELECT) 文を 1 回実行するだけで、Snappy 圧縮 Parquet＋年月日パーティションのテーブルを生成でき、列プルーニングとパーティションプルーニングの両方が効くため、クエリスキャン量を 90% 以上削減できます。
フォーマット別スキャン量比較
| 形式 | 圧縮 | 列プルーニング | 典型的削減率 |
|---|---|---|---|
| CSV | なし | 不可 | 0% |
| CSV+gzip | あり | 不可 | 70% |
| Parquet+Snappy | あり | 可 | 90% 以上 |
CTAS 例
CREATE TABLE clicks_parquet
WITH (format='PARQUET', parquet_compression='SNAPPY',
partitioned_by=ARRAY['year','month','day'],
external_location='s3://bucket/clicks_parquet/')
AS SELECT user_id, event, year, month, day FROM clicks_csv;不正解の理由
- A: スキーマ再検出やキャッシュではスキャン量自体は減らず、列指向化やパーティション化のような根本的なコスト最適化にはなりません。
- B: RDS へのロードは追加のインフラコストと運用負担が増える副作用があり、TB 級データの集計用途には設計目的が合致しません。
- C: S3 Select は 1 オブジェクト単位の絞り込みが目的で、Athena の集計クエリ全体のスキャン量削減という用途には適していません。
参考：Athena CTAS
あるヘルスケア企業は、患者データに含まれるPII（氏名・社会保障番号・電話番号など）を学習前にマスクする必要があります。GUI操作で機微情報を検出・変換し、データサイエンティストの工数を最小化したい場合、組み合わせとして最適なものはどれですか。
解説
正解の根拠
Amazon Macie は機械学習で PII/PHI を自動検出し、AWS Glue DataBrew はノーコード GUI でマスキングレシピ (ハッシュ化・置換・削除等) を構築できます。両者の組合せで GUI 操作主体・データサイエンティスト工数最小化を満たします。
役割
| サービス | 役割 |
|---|---|
| Macie | 機微検出 |
| DataBrew | GUI マスキング |
不正解の理由
- B: S3 Object Lambda はカスタムスクリプト前提で、GUI ノーコードでの匿名化要件と合わずデータサイエンティストの工数最小化に反します。
- C: Comprehend + Lambda はコード実装が必要となる副作用があり、GUI 操作で工数最小化したいというシナリオの要件を満たしません。
- D: Lake Formation のタグや Athena ビューの列除外は単純な閲覧制御で、PII を実体としてマスクする変換機能ではありません。
あるメーカーは、複数のオンプレミスNASに保存された100TBの製造画像データをS3に移行し、SageMakerで学習に利用したいと考えています。回線帯域は1Gbpsで、転送に1か月以上かけることは許容されません。最適な方法はどれですか。
解説
正解の根拠
1Gbps 回線では 100TB の転送に理論上約 9 日（実効帯域でさらに長期化）かかり、業務影響が大きいため、Snowball Edge Storage Optimized で物理デバイス輸送する方が早く確実です。1 台あたり 80TB 級の容量があり、複数台並列で 1 か月以内に完了できます。
データ移行手段の比較
| 手段 | 適合容量 | 所要時間 |
|---|---|---|
| DataSync | 〜数TB | 回線次第 |
| Snowball Edge | 数十TB/台 | 約1週間/台 |
| Snowmobile | PB級 | 数週間 |
| Storage Gateway | 段階的 | 常時同期 |
不正解の理由
- A: 1Gbps で 100TB を転送する方式は時間がかかりすぎ業務帯域も圧迫する副作用があり、1 か月以内の要件を満たしません。
- B: Storage Gateway は継続的なハイブリッド利用が目的のサービスで、一括大容量データ移行手段としては設計されていません。
- D: マルチパートアップロードでも回線帯域がボトルネックとなる副作用があり、物理輸送に比べて完了までの時間が長期化します。
参考：AWS Snowball
機械学習チームは、複数モデル間で再利用するためにユーザー特徴量（年齢・購買履歴集計など）を一元管理し、リアルタイム推論時には数十ミリ秒以内に取得し、学習時には時点整合の履歴を取得したいです。最適なサービスはどれですか。
解説
正解の根拠
SageMaker Feature Store はオンラインストア (低レイテンシ KV) とオフラインストア (S3 上の時点整合履歴) の両方を提供します。リアルタイム推論時は数十 ms 取得、学習時は時点整合の履歴取得が一サービスで実現できます。
Feature Store 構成
| ストア | 用途 |
|---|---|
| オンライン | 低遅延推論 |
| オフライン | 時点整合学習 |
不正解の理由
- A: Aurora Serverless v2 リードレプリカは RDB 用途で、Feature Store の時点整合履歴と低遅延 KV を統合する機能は提供しません。
- C: Redshift + ElastiCache の組合せは独自構築の副作用があり、Feature Store のような統合管理機能を自前で再実装する負荷が大きい構成です。
- D: DynamoDB + S3 スナップショットは時点整合の履歴管理を自前運用する副作用があり、Feature Store の標準機能を再実装する形になります。
データサイエンティストが日次バッチで生成されるS3上のJSONログに対して品質ルール（必須カラム存在、一意性、値域）を宣言的に記述しモニタリングしたいです。最も少ないコードで実装できるのはどれですか。
解説
正解の根拠
AWS Glue Data Quality は、宣言的な DSL である DQDL でルールを記述し、Glue ジョブやデータカタログテーブルに対し品質評価を行えます。マネージドのため最小コードでルール検査が可能で、結果は CloudWatch や EventBridge に連携できます。
DQDL 例
Rules = [
IsComplete "user_id",
Uniqueness "session_id" > 0.99,
ColumnValues "age" between 0 and 120
]主要選択肢比較
| サービス | コード量 | 運用 |
|---|---|---|
| Glue Data Quality | 少 | マネージド |
| Deequ on EMR | 多 | クラスタ管理要 |
| Lambda+Pydantic | 多 | 独自実装 |
不正解の理由
- D: Deequ は OSS で強力ですが EMR クラスタの構築運用が必要となる副作用があり、宣言的記述の最小コード要件には合致しません。
- A: Lambda 独自スクリプトは保守負荷が高く再利用性も低い副作用があり、宣言的なルール記述による最小コード要件には合いません。
- C: Macie は機微情報検出が目的のサービスで、品質ルールの宣言的評価とは設計目的が根本的に異なります。