❄️

【Snowflake】Internal Marketplace/Organizational Listingについて知ろう

まつば~ら

2025/02/12に公開

 本記事の内容Organizational listingとは？ Internal Marketplaceとは？ 何ができるのか？ 実際の動作と権限制御について紹介していきます

 はじめにOrganizational listing / Internal Marketplaceは組織内でセキュアにガバナンスを効かせ、そして共通のデータアクセスの手法をもたらす画期的な機能です. 特に巨大な組織において Deta Meshを実現する上では必須の機能と言えるでしょう！

 Internal MarketplaceとOrganizational listingがもたらす世界
同じOrganization配下のSnowflakeアカウント間でのデータ共有を高度化・簡易化します

特定のアカウントにデータを共有するだけではなく、Organization配下の全てのSnowflakeアカウントを対象にデータを公開共有することも可能です

また、共有する際にはそのアカウントどどのRoleに共有するか設定することも可能です

データを共有された全てのアカウントで、そのデータへのアクセスに利用するクエリ文を全く同じにすることができます(後述：ULL)

 Organizational listing
 基本的な考え
データを共有する構成を見てみましょう

 Share Object・「Data」まず、「Share Object」を見てみます. これは、共有するデータを集めたオブジェクトです.
例えば、クエリを用いてデータベースを共有するShareを作成する場合は
CREATE SHARE test_share;
GRANT USAGE ON DATABASE test_db TO SHARE test_share;
のようなクエリを実行します
参考: Organizational Listingに紐付けたShare Objectは "to"カラムが「TARGETED WITHIN ORGANIZATION」になります.
SHOW SHARES;

 「List」 Object次に、「List Object」を見てみます. これは、共有するデータのカタログのようなものです.

Share Objectのデータがどんなデータか？責任者は？使用例は？等様々なメタデータが取りまとめられます.

Organizational listingの場合は、組織内に公開するか/組織内の特定のアカウントに公開するか、承認式にするか、等々の設定を行うことになります.
以上のように、Organizational listingは基本的にPrivate Listingなどの方式と大きな相違がないことがわかります（Share objectの部分は変わりありません）

変わる部分は、

・データ提供側のListの設定

だけです.

Organizational listingで新しく登場した設定値については、この後詳しく説明します.

 Internal Marketplace
 「Data」と「List」の公開非公開等の設定の組み合わせで多様なデータ連携手続きのパターンをカバーします
「Data」と「List」のアクセス制御の組み合わせをOrganization配下に限定するOrganizational Listingを利用することで組織内のデータ連携の利便性を向上しています.
Marketplaceの組織限定版

Uniform Listing Locator(ULL) が利用可能（後述）
既存のSharing方式と組み合わせて利用可能（同一オブジェクトのSharingなどに一部制約あり）

 各種設定Internal Marketplaceでは、大きく分けて２つの制御軸があります.

⭐️ １つ目が「List」の共有設定、２つ目が「Data」の共有設定です.

 データ提供アカウントにおいてSnowsight UI [Data Products/データ製品]→[Provider Service/プロバイダーStudio]→[Listing]から右上の＋Listingをクリックし、Internal Marketplaceをクリック

ListのDraftが作成されます.

指示に従い、共有するDataを選択します（※省略）.

そして、本listとDataをどのように共有していくかを設定します.

 「List」の共有設定作成したList (Organizational Listing) は、同じOrganization配下のアカウントに対して下記のいずれかの設定を行い共有することが可能です
🔷全てのアカウントが本Listを検索発見し、「Dataへのアクセス権」取得のリクエストをあげることができる

🔷特定のアカウント（かつ特定のRole）が本Listを検索発見し、「Dataへのアクセス権」を要望するリクエストをあげることができる

🔷「Dataへのアクセス権」があるアカウントが本Listを検索発見できる
例：「特定のアカウントが本Listを検索発見できる」及び「対象のアカウントの特定のRoleのみが検索発見できる」を指定した場合（①、②）


 「Data」の共有設定Listに含まれるDataを同じOrganization配下のアカウントに対して下記のいずれかの設定を行い共有することが可能です
🔶全てのアカウントが本Dataへアクセスすることができる

🔶特定のアカウント（かつ特定のRole）が本Dataへアクセスすることができる

🔶 「Dataへのアクセス権」を要望するリクエストが承認されたアカウントが本Dataへアクセスすることができる
必要な権限と注意点🔷全てのアカウントが本Listを検索発見し、「Dataへのアクセス権」取得のリクエストをあげることができる

🔶全てのアカウントが本Dataへアクセスすることができる
を実現するには、下記３つの権限が必要です.
GRANT CREATE ORGANIZATION LISTING ON ACCOUNT TO ROLE XXXX;
GRANT CREATE DATA EXCHANGE LISTING ON ACCOUNT TO ROLE XXXX;
GRANT MANAGE LISTING AUTO FULFILLMENT ON ACCOUNT TO ROLE XXXX;　※注意！！
🚨 ここで注意が必要なのが、３つ目の「MANAGE LISTING AUTO FULFILLMENT」です.

これは、通常では実行できません.実行するには下記の２つの方法があります.

