AWS分析サービスの違いと使い分け

この単元で学ぶこと

• 分析の各段階に合うサービスを区別する
• 問い合わせ方式を利用条件から比較する
• 連続データと可視化の役割を説明する

本文解説

1. 役割を基準に比べる 分析サービスを比較する時は、何をしたいかを動詞にします。連続レコードを「取り込む」、異なる形式を「整える」、SQLで「集計する」、図表で「伝える」は別の仕事です。一つのサービスの名前だけで全段階が自動完成するとは考えず、入力と出力を整理します。

2. 連続データの取込み Kinesis Data Streamsはアプリのログやクリック等の連続したレコードを取り込み、処理するアプリへ提供します。複数の処理アプリで集計と保存を分ける構成もあります。ストリームを作っただけで最終のグラフや永久保管が完成するわけではなく、利用する処理と保存先を設計します。

3. 準備とカタログ Glueでは構造を調べるクローラー、構造や場所を保存するData Catalog、データを変換するジョブを区別します。CSVをParquetへ変える処理と、その列の型をカタログへ記録する処理は別です。分析先が使える形へ整え、元の業務情報を正しく反映したかを検証します。

4. 必要時のSQL分析 AthenaはS3へ保存済みのデータ等をSQLで調べる場合に使いやすい選択肢です。調査対象をパーティション等で絞り、読み取る量と結果を確認します。ただし毎回同じ大量データを多数の利用者が問い合わせる場合等は、他の分析方式と実際の性能・費用を比較します。

5. 統合データウェアハウス Redshiftは継続的な統合分析の基盤として、SQLとBIツールを使います。ProvisionedとServerlessがあり、外部データを読む機能もあるため、AthenaだけがServerless・S3参照可能と分類しません。必要なデータ構造、頻度、同時利用、運用と費用から差を評価します。

6. ダッシュボードで示す Quick Sightはデータ源へ接続して可視化やBIを行い、ダッシュボードを共有する役割です。現行のAmazon Quickの一機能として提供され、試験や旧資料のQuickSight表記と対応します。表示対象の集計や更新間隔、見る利用者の権限も決め、グラフ化しただけでデータの正しさが保証されるとは考えません。

7. 鮮度と品質 日次ファイルの集計と、数秒単位で増えるクリックの分析では必要な更新の速さが違います。ストリーミングにすれば全ての遅延が0になるわけではなく、処理・保存・表示の各段階を確認します。重複や欠損、時刻の基準を整え、集計値と元データを突き合わせます。

8. 組合せの費用と保護 Kinesisで受けたレコードを処理してS3へ保存し、Glueで整えてAthenaやRedshiftで集計、Quick Sightで共有する例があります。全用途で五つを必須にせず、必要な役割だけ選びます。各段階の料金・権限・暗号鍵・保存期間と結果の共有範囲を一体で設計します。

図解

重要ポイント

• 取込み・準備・集計・可視化は別の役割。
• AthenaとRedshiftは機能が一部重なるため要件で比較する。
• 可視化にも鮮度と閲覧権限が必要。

間違えやすい点

• RedshiftにはServerlessも外部データ参照もないと分類する。
• ストリームを作ればダッシュボードが自動完成すると考える。

用語解説

Kinesis Data Streams

連続するレコードの取込みと処理アプリへの提供を行うサービス。

Quick Sight

データ源へ接続し図表・ダッシュボード等で分析するBI機能。

データパイプライン

取込み・準備・保存・分析等をつなぐ処理の流れ。

関連教材

• AWS分析サービスのシナリオ判断
• Glueを理解する
• 連携・顧客対応・アプリ配信の全体像
• Athenaを理解する
• Amazon SQSを理解する