[新機能] Amazon Athena データソースコネクタを使ってGoogle Cloud Storageのライブデータにクエリしてみました！

データアナリティクス事業本部のコンサルティングチームの石川です。先日、Amazon AthenaのFederated Queryを経由してGCS(Google Cloud Storage)にアクセスできるデータソースコネクタが新たに追加されました。ザックリ言うと、AthenaからGCSのデータにアクセスできるようになったということです！ 本日は、AthenaからGCSへのクエリについて試してみます。

Amazon AthenaのGCSのデータソースコネクタが動作する環境

データソースコネクタの実態は、Lambda関数です。今回の動作検証では、以下のような非VPC環境を用意しています。

以降では、早速試したみたいと思います！

GCSの認証情報をSecrets Managerに作成

Google Cloudのサービスアカウントの秘密鍵を取得

事前にGCSにアクセスするためのGoogle Cloudのサービスアカウントを用意して、そのアカウントの秘密鍵を取得します。

秘密鍵は、jsonフォーマットでファイルをダウンロードします。

Secrets Managerに登録

Step1: [Other type of secret]を選択、次に[Plaintext]を選択して先程の秘密鍵の中身をコピーして、[Next]ボタンに進みます。

Step2: Secret nameを指定して、[Next]ボタンに進みます。

Step3: ストアした秘密鍵を自動的にローテーションできないため、変更することなく[Next]ボタンに進みます。

Step4: 変更することなく[Store]ボタンを押すとSecretの作成完了です。

デプロイが終わりますと、SecretのARNが割り当てられます。SecretのARNは、作成したSecretはSecretにアクセスするためのキーとして、以降で利用します。

GCSのデータソースコネクタを試してみる！

Serverless Application Repositoryから検索

利用に先立って、Serverless Application Repository（東京リージョン）の画面からデータソースコネクタを検索してクリックします。

GCSデータソースコネクタのデプロイ

データソースコネクタの実態は、Lambda Functionなので、GCSに接続するための認証情報（Secret 名）、Lambda、Spill先のパラメータを設定して、デプロイします。

Athena Google Cloud Storage Connectorは、Lambda環境変数を介して構成オプションを設定します。使用可能なパラメーターの詳細については、以下を参照してください。

パラメータ名	値の例	説明
Application name	AthenaGCSConnector	LambdaのApplication名に利用されます。デフォルト値は、AthenaGCSConnectorです。
SpillBucket	cm_spill_bucket	Lambda関数がデータをSpillさせるバケツの名前です。
SpillPrefix	cm-spill-bucket	デフォルトは、バケット内の cm-spill-bucket というサブフォルダです。Lambda関数がSpillBucket 内のフォルダに、このデータを出力先のプレフィックスです。
DisableSpillEncryption	True or False	デフォルトは、Falseです。True に設定すると、Spillしたデータの暗号化は無効になります。
GCSSecretName	dev/devio/gcs	Secrets Managerのキー名を指定します。
LambdaFunctionName	athena-federated-query	LambdaのFunction名です。
LambdaMemory	3008	Lambdaのメモリサイズを指定します。（128〜3008MB）
LambdaTimeout	900	Lambdaの実行タイムアウトを指定します。（1〜900秒）
PermissionsBoundaryARN	arn:aws:iam::123456789012:policy/athena-cgs-connector	今回は特に指定していません。（オプション）作成されたLambda関数の実行ロールのPermissionsBoundaryとして使用するIAMポリシーARNです。

※ spillとは、メモリ内に保存しきれないデータを共有ストレージ（この場合はS3）に一時的に退避することを表します。例えば、spill dataは「あふれたデータ」といった意味でとらえてください。

デプロイが開始すると以下の画面に遷移し、画面下にLogical IDのリンクが表示されます。

データソースコネクタの実態は、Lambda Functionです。Logical IDをクリックすると、Lambda Functionの画面が表示されます。

デプロイ状況の確認

データソースコネクタは、CloudFormationでデプロイされますので、デプロイの状況は、CloudFormationの画面から確認できます。なお、データソースコネクタの削除（アンデプロイ）は、このCloudFormationのスタックを削除します。

テーブルの作成

GlueのコンソールからGlueテーブルを作成します。

　

Include pathには、GCSのフォルダのパスを指定します。（ファイルのパスではない。）

Schemaの指定で、CSVファイルのカラム名とデータ型を指定します。

確認して、[Create]を押すとテーブルが作成されます。

クエリの実行

デプロイしたデータソースコネクタでクエリした結果は、以下のとおりです。GCS上のデータが、Amazon Athenaでも同じように表示されることを確認できました。

Partition分割について

今回、パーティション分割しておりませんが、GCSの場合もAthneaと同様に、Hive と非 Hive の両方のパーティションスキームをサポートしています。この設定は、Glueテーブルを作成する際に設定できます。

最後に

Athenaのfederated QueryのGCSのデータソースコネクタを用いると簡単に、GCSのデータにアクセスできることが確認できました。GCSライブデータとAthenaのデータをアドホックにブレンディングして分析できるようになります。このデータソースコネクタを作成しておけば、Glueテーブルを作成する際にGCSのパスを設定するだけで済み、汎用的な利用も可能になります。

以前に検証したBigQueryのデータソースコネクタは、VPC Lambdaが前提であるため、VPC/SubnetやNATの準備が必要でしたが、GCSは非VPC環境が前提で設計されています。そのため、GCS側がインバウンドに対するIPアドレス制限が設定できないことはご了承ください。

データソースコネクタは、オープンソースで公開していますので、仕様の詳細を確認したり、ユースケースに合わせて実装を見直し、デプロイするということも可能です。今回は、Version 2023.5.4をデプロイしましたが、数日前からバージョンが更新されたり、マニュアルに新たねパラメータが追加されたり、まだまだ進化の過程なのかも知れませんので、継続的に機能や品質の改善する可能性があります。その場合は、データソースコネクタ（Lamnbda 関数）の再デプロイが必要になります。

参考文献

合わせて読みたい