SAP-C02-092 · 理解確認
Purpose-built Data / Analytics Serviceの選択
10問 · 1問ずつ確認
大規模なデータレイクにParquet形式のデータがAmazon S3へ保存されている。
分析担当者は月に数回、標準SQLでアドホック分析を行う。専用クラスターを常時稼働させたくない。
最も適切なサービスはどれか。
B. Amazon Redshift Serverlessへデータを継続的にロードし、専用のデータウェアハウスとして管理する
C. AWS Glueジョブで分析のたびに全データを別形式へ変換してから結果をS3へ出力する
D. Amazon EMR ServerlessでSparkアプリケーションを作成し、単発のSQL分析もすべてSparkで実行する
答えと解説
答え：A
要件は、
Amazon S3
+
アドホックSQL
+
インフラ管理不要なので、Amazon Athenaが最も直接的です。
複数のデータソースからデータを抽出・変換し、分析用のAmazon S3データレイクへ定期的に書き込む。
インフラストラクチャ管理を減らし、共通メタデータも管理したい。
最も適切なサービスはどれか。
B. AWS Glueでデータ統合ジョブを構築し、AWS Glue Data Catalogでメタデータを管理する
C. Amazon Redshift Serverlessへすべての生データを先にロードし、変換処理もデータウェアハウス内だけで行う
D. Amazon EMRクラスターを常時稼働し、管理負荷よりもクラスター制御を優先してETLを実行する
答えと解説
答え：B
決定条件は、
データ統合
+
ETL
+
メタデータ
+
サーバーレスです。
既存の分析基盤ではApache SparkとApache Hadoopの複数フレームワークを使用し、クラスター設定やオープンソースコンポーネントを細かく制御する必要がある。
大規模なバッチ処理をAWSへ移行したい。
最も適切なサービスはどれか。
B. Amazon Athena。S3上の入力データへSQLを実行し、既存のSpark・Hadoop処理はSQLへ全面移行する
C. Amazon EMR。SparkやHadoopなどのビッグデータフレームワークとクラスター設定を活用して処理する
D. Amazon Redshift Serverless。既存の分散処理をデータウェアハウスSQLへ移行してフレームワークを不要にする
答えと解説
答え：C
このシナリオでは、
Spark / Hadoop
+
フレームワーク制御が決定条件です。
多数のBI利用者が日常的に複雑なSQL集計や結合を繰り返す。
分析用データをデータウェアハウスとして管理し、反復的な分析へ高い性能を提供したい。
最も適切なサービスはどれか。
B. AWS Glue。ETLジョブを実行するサービスを利用者向けの反復BIクエリエンジンとして使用する
C. Amazon EMR。SparkジョブをBIツールの各SQL要求ごとに起動し、データウェアハウスの役割を置き換える
D. Amazon Redshift。反復的なBI分析とデータウェアハウス処理を中心に、分析用データを最適化して提供する
答えと解説
答え：D
決定条件は、
データウェアハウス
+
継続的なBI
+
反復SQL分析です。
IoTイベントをリアルタイムで取り込み、異常検知、リアルタイムダッシュボード、長期保存という複数の処理が同じイベントを独立して利用する。
一定期間はイベントを再処理できる必要もある。
最も適切なサービスはどれか。
B. Amazon Data Firehose。イベントをAmazon S3へ集約して保存し、各処理は配信後のS3オブジェクトを利用する
C. Amazon Managed Service for Apache Flink。1つのストリーム処理アプリケーションで異常検知・集計・保存用出力をまとめて実装する
D. Amazon Data Firehoseを複数作成し、異常検知・ダッシュボード・長期保存の各配信経路へ個別にデータを送る
答えと解説
答え：A
B・Dは保存や複数配信先には対応できますが、
同じストリームを保持
+
独立した複数コンシューマー
+
保持期間内の再処理という要件にはKinesis Data Streamsが適します。
アプリケーションログを継続的に受信し、複雑な独自ストリーム処理は行わずAmazon S3へ配信したい。
配信処理用の独自コンシューマーやインフラストラクチャの管理を最小化したい。
最も適切なサービスはどれか。
B. Amazon MSKを使用し、Kafkaクラスターとコンシューマーを構築して単一のS3配信経路だけを管理する
C. Amazon Managed Service for Apache Flinkを使用し、状態を持つストリーム処理アプリケーションからS3への単純配信を実装する
D. Amazon Data Firehoseを使用し、受信したストリーミングデータを設定した配信先へマネージドに届ける
答えと解説
答え：D
この場合は、
ストリーム処理そのものより、
マネージド配信が主な要件です。
オンプレミスで多数のApache Kafkaプロデューサーとコンシューマーを運用している。
アプリケーション側のKafka APIや既存クライアントをできるだけ維持しながら、AWSへ移行してブローカー運用の負担を減らしたい。
最も適切なサービスはどれか。
B. Amazon MSKを使用し、Apache Kafka互換のマネージド基盤で既存アプリケーションを活用する
C. Amazon Data Firehoseを利用してKafkaからデータを受信し、既存コンシューマーはS3などの配信先を読む方式へ変更する
D. Amazon Managed Service for Apache FlinkでKafkaストリームを処理し、既存コンシューマーの処理ロジックをFlinkジョブへ統合する
答えと解説
答え：B
A・C・Dも移行方式としては考えられますが、
Kafka API
+
既存Kafkaクライアント
+
変更を最小化という決定条件を最も直接満たすのはAmazon MSKです。
継続的に到着する取引イベントに対して、5分間の時間ウィンドウ、イベント間の状態を保持した集計、複数ストリームの結合をリアルタイムで実行したい。
最も適切なサービスはどれか。
B. Amazon Kinesis Data Streamsでイベントを保持し、状態を持つ時間ウィンドウ集計は各コンシューマー側で独自実装する
C. Amazon Managed Service for Apache Flinkで、時間ウィンドウ・状態管理・ストリーム結合を継続実行する
D. Amazon Data Firehoseでイベントをバッファリングし、配信先へ届いたデータを小さな単位で繰り返し集計する
答えと解説
答え：C
他の選択肢もストリーミングデータを扱えますが、
時間ウィンドウ
+
状態管理
+
ストリーム結合をリアルタイム処理の中心要件とするなら、Managed Service for Apache Flinkが最も適します。
Amazon S3を中心とするデータレイクで、複数の分析サービスから共通データへアクセスする。
テーブル・列・行などのきめ細かな権限を中央で管理したい。
最も適切なサービスはどれか。
B. AWS Glue Data Catalogだけを利用し、データアクセス権限は各分析サービスで個別に管理する
C. Amazon Athenaのワークグループだけを利用し、S3データと全分析サービスの行・列権限を統一管理する
D. Amazon Redshiftのデータ共有だけを利用し、S3データレイク全体のアクセス権限を一元管理する
答えと解説
答え：A
ここで必要なのは、
クエリではなく、
データレイクのガバナンスです。
Amazon S3上のデータセットを複数の分析担当者が共有する。
スキーマやパーティション情報を共通メタデータとして管理し、そのデータをサーバーレスに標準SQLで調査したい。
最も適切な組み合わせはどれか。
B. AWS Glueジョブで全データをAmazon Redshiftへロードし、単発の調査クエリも必ずウェアハウスから実行する
C. AWS Lake Formationだけを使用し、クエリエンジンを用意せずLake Formation自身でSQLを実行する
D. AWS Glue Data CatalogでS3データのメタデータを管理し、Amazon AthenaからそのデータをSQLで分析する
答えと解説
答え：D
この構成では、
メタデータ
→ AWS Glue Data Catalog
クエリ
→ Amazon Athenaと責任を分けます。