LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AthenaのSQLクエリはスキャン量で課金される

Amazon Athena（アマゾン アテナ）のSQLクエリとは、Amazon S3上のデータに対してサーバーレスでSQLを実行できるサービスであり、クエリが読み取ったデータ量（スキャン量）に応じて課金されるモデルです。AWSの料金例として「スキャンされた3TBの料金は3×5USD/TB＝15USD」と示されており、SQLクエリは1TBあたり5USDが基準となります^*1。

RedshiftがプロビジョニングまたはServerlessの計算リソースに対して課金されるのとは異なり、AthenaのSQLクエリは実行したクエリがS3から読み取ったバイト数だけに課金されます。データウェアハウス（DWH）を常時稼働させる必要がなく、アドホックな分析に向いている反面、クエリ設計を誤ると想定外のスキャン量が積み上がります。

AWS Glue・EMRがETLジョブの処理時間やDPU使用量で課金されるのとも課金軸が異なります。Athena固有のコスト最適化は「いかにスキャン量を減らすか」という一点に集約されます。

パーティション設計でスキャン範囲を行方向に絞る

AWS公式ドキュメント「データのパーティション化」によると、パーティション化されたテーブルに対してWHERE句でパーティション列を指定すると、Athenaはそのパーティションのデータだけをスキャンします^*2。これをパーティションプルーニング（プルーニング＝枝刈り）と呼びます。

典型的な設計はS3パスを年・月・日などの階層で区切る方法です。`year=2024/month=06/day=25/` のようなHiveスタイルのパスを使うと、Athenaが自動でパーティションを認識します。クエリでは `WHERE year=’2024′ AND month=’06’` のように条件を付けることで、その期間外のパーティションはスキャン対象から除外されます。

パーティション列は検索条件として頻繁に使うものを選ぶことが大切です。日付・リージョン・サービス名などがよく使われます。カーディナリティ（一意な値の数）が高い列をパーティション列にすると逆に小ファイルが増えるため、適切な粒度の選定が重要です。

パーティション射影でメタデータ取得のオーバーヘッドを削減

パーティション数が多いテーブルでは、AWS Glue Data Catalogへのメタデータ取得（GetPartitions呼び出し）がクエリのレイテンシを増やします。パーティション射影（Partition Projection）を使うと、テーブルプロパティにパーティション値の範囲や型を定義することで、Athenaがメモリ内でパーティション情報を計算し、カタログへのリモート呼び出しを省略できます^*3。

日付範囲のような連続値や、列挙可能な固定値を持つパーティションに特に効果的です。新しいパーティションを追加した際に手動でALTER TABLE ADD PARTITIONを実行する必要がなくなるという運用面のメリットもあります。

列指向フォーマット（Parquet/ORC）でスキャン範囲を列方向に絞る

CSVやJSONは行単位でデータを格納するため、特定列だけを参照するクエリでも行全体を読み取ります。対してParquet（パーケット）やORC（オーク）は列単位でデータを格納する列指向フォーマットで、クエリが参照する列だけを読み取れます。AWS公式ドキュメントでは、列指向フォーマットを使うことでストレージ領域の節約とI/O削減が得られると説明されています^*4。

述語プッシュダウン（Predicate Pushdown）も列指向フォーマットの重要な機能です。ParquetやORCはデータブロックごとにmin/max値（範囲統計）などの統計情報を保持しており、WHERE句の条件に合致しないブロックをスキャン前に除外できます。Athenaはこの情報を使って必要なブロックのみを取得し、クエリパフォーマンスの向上とスキャン量削減を同時に実現します^*4。

CTASクエリとAWS GlueでParquet/ORCに変換する

既存のCSV・JSONデータをParquet/ORCに変換するには、AthenaのCTAS（CREATE TABLE AS）クエリを使う方法が代表的です。既存テーブルをSELECTしながら新しいParquet形式のテーブルとして作成できます。AWS Glue ETLジョブを使って定期的な変換パイプラインを組む方法も有効です。

