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

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

Clock Icon2023.02.05 16:36

この記事は公開されてから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 関数)の再デプロイが必要になります。

参考文献

合わせて読みたい

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.