組織でデータを管理している場合、部門間でデータを連携したいという場合があると思います。
例えば、データエンジニアリング部門が用意したデータをユーザ部門がBI開発のために利用する、といったケースです。

このような場合に、必要とするデータを発見→利用申請→利用承認→利用開始というステップを踏むことになりますが、そのデータ利用フローはSnowflakeの純正機能だけで（外部のカタログツールを使わずに）実現可能です。

本記事では、Snowflakeの基本的なデータカタログ機能に加え、上記のデータ利用フローを実現する方法について具体的な例とともにご紹介します。

事前準備

以下のSQLを実行し、必要なユーザおよびロールの作成と設定をしておきます。

USER ROLE ACCOUNTADMIN;

-- ユーザ作成
CREATE USER TARO PASSWORD='taro123';
CREATE USER JIRO PASSWORD='jiro123';

-- ロール作成
CREATE ROLE ROLE_DE;
CREATE ROLE ROLE_USER;

-- ロール付与
GRANT ROLE ROLE_DE TO USER TARO;
GRANT ROLE ROLE_USER TO USER JIRO;

-- ロールへの権限付与
GRANT CREATE DATABASE ON ACCOUNT TO ROLE ROLE_DE;
GRANT MANAGE GRANTS ON ACCOUNT TO ROLE ROLE_DE;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE ROLE_DE;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE ROLE_USER;
GRANT CREATE SHARE ON ACCOUNT TO ROLE ROLE_DE;
GRANT CREATE ORGANIZATION LISTING ON ACCOUNT TO ROLE ROLE_DE;

-- ロールの継承
GRANT ROLE ROLE_DE TO ROLE SYSADMIN;
GRANT ROLE ROLE_USER TO ROLE SYSADMIN;

リネージの取得、参照

サンプルのデータベース、スキーマ、テーブル、ビューを作成します。

以下のSQLをロールROLE_DEのユーザTAROとして実行します。

USE ROLE ROLE_DE;

-- データベース、スキーマ作成
CREATE DATABASE DB_DE;
CREATE SCHEMA SALES;

-- テーブル作成
CREATE TABLE products (
  id INT,
  name STRING,
  unit_price FLOAT
);

CREATE TABLE daily_sales (
  id INT,
  product_id INT,
  quantity INT,
  sales_at TIMESTAMP
);

-- データ挿入
INSERT INTO products VALUES
(1, 'Desktop', 800),
(2, 'Laptop', 400),
(3, 'Monitor', 100);

INSERT INTO daily_sales VALUES
(1, 2, 2, '2024-01-14 09:00:00'),
(2, 3, 3, '2024-01-15 10:00:00'),
(3, 1, 1, '2024-01-16 15:00:00'),
(4, 3, 1, '2024-02-01 11:00:00'),
(5, 1, 2, '2024-02-01 11:00:00');

-- ビュー作成
CREATE VIEW sales_view AS
WITH sales_view AS (
  SELECT
    d.id AS id,
    p.id AS product_id,
    p.name AS product_name,
    d.quantity * p.unit_price AS sales,
    d.sales_at AS sales_at
  FROM daily_sales d
  LEFT JOIN products p
  ON d.product_id = p.id
)
SELECT
  product_id,
  product_name,
  SUM(sales) AS total_sales,
FROM sales_view
GROUP BY 1, 2
ORDER BY 1, 2;

作成したテーブルとビューは以下の通りです。

• テーブル
  • products：製品データを格納したテーブル
  • daily_sales：売上データを格納したテーブル
• ビュー
  • salesview：productsとdailysalesから作成した売上確認用ビュー

テーブルやビューを作成すると、それらの関係が自動的に取得され、「Lineage」タブで参照できるようになります。

ビジネスメタデータの登録・編集

「データ」→「データベース」から個別のテーブルやビューを確認し、テーブルや列のメタデータを登録、編集することができます。

※説明は自分で入力できるほか、Copilotに生成してもらうことも可能です。

「Search」から関連するテーブルやビューを検索することができます。
検索は部分検索や自然言語による検索にも対応しています。

今回の場合、「売上」と検索したらdaily_salesやsales_viewが表示されました。

データ共有と権限制御

データ利用フローの要となるデータ共有と権限制御について、通常の場合と内部マーケットプレイスを利用する場合のそれぞれについて詳しく見ていきます。

通常の場合

オブジェクトへのアクセス権設定

上記で作成したサンプルデータについて、以下のようにアクセス権を設定します。

※ロールROLE_DEのユーザTAROとして実行します。