ORGADMIN Roleを利用する
<例>：
USE ROLE ACCOUNTADMIN;
GRANT CREATE ORGANIZATION LISTING ON ACCOUNT TO ROLE XXXX;
GRANT CREATE DATA EXCHANGE LISTING ON ACCOUNT TO ROLE XXXX;
USE ROLE ORGADMIN;
GRANT MANAGE LISTING AUTO FULFILLMENT ON ACCOUNT TO ROLE XXXX;

ORGADMIN Roleを持たないアカウントでは、ORGADMIN Roleを持つアカウントから権限を委任してもらって実行する
<例>：

ORGADMIN Roleを持つアカウントA内で、ORGADMIN Roleを持たないアカウントBに対して権限を委任
ORGADMIN Roleを持つアカウントA内で実行
USE ROLE ORGADMIN;
SELECT SYSTEM$ENABLE_GLOBAL_DATA_SHARING_FOR_ACCOUNT(
  'アカウントB'  // アカウント識別子です　（ URL: https://アカウントB.snowflakecomputing.com）
  );
ORGADMIN Roleを持たないアカウントB内で実行
USE ROLE ACCOUNTADMIN;
GRANT CREATE ORGANIZATION LISTING ON ACCOUNT TO ROLE XXXX;
GRANT CREATE DATA EXCHANGE LISTING ON ACCOUNT TO ROLE XXXX;
GRANT MANAGE LISTING AUTO FULFILLMENT ON ACCOUNT TO ROLE XXXX;
🔷特定のアカウント（かつ特定のRole）が本Listを検索発見し、「Dataへのアクセス権」を要望するリクエストをあげることができる

🔷「Dataへのアクセス権」があるアカウントが本Listを検索発見できる

🔶特定のアカウント（かつ特定のRole）が本Dataへアクセスすることができる

🔶 「Dataへのアクセス権」を要望するリクエストが承認されたアカウントが本Dataへアクセスすることができる
上記を実現するには下記の権限が必要です
GRANT CREATE ORGANIZATION LISTING ON ACCOUNT TO ROLE XXXX;
GRANT CREATE DATA EXCHANGE LISTING ON ACCOUNT TO ROLE XXXX;
ACCOUNTADMINを用いて権限付与が可能です.
すべての設定が終わると、下記のようにStatusがLive状態で表示されます.

 データ受取アカウントにおいてSnowsight UI [Data Products/データ製品]→[Marketplace]→[Internal Marketplace/内部Marketplace]から提供されたListを検索


 データへのアクセス今回はデータ提供アカウント側で、List/Dataを検索可能&リクエストなしで利用可能な共有としました.

そのため、すぐにアクセスが可能です.

共有されたデータはデフォルトでは下記のようにSnowsight UIで表示されます.
右枠に新しく「Data Product/データ製品」という新しい枠が用意されそこに表示されます.
!Uniform Listing Locator(ULL) を用いたアクセス
本データへのアクセスは少し変わっています。

通常下記のようにSQLを実行しアクセスするでしょう.
select * from <database>.<schema>.<table>;
一方、本データへのアクセスは
select * from <provider’s organization name>$<provider profile>$<listing name>.test.test;

//  <provider’s organization name>$<provider profile>$<listing name> = <databasename>
になります.

つまり、今まで<database>だったものが、<provider’s organization name>$<provider profile>$<listing name>に置き換わるということです.
これが、Uniform Listing Locator(ULL) です
基本的にSnowflake内であれば

・<provider’s organization name>はORGDATACLOUDです.

今回、Internal Marketplaceを利用しているため、

・<provider profile>はINTERNALになります.

そして、最後の

・<listing name>はlistの名前になります.
select * from ORGDATACLOUD$INTERNAL$TEST_ORGANIZATIONAL_LISTING.test.test;
ただ.....これをいきなり書けと言われても難しいわけです. そのため、Snowsight UI上で表示されたテーブルをダブルクリック or 「名前をコピー」して、Worksheetに転記してもらいましょう.
Uniform Listing Locator(ULL) の何が嬉しいの？見慣れない方式で、慣れるまでに少し時間がかかるかもしれません.

一方、時として非常に利便性の高いものになります.

一つは、データのSingle Source of Truthをわかりやすく担保できることです.

Internal Marketplaceで同じデータを共有された別のアカウントでも同じSQLを流用してデータへのアクセスが可能になります.

 まとめInternal MarketplaceとOrganizational Listingを利用することで、よりセキュアに簡単に組織内でのデータ連携を実現できます.

特に、データ提供者側でデータ提供先であるデータ受取側のアカウントだけではなくRoleも指定できるようになったことで、よりデータの高いガバナンス/アクセス制御をデータ提供側でコントロールできるようにもなりました. ※もちろんそれを十全に機能させるためにはデータ受取側アカウントのRole設計ルールを組織内で意識合わせしておくことが必要ではあります.
本機能は特に大規模で複数の組織を抱える会社には非常に強力な機能になるのではないでしょうか？

ぜひ、お試しください.
※次回は、Icebergと絡めてInternal Marketplaceを用いたData Meshの構成について記載できればと思います.

 参考https://docs.snowflake.com/en/user-guide/collaboration/listings/organizational/org-listing-about