AWS入門ブログリレー2024〜 Amazon Athena 編〜

当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』に部外者ですが参戦している14日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。今回のテーマは『Amazon Athena』です。

Amazon Athena とは

Amazon Athenaは、AWSが提供するサーバーレスのクエリサービスです。従来のデータウェアハウスソリューションとは異なり、Athenaではデータの保存場所であるデータレイクに対してSQL形式のクエリを実行することができます。従来からあるオンデマンドキャパシティのAthenaは、サーバの管理やインフラの構成などの手間をかけずに、瞬時にデータ分析を始めることが可能です。料金も実際にクエリを実行したデータ量に基づいているため、コスト効率が高く、大量のデータを扱う企業にとって有効なサービスです。

Amazon Athenaは、データエンジニアがデータ分析に用いるだけでなく、インフラエンジニアがALBやCloudTrailなどのログを検索、可視化する際にも有用なクエリエンジンです！

Athenaのデータストア「データレイク」

Athenaのデータストアとなる、「データレイク」とその「データフォーマット」について解説します。

データレイクとは

データレイクは、さまざまな形式や構造のデータを保存しておく大規模な保管場所のことを表し、AWSクラウドでは主にS3に保存することから、S3データレイクと呼ばれることもあります。企業は、構造化されたデータだけでなく、半構造化データ、非構造化データも含めて、すべてのデータを保存・利用できます。データレイクを活用することで、データの種類を選ばずに収集・保存でき、将来的な分析の幅が広がります。また、データレイクではデータを加工せずに格納できるため、データ準備にかかるコストを抑えることができます。

Amazon Athenaは、データレイクとの組み合わせて本領を発揮する事ができるのです。

データフォーマット

データレイクにどのようなフォーマットでデータを保存するかを決めるのが、データフォーマットになります。データフォーマットには、HIVEとICEBERGがあり、それぞれの特徴と違いを理解することは、データ分析の効率化やパフォーマンス向上に繋がります。

HIVE

HIVEは、データ用のフォルダにデータファイルを保存する簡単な方法です。データ分析のためのテーブルフォーマットとして広く利用されています。

HIVEでは、さらにHiveスタイルパーティションといって、データを論理的に分割して保存する方法もあります。いわゆる、「パーティショニング」です。テーブルを複数の小さな部分に分割することで、データ分析のパフォーマンスとスケーラビリティを向上させることができます。

Hiveスタイルパーティションは、ディレクトリ階層を使用してデータを分割します。各ディレクトリは、パーティションキーと値の組み合わせを表します。例えば、テーブルにyearとmonthというパーティションキーがあると、以下のディレクトリ階層が作成されます。フィルタ条件に2023年1月を指定すると、そのフォルダをスキャンするだけで済むため、コストとパフォーマンスが改善します。

/market_sales/
    /year=2023/
        /month=1/
        /month=2/
    /year=2024/
        /month=1/

末端のフォルダの下にデータファイルを保存します。データ形式は、CSV、JSON、Parquet、ORC、正規表現をはじめに、多くをサポートしています。

HIVEの課題は、DMLと呼ばれるデータ操作機能が限定されていることにありました。具体的には、DELETE、UPDATE、MERGEなどのDMLをサポートしていないため、主な用途としてデータ参照に利用されることがほとんどでした。さらに、カラムのデータ型変更や追加・削除にも対応できないため、データ形式によっては、変更に対応するためにS3データレイク上のファイルを事前に変換する必要がありました。

ICEBERG（Apache Iceberg）

ICEBERGは、HIVEの課題を克服するために開発された大規模なデータセットの効率的な分析を実現するテーブルフォーマットです。ACIDトランザクション、スキーマの変更、パーティショニングの最適化など、一般的なデータウェアハウスが備えている機能を提供することで、データの整合性とクエリのパフォーマンスが向上します。Athenaでのサポートにより、これまで以上にサーバレスな環境でIcebergテーブルを簡単にクエリできるようになります。

