SnowflakeとAWSでデータ分析基盤を構成するポイントとは?(vol.4)

  • 公開日:
  • 最終更新日:

Snowflakeはマルチクラウド対応をしており、次の3つのクラウドプラットフォームのいずれかと組み合わせてデータ分析基盤を構成することが可能です。
・Amazon Web Services(以降、AWSという)
・Google Cloud Platform(以降、GCPという)
・Microsoft Azure(以降、Azureという)
※ご参考URL:https://docs.snowflake.com/ja/user-guide/intro-cloud-platforms.html

本ブログ記事では、特にAWSとの連携に注目し、SnowflakeとAWSを組み合わせてデータ分析基盤を構成する際のポイントについてわかりやすく解説します。

Snowflake と AWS で構成するデータ分析基盤 ~Amazon Redshiftとの違い~

データ分析基盤を構成する際、データウェアハウス(以降、DWHという)の選定は、極めて重要な検討ポイントです。
Snowflakeはマルチクラウド対応をしており、AWS/GCP/Azureいずれかのクラウドサービス上で稼働します
例えば、SnowflakeのクラウドプラットフォームとしてAWSを採用した場合、AWSサービスとの親和性が非常に高くなり、サービス間の連携を実現しやすくなります。そのため、AWSユーザがDWHを選定する場合でも、Amazon RedShiftに加え、Snowflakeを検討対象にするケースが増えています。
そこで、本章では、Amazon RedShiftとSnowflakeの違いを解説します。
下図は、コストの考え方や拡張性などの観点で比較した表です。

Amazon Redshift Snowflake
コストの考え方 選択するノードタイプ・利用時間でコストが決定。
ノードタイプによって、vCPU・メモリ・ストレージ容量・I/OなどのDWH性能が異なり、時間単価も変わる。
処理の料金とストレージ料金が分離されている。
処理の料金は、ウェアハウス(コンピュート)のサイズ(処理性能)と利用時間で決定する。サイズのみをフレキシブルに変更可能。
ストレージ容量
拡張時の対応
ノードタイプのアップグレードで対応 自動で拡張。
利用するストレージ量に対して請求。
同時接続増加
への対応
ノードタイプのアップグレードで対応 処理の目的ごとのウェアハウス単位で並列化して対応。

なお、2022年7月より、Amazon Redshift Serverlessの提供が開始されました。自動スケール、利用時間での課金という点で、従来のRedshiftとは異なるサービスとなっています。

Snowflake と AWS で構成するデータ分析基盤 ~Amazon S3 を活用しよう~

SnowflakeとAWSでデータ分析基盤を構成する場合、データレイクとして「Amazon S3」が活躍します。
Snowflakeにはステージという概念があります。ステージとは、Snowflakeから参照できるデータファイル置き場のことです。
ステージには「内部ステージ」と「外部ステージ」があり、その名のとおりSnowflakeの内部にファイル置き場が存在するケースと、クラウドストレージなどの外部にファイル置き場が存在するケースがあります。

SnowflakeのクラウドプラットフォームとしてAWSを採用した場合、内部ステージはAmazon S3に作成されます。
また、外部ステージとしてAmazon S3を利用することもできます。

例えば、他システムからの出力データファイルをAmazon S3に配置し、Snowflakeの外部ステージとしてAmazon S3を参照します。すると、Snowflakeからデータファイルにアクセス可能となり、データファイルをSnowflakeのテーブルにinsertすることが可能となります。反対に、Snowflakeのデータを外部ステージのAmazon S3上に出力し、他システムからAmazon S3に取得しに行くことも可能です。
このように、Amazon S3をSnowflakeと他システムとの連携に活用することで、システム間のデータ連携が容易になるというメリットが生まれます。

Snowflake と AWS で構成するデータ分析基盤 ~豊富なデータ連携機能~

前章では、Amazon S3を経由したデータファイルの授受により、Snowflakeとのデータ連携が可能であることを解説しましたが、Snowflakeには、データ連携処理をSnowflake上で構築するための機能が多数搭載されています。本章では、これらの機能について解説します。

  • Webインターフェースからのロード
    Snowflakeが提供するWebインターフェースを利用して、データファイルをロードする機能です。
    ただし、ファイルサイズは最大50 MBの制限があるため、当機能はテストデータのアップロードなど、限られた用途での利用となります。
  • Snowflakeタスク
    時間起動や前処理の終了をトリガーとして、SQLやストアドプロシージャの実行などのタスクを自動実行する機能です。データロード処理をSnowflakeタスクとして定義することで、逐次バッチ的なデータロードを実現します。
  • Snowpipe
    ステージ上のファイルが利用可能になり次第、自動でロードする機能です。SnowpipeとAmazon SQSによる通知を組み合わせることで、継続的なデータロードを実現します。
    例えば、外部システムから継続的にAmazon S3にデータファイルが出力されるようなケースでは、下記のフローで、Amazon S3へのファイル受信をトリガーとしたSnowflakeへのデータ連携を実現します。

    <Snowpipeによるデータ連携フロー(例)>
    1. 外部システムから、データファイルがステージ(Amazon S3)に出力される。
    2. Amazon S3のイベント通知は、データファイルの到着をAmazon SQSを介して自動でSnowpipeに通知する。
    3. Snowpipeはデータファイルをキューイングする。
    4. キューイングされたデータをSnowflakeのテーブルにロードする。

Snowflake と AWS で構成するデータ分析基盤 ~AWS PrivateLink でセキュアな接続~

Snowflakeへのアクセスは、通常インターネットを介して通信します。しかし、AWS Private Linkを構成することで、Snowflakeのアカウントを1つ以上のAWS VPCに直接接続することができます。この場合、インターネットを経由しないため、セキュアな接続を実現することができます。

例えば、自社のVPC内に、TableauなどのBIツールをインストールしたサーバとしてAmazon EC2があり、BIツールのデータ参照先としてSnowflakeを利用する場合を考えます。このとき、Private Linkを構成することで、パブリックインターネットを経由せず、Amazon EC2が属するVPCとSnowflakeを直接接続できます。

<Private Linkでの接続イメージ図>

Snowflake と AWS で構成するデータ分析基盤 ~まとめ~

さてこれまで、SnowflakeとAWSを組み合わせてデータ分析基盤を構成する際のポイントについて、次の観点で解説して参りました。

  • DWHの選定におけるAmazon RedShiftとSnowflakeの比較
  • Snowflakeとのデータ連携におけるAWSサービスの活用
  • AWS環境とSnowflakeのセキュアな接続方法

本記事をとおして、SnowflakeとAWSの親和性の高さや、AWSサービスと組み合わせることのメリットをご理解いただけたのではないでしょうか?

弊社電通総研は、Snowflakeを使用したデータ基盤の”短期”構築を実現すべく、導入テンプレート「SnowBase」を開発しました。
SnowBaseは、SnowflakeとAWSでデータ分析基盤を構成する際に活用できる導入テンプレートです。「拡張性と柔軟性を持つ全社横断のデータ基盤を短期に構築したい」といったご要望がございましたら、是非、電通総研へお声掛けください。

◆ お問い合わせページ:https://itsol.dentsusoken.com/snowflake/inquiry/

*本記事は、2022年12月1日時点の情報を基に作成しています。
 製品・サービスに関する詳しいお問い合わせは、電通総研のWebサイトからお問い合わせください。