ORC形式はParquetよりもファイルサイズが小さくなる傾向があり、ストレージコストをさらに抑えられます。どちらも圧縮コーデック（Snappy・Zstdなど）と組み合わせることで、スキャン量と転送量の両方を削減できます。

パーティション（行方向）と列指向（列方向）の組み合わせが要点

Athenaのコスト最適化において特に重要なのが、パーティション設計と列指向フォーマットの組み合わせです。パーティション設計はスキャン対象の「行の範囲」を絞り、列指向フォーマットは「列の範囲」を絞ります。二方向にスキャン範囲を制限することで、課金対象のデータ量を大きく削減できます。

クエリ記述・ファイル管理で積み上げるコスト削減

データ形式やパーティション設計の整備に加え、日常のクエリ記述と運用管理でもスキャン量を積み重ねて削減できます。

SELECT *を避けて必要列のみを指定する

列指向フォーマットを使っている場合でも、SELECT *（全列取得）を実行するとすべての列を読み取ります。クエリで実際に必要な列だけを明示的に指定することで、スキャン量を減らせます。分析用のダッシュボードクエリやETLパイプラインのSQLを定期的にレビューし、不要な列の取得を排除することが大切です。

小ファイル問題を解消して読み取り効率を上げる

S3に格納されたファイルが細かく分割されている（いわゆる「小ファイル問題」）と、Athenaが多数のS3オブジェクトを個別に読み取るためスキャン効率が下がります。AthenaのCTASクエリやAWS Glueを使ってファイルを定期的にまとめる（コンパクション）ことで、1ファイルあたりのサイズを適切に保ちスキャン効率を改善できます。

圧縮でスキャンデータ量を削減する

Snappy・Gzip・Zstdなどの圧縮コーデックを組み合わせると、S3に格納するデータ量とAthenaがスキャンするデータ量の両方を削減できます。Parquet/ORCと圧縮を組み合わせると、圧縮前のCSVと比べてスキャン量が大幅に変わる場合があります。ただし圧縮率はデータの種類やコーデックによって異なるため、実際のデータで検証することが大切です。

クエリ結果の再利用とコスト管理

同じクエリを繰り返し実行している場合、Athenaのクエリ結果の再利用機能を活用することでスキャンを省略できます。また、AWS Cost ExplorerやAthenaのクエリ履歴からスキャン量の多いクエリを特定し、優先的に最適化対象として絞り込む進め方が実務では効率的です。

内製で最適化を進める際に必要なスキルと工数

Athenaのコスト最適化を内製で推進するには、複数の専門領域にまたがる知識が必要です。作業前に必要なスキルと工数を把握しておくことで、内製か外注かの判断を適切に行えます。

必要な専門知識の範囲

最低限必要なのは次の知識です。S3の設計（バケット構成・パスルール・IAM）、Athena・Glue Data Catalogの仕組み（テーブル定義・パーティション管理）、クエリ最適化（実行計画の読み方・述語プッシュダウン）、Parquet/ORCのファイル形式仕様、データパイプライン設計（Glue ETLまたはCTASの運用）です。これらを1人のエンジニアが網羅することは難しく、実務ではAWSデータエンジニアとSQLアナリストが協働するケースが見られます。

工数と難易度の目安

スキャン量の多いクエリを特定して原因を分析する初期調査だけでも、2〜3名×数週間程度の工数がかかることがあります。パーティション設計の変更を伴う場合は、S3上のデータを再配置し既存テーブルを再作成する必要があり、ダウンタイムリスクや移行後の検証コストも発生します。また最適化後も新規クエリの追加や定期的なコンパクション運用が継続的に必要です。

対応を誤った場合のリスク

パーティション設計を誤ると、意図したパーティションプルーニングが効かず最適化前と同じスキャン量になります。パーティション射影の設定ミスでは、実在しないパーティションへのクエリがエラーなく空の結果を返すため、問題に気づきにくいリスクがあります。Parquet変換時にスキーマが不整合になると、クエリエラーやデータ欠損につながります。内製で進める際は各工程の検証フローを確保することが大切です。

