S3とGCSのSnowpipeの設定方法を比べてみた

おはようございます、祥です。

今回は直近の案件で利用したS3とGCSに対するデータの自動取り込み（Snowpipe）について設定方法や両クラウドストレージ間での設定の違いなどをまとめていきたいと思います。

💡急ぎの方向けの要約はこちら

Amazon S3向けのSnowpipe自動化

S3バケットへのアクセス許可の設定（AWS操作）
1. ポリシー、ロールを作成し、ロールにポリシーを紐づける
クラウドストレージ統合の作成（Snowflake操作）
S3向けSnowflakeアカウントのIAM情報を取得（Snowflake操作）
1. DESC INTEGRATIONコマンドでSTORAGE_AWS_ROLE_ARN とSTORAGE_AWS_EXTERNAL_ID の値を確認
作成したロールに対するアクセス権限付与（AWS操作）
イベント通知設定 -前半-（Snowflake操作）
1. 3つのオプションが準備されているが、今回はS3イベント通知で設定
2. 外部ステージを作成
3. パイプ作成
4. SQSのARN取得
イベント通知設定 -後半-（AWS操作）
1. S3のイベント通知を設定

クラウドストレージ統合の作成（Snowflake操作）
GCS向けSnowflakeアカウントのSA情報を取得（Snowflake操作）
1. DESC INTEGRATIONコマンドでSTORAGE_GCP_SERVICE_ACCOUNTの値を確認
バケットオブジェクトに対する権限付与（Google Cloud操作）
1. カスタム IAM ロールの作成
2. 取得したSAに対してロールを割当
Pub/Subの設定（Google Cloud操作）
1. Pub/Subトピックの作成 ※CLIでの操作
2. Pub/Subサブスクリプションの作成
3. Pub/Subサブスクリプション ID の取得
通知統合の作成（Snowflake操作）
Pub/Sub向けSnowflakeアカウントのSA情報を取得（Snowflake操作）
1. DESC INTEGRATIONコマンドでGCP_PUBSUB_SERVICE_ACCOUNTの値を確認
Pub/Subに対する権限付与（Google Cloud操作）
1. 対象サブスクリプション：取得したSAにPub/Sub Subscriberロールを付与
2. Google Cloudのプロジェクト：取得したSAMonitoring Viewerロールを付与
クラウドストレージ統合の作成（Snowflake操作）
パイプの作成（Snowflake操作）
履歴ファイルをロード（Snowflake操作）
1. ALTER PIPEコマンドのREFRESHコマンドを利用しパイプ開始前に作成された未取り込みデータを取り込む

パイプ開始前に作成されたデータについては、取り込みができないためALTER PIPEコマンドのREFRESHオプションを利用して取り込みをおこないます。

このオプションは、パイプとターゲットテーブルの両方のロード履歴をチェックしてくれるため、未取り込みデータのみを取得することが可能です。

手順のステップ数だけ見ると、Amazon S3のほうが手順が少なく、容易に設定が可能。
- Amazon S3はイベント通知で設定を行ったため手順が少なくて済みましたが、SQS＋SNSやEventBridgeを利用する場合は手順が増え、GCSと同様のステップ数となりそう。
Google Cloud Storageは、一部操作をCLIで実施する必要があり、若干難易度が高め。
PIPE開始前の未取り込みデータは、ALTER PIPEコマンドのREFRESHオプションで取り込みましょう。（運用のことも考えたオプションを追加するSnowflakeステキです。）