❄️

SnowflakeのLIST機能とInternal Marketplaceを使ってリージョン間データ共有を試す

に公開

はじめに

Snowflakeのリージョン間データ共有を試してみたら、思った以上に簡単だったのでご紹介します。
Snowflakeにはデータ共有の方法が3つあります。

No データ共有方法 概要
1 リスト - 組織内で自由にデータの共有が行える多対多の関係
- クロスリージョンにも対応
2 直接共有
(Secure Data Sharing)
- 組織内の同一リージョンアカウントに対して共有可能
- 一対一の関係
- レプリケーション機能を利用することでデータプロバイダーが異なるリージョンとクラウドプラットフォーム間でデータ共有が可能
3 Data Exchange - サポートへ依頼し有効化してもらう必要がある
- 組織内外など特定のグループに属するコンシューマとデータ共有可能
- おそらくクロスリージョン対応(※参照)

今回検証してみたのはリスト機能です。
同じ組織内で利用しているSnowflakeで異なるリージョン間でデータを共有したい場合、このリスト機能は非常に有効です。
さらにCross-Cloud Auto-Fulfillmentを利用すれば、共有したいデータを対象のリージョンのSnowflake環境に自動でデータ連携をサポートしてくれます。

3つのデータ共有についてもう少し詳細な内容を本記事の末尾にも記載しておりますので、気になる方は読んでいただければと。
リストについて
直接共有について
Data Exchangeについて

実践!リスト機能を使ったクロスリージョンデータ連携

環境について

  • Free trialアカウントを利用(US West (Oregon)リージョンのEnterprise Editionと)する
  • データ共有側のリージョンをUS Westとし、データ利用側のリージョンをAsia Pacific (Tokyo)としEnterprise Editionとする
  • データ利用側アカウントはUS WestアカウントのORGADMINより払い出すこと

注意事項

  • 本来はデータ共有のロールを用意するのがベターですが、あくまで動作検証のためなのでACCOUNTADMINを利用しています。
  • アクセス制御の要件を確認し、必要な権限を用意できること(Free trialアカウントを利用していれば大丈夫です)

共有するデータの準備(US West (Oregon)リージョンで実施)

use role ACCOUNTADMIN;
create database TEST_SHARE_DB;
create schema TEST_SHARE_DB.TEST_SHARE_SCHEMA;
create table TEST_SHARE_DB.TEST_SHARE_SCHEMA.TEST_SHARE_TABLE (
    plant_name string
    , rooting_depth string
);
INSERT INTO TEST_SHARE_DB.TEST_SHARE_SCHEMA.TEST_SHARE_TABLE (plant_name, rooting_depth)
VALUES
    ('Kohlrabi', 'S'),
    ('Leeks', 'S'),
    ('Lettuce', 'S'),
    ('Okra', 'D'),
    ('Onions', 'S'),
    ('Parsnips', 'D'),
    ('Peas', 'M'),
    ('Peppers, hot', 'M'),
    ('Peppers, bell', 'M'),
    ('Potatoes', 'S'),
    ('Pumpkin', 'D'),
    ('Radishes', 'S'),
    ('Spinach', 'S'),
    ('Rutabaga', 'M'),
    ('Spinach', 'D'),
    ('Squash, summer', 'M'),
    ('Squash, winter', 'D'),
    ('Sweet potato', 'D'),
    ('Tomatoes', 'D'),
    ('Turnips', 'M'),
    ('Zucchini', 'D');

organizational listingの作成(US West (Oregon)リージョンで実施)

  1. Snowsightへサインイン
  2. 画面左メニューバーの「Data Products」項目のProvider Studioをクリック
  3. 「Listings」項目に移動し、画面右上の「Create listing」をクリック
  4. 「Internal Marketplace」をクリック

organizational listingに共有データを設定(US West (Oregon)リージョンで実施)

organizational listingの作成ステップの続き

  1. 「+ Add data product」をクリック
  2. 「+ Select」をクリック
  3. 先ほど作成した「TEST_SHARE_TABLE」にチェックを入れ、「Done」をクリック
  4. 「Save」をクリック

organizational listingにアクセス制御を設定(US West (Oregon)リージョンで実施)

  1. 「+ Access control」をクリック
  2. どのようにデータへアクセス許可させるかの方式を決める
    「Who can access this data product?」パラメータ
パラメータ 説明
Entire organization (default) 組織内の誰もがリストを検出して、アクセスを要求できます。
Selected accounts and roles 選択されたアカウントとロールのみが、リストを検出してアクセスを要求できます。
No accounts or roles are pre-approved アクセス権を持つユーザーだけがこのリストを発見できます。

各パラメータ設定パターンの動作イメージ