外注で進める際の委託先選定と体制構築

Athenaのコスト最適化を外注で進める場合、委託先に求める要件と作業範囲の明確化がプロジェクト成否を左右します。

委託先に確認すべき技術要件

Athena特有の課金モデルとS3データレイク設計の両方を理解しているパートナーを選ぶことが重要です。確認したい実績・ケイパビリティは次の点です。Athena・Glue・S3を組み合わせたデータ基盤の設計・構築経験、Parquet/ORC変換を含むデータパイプラインの実装経験、クエリ最適化（実行計画の分析・パーティションプルーニングの確認）の経験、コスト削減後の運用保守まで一貫して対応できる体制です。

AWS Certified Data Engineer – AssociateやAWS Certified Solutions Architect等の資格保有は、基礎知識の目安になります。ただし資格よりも実際の案件実績と担当者のAthena経験を確認する方が実務的です。

委託範囲と契約形態の設計

外注でAthenaコスト最適化を進める際の委託範囲は、大きく「現状分析フェーズ」「設計・実装フェーズ」「運用保守フェーズ」に分けられます。

現状分析フェーズでは、Athenaのクエリ履歴からスキャン量・コストの分布を可視化し、改善対象の優先度を決定します。設計・実装フェーズでは、パーティション再設計・データ変換・クエリ修正を実施します。運用保守フェーズでは、定期的なコンパクション実行・新規クエリのレビュー・コスト監視の継続を担います。

フェーズごとに契約を分けることで、現状分析の結果を見てから実装の進め方を判断できます。初期は準委任契約（工数精算型）で現状分析を委託し、実装フェーズは請負または継続的な準委任で対応するケースがあります。

外注後に内製化する際の引き継ぎ設計

外注で最適化を進めた後、運用を内製化したい場合は引き継ぎを前提とした設計を委託開始時に合意しておくことが大切です。具体的には、設計ドキュメント（パーティション設計書・テーブル定義書）の整備、クエリチューニングのレビュープロセスの文書化、コスト監視ダッシュボードの引き渡し条件などを契約に盛り込みます。

元請（プライムベンダー）として一括受注するパートナーを選ぶことで、AWS側の調整・Glue設定・クエリ改修・運用設計まで一貫した対応が得やすくなります。複数ベンダーに分散して委託する場合は、調整コストが発生することを考慮して発注設計を行いましょう。

まとめ：Athenaコスト最適化で押さえる3つの軸

本稿ではAmazon Athenaのクエリ課金（スキャン量課金）の特性と、コスト最適化の主要手法、外注で進める際の要点を整理しました。要点を3つに集約します。

第一に、AthenaのSQLクエリはS3スキャン量に応じた課金であり、RedshiftやGlue/EMRとは課金軸が異なります。最適化の目標は「スキャン量を減らすこと」の一点に絞られます。第二に、パーティション設計（行方向の絞り込み）と列指向フォーマット（Parquet/ORC、列方向の絞り込み）を組み合わせることが、スキャン量削減の中心的な手法です。これにSELECT *の解消・圧縮・小ファイル統合を加えた多層的なアプローチが実務で使われます。第三に、内製で推進するには複数領域の専門知識と継続的な運用工数が必要であり、AWS Athena・Glueのデータ基盤設計経験を持つ外部パートナーへの委託で初期リスクを下げながら進める選択肢があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「Amazon Athena の料金」（2024年確認）
2. *2　出典：Amazon Web Services「データのパーティション化」Amazon Athena ユーザーガイド（2024年確認）
3. *3　出典：Amazon Web Services「Amazon Athena のパーティション射影」Amazon Athena ユーザーガイド（2024年確認）
4. *4　出典：Amazon Web Services「列指向ストレージ形式の使用」Amazon Athena ユーザーガイド（2024年確認）

Tweet