具体的なテーブル作成やデータの操作については、以下のブログを参照してください。

ICEBERGは、個人的にもイチオシのデータフォーマットであり、AWS主催のオンラインカンファレンス、ちょっぴり DiveDeep する AWS の時間にて「Amazon Athena (Iceberg) x dbt ではじめるデータ分析！」というテーマにて登壇しました。セッション動画と資料が公開されていますのご覧いただけたら幸いです。

ICEBERG は、Parquet 形式のデータファイルに加えて、メタデータファイルも保持します。メタデータファイルには、テーブルスキーマ、パーティショニング情報、トランザクション履歴などの情報が含まれます。利用者は、どのようなファイル構成であるかを意識する必要はありません。

HIVEとICEBERGの比較

データストアとしてのデータレイクとデータウェアハウスとの違い

大量のデータを分析する場合、まず思い浮かぶのはデータウェアハウス（DWH）です。ここでは、両者の違いをざっくり解説します。

データウェアハウス（DWH）は構造化されたデータの分析に特化している一方、データレイクは構造化・非構造化問わずあらゆるデータを格納できるという違いがあります。

データレイクとデータウェアハウス（DWH）は、データの形式、加工の有無、スキーマの扱い方、用途、スケーリングのしやすさ、コストなどの点で大きく異なります。データレイクは、様々な形式のデータを加工せずに格納でき、探索的な分析や機械学習などに適しています。一方、データウェアハウスは、主に構造化データを扱い、定型的な分析やレポーティングなどに適しています。

データレイクとしてテーブルフォーマットHIVEを用いる場合と、データウェアハウス（DWH）に限りなく近い用途でテーブルフォーマットICEBERGを用いる場合がある。Amazon Athenaは、これらの2つのテーブルフォーマットのデータをシームレスにブレンドできるのが大きな特長です。

データウェアハウス(DWH)について、もう少し知りたい方は以下の動画をご覧ください。

Amazon Athenaのクエリエンジン

Amazon Athena は、2 つの異なるエンジンを使用できます。ワークグループごとにエンジンやバージョンを設定可能で、クエリのパフォーマンスやコストに応じてエンジンやバージョンを変更可能です。

Apache Trino（Athena SQL）

Apache Trinoは、元々はFacebookによって開発されたPrestoという分散SQLクエリエンジンをベースに、2020年に独立したプロジェクトです。Amazon Athenaは、Trinoをベースに独自に開発されたクエリエンジンを使用しており、Prestoから進化した多くの機能を利用できます。

• Athena エンジンバージョン3 で使用されるオープンソースの分散 SQL プロジェクト
• オンデマンドキャパシティ（後述）は、スキャンしたデータソースのサイズに応じた課金で、コストがわかりやすい
• アイコンがかわいい（これ重要）

AthenaからTrinoを使ってクエリを実行したい場合は、クエリエディタを開いてSQLを入力し、実行するだけです。もちろん、JDBCドライバやODBCドライバもAWSから提供されており、組み込みアプリケーションに活用していただくことも可能です。

オンデマンドキャパシティとプロビジョニングしたキャパシティの違い

オンデマンドキャパシティはサーバーレスアーキテクチャで、自動的にスケーリングされ、初期費用がかからず、スキャンしたデータサイズに応じて料金を支払います。

一方、プロビジョニングしたキャパシティはクラスターベースのアーキテクチャで、専用のリソースを確保でき、高いパフォーマンスが期待できますが、長期的なコストが高くなる可能性があります。

ワークロードが変動したり、突発的なクエリが発生する可能性がある場合は、オンデマンドキャパシティ（デフォルト）が向いており、ワークロードが予測可能で安定する必要がある場合は、プロビジョニングしたキャパシティを選択します。コストとパフォーマンスのバランスを重視する場合は、オンデマンドキャパシティとプロビジョニングしたキャパシティを組み合わせて使用することもできます。

