MLS-1.3データ変換ソリューションの特定と実装。
採点する
14問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数14
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- MLS-1.3データ変換ソリューションの特定と実装。 0%
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 14
1. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-18】FinTech 企業はクリックストリームを約 500 GB/日、Gzip 圧縮 JSON で Amazon S3 に保存し、Athena で BI ダッシュボードを更新しています。
スキャン量が多く 1 日あたり 600 USD のクエリ料金が発生し、平均応答時間も 20 秒に達しています。
今後は
①ダッシュボードを 5 秒以内で更新
②クエリコストを 80% 以上削減
③追加運用は最小化―という要件を満たす最も適切なアーキテクチャはどれですか。正解不正解ヒントボタン
Amazon Athena で Gzip JSON を直接クエリすると列を絞っても全行を読み込むため課金が膨らみます。AWS Glue などで列指向の Parquet に Snappy 圧縮すれば I/O は 1/10 まで減り、スキャンコストと応答が大幅に改善します。さらに S3 を event_date や user_id でパーティション分割し Data Catalog に登録しておくと、必要ファイルだけを読むので BI ダッシュボード更新が数秒に短縮できます。
サーバーレスで運用を簡素化したい場合は Amazon S3 の PUT 通知から AWS Glue ETL ジョブを自動起動し、変換後に Glue Data Catalog へパーティションを追加する流れが有効です。EMR や Redshift のようにクラスターを立ち上げたりパッチを当てたりする必要がなく、500 GB/日規模でもスケーリングはマネージドに任せられます。CloudWatch Logs と EventBridge を併用すれば監視・再試行も自動化でき、追加運用はほぼ不要です。
高性能な Amazon EMR や Amazon Redshift を常時稼働させるとインスタンス時間やストレージの固定費が発生し、Athena のスキャン費を 80% 以上下げるという目標には適合しにくいです。Athena を活かした Parquet ＋ パーティション構成なら、課金は読み込む分のみで列指向の高速処理が可能となり 5 秒以内のダッシュボード更新も現実的です。コスト削減・性能・運用の三要件を横断的に評価し、最もバランスが取れた仕組みかを総合判断しましょう。 -
質問 2 of 14
2. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-19】多国籍ゲーム会社は、世界中のクライアントから毎秒 50 MB のプレイログを収集している。
5 秒以内に
①不正行為判定、
②DynamoDB に保管されたプレイヤーメタデータでのリッチ化、
③SQL で同時接続数を集計しダッシュボードへ配信する必要がある。
中間ストレージは禁止され、運用負荷とコストは最小化したい。
この要件を最も満たすアーキテクチャはどれか。正解不正解ヒントボタン
50 MB/秒ものログを5 秒以内で処理するには、Kinesis Data Streams で取り込んだデータを Kinesis Data Analytics の SQL ウィンドウ関数で直接不正判定や同時接続数集計にかけ、Lambda UDF を経由して DynamoDB メタデータを参照する一筆書きのストリーム処理にすると、1 秒幅ウィンドウでも安定して遅延を抑えられフルマネージドで保守も軽く済みます。
「中間ストレージは禁止」という制約下では、Kinesis Data Firehose→S3、あるいは DynamoDB→Glue→Athena といった経路はバッファリングやフルスキャンが避けられずレイテンシーが数十秒以上になりがちで、保存容量の管理も発生するため「5 秒以内」と「運用負荷最小化」の両立が難しくなることを思い出してください。
自己運用が前提の EMR Spark Streaming や Presto クラスター、さらには Amazon SQS を高スループットで使い続ける案はスケール調整・パッチ適用・可視性タイムアウト調整など多面的な管理が必要となりコストも増えます。複数要件を俯瞰した総合判断として、リアルタイム性・制約遵守・保守容易性を同時に満たすフルマネージドのストリーミング処理を選ぶ視点が鍵です。
-
質問 3 of 14
3. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-20】動画配信企業は S3 バケットに 1 日 5 TB の JSON クリックストリームを蓄積し、Athena で直近 90 日を分析している。
1 回のクエリで 100–200 GB をスキャンするため費用が増大している。
要件は
①スキャン量を 1/10 以下に削減、
②データ到着後 15 分以内にクエリ可能、
③インフラ運用を最小化しスキーマ変更へ自動追従、
④EC2 管理を回避である。
最適なアプローチはどれか。正解不正解ヒントボタン
列指向フォーマットの Parquet や ORC に変換し、さらに dt=yyyy/MM/dd のような日付パーティションを付与して Amazon Athena でクエリすると、Snappy 圧縮と列プルーニングの相乗効果で JSON を直接読む場合よりスキャン量と課金がおよそ 1/10 に圧縮できます。変換処理を継続的に走らせ、カタログに正しいパーティションを登録し続ける仕組みをまず検討してください。
到着後 15 分以内に分析したい場合、S3 ObjectCreated イベントで即時起動できる AWS Glue ジョブや、バッファ間隔を 900 秒に設定した Kinesis Data Firehose など、サーバーレスで短周期の ETL を自動実行する選択肢が有効です。対照的に日次バッチを前提とした Amazon EMR 常時稼働は遅延と運用コストの面で要件に合いづらい点を意識しましょう。
長期運用では Glue Crawler による Data Catalog の自動更新でスキーマ変更やパーティション追加を無人化し、Redshift クラスターや EC2 ノードの保守を不要とする構成が望まれます。クエリコスト削減、15 分以内の可用性、スキーマ追従、自動運用の四つの要件を総合的に満たせるサーバーレスアーキテクチャを選びましょう。
-
質問 4 of 14
4. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-21】国内大手EC企業は、1日あたり4 TBのクリックストリームをAmazon S3にCSV形式で蓄積している。
SageMaker組み込みXGBoostで毎晩1時間以内にモデルを再学習する必要がある。
トレーニングインスタンスのEBS容量は最小限にし、データ読込待ち時間も極力短縮したい。
最新のAWSベストプラクティスに基づき、最適なデータ変換とI/O処理の組み合わせを選択せよ。正解不正解ヒントボタン
毎日蓄積される 4 TB を Amazon S3 から学習ノードへ全部コピーすると、スピードとコスト面で EBS がボトルネックになります。SageMaker の Pipe モードは S3 からコンテナへデータをストリーミング送信しながら学習を進めるため、転送完了待ちが不要です。I/O 待機が削減され、EBS を数十 GB 程度に抑えても 1 時間以内の再学習という制約を満たしやすくなります。
SageMaker 組み込み XGBoost コンテナが扱える入力は CSV か LibSVM を RecordIO-protobuf にパッケージしたものが推奨格式です。Pipe モードではこのバイナリ形式が最も高効率で、メッセージ境界が明確なためスループットが大きく伸びます。Parquet のような列指向ファイルは機械学習用の入力としては直接読めず追加変換が要るので、変換・I/O 両面で余計な遅延を生みます。
ETL を自動化するならサーバーレスでスケーラブルな AWS Glue を使い、CSV を RecordIO-protobuf へ変換しつつ Amazon S3 のプレフィックス単位で数百 MB 程度にシャーディングしておくと、SageMaker Pipe モードが複数スレッドで均等にチャンクを取得でき帯域を使い切れます。Storage, Throughput, 運用、ベストプラクティスを総合評価すると、この組み合わせが最も要件にフィットします。 -
質問 5 of 14
5. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-22】国内EC企業は顧客マスタを日次で S3 に CSV 形式で集約しているが、複数システム由来の表記揺れにより氏名・住所の重複が 10％ 以上発生しレコメンド精度が低下している。
開発チームは Spark 経験が乏しく、SQL の厳密一致だけでは対応できない。
週次で約 10 GB を処理し、コストを抑えつつ運用負荷を最小化したい。
最も適切な重複排除パイプライン構成はどれか。正解不正解 -
質問 6 of 14
6. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-23】ある EC 企業は、1 日あたり 500 GB の JSON 形式クリックストリームを S3 に蓄積している。
学習用データは user_id と日付でパーティション化された Parquet とし、到着後 2 時間以内に変換を完了させたい。
運用チームはサーバーレスで自動スケールし、アイドルコストやインフラ管理を最小化したい。
さらにスキーマ進化を自動検知し、Athena から即時にクエリ可能な Data Catalog を保ちたい。
これらの要件を最も満たす ETL アーキテクチャはどれか。正解不正解ヒントボタン
1. 1日500GBのJSONを到着後2時間以内にParquetへ集約するには、実行ごとに並列度を自動調整しSparkをフル活用できる仕組みが鍵です。EC2ベースのAmazon EMRやコンテナ起動型のAWS Batch on Fargateはクラスター管理やアイドル課金が残りますが、S3のPUTイベントで即座に開始できDPUオートスケーリングで秒単位に拡縮するAWS Glueジョブなら、ジョブ終了と同時に課金も止まりサーバーレスの利点を最大化しつつ目標時間を守りやすくなります。
2. Athenaで変換直後に分析したい場合、ETL内でGlue Data Catalogへパーティションとスキーマを自動反映できるかがポイントです。Glueクローラの定期走行や手動のMSCK REPAIR・ALTER TABLEでは数十分のギャップが残りますが、DynamicFrameでcatalogUpdateを有効化したAWS Glueジョブなら列追加もuser_idと日付のパーティション追加も即時登録され、スキーマ進化にも自動追従するためクエリの待ち時間を最小化できます。
3. パーティションを自由に切りたい要件はKinesis Data Firehoseの時間基準パスでは難しく、常時起動型EMRはアイドルコスト、Fargate上のSparkは水平分散の制限という弱点があります。到着イベントでトリガーし、サーバーレスで自動スケールし、ジョブ内でカタログ更新とスキーマ検知を完結できるAWS Glueのアプローチがこれら複数要件を俯瞰した総合判断として最も合理的です。
-
質問 7 of 14
7. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-24】オンライン広告企業は 1 日あたり約 4 TB のクリックログ (JSON) を Amazon S3 に保存している。
翌朝の Amazon SageMaker トレーニングでスキャン量を最小化するため、圧縮 Parquet 形式へ変換し dt=YYYY-MM-DD でパーティションを切り、Glue Data Catalog へ自動登録したい。
スキーマ進化への追従とジョブ運用負荷を最小化しつつコスト効率も確保する方法はどれか。正解不正解ヒントボタン
S3 に新規オブジェクトが置かれた瞬間に処理が走れば、夜間バッチのスケジュールやクラスター起動停止を考えずに済みます。S3 イベント通知で AWS Glue ジョブをサーバレス起動すれば、PySpark の DynamicFrame が JSON スキーマを自動推論し、列追加などのスキーマ進化にも追随して Parquet(SNAPPY) を dt=YYYY-MM-DD で分割出力し、そのまま Glue Data Catalog を更新できます。Athena や SageMaker が翌朝読むときはパーティションプルーニングでスキャン量と I/O コストが大幅に削減されます。
初期コストだけを見ると Spot インスタンスの EMR クラスターを夜間だけ立ち上げ Hive で変換する方法も安価に感じますが、メタストアと Glue Data Catalog の同期、クラスターのバージョン管理、起動と終了の失敗対応などで運用負荷が増大します。対して Glue ワーカーは冗長化やパッチ適用を AWS が担う完全マネージドで、DynamicFrame がスキーマ変更を自動吸収するためジョブコードに集中でき、日次 4 TB 規模でもオートスケールで安定して処理できます。
pandas を使う Batch コンテナはメモリ内処理で 4 TB をさばくには分散実装が別途必要になり、Data Pipeline＋EC2 ではインスタンス運用が発生します。Parquet と Snappy 圧縮、dt パーティション、Data Catalog 自動連携、サーバレストリガー、スキーマ進化追随という複数要件を総合的に満たす構成を選ぶことがコスト効率と保守性を両立させる鍵です。
-
質問 8 of 14
8. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-25】国内EC企業A社は、3 つのレガシー CRM から毎日最大 200 万行 (約 3 TB) の顧客 CSV を Amazon S3 に集約している。
氏名や住所の表記ゆれにより月次で約 15 % の重複が発生するため、マーケティング分析用に 95 % 以上の一致精度で類似レコードを自動識別し、結果を Amazon Redshift にロードしたい。
運用チームは PySpark の詳細実装に時間を割けず、Glue ジョブの定期実行のみで完結させることを求めている。
サンプル教師データの作成はデータサイエンティストが対応し、モデルの再学習は四半期ごとに行う予定である。
要件を最も満たす実装はどれか。正解不正解ヒントボタン
エンティティレゾリューションを高精度で行うには、Amazon S3 に置いた CSV を取り込みながら AWS Glue の FindMatches ML トランスフォームを使う方法が効率的です。ラベル付きサンプルを用意すると Glue が教師あり学習モデルを自動生成し、EstimateQuality アクションで検証しつつ Precision や Recall の目標値をコンソールで調整できるため、氏名や住所の表記ゆれがあっても 95 ％ 以上の一致精度を狙えます。
運用チームが PySpark コードに深入りできないという条件では、Amazon EMR で UDF を実装したり、Amazon Comprehend を API 連携させたりすると、クラスター構築やネットワーク制御、レイテンシ管理など追加作業が多く発生します。対して AWS Glue ジョブはマネージドでスケジュール設定のみ行えば毎日 3 TB ものデータをサーバレスで処理でき、四半期ごとの再学習もモデルバージョンを切り替えるだけで済むため、最小限の運用負荷に適合します。
要件は「サンプル教師データの利用」「95 ％ 以上の類似判定精度」「PySpark 実装を避け Glue ジョブだけで完結」「四半期ごとの再学習」「Redshift へのロード」の五点です。Amazon S3 を起点にデータを読込み、Glue の FindMatches でモデル更新と重複検出を自動化し、DynamicFrame から Amazon Redshift へ書き込む流れが、精度・運用・拡張性すべてを満たす総合的にバランスの取れた選択となります。 -
質問 9 of 14
9. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-26】決済系スタートアップは、
①オンプレ MySQL から AWS DMS で `s3://raw/mysql/` に 5 分毎に吐き出される 100 GB/日の CSV、
②Kinesis Data Firehose で `s3://raw/click/` に書き込まれる 100 GB/日の JSON を統合し、毎晩 02:00 までに結合・正規化・重複排除した Parquet を `s3://ml/train/` に日付パーティションで出力したい。
運用者は 2 名のみでサーバを管理したくない。
処理時間は 30 分以内、将来の増量に備え水平スケール可能であることが求められる。
最も適切なアーキテクチャはどれか。正解不正解ヒントボタン
運用者が 2 名だけでサーバを管理したくないという条件では、AWS Glue や Lambda などのサーバレスが候補になりますが、1 日 200 GB を 30 分以内に処理するには Spark 互換の分散実行基盤が必要です。Glue は DPU を増やすだけで水平スケールでき、起動も数十秒、EMR のクラスタ起動時間や m5 インスタンスの管理、Lambda の 15 分制限や並列オーケストレーションより運用負荷が大幅に低減できます。
S3 に 5 分おきで追加される CSV と JSON を毎晩 02:00 までに差分取り込みしたい場合、Glue クローラで `s3://raw/mysql/` と `s3://raw/click/` のスキーマをカタログ化し、ジョブブックマークを有効にすれば前回ジョブ以降の増分だけを読み込み可能です。ワークフローのスケジューラで 01:30 に自動実行させればバッファも確保でき、手動終了やバッチファイル管理から解放されます。
Glue DynamicFrame は CSV と JSON を型付けしながら結合でき、出力を Parquet 列指向形式にし日付パーティションで `s3://ml/train/` に保存すれば Athena や SageMaker が高速かつ低コストに参照できます。DMS と Kinesis Firehose で蓄積した生データをサーバレスで統合し、水平スケール・30 分完了・自動スケジュール・Parquet 出力という全要件を一挙に満たせる構成を選ぶのが総合的に合理的です。
-
質問 10 of 14
10. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-27】動画配信サービス企業は、毎秒平均30,000件の視聴イベントを収集している。
各レコードにユーザーのリージョンIDを付与した上で、1分以内にParquet形式でAmazon S3へ格納し、Amazon Redshift Spectrumから即時分析可能としたい。
追加要件は以下のとおり。
・イベント到達順序を維持する
・変換ロジックはPythonで週1回更新
・サーバー運用は最小化し自動スケーリングを利用
・失敗レコードは5分以内に再処理し、メトリクスとアラームで通知
・将来、圧縮方式や出力先の追加を容易に変更できる
この要件を最も効率的かつ運用負荷を抑えて満たすアーキテクチャはどれか。正解不正解ヒントボタン
毎秒3万件のストリームを到達順序のまま1分以内に Amazon S3 へ流し込みたいときは、シャードやブローカー数を気にせず自動スケールし、バッファした順に書き込みまで行える完全マネージドの Amazon Kinesis Data Firehose を軸に据えると運用負荷と順序崩れを同時に抑えられ、バッファ時間を60秒に設定するだけでファイル生成のSLAも満たせます。
変換ロジックを Python で週1回差し替えるなら、デリバリーストリームに組み込める AWS Lambda 変換機能を利用するとサーバー管理もパッケージ更新も不要で、Parquet＋Snappy 形式の出力は設定変更だけ、失敗レコードは Amazon CloudWatch Metrics に自動記録されるので5分以内の再処理やアラーム設定もクリック操作で済みます。
スループット、順序保持、自動スケーリング、Parquet 出力、再試行監視、将来の柔軟性を横並びで評価すると、クラスタ運用やシャード管理を背負わず単一設定でこれらを網羅し CloudWatch まで統合されている Amazon Kinesis Data Firehose が最もバランス良く複数要件を満たすとの総合判断になります。 -
質問 11 of 14
11. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-28】金融SaaS企業は 1 レコード平均 2 KB の JSON イベントを最大毎秒 5 万件受信している。
要件は次のとおり。
1) 受信から 60 秒以内にユーザ ID ごとの 1 分移動平均を算出し BI ダッシュボードへ配信する。
2) 集計結果と生データの双方を Apache Parquet＋GZIP に変換して S3 に蓄積し、Athena で日次分析を行う。
3) ストリーム処理はフルマネージドサービスを優先し、運用工数とコストを最小化する。
これらの要件を最も効率的に満たすストリーミング ETL 構成はどれか。正解不正解ヒントボタン
毎秒5万件を60秒以内にユーザIDごとの移動平均へ変換するには、Kinesis Data Streamsで受信したストリームをステートフルにウィンドウ処理できるKinesis Data AnalyticsのSQLアプリが王道で、数行のSQLで1分平均を計算しつつ自動スケールとCloudWatch監視が標準装備のため運用負荷が小さく、シャードを増やすだけでスループットを上げられるのでDynamoDBなどへ状態を逃がす追加設計も不要でレイテンシ要件を楽々クリアできます。
集計結果と生データをAthenaで効率分析するにはParquet＋GZIPが最適ですが、Kinesis Data FirehoseはS3配信時にこの変換と圧縮をボタン一つで有効化でき、バッファサイズ設定だけでファイル整形も自動化してくれるためGlueジョブやLambda変換のコード保守や高頻度呼び出しコストを避けられ、さらに1本の配信ストリームで集計後データと生データを同時に保存できるため要件2をシンプルに満たします。
リアルタイム60秒以内の可視化、Parquet圧縮によるストレージ最適化、フルマネージドでの運用最小化という複数要件を俯瞰すると、取り込みをKinesis Data Streams、ウィンドウ集計をKinesis Data Analytics、フォーマット変換とS3書き込みをKinesis Data Firehoseに分担させる構成が技術適合性とコスト効率の両面で最も合理的という総合判断になります。
-
質問 12 of 14
12. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-29】大手フードデリバリー企業は、毎秒10,000件・平均2 KBの注文CSVレコードを取り込み、RPO 0 秒かつ RTO 1 分以内で Athena から分析できる特徴量ストアを構築したい。
データは S3 に 1 時間単位で区切った Parquet 列指向形式で保存し、コストと運用負荷を最小化する必要がある。
最も適切なストリーミング変換基盤を選択せよ。正解不正解ヒントボタン
毎秒1万件・合計20MBの注文を途切れなく取り込みつつ即分析したい場合、Kinesis Data Streams のシャード並列処理に AWS Glue ストリーミング ETL を接続しチェックポイントを有効化することで、Spark Structured Streaming が CSV を Parquet へ変換し S3 の時間パーティションへ Exactly-Once 出力でき、Athena が数十秒後にはクエリ可能になるため RPO 0 秒と RTO 1 分を自然に満たしやすいです。
Kinesis Data Firehose は Lambda 変換を挟むと 128MB または 15 分バッファで遅延が生じ、SQS FIFO は 300 メッセージ/秒上限でスループットが足りず、Amazon MSK＋Spark 自己運用はブローカーや EBS、cron 同期の管理コストが増大しますので、ほぼリアルタイム配信と運用負荷最小という要件とのギャップを意識して比較してください。
スループット拡張性、数秒レイテンシ、Parquet 変換の容易さ、Exactly-Once 処理、マネージド度、費用対効果を俯瞰すると、Streams と Glue Streaming の組み合わせだけが全評価軸をバランス良く充足し、他案はいずれかの軸で大きく要件を外れるという総合判断に至ります。 -
質問 13 of 14
13. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-30】製薬企業A社はAmazon Redshiftの売上テーブル（5,000万行、日次増分30 GB）を、毎日02:00にAmazon S3データレイクへParquet形式かつdateパーティションで保存し、Glue Data Catalogへ自動登録したい。
処理は2時間以内に完了し、クラスター負荷を最小化するためlast_update列による差分抽出が必須である。
RPOは24時間、GUIから失敗時の再実行が容易であることも求められる。
最も効率的なAWS Glueの構成はどれか。正解不正解ヒントボタン
Redshift テーブルから last_update 列を基に増分だけを取得しクラスター I/O を抑えるには、AWS Glue の Amazon Redshift ネイティブコネクタにジョブブックマークと Push-down predicate を併用し、前回処理済みタイムスタンプを自動管理しつつ Secrets Manager で認証情報のローテーションも任せる構成が最もシンプルかつ高速です。
1日 30 GB 程度の増分を 2 時間以内に Parquet へ変換して S3 に保存するには Glue Spark ジョブで DynamicFrame を分散処理させながら date パーティション列を付与し、書き出し時に Glue Data Catalog を自動更新することで変換・登録を一気に完結させる方法が現実的です。
02:00 の定期実行や失敗時の GUI からのワンクリック再実行を考えるなら Glue ワークフローを EventBridge の cron ルールで起動して可視化し、Athena 連携や Data Pipeline など複数サービスに跨る運用を避けて単一コンソールで監視とリトライを完結させると RPO 24 時間の担保が容易になります。
性能要件（増分抽出・2 時間以内）と運用要件（低負荷・自動カタログ・定時起動・簡易リトライ）を俯瞰すると、Glue ネイティブコネクタ＋ジョブブックマーク＋Spark 分散処理に EventBridge スケジューラを組み合わせたパターンがサービス間の機能とコストのバランスを最も高い水準で満たします。 -
質問 14 of 14
14. 質問
カテゴリ: MLS-1.3データ変換ソリューションの特定と実装。【MLS-31】企業Aは1時間あたり約10 GBのGzip圧縮JSONクリックログをAmazon S3に格納している。
要件:
・ログ到着から15 分以内にAthenaで分析可能にする
・列指向形式へ変換し日/時パーティションで保存する
・変換コストと運用負荷を最小化する
・メタデータはAWS Glue Data Catalogへ自動登録する
最適なETL実装はどれか。正解不正解ヒントボタン
到着後15分以内にAthenaで検索できることが最優先なので、S3にファイルが置かれた瞬間に処理が始まるイベント駆動が適しています。AWS Glueジョブはサーバレスで数秒で立ち上がりますが、Amazon EMRやAWS Batchはコンピュート資源の確保に数分かかることがあります。さらに毎時間クラスターを起動・停止する方式は準備のオーバーヘッドだけで遅延とコストを増やしがちです。すでにGzip JSONがS3に到着する前提では、S3イベントを直接トリガーにして計算時間だけ課金される形態が鍵になります。どのサービスがこの条件を満たすかを考えてみましょう。
列指向フォーマットのParquetやORCはAthenaのスキャン量を大幅に削減でき、Snappy圧縮を併用すればストレージ料金も節約できます。Glue DynamicFrameは書き込み時に年/月/日/時といったパスを動的に生成し、Glue Data Catalogにパーティションメタデータを即時反映できるためCrawlerを別に走らせる必要がありません。PySparkでETLを組むと数十行のコードで完結し保守も容易です。1時間あたり10GB程度ならデフォルトDPUでも数分で変換が終わるため、15分のSLAを十分にクリアできます。
運用負荷とコストを最小化するには、EC2やAuto Scaling、Data Pipelineなど複数サービスを組み合わせるより、S3 Putイベント→Glue ETL→Snappy Parquet→Athenaという単純なパスが有効です。ジョブ実行時のみ課金され、監視やIAM設定もシンプルです。AthenaのCTASを都度実行して変換する手法はクエリ時に全行を読み込み料金が高騰し、即時分析性も損ないます。遅延、コスト、保守性を総合的に比較したうえで、もっともサーバレスで自動化度が高い選択肢を選びましょう。
改善リクエスト