Athena講座

この講座では、S3上のデータに直接SQLクエリを実行できるサーバレス分析サービス、Amazon Athenaについて学びます。

Amazon Athenaの概要と特徴
Athenaの仕組み（Glueデータカタログとの連携）
SQLクエリの実行方法
パーティションによるクエリの最適化
データ形式とパフォーマンスの関係
主なユースケース
設計のポイント

1. Athenaの概要

1.1 Amazon Athenaとは

Amazon Athenaは、Amazon S3に保存されたデータに対して、標準的なSQLを使って直接クエリを実行できるサーバレスの分析サービスです。サーバのプロビジョニングやインフラの管理は一切不要で、SQLを書いて実行するだけですぐにデータ分析を開始できます。

Athenaにはいくつかの大きな特徴があります。

まず、Athenaはサーバレスのサービスです。サーバの構築や運用管理は一切不要で、AWSマネジメントコンソールからクエリを入力して実行するだけで、すぐにデータ分析を始められます。

また、Athenaは標準的なSQLに対応しています。普段使い慣れたSQLの知識をそのまま活かせるため、新しいクエリ言語を覚える必要はありません。SQLを扱える方であれば、導入直後からデータ分析を開始できます。

料金体系はスキャン量課金を採用しています。クエリの実行時に実際にスキャンしたデータ量に対してのみ課金される仕組みで、1TBあたり約5ドルという料金設定です。クエリを実行しなければ料金は発生しないため、分析頻度が低い場合にも無駄なコストがかかりません。

さらに、AthenaはGlueデータカタログと統合されています。Glueで管理されているテーブル定義やスキーマ情報をそのままAthenaから参照できるため、データカタログを一元管理しながら、複数のサービスからデータを活用できます。

1.2 なぜAthenaが選ばれるのか

従来、大量のデータを分析するにはデータウェアハウスなどの専用インフラを構築する必要がありました。しかし、Athenaを使えば、S3にデータを置くだけで即座にSQL分析を開始できます。Athenaが適しているユースケースをいくつか紹介します。

まず、アドホッククエリです。「ちょっとデータの中身を確認したい」「特定の条件に合うレコードがあるか調べたい」といった場面で、事前にインフラを準備することなく、すぐにSQLクエリを実行してデータを確認できます。

次に、ログ分析です。AWS CloudTrailの操作ログやALB（Application Load Balancer）のアクセスログなど、AWSサービスが自動的にS3へ出力するログデータに対して、Athenaで直接クエリを実行できます。障害調査やセキュリティ監査の際に、大量のログから必要な情報を素早く抽出できます。

また、定期的なレポートの作成にも適しています。日次や週次の売上集計、ユーザ数の推移といった定型的なデータ集計をSQLで実行し、レポートを生成する用途で活用できます。

さらに、データ探索にも活用できます。データレイクに新たに蓄積されたデータセットの内容や構造を把握したい場合に、Athenaでクエリを実行してデータの傾向や分布を手軽に確認できます。

💡 ポイント
Athenaは「データをS3に置くだけで分析できる」という手軽さが最大の魅力です。データウェアハウス（Redshift）のように常時稼働するクラスターを維持する必要がないため、分析頻度が低い場合や、まずは手軽にデータ分析を始めたい場合に最適です。

2. Athenaの仕組み

2.1 Athenaで利用できるテーブルの作成

Athenaでクエリを実行するためには、テーブル定義（メタデータ）が必要です。テーブルを作成する方法は主に3つあります。

Glueクローラーで作成

Glueクローラーは、S3上のデータを自動的にスキャンし、データの形式やスキーマを解析してテーブル定義をGlueデータカタログに自動登録する機能です。大量のデータセットがある場合や、スキーマを手動で定義するのが手間な場合に便利です。Glueクローラーの詳細については、前の講座で学習した内容に記載があります。

Glueコンソールで作成

Glueの管理画面（コンソール）から、テーブル名・カラム定義・データの保存場所・データ形式などを手動で入力してテーブルを定義する方法です。GUIで操作できるため、SQLに不慣れな場合でもテーブルを作成できます。

Athenaで直接作成

AthenaのクエリエディタからDDL（データ定義言語）のCREATE TABLE文を実行してテーブルを作成する方法です。SQLの知識があれば最も手軽にテーブルを作成でき、Athena上で完結します。具体的なCREATE TABLE文の書き方については、後のセクションで解説します。

