Amazon Athenaで小さく始めるデータ分析 - コドモン Product Team Blog

こちらの記事は「コドモン Advent Calendar 2022」の 24日目の記事です 🎁

こんにちは、コドモンSREチームの菅野です。いよいよクリスマス・イブですね。子どもにプレゼントがみつからないかヒヤヒヤドキドキしております。

今回はお手軽にデータのETL処理ができるAmazon Athenaの定期実行を紹介します。

コドモンではデータの分析をする際にAmazon Athenaを利用することがあります。使っていくうちに「よく見る結果は集計した状態で置いておきたい」や「簡単な加工をしたい」場面がでてきました。

いわゆるETL(Extract/Transform/Load)と呼ばれる処理で、そのなかでも特に小さく短時間で終わるものについては、LambdaからAthenaを定期実行する形で行っています。

構成について

EventBridge RuleからLambdaを定期実行し、Lambdaの中でAthenaにクエリを実行するのが基本的な動きです*1。

Athenaで実行するSQLは、S3にファイルでアップロードしておき、EventBridge実行時のパラメータで指定しています。また、EventBridgeはまれに複数回起動することがある*2 とのことで、念のためにDynamoDBも置いて一度に1回のみ実行されることを担保しています。

事前にCTASクエリでテーブルを作成しておき、定期実行時はINSERT INTOクエリでデータを追加しています。

CTASクエリはCleate Table As Selectのことで、SELECT文で実行した結果からテーブルを作成できます。

CTASで作成したテーブルに対しては、INSERT INTO文を発行することでさらにSELECT結果を追加していくことが可能です。

下図はCTASクエリ発行時のデータのイメージです。Athenaでクエリを実行するとS3からデータが検索され、テーブル情報がGlue Datacatalogに作成されます。結果のデータはクエリ時に指定した新しいS3パス上に書き込まれます。

差分更新ではなくUpdate系の処理がしたい場面では、S3の結果データを削除し新たにINSERT INTOをして洗い替えでいまは対応しています。

「EventBridge ＋ Athena ＋ Lambda」構成のよいところとして、使用した分のみにコストが抑えられる点があげられます。一度Lambdaを作ってしまえば、SQLを増やしていくだけで拡張もできます。

反面、SQLを1回実行するだけのシンプルなことしかできないため、要件がこの構成に向いている場合のみ利用し、合わない場合は別の方法を利用する、と割り切って使っています。

具体的には、前後に依存関係がある場合や処理が複雑・長時間に及ぶ場合は、AWS Step Functions、AWS GlueもしくはAmazon Redshiftのほうが向いているように感じます。

コドモンでは現在この構成で主に集計系の処理を行っています。

SQLだけで書けること、導入や管理コストがあまりかからない点が便利に感じています。

最後まで読んでいただいてありがとうございました！