Amazon AthenaによるS3データのSQL分析

Amazon S3上のデータをその場で分析する

Amazon Athenaは、Amazon S3に保存されたデータへ標準SQLでクエリを実行するサーバーレスの対話型分析サービスです。クエリを処理するサーバー群を利用者が作成・管理する必要がなく、分析用に別のデータベースへ全件ロードしてから始める必要もありません。Athenaはテーブル定義を手掛かりにS3上のファイルを読み取ります。

たとえば、複数のスキー場に設置した積雪計の測定値をS3に蓄積しているとします。運用担当者は必要な期間や施設だけをSQLで選び、測定値の推移を調べられます。分析対象のデータをS3からAthena専用の保存領域へ移す処理をあらかじめ用意せずに、調査やアドホック分析を始められます。

AthenaのSQLクエリエンジンは、オープンソースのPrestoとTrinoの系譜に基づいています。現在のAthenaエンジンバージョン3は、Trinoプロジェクトの機能や改善を継続的に取り込むエンジンです。AthenaはSQL実行を提供し、データファイル自体はS3に残る、という役割分担を押さえましょう。

テーブル定義とGlue Data Catalog

AthenaがS3のどの場所にあるどの形式のデータを、どの列として読むかを知るには、データベースとテーブルのメタデータが必要です。AthenaとAWS Glue Data Catalogは連携しており、カタログにはデータベース名、列名やデータ型、パーティション、S3上の場所、ファイル形式に関する定義を保存できます。

テーブルのメタデータを用意する方法は大きく二つあります。

1. DDLで定義する — Athenaのクエリエディタなどから CREATE DATABASE や CREATE EXTERNAL TABLE を実行し、列と型、S3の LOCATION、データ形式やSerDe、パーティション列などを定義します。テーブル定義はカタログに登録されますが、通常の外部テーブル作成ではS3のファイル内容を別の保存領域へコピーしません。
2. AWS Glueクローラーで推測する — クローラーにS3のデータストアを指定すると、ファイルを調べてスキーマやパーティションを推定し、Glue Data Catalogへテーブル定義を登録できます。必要に応じてスケジュール実行し、新しいデータやスキーマ変更を検出する運用にできます。

クローラーは任意のタイミングでメタデータを調べる仕組みです。Athenaを使い始めるだけでクローラーが自動的に起動し、常に新しい定義へ更新するわけではありません。データの到着頻度やスキーマ変更の管理方法に合わせて、クローラーの実行間隔を決めるか、DDLやパーティション更新を管理します。

Athenaでは、カタログ上のスキーマを実データに読み取り時に適用する schema-on-read の考え方を使います。定義はデータの所在と構造を示すメタデータであって、データ本体ではありません。Glue Data Catalogは複数の分析サービスから共有でき、クローラーなどによるテーブル定義の更新やバージョン管理にも利用されます。テーブルを作っただけでS3のファイル形式や中身が変換されるわけではありません。

対応データ形式と読み取り量

AthenaはApache Hive形式のテーブル定義などを通して、CSV、JSON、Apache Avro、Apache ORC、Apache Parquetを含むさまざまな形式のデータを読み取れます。形式ごとに読み取り方や圧縮方式、スキーマの持ち方が異なります。生データをそのまま調べるだけでなく、分析頻度が高いデータを列指向形式へ変換して、読み取る量を抑える設計も一般的です。

ParquetやORCのような列指向形式では、列ごとに値が格納されます。クエリが一部の列しか参照しない場合、必要な列を中心に読み取ることができ、データの圧縮効率や不要な範囲を読み飛ばすためのメタデータも活用できます。たとえば利用者ID、測定時刻、気温、湿度を含むテーブルから平均気温だけを集計する場合、行全体を読む形式よりも列指向形式が有利になりやすくなります。

列指向形式の性能は、ファイル内のデータ配置にも左右されます。よく範囲検索する時刻列などでデータを適切に並べておけば、ファイル内の最小値・最大値などの情報から不要なブロックを読み飛ばせることがあります。Athena向けにデータを変換・整列する処理には、AthenaのCTAS（CREATE TABLE AS SELECT）やAWS Glue ETLなどを利用できます。

クエリ性能と料金を左右するファイル設計

S3上に小さなファイルが大量にあると、Athenaはデータ本体を読む前に多数のオブジェクトを列挙し、メタデータを確認して各ファイルを開く必要があります。そのため、スキャンするデータ量が小さく見えても、ファイル数の多さによって計画や読み取りの処理時間が増えることがあります。小さなファイルをまとめたり、データ取り込みや変換の段階でファイル出力サイズを調整したりします。

サイズの目安として、AWSのガイダンスでは一般に128 MBを超えるファイルが示されています。ただし、これをすべての形式・クエリに適用する固定ルールとして扱うのではなく、パーティション数、ファイル形式、並列処理、書き込み側の制約も考えて決めます。Parquetの行グループは既定で128 MB、ORCのストライプは既定で64 MBです。ファイル全体と内部ブロックのサイズは別の設計値であり、列数の多いデータなどでは調整が必要になることがあります。

データ圧縮はS3上の保存容量を抑え、圧縮後の読み取り量を減らす助けになります。一方、形式や圧縮コーデックによっては分割読み取りのしやすさが異なるため、圧縮率だけで決めず、Athenaの対応形式・圧縮方式とクエリ性能も確認してください。ParquetやORCなど分析向けの列指向形式と、適切な圧縮を組み合わせると、読み取りと保存の両方を効率化できます。

