この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
データアナリティクス事業本部のコンサルティングチームの石川です。先日、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 関数）の再デプロイが必要になります。
4