2.2 クエリの実行フロー

Athenaのクエリ実行フローを以下に示します。

sequenceDiagram
  participant User as ユーザ
  participant Athena as Amazon Athena
  participant Catalog as Glue データカタログ
  participant S3 as Amazon S3

  User->>Athena: SQLクエリを送信
  Athena->>Catalog: メタデータを取得
  Catalog-->>Athena: スキーマ・保存場所
  Athena->>S3: データを読み取り
  S3-->>Athena: 対象データ
  Athena-->>User: クエリ結果を返却

ユーザがSQLクエリをAthenaに送信すると、AthenaはまずGlueデータカタログからテーブルのメタデータ（スキーマやデータの保存場所）を取得します。次に、そのメタデータに基づいてS3から対象のデータを読み取り、分散処理エンジン（Trino/Presto）を使ってクエリを実行します。処理が完了すると、結果はユーザに返却されると同時に、クエリ結果用のS3バケットにも自動的に保存されます。

📝 Trino/Prestoとは
Athenaの内部ではTrino（旧Presto）という分散SQLクエリエンジンが使われています。Trinoは大量のデータを複数のノードで並列処理することで、高速なクエリ実行を実現します。ユーザはTrinoの存在を意識する必要はありませんが、Athenaで利用できるSQL構文やデータ型はTrinoの仕様に基づいています。

2.3 クエリ結果の保存先

Athenaのクエリ結果は、指定したS3バケットに自動的に保存されます。このバケットは「クエリ結果の場所」としてAthenaの設定で指定する必要があります。

クエリを実行するたびにCSV形式の結果ファイルが保存されるため、結果用のS3バケットが肥大化しないよう、S3ライフサイクルルールで古い結果を自動削除する設定を行うことを推奨します。

2.4 ワークグループ

ワークグループは、Athenaのクエリ実行環境をチームや用途ごとに分離して管理するための機能です。ワークグループごとに、クエリ結果の保存先（S3バケット）、1クエリあたりのデータスキャン量の上限、ワークグループ全体のデータスキャン量の上限などを個別に設定できます。

例えば、開発チームと分析チームでワークグループを分けることで、クエリ結果の保存先を別々に管理したり、チームごとにスキャン量の上限を設定してコストを制御したりできます。

Athenaにはデフォルトでprimaryというワークグループが用意されており、特にワークグループを指定しない場合はこのprimaryワークグループが使用されます。小規模な利用であればprimaryワークグループのみで問題ありませんが、複数のチームや用途でAthenaを利用する場合は、ワークグループを分けて管理することを推奨します。

3. SQLクエリの実行

3.1 Athenaクエリエディタ

AthenaにはWebベースのクエリエディタが用意されており、AWSマネジメントコンソール上でSQLクエリを記述・実行できます。

クエリエディタでは、左側のペインにデータベースとテーブルの一覧が表示されます。テーブルを選択すると、カラム名やデータ型を確認できるため、テーブル構造を把握しながらクエリを記述できます。

3.2 テーブルの作成（CREATE TABLE）

Athenaでテーブルを作成する例を示します。S3上のParquetファイルに対するテーブル定義です。

CREATE EXTERNAL TABLE IF NOT EXISTS sales_db.sales_data (
    order_id STRING,
    customer_id STRING,
    product_name STRING,
    amount INT,
    order_date STRING
)
STORED AS PARQUET
LOCATION 's3://my-bucket/raw/sales/';

この例では、データベースsales_db内にsales_dataというテーブルを作成しています。カラムはorder_id、customer_id、product_name、amount、order_dateの5つを定義しています。データ形式はParquetで、データの保存先はs3://my-bucket/raw/sales/です。

📝 EXTERNAL TABLEとは
Athenaで作成するテーブルは常に外部テーブル（`EXTERNAL TABLE`）です。外部テーブルは、テーブルの定義（メタデータ）のみをGlueデータカタログに登録し、実際のデータはS3に保存されたままです。テーブルを削除しても、S3上のデータは削除されません。

なお、CREATE TABLEで直接テーブルを作成する場合は、カラム定義やデータ形式、保存先などを一つずつ指定する必要があります。一方、Glueクローラーを使えば、S3上のParquetやCSVなどのファイルからスキーマを自動的に検出し、テーブル定義を作成できるため、手動での定義が不要になります。

3.3 データのクエリ