オンデマンドのSQLクエリでは、主な課金基準はクエリがスキャンしたデータ量です。そのため、列指向形式で必要な列だけを読む、圧縮する、パーティションで対象範囲を狭める、といった工夫は応答時間だけでなくクエリコストの抑制にもつながります。正確な料金はリージョンや選択する機能・容量モデルで異なり、S3へのクエリ結果の保存など関連サービスの料金も考慮します。最新の単価と課金条件は公式料金ページで確認してください。

パーティションで対象データを絞る

パーティショニングは、データを列の値に基づいて複数のまとまりに分け、S3上のプレフィックス（フォルダのように見えるキーの階層）へ配置する方法です。たとえば、複数地域の発電設備から届くデータを plant_region=west/measurement_year=2026/measurement_month=10/ のように分ける設計が考えられます。Athenaのテーブル定義にパーティション列を登録しておくと、クエリの WHERE 条件で該当値を指定したとき、条件に合わないパーティションを読み飛ばせます。

パーティション列は、実際のクエリで頻繁に絞り込みに使う列から選びます。候補は日付だけとは限らず、地域、テナント、製品種別などもアクセスパターン次第で有効です。細かく分割し過ぎるとパーティション数やメタデータの管理負荷が増え、小さなファイルがさらに増えることもあります。反対に、分割が粗すぎるとクエリが不要なデータを多く読みます。分析条件とデータ量のバランスを取って粒度を決め、クエリではパーティション列を明示的に条件指定します。

多数のパーティション値を持つテーブルでは、**Partition Projection（パーティション射影）**を設定して、値やS3の場所をテーブルプロパティから計算させる方法もあります。これにより、各パーティションの登録・参照に伴うカタログ問い合わせを減らせます。射影を有効にすると、AthenaはそのテーブルについてGlue Data Catalogに登録済みのパーティション情報を無視するため、テーブルの管理方法を揃える必要があります。

バケットで値の分布を整理する

バケット化では、一つまたは複数の列の値からデータを複数のバケット（ファイル群）へ分散させます。Athenaはバケット化されたテーブルの定義に従い、対象の値に対応する範囲を読み取ってスキャン行数を減らせる場合があります。値の種類が多く、分布が偏り過ぎず、クエリで頻繁に等価条件として使う列が候補になります。たとえば、設備の保守記録を設備シリアル番号で絞り込む頻度が高いなら、その識別子をバケット列として検討できます。

バケットとパーティションは別の軸でデータを整理する方法なので、組み合わせられます。地域ごとにパーティションを分け、その範囲内で設備番号をバケット化すれば、地域と設備の両方を条件にするクエリで読み取りを減らせる可能性があります。ただし、バケット化されたファイルの生成方法とテーブル定義を一致させる必要があり、すべてのクエリで必ず効果が出るわけではありません。出力ファイル数や書き込み側の制約も含めて評価します。

読み取りを抑える確認手順

Athenaの性能とコストを改善するときは、次の順で実際のクエリを見直します。

1. クエリが参照していない列を SELECT * で読み込んでいないか確認する。
2. WHERE 句で対象データを絞り、テーブルのパーティション列に条件を適用しているか確認する。
3. CSVやJSONのまま繰り返し分析するデータについて、ParquetまたはORCへの変換を検討する。
4. オブジェクト数とサイズの分布を確認し、小さなファイルが多い場合はCTASやGlue ETLなどでまとめる。
5. 圧縮、データの並び順、必要に応じたバケット化が実際の読み取り量と所要時間に効いているか測る。
6. Glueクローラーやパーティション射影など、メタデータ管理方法がデータ更新の頻度に合っているか確認する。

ワークグループを使うと、クエリの実行環境を利用者や用途ごとに分け、クエリ結果の出力先や暗号化、スキャン量の制御などを管理できます。調査用クエリが予想外に大きなデータを読み取る可能性がある場合は、スキャン上限やCloudWatchによる監視も組み合わせてください。

試験での判断軸

• **「S3に保存したCSVやParquetをロードせずにSQLで調査したい」**なら、サーバーレスのAmazon Athenaが候補です。
• **「テーブルの列やデータ場所を定義したい」**ならGlue Data CatalogへDDLで定義するか、必要に応じてGlueクローラーでスキーマを推測します。
• **「Athenaを使えばメタデータが自動発見される」**とは限りません。クローラーの実行やDDLによるカタログ登録などが必要です。
• **「スキャンコストとクエリ時間を減らしたい」**なら、列指向形式、圧縮、適切なファイルサイズ、パーティション条件を検討します。
• **「頻繁に検索する高カーディナリティのID列がある」**なら、テーブルのパーティション構成に加え、バケット化の効果も評価します。
• **「データをAthenaへインポートする必要がある」**とは限りません。AthenaはS3上のファイルを直接読み、クエリ結果は別に設定したS3の場所などへ出力します。

公式ドキュメント

• Amazon Athenaとは
• Amazon Athenaの料金
• Athenaエンジンのバージョン
• AWS Glue Data CatalogとAthena
• AWS Glueクローラーの利用
• データ形式と圧縮のサポート
• Athenaのデータ最適化手法
• Athenaのパーティションとバケット
• パーティション射影
• Athenaのクエリ処理容量