Partition Projection（パーティション射影）

Partition Projection（パーティション射影）は、テーブル定義で指定したパーティションキーのルールやフォーマットからパーティションを計算し、パーティションプルーニングを自動化します。本来、パーティションごとに必要なパーティション設定不要になり、運用負荷が下がるAthenaならではの素晴らしい機能です。

Apache Spark（Athena for Spark）

Apache Sparkは、大規模データ処理のためのオープンソースクラスタコンピューティングフレームワークです。このようにAmazon Athenaは、Apache Sparkの並列分散処理、インメモリ計算、フォールトトレランス、データソースサポート、クエリ最適化などの機能を活用することで、大規模データに対して高速かつ信頼性の高いクエリ実行を実現しています。

• Athena エンジンバージョン 1 で使用されていたオープンソースの分散処理フレームワーク
• ノートブックの利用時間と、実際にクエリを実行したDPUの数に応じた時間課金
• Sparkは、SQL（SparkSQL）だけでなく、プログラミング言語（PySpark、Scala）による分析が可能で、柔軟性が高い

AthenaからSparkを使うには、クエリエディタではなく、ノートブック（Jupyter Notebook）からクエリを実行します。

手順など、詳しくは以下のブログをご覧ください。

様々なデータソースにクエリができるFederated Query

これまで、混乱を避けるために「Athenaは、S3データレイクのデータに対してクエリするサービス」 と解説してきましたが、実は外部のデータソースに対してもクエリを実行することができるFederated Queryという機能があります。Apache Trino用のデータソースコネクタを開発・デプロイすることで様々なデータソースへのクエリが可能になります。

ユースケース

Amazon Athenaのフレキシブルなデータクエリ能力が活かしたユースケースを紹介します。

料金

下記の料金は、2024年4月現在、東京リージョンの料金を解説しています。最新情報については、以下をご覧ください。

クエリエンジン：Apache Trinoの場合

オンデマンドキャパシティの料金（SQLクエリ）

• $5/TBスキャンデータ
  • バイト数はメガバイト単位で切り上げられ、クエリごとに最小 10 MB が課金

プロビジョニングしたキャパシティの料金

• 0.43USD/時 x DPUの数（最小24）
  • アカウントでアクティブな期間 (最低1時間) の料金
  • アカウントとリージョンごとに、最大合計 1,000 個の DPU で最大 100 個のキャパシティ予約を作成できます。

クエリエンジン：Apache Sparkの場合

Apache Sparkは、１つドライバと複数のワーカーのノードがあります。ドライバはタスクのスケジュールに基づきワーカーの起動、ワーカーにタスクを送信し、ワーカーは結果をドライバに送信します。

よって、Apache Sparkの場合は、ドライバー DPU 利用時間とワーカー DPU 利用時間の合算になります。

• ドライバー DPU 利用時間は、セッションを開始してから終了するまでの時間
• ワーカー DPU 利用時間は、ワーカーが起動して停止するまで使ったDPUの合算時間
• 0.5USD x （ドライバー DPU 利用時間 + ワーカー DPU 利用時間）

終わりに

Amazon Athenaは、サーバーレスでスケーラブルなクエリサービスです。Athenaを使えば、データレイクに格納された様々な形式のデータに対してSQLクエリを実行でき、ビッグデータ分析を手軽に始めることができます。Athenaは、ログ分析、IoTデータ分析、機械学習、データ探索など、様々なユースケースに活用できます。従量課金制のため、初期費用がかからず、コストを抑えながらビッグデータ分析を行うことができます。

Amazon Athenaは、進化の歩みは止まりません。恐らく、将来的にはIcebergのみならず、Delta LakeやApache Hudiなども段階的にサポートを広げていくのではないかと予想しています。

2023/11時点の最新情報が知りたい人は、下記のセッションをご覧ください。