テーブルが作成されたら、通常のSQLと同様にクエリを実行できます。

-- 売上の合計を商品別に集計
SELECT
    product_name,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount
FROM sales_db.sales_data
WHERE order_date >= '2025-01-01'
GROUP BY product_name
ORDER BY total_amount DESC
LIMIT 10;

Athenaは標準的なSQLをサポートしているため、JOIN、GROUP BY、HAVING、サブクエリ、ウィンドウ関数など、一般的なSQL構文を使用できます。

3.4 CTAS（Create Table As Select）

CTAS（Create Table As Select）は、CREATE TABLE ... AS SELECTの略で、SELECTクエリの結果を新しいテーブルとしてS3に保存する機能です。通常のSELECTではクエリ結果を確認するだけですが、CTASを使えばその結果をParquetなどの形式でS3に書き出し、再利用可能なテーブルとして保存できます。GlueジョブでETL処理を組むほどではない簡単なデータ変換やフィルタリングに便利です。

CREATE TABLE sales_db.sales_parquet
WITH (
    format = 'PARQUET',
    external_location = 's3://my-bucket/processed/sales/'
) AS
SELECT * FROM sales_db.sales_data
WHERE order_date >= '2025-01-01';

この例では、sales_dataテーブルから2025年1月1日以降のデータを抽出し、Parquet形式で新しいテーブルsales_parquetとして保存しています。WITH句のformatで出力形式を指定し、external_locationでデータの保存先となるS3パスを指定しています。AS以降のSELECT文が、新しいテーブルに格納するデータを定義しています。

4. パーティションによるクエリの最適化

4.1 パーティションとは

パーティションは、データを特定のキー（日付、地域など）で分割して保存する仕組みです。パーティションを設定すると、クエリ実行時に必要なパーティションのデータのみを読み取るため、スキャンするデータ量が大幅に削減されます。

例えば、売上データを日付（年/月/日）でパーティション分割する場合、S3上のデータは以下のようなディレクトリ構造で保存されます。

s3://my-bucket/sales/
├── year=2025/
│   ├── month=01/
│   │   ├── day=01/
│   │   │   └── data.parquet
│   │   ├── day=02/
│   │   │   └── data.parquet
│   │   └── ...
│   ├── month=02/
│   │   └── ...
│   └── ...
└── year=2024/
    └── ...

4.2 パーティションの効果

パーティションなしの場合、WHERE order_date = '2025-01-15'というクエリを実行すると、全データをスキャンする必要があります。しかし、日付でパーティション分割されていれば、year=2025/month=01/day=15/のデータのみをスキャンすれば済みます。

パーティション	スキャン対象	スキャン量（例）
なし	全データ	100 GB
年/月/日で分割	該当日のデータのみ	0.3 GB

Athenaはスキャン量に応じて課金されるため、パーティションの設定はコスト削減に直結します。

📝 パーティション設計の注意点
パーティションの分割が細かすぎると、小さなファイルが大量に生成され、かえってパフォーマンスが低下することがあります。一般的には、日付（year/month/day）での分割が最も広く使われるパターンです。AWS公式のOptimize data（Amazon Athena公式ドキュメント）にも「Having too many partition keys can result in fragmented datasets with too many files and files that are too small.」と記載されており、過剰なパーティション分割が小さいファイルの量産につながることが明示されています。

📝 パーティション設計の注意点

パーティションの分割が細かすぎると、小さなファイルが大量に生成され、かえってパフォーマンスが低下することがあります。一般的には、日付（year/month/day）での分割が最も広く使われるパターンです。AWS公式のOptimize data（Amazon Athena公式ドキュメント）にも「Having too many partition keys can result in fragmented datasets with too many files and files that are too small.」と記載されており、過剰なパーティション分割が小さいファイルの量産につながることが明示されています。

4.3 パーティションテーブルの作成

パーティション付きテーブルの作成例です。

CREATE EXTERNAL TABLE IF NOT EXISTS sales_db.sales_partitioned (
    order_id STRING,
    customer_id STRING,
    product_name STRING,
    amount INT
)
PARTITIONED BY (year STRING, month STRING, day STRING)
STORED AS PARQUET
LOCATION 's3://my-bucket/sales/';

PARTITIONED BYでパーティションキーを指定します。パーティションキーは通常のカラムとは別に定義される点に注意してください。

パーティションテーブルを作成した後は、以下のコマンドでS3上の既存パーティションを自動検出して登録します。

