AWS分析サービスのシナリオ判断

売上、アクセスログ、クリックデータを扱う案件から、取込み・準備・分析・共有の役割を判断します。サービス選択だけでなく、スキャン量、件数、単位、権限の確認まで行います。

この単元で学ぶこと

分析の具体的な仕事へサービスを対応付ける
データ量と品質条件を検算する
連続取込みと共有の運用条件を評価する

本文解説

1. 既存ログの調査 S3に日付別のログがあり、一日だけエラー傾向を調べたいならAthenaのSQL分析が候補です。テーブル定義と実データの形式を合わせ、日付のパーティション条件を指定します。問い合わせの結果行数だけでは読み取った元データ量は分からないため、実際のスキャン量を確認します。

2. 読取り量の見積り一日10GBで同じ大きさの30日分があり、クエリが一日分だけを完全に選択できる前提なら、全量300GBに対して10GBを読みます。削減量は290GBです。これは説明用の条件付き計算であり、最低課金量や形式、別料金を無視して実請求まで同じ割合で減ると断定しません。

3. 構造だけ見つかった GlueクローラーによりCatalogへ列名が登録されたが、日付形式が複数混ざっている場合は変換を別に設計します。カタログの成功は入力が完全である証拠でもありません。実ファイルの数や内容を確認し、必要な入力が揃った時点でジョブを実行します。

4. 重複と単位を整える入力1000件に同じ注文の完全重複が100件あり、重複分だけ除外するなら900件が残ります。ただし訂正レコードや別の注文を重複と誤認しないよう定義します。円とドル、UTCと日本時間等の違いも変換規則へ反映し、処理成功だけでなく合計や件数を突き合わせます。

5. 継続的な統合分析店舗や販売チャネルを横断してSQL分析とBIを継続するなら、Redshift等のデータウェアハウスを比較します。AthenaもSQL分析ができるため、頻度や同時利用、処理量、運用を実測します。RedshiftにはServerlessや外部データの利用もあり、古い機能分類だけで候補を落としません。

6. 新着クリックを扱うクリックが次々に発生し、日次ファイルを待たず処理アプリへ届けたい場合はKinesis Data Streamsを検討します。取込み後に集計・保存する処理を用意し、後続の遅延や失敗を監視します。取込みが成功した時刻と、ダッシュボードへ反映された時刻を区別します。

7. 分析結果を共有する集計結果をQuick Sightへ接続し、部門別の指標をダッシュボードとして共有する例があります。見せる指標、データの更新頻度、利用者の権限を設定します。画面が更新されても入力データが昨日分のままなら最新とは限らないため、データの到着と表示の両方を確認します。

8. 全体を検証する担当サービスごとの成功だけでなく、入力から最終結果までデータが正しく流れるか検証します。元データと結果ファイル、Catalog、鍵、ダッシュボードの権限は別に確認します。必要な段階だけを構成し、各サービスの料金と失敗時の再実行・重複防止も計画へ含めます。

図解

クリック分析の成功を段階別に測る — 取込み成功だけで利用者の画面まで最新になったとは判断しません。

重要ポイント

スキャン量の計算には分割と選択の前提を明記する。
入力到着・変換・集計・表示の成功は別。
連続取込みとBI可視化を分けて設計する。

間違えやすい点

クローラー成功を全データ変換済みと考える。
グラフが更新された時刻だけでデータ鮮度を判断する。

用語解説

スキャン削減: 不要なデータを読まないようにして処理量を減らすこと。
データ品質: 必要な正確さ・完全さ・一貫性等を満たしているかという性質。
データ鮮度: 入力や更新がどの時点まで反映されているか。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。