-- SALESスキーマを全員から参照可能にする
-- 実際のデータを見るためにはSELECT権限が必要
GRANT USAGE ON DATABASE DB_DE TO ROLE PUBLIC;
GRANT USAGE ON SCHEMA DB_DE.SALES TO ROLE PUBLIC;
GRANT REFERENCES ON ALL TABLES IN SCHEMA DB_DE.SALES TO ROLE PUBLIC;
GRANT REFERENCES ON ALL VIEWS IN SCHEMA DB_DE.SALES TO ROLE PUBLIC;

この場合、組織内の全員がDB_DE.SALESスキーマ内のテーブルとビューの情報を参照できます。

ロールROLE_USERのユーザJIROはテーブルやビューのメタデータを参照できますが、SELECT権限が与えられていないため実際のデータのプレビューや参照はできません。

現在の状態を図式化すると以下の通りです。

連絡先の設定

Snowflake では、データベース、スキーマ、テーブルに対して連絡先を設定することができます。

以下のように「Contact」を作成し、それを対象のオブジェクト（今回はスキーマ）に割り当てることで、データの利用者が適切な連絡先に連絡を取ることが可能になります。

-- Contact作成
CREATE CONTACT db_admins
  USERS = ('FUMA');

-- SALESの連絡先設定
ALTER SCHEMA SALES SET CONTACT ACCESS_APPROVAL = db_admins;

設定した連絡先は、以下のように詳細ページに表示されます。

※親オブジェクトに設定した連絡先は子オブジェクトにも継承されます。例えば、データベースに連絡先を設定した場合、その配下のスキーマやテーブルにも同じ連絡先が表示されるようになります。

内部マーケットプレイスを利用する場合

オブジェクトの共有設定

以下のようにSQLを実行し、シェアを作成します。

-- シェア作成
CREATE SHARE db_de_share;
GRANT USAGE ON DATABASE DB_DE TO SHARE db_de_share;

-- シェアの確認
SHOW SHARES;

「Data sharing」→「Provider Studio」で「Create listing」を開き、「Internal Marketplace」をクリックします。

リストの設定を行います。

「アクセス制御」でアクセス可能な組織やアカウントを設定できます。

アクセス（access）と検出（discovery）は以下を設定可能です。

• アクセス
  • 組織全体
  • 選択したアカウントとロールのみ
  • 事前承認されたアカウントまたはロールなし
• 検出
  • 組織全体
  • 選択したアカウントとロールのみ
  • アクセスのないユーザにより発見されない

今回は以下の内容で設定しました。

• アクセス：事前承認されたアカウントまたはロールなし
• 検出：選択したアカウントとロールのみ（現在のアカウントのPUBLICロール）

アクセスを設定し公開すると、以下のように内部マーケットプレイスから利用できるようになります。

※ユーザJIROで確認した例。アクセスリクエストにあたり、ユーザJIROに姓、名、メールアドレスを設定しておく必要あり。

「Request access」をクリックすると、以下のポップアップが表示されます。

リクエストを送信すると、連絡先のユーザに通知メールが届きます。リンクを開いてリクエストを確認し、アクセス権の付与を実行します。

リクエストが承認されて内部マーケットプレイスのデータが利用できるようになると、「Data products」というタブが追加され、共有対象のデータを確認できるようになります。

また、以下のようにSQLを実行することで、データを参照することができます。

SELECT * FROM ORGDATACLOUD$INTERNAL$SALES_DATA.SALES.products;

テーブルやビューの指定は、通常のクエリと異なり Uniform Listing Locator（ULL）を使用します。ULLは、上記クエリのように<LISTING>.<SCHEMA>.<TABLE>という形で表されるリソースの識別子です。

補足

共有リソースにおいても、CURRENT_ACCOUNTのようなコンテキスト関数を使ったRLSが機能します。例えばプロバイダー側のテーブルにRLSが適用されている場合、コンシューマー側には条件を満たす一部のレコードしか表示されません。

補足：共有方法の使い分けについて

通常の共有と内部マーケットプレイスには以下の違いがあります。

	通常	内部マーケットプレイス
共有対象	組織内	グローバル
権限付与	手動で付与（※1）	簡単
オブジェクト共有先	カタログ	カタログ
データ探索	〇	〇

※1：利用者側が連絡先にコンタクトを取り、SQLで権限を付与してもらう必要あり

組織内でデータを連携したい場合、利用承認までSnowflake上で完結しスムーズにデータを連携可能な内部マーケットプレイスの利用をおすすめします。

参考

• 【Snowflake】Internal Marketplace/Organizational Listingについて知ろう
• Sharing with row access policy applied - Governance & Security - Snowflake
• 総コストについて | Snowflake Documentation