MSCK REPAIR TABLE sales_db.sales_partitioned;

5. データ形式とパフォーマンス

5.1 データ形式によるパフォーマンスの違い

Athenaのクエリパフォーマンスとコストは、データの保存形式によって大きく変わります。

データ形式	スキャン量	クエリ速度	コスト
CSV（非圧縮）	大	遅い	高い
JSON（非圧縮）	大	遅い	高い
CSV（gzip圧縮）	中	やや遅い	中
Parquet	小	速い	低い

Parquet形式は列指向ストレージであるため、必要なカラムのみを読み取ることができ、スキャン量が大幅に削減されます。さらに、Parquet自体が高い圧縮率を持つため、同じデータでもCSVと比較してファイルサイズが1/5〜1/10程度になります。

💡 ポイント
Athenaで分析するデータは、可能な限りParquet形式で保存することを推奨します。Glueジョブで生データ（CSV/JSON）をParquet形式に変換し、変換後のデータに対してAthenaでクエリを実行する構成が、パフォーマンスとコストの両面で最適です。

5.2 ファイルサイズの最適化

Athenaのパフォーマンスは、ファイルサイズにも影響を受けます。

ファイルが小さすぎると、ファイルのオープン・クローズのオーバーヘッドが大きくなり、処理が遅くなる
ファイルが大きすぎると、並列処理の効率が下がる

一般的に、128MB〜512MB程度のファイルサイズが最適とされています。小さなファイルが大量にある場合は、GlueジョブやCTASでファイルをマージすることを検討してください。AWS公式のOptimize data（Amazon Athena公式ドキュメント）にも「loading a single bigger file from Amazon S3 is faster than loading the same records from many smaller files」と明記されており、小さいファイルを大量に持つよりも適度に大きいファイルにまとめる方が高速であることが示されています。

6. 主なユースケース

6.1 CloudTrailログの分析

AWS CloudTrailのログをAthenaで分析することで、「誰が」「いつ」「どのAWSリソースに」「何をしたか」を調査できます。セキュリティインシデントの調査や、IAMポリシーの最適化に活用できます。具体的なテーブル定義例やクエリパターンはQuery AWS CloudTrail logs（Amazon Athena公式ドキュメント）に記載があります。

6.2 ALBアクセスログの分析

Application Load BalancerのアクセスログをAthenaで分析することで、アクセスパターンの把握、エラー率の監視、レスポンスタイムの分析などが可能です。

6.3 コスト分析

AWS Cost and Usage Report（CUR）のデータをAthenaで分析することで、サービス別・アカウント別のコスト分析や、コスト最適化のための詳細な調査が可能です。

6.4 ビジネスデータの分析

売上データ、顧客データ、在庫データなどのビジネスデータをS3に蓄積し、Athenaで集計・分析を行うことで、ビジネスインサイトを得ることができます。

7. 設計のポイント

Athenaを設計する際の主要な検討項目を以下にまとめます。

設計項目	検討内容	推奨・注意事項
データ形式	保存フォーマットの選択	Parquet形式を強く推奨。CSV/JSONは事前にParquetに変換
パーティション	データの分割戦略	日付（year/month/day）での分割が一般的。クエリパターンに合わせて設計
ファイルサイズ	1ファイルあたりのサイズ	128MB〜512MBが最適。小さすぎるファイルの大量生成を避ける
圧縮	圧縮形式の選択	Parquetの場合はSnappy圧縮（デフォルト）が推奨
クエリ結果	結果の保存先管理	S3ライフサイクルルールで古い結果を自動削除
ワークグループ	チーム・用途ごとの管理	ワークグループでクエリのコスト上限やアクセス制御を設定

8. まとめ

この講座では、S3上のデータにSQLクエリを実行できるAmazon Athenaについて学びました。

Amazon AthenaはS3のデータに直接SQLを実行できるサーバレス分析サービス
Glueデータカタログと連携し、テーブル定義を共有して利用する
パーティションを設定することで、スキャン量を大幅に削減し、コストとパフォーマンスを改善できる
データはParquet形式で保存することで、クエリ速度とコスト効率が大幅に向上する
CTASを使うと、クエリ結果を新しいテーブルとして保存でき、簡単なデータ変換にも利用できる
スキャン量課金のため、パーティション設計とデータ形式の最適化がコスト管理の鍵となる