AWSで構築するデータレイクがテーマの連載、今回は第2回目です。 前回は、AWS Lake Formationの概要と基本となるデータレイクの構築を確認しました。今回は、Amazon Athenaを利用し、前回構築したデータレイクから実際にクエリでデータを取得する部分を試していきます。
AthenaはS3からSQLで簡単にデータを取得できることが特徴のサービスですが、実際使うと本当に手軽に扱うことができました。 その一方、気を付けておきたいポイントも分かったので、その点を踏まえ、まとめていきたいと思います。
- 第1回:AWS Lake Formationでデータレイク体験! #1 何がうれしいのか?
- 第2回:AWS Lake Formationでデータレイク体験! #2 Athenaで簡単データ連携 (本記事)
- 第3回:AWS Lake Formationでデータレイク体験! #3 きめ細かな権限管理
本記事で扱うのは、赤枠部分です。
1. Athenaとは
まずはAthenaについて、その概要を見ていきます。
Athenaは、SQLで、S3内のデータを集計・分析できるサービスです。
Athenaの特徴は、主に以下4点です。
2. 利用方法
ここからは、実際にAthenaを利用して、前回構築したデータレイクからデータを取得していきます。 前回の記事で作成した、「データレイク管理者」のIAMユーザで操作していきます。
(1) クエリ結果保存用バケット作成
Athenaからクエリを発行すると、その結果は自動的にS3に保存されます。 まずは、クエリ結果保存用のバケットをS3に作成しておきます。
次にAthenaコンソールを開き、「設定」 > 「管理」から、「クエリ結果の設定」で、クエリ結果の保存先バケットを指定します。
(2) SELECT文でデータ取得する。
Athenaのクエリエディターを開くと、前回の記事で作成したテーブルの一覧が表示されていることが確認できます。
なお、今回は前回の記事でGlueで作成したテーブルにクエリを発行しています。S3にcsvファイルを配置しただけでは、Athenaから参照できないのでご注意ください。
続いて、SELECT文でsalesテーブルのデータを取得してみます。
SELECT * FROM "sales" WHERE shop_id = 25 LIMIT 10;
をクエリとして入力し、「実行」を押すとクエリ結果が表示されます。
LIKE句なども、もちろん利用可能です。
2014年のデータのみに絞り込む場合、SELECT * FROM "sales" WHERE date LIKE '%.2014' LIMIT 10;
というクエリで取得できます。
以下のドキュメントで、クエリに関して詳細に説明されています。
3. Athenaを利用する上での注意点
Athenaは、簡単にS3上のデータを分析することができますが、他方、意図しない超過課金が発生するリスクもあります。データを大量に読み込ませないために、最低限気を付けておきたいポイントを簡単にまとめていきます。
ワークグループによる制限
Athenaには、「ワークグループ」という機能があります。
このワークグループを利用することで、クエリ実行時のスキャンの最大量を設定できます。 スキャン最大量を超えるクエリが実行された場合、クエリはキャンセルされます。
検証時など、意図しない大量データスキャンを避けるためにも、この設定をしておくことで安心できると思います。 ワークグループ作成時、もしくはワークグループの編集画面より、制限を設定できます。
ワークグループは、スキャンの最大量制限のほかにも、
- クエリを実行できるユーザーを管理
- ワークグループ毎のメトリクス取得
- ワークグループ毎のコスト管理
にも利用できます。
読み込みカラムの指定
SELECT文でクエリを発行する際、読み込み対象のカラムを明示的に指定することが推奨されています。 特に、大量のカラムがあるテーブルや、文字列ベースのカラムが多い場合に有効なアプローチです。
Parquet または ORC を利用する。
AthenaはCSV、TSV、JSONなどのデータ形式のほか、Apache ParquetやLogstash、CloudTrailなどの形式をサポートしています。(サポートしているデータ形式)
この中でも、Parquet・ORCを利用することが、よいとされています。
Parquetは、Hadoopで利用される列指向のデータ形式です。ORCは、Hiveで利用される列指向のデータ形式です。
これらのデータ形式を利用するメリットは、2つあります。
一つは、parquet形式にすることで、単純にデータ量を圧縮できることが挙げられます。
一例として、1TBのCSVファイルも、parquet形式にすることで、130 GBまで削減することができるとされています。
データ量を削減できることで、S3の利用コストを削減することができます。
二つ目の理由として、列指向形式に変換することで、クエリ実行時のスキャンデータ量の削減が期待できる点が挙げられます。 列指向形式のデータにすることで、必要な列のみが選択的に読み込まれ、不要なデータのスキャンを避けることができるため、 コスト削減、パフォーマンス向上に寄与します。
参考資料
本記事では、よく使いそうなものに絞って、ベストプラクティス、チューニング方法を挙げてみました。 より詳しい最適化、チューニング方法は、以下のAWSが出している資料に載っています。
www.slideshare.net
4. コスト
Athenaで発生する料金は「クエリ」に対して発生します。
クエリ実行時のスキャンデータ量 1TBにつき、5USDが発生します。(リージョンによって、5USD以上の料金になります。)
上記に加え、S3、Glue、Lambda、Sage Makerなど他サービスを利用する場合、それぞれの料金体系に応じた料金が発生します。 特にS3については、Athenaクエリ結果をS3に保存するため、転送量、リージョンには気を付けておきたい所かと思います。
5. まとめ
Athenaを利用するのは初めてでしたが、簡単にSQLでS3のデータを取得、分析できる点は便利だと感じました。
データ分析をするとき、pythonでPandasを利用することが多いと思います。しかし、Pandasはパッケージとしてのサイズが大きく、サーバレス案件でAWS Lambda xPandasの組み合わせを採用すると、Lambdaのデプロイパッケージに関するサービスクォーターに達しないように意識する必要が出てきます。
Lambda Layerに載せきれないといった時の代替手段として、Athenaを利用する手もあるんじゃないかなと思いました。 また、数百MB ~ 数GB程度の小~中規模程度のデータの検証、分析であれば、AWSコンソール上で手軽にクエリを実行できる点も魅力だと思います。
他方、数十GB~数TB級の大規模データを分析する際は、綿密にチューニングしないと、コストとパフォーマンスの面で負担がかかってしまう点は注意が必要だと思いました。
本記事では、Athena を使って、Lake Formationで構築したデータレイクからデータを取得するところまでを試してみました。 次の記事で、Lake Formationの権限管理で、Athenaからのクエリをアクセスコントロールしていきます。
Acroquest Technologyでは、キャリア採用を行っています。少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com
- ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
- Elasticsearch等を使ったデータ収集/分析/可視化
- マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
- 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長