No Grant Access Allow discovery result
1 Selected accounts and roles Entire organization - 指定のアカウントのみデータへアクセス可
- 発見は組織内の全てのアカウントで可
2 Selected accounts and roles Selected accounts and roles - 指定のアカウントのみデータへアクセス可
- 発見も指定のアカウントのみ可
3 Selected accounts and roles No accounts or roles are pre-approved - 指定のアカウントのみデータへアクセス可
- 発見はGrantAccess指定のアカウントのみ可
4 No accounts or roles are pre-approved Entire organization - データへのアクセスは許可制
- 発見は組織内の全てのアカウントで可
5 No accounts or roles are pre-approved Selected accounts and roles - データへのアクセスは許可制
- 発見は指定のアカウントのみ可
6 No accounts or roles are pre-approved No accounts or roles are pre-approved 誰もこのデータ製品を見ることもアクセスすることもできない
現在の設定に基づくと、社内のマーケットプレイスや検索結果を通じて、誰もこのデータ製品にアクセスしたり、発見したりすることはできません。

※上記表のアカウントの意味は全て組織内のアカウントを意味しています

Entire organization

Entire organizationを選択すると、Allow discoveryはEntire organization以外選択出来ないようになります。
Additional setup needed項目が表示されるので「Review listing auto-fulfillment」の設定を行うことができます。
これは、organizational listingのデータ製品がリージョン間で自動的に伝播され、手作業による複製が不要になります。

Review listing auto-fulfillment settingsの設定

Data product refreshのパラメータ

パラメータ 説明
Time interval 特定の時間周期にデータを伝播させる設定、単位はN分、N時、N日、N週を選択できます
Scheduled time CRON式で伝播スケジュールを設定可能になります

今回はデータ伝播の動作検証もしたいので、10分おきに伝播させるとしました。

organizational listingに必要な情報を設定する

設定項目 設定値
TITLE TEST_SHARE_DATA
Description test share data
Data dictionary 共有するデータをプレビューできるようにする(後述に設定方法を記載)
Usage examples 共有データのクエリの使い方を記述
Details Support ContactとApprover Contact用のEメールアドレスを設定(この設定により画面右上の「Publish」することが可能になるっぽい

Data dictionary設定手順

  1. 「Add data dictionary and data preview (visible to users with discovery permissions)」部分をクリックする
  2. 以下スクショとおりに、共有テーブルに対して、「+ Add to Featured」をクリックし、画面右下の「Save」で保存する

最終的にこのような設定としました。

organizational listingをInternal Marketplaceへ公開

最後に画面右上の「Publish」をクリックします。

Internal Marketplaceで共有データを確認する

「Data Product」->「Martketplace」->「Internal Marketplace」

東京リージョンのSnowflake側で共有データを確認する

US WESTリージョンで作成した東京リージョンのアカウント:KYAMISAMAへアクセスし、「TEST_SAHRE_DATA」へSELECTできることを確認します。

「Data Product」->「Martketplace」->「Internal Marketplace」へとアクセスするとTEST_SHARE_DATAが表示されています。

TEST_SHARE_DATAをクリックし、画面遷移後右上の「Get」をクリックします。

データ利用者のプロフィルを記入し、「Save」します。

プロファイルに設定したEメールアドレスの確認を行うためのEメールが送られます。
もしいくら待っても届かない場合は「Re-send verification email」をクリックし再送要求をします。

確認用Eメールが届くのを待ちます・・・・
3分ほどで以下のようなEメールが届きました。
「VALIDATE YOUR EMAIL」をクリックします。

Eメール確認が完了しました。

スクショを撮り損ねたのですが、Eメール検証が完了後、TEST_SHARE_DATAに対してリクエストを送信します。
以下スクショはリクエスト送信後の画面で、「Requested just now」となっています。
リクエストした際の画面には最低でも10分はリクエスト処理に時間がかかると記載がありました。
なので少し待ちます。

5分程度経過後に画面を更新すると、「Query in worksheet」の文字に変わっており、クリックします。

別タブが開き、SQLワークシート画面に遷移しています。

TEST_SHARE_DATAに対してSELECTクエリを実行できました。

ここで注目したいのが、TEST_SHARE_DATAが存在する場所ですが、SQLワークシート画面の左のバーにDatabasesとWorksheetの横にData Productsが存在しており、TEST_SHARE_DATAはそこに存在しています。

データ伝播の動作検証

それではUS WESTリージョンのデータ共有元でデータを更新してみましょう。
現在のデータ行数をカウントすると21行です。

次にUS WESTリージョンのSnowflakeにて、以下クエリをテストレコードを1行追加します。

INSERT INTO TEST_SHARE_DB.TEST_SHARE_SCHEMA.TEST_SHARE_TABLE (plant_name, rooting_depth)
VALUES
    ('TEST', 'TEST');

データ伝播間隔時間が10分に設定するので、少し待ちます。
東京リージョン側でCOUNTクエリを実行し、カウントが22となっていることを確認します。

終わり

いかがでしたでしょうか。とっても簡単にリージョン間でのデータ共有が行えることがわかると思います。
これまで直接共有しかやったことがありませんでしたが、直接共有と同じくらい簡単に構築できると感じました。
さらにデータ共有へのアクセスも指定のアカウントのみ許可するや、リクエスト許可制にするなどよくあるユースケースに対応しており、使い勝手は非常に良いと感じました。

Appendix

Snowflakeのデータ共有機能について

用語説明

データプロバイダー(データ提供側)

データプロバイダーは、共有を作成し、それらを他のSnowflakeアカウントが利用できるようにするSnowflakeアカウントです。
データプロバイダーとして、データベースを1つ以上のSnowflakeアカウントと共有します。
共有するデータベースごとに、Snowflakeは許可を使用して、データベース内の選択したオブジェクトに詳細なアクセス制御を提供(つまり、データベース内にある1つ以上の特定のオブジェクトに対するアクセス権限を許可)します。

共有はいくつでも作成でき、1つの共有にいくつでもアカウントを追加できます。
多数のアカウントに共有を提供したい場合は、 リスト または データ交換 を使用することをお勧めします。

データコンシューマー(データ利用側)

データコンシューマーは、データプロバイダーにより提供される共有から、データベースの作成を選択したアカウントです。
データコンシューマーとして、インポートされたデータベースをアカウントに追加すると、アカウント内にある他のデータベースの場合と同じように、データベース内のオブジェクトにアクセスしてクエリを実行できます。

データプロバイダーから提供された共有はいくつでも使用できますが、共有ごとに作成できるデータベースは1つだけです。

リスト

https://other-docs.snowflake.com/ja/collaboration/collaboration-listings-about
リストを使用すると、データやその他の情報を他の Snowflake ユーザーに提供したり、Snowflake プロバイダーが共有するデータやその他の情報にアクセスしたりできます。
リストは、 Secure Data Sharing を強化した方法であり、同じプロバイダーおよびコンシューマーモデルを使用します。
次のような特徴:

  • 特定のアカウントに非公開でリスト(共有するデータ)を提供することも、 Snowflake Marketplace で公開することもできる
  • さらにInternal Marketplaceを利用すれば組織内のアカウントのみにデータ公開を限定できる
  • クロスリージョンにも対応しており、Auto-fulfillmentを有効にするとリージョン間のデータ伝播を自動で行ってくれる

直接共有(Secure Data Sharing)

https://docs.snowflake.com/ja/user-guide/data-sharing-intro

次のような特徴:

  • アカウント間で実際のデータのコピー、または転送はされません
  • リージョン内の別のアカウントに特定のデータベース(共有)を直接共有できる
  • 共有データはコンシューマーアカウントのストレージを占有しないため、コンシューマーの毎月のデータストレージ料金に課金されません
  • コンシューマーへの課金は、インポートされたデータのクエリに使用されるコンピューティングリソース(つまり仮想ウェアハウス)に対するもののみ

このアーキテクチャにより、Snowflakeは、複数のコンシューマー(組織内を含む)および複数のプロバイダーからのインポートされたデータにアクセスできるコンシューマーと、データを共有できるプロバイダーのネットワークを実現できます。
alt text

Data Exchange

https://docs.snowflake.com/ja/user-guide/data-exchange

Data Exchangeを使用すると、Data Exchangeに参加している整合性のあるビジネスパートナーの特定のグループ(社内の部門、または社外のベンダーや、サプライヤー、パートナーなど)にデータを簡単に提供できます。
組織内外のさまざまなコンシューマーとデータを共有したい場合は、特定のコンシューマーに提供されるリストや Snowflake Marketplace で公開されているリストを使用することもできます。
次のような特徴:

  • 招待した特定のメンバーのグループとデータを安全にコラボレーションするためのデータハブです
  • これにより、プロバイダーとして、交換に参加しているコンシューマーが発見できるデータを公開できます
  • Data Exchangeを使用すると、Data Exchangeに参加している整合性のあるビジネスパートナーの特定のグループ(社内の部門、または社外のベンダーや、サプライヤー、パートナーなど)にデータを簡単に提供できます

組織内外のさまざまなコンシューマーとデータを共有したい場合は、特定のコンシューマーに提供されるリストや Snowflake Marketplace で公開されているリストを使用することもできます。
alt text

Discussion