Athenaを理解する

この単元で学ぶこと

• S3データへのSQL分析の流れを説明する
• パーティション等とスキャン量の関係を理解する
• アクセス権と費用・結果の管理を判断する

本文解説

1. S3へ置いたデータを読む Athenaは標準SQLでデータを問い合わせる分析サービスです。例えばS3に保存した日別アクセスログから特定日のエラー数を数えます。利用者が問合せ用サーバーのOSを管理せず利用できます。現行にはSparkや他のデータへの接続機能もありますが、ここではS3のSQLクエリを基本例とします。

2. テーブルの定義 CSVやParquet等のファイルを解釈するには、列、型、場所、形式等の情報が必要です。Glue Data Catalogのテーブル定義等を使い、実際のデータと一致させます。テーブルを定義したことだけでS3原本が別の場所へコピーされたり、形式が自動変換されたりするわけではありません。

3. SQLとデータの意味 エラー数を調べるなら、対象期間、エラーとみなすコード、重複の扱いをSQL等で指定します。結果が返っても期間の指定や時刻の基準を間違えると業務上の答えは違います。タイムゾーンや欠損、データ到着の遅れも確認し、実行成功だけで分析完了とはしません。

4. パーティションで絞る 日付等でデータを分割し、クエリが必要なパーティションだけを読むようにすると、スキャン量を減らせます。例えば同じ量の日別データが30日分あり一日だけ読むなら、理想的に他の日を除外できる条件では対象は30分の1です。分割しただけで全クエリが自動で一日分になるわけではなく、条件と配置を合わせます。

5. 形式と列の選択 Parquet等の列指向形式や圧縮を適切に使うと、読む量を減らす効果があります。必要な列だけを指定し、どのデータが実際に読まれたか確認します。返された行数が少なくても、元の広い範囲をスキャンしている場合があるため、結果の大きさと処理した量を同一視しません。

6. 料金方式の確認 SQLのスキャン量に基づく料金では、読み取る量を減らす工夫が費用に関係します。ただしAthenaには容量ベースの方式やSpark等もあるため、全利用を一つの料金式へ固定しません。S3の保存・要求、Glue等の関連料金も確認し、数値の見積りでは選択方式と仮定を明記します。

7. 結果と権限 問い合わせにはサービス実行の許可だけでなく、対象のデータやカタログ、暗号鍵等の条件が関係します。結果の保存・利用方式も設定により異なります。元データを保護していても結果へ個人情報が出るなら、結果へのアクセスや保持を管理する必要があります。

8. 選び方と運用 S3へ保存済みのログを必要な時に調べる用途では始めやすい選択肢です。繰返しの同時分析や統合データウェアハウスの要件ではRedshift等とも比較します。ワークグループで利用や設定を管理し、スキャン量、失敗、応答時間を監視します。SQLやデータの品質は利用者が確認します。

図解

重要ポイント

• テーブル定義は実データの場所・構造を表す。
• パーティション条件と配置を合わせる。
• 結果件数とスキャン量は別。

間違えやすい点

• LIMITや少ない結果件数だけで読取り料金が小さいと判断する。
• Serverlessを関連保存・権限も不要と考える。

用語解説

パーティション

日付等の条件で分けたデータのまとまり。

スキャン量

問い合わせで読み取ったデータの量。

Parquet

必要な列の利用や圧縮等に適した列指向データ形式。

ワークグループ

Athenaの問い合わせや利用者、設定等を管理するまとまり。

関連教材

• Glueを理解する
• Amazon Redshiftを理解する
• AWS分析サービスの違いと使い分け
• AWS分析サービスの全体像
• AWS分析サービスのシナリオ判断