Snowflake Native Appsとはなにか？

Snowflake Native AppsとはSnowflakeの提案するデータ共有の新しいカタチです。
本記事では、データ共有とそれに関係するSnowflakeの歴史を深堀りし、Snowflake Native Appsに対する理解を深めていただくことを目的としています。

データを共有する難しさ

現代において、データは新たな「資源」として認識されています。しかしデータの価値は、単に所有することでは生まれません。データの価値はそのデータを本当に必要とする人々の手元に届けられ、適切に分析されることで初めて生まれます。
Snowflake登場以前は、そもそもデータを他社へ共有・販売することは非常に困難なことでした。

全てのデータが売買できる世界を作るまで

Snowflakeは、このデータ共有に関する課題に挑みました。「全てのデータが売買できる世界を作る」という世界観のもと、革新的な機能を追加していきます。最初に追加されたのがダイレクトシェアです。

ダイレクトシェアは、あるアカウントからある特定のアカウントにデータベースを共有する機能です。
これにはシェアと呼ばれるオブジェクトを使用しており、データのダンプやコピーを行うことなく、第三者のアカウントとデータを安全に共有できます。

４ステップでダイレクトシェアを使って理解する

簡単に使いかたを確認して動作を理解してみましょう。
プロバイダーアカウントでSHAREオブジェクトにテーブルなどのデータを『梱包』して、コンシューマーアカウントでDBオブジェクトとして『展開』するようなイメージで使う事ができます。

1. シェアオブジェクトを作る

   CREATE SHARE TEST_SHARE
   

2. シェアオブジェクトにデータベース・テーブルを読み込む権限をつける（梱包）

   GRANT USAGE ON DATABASE DB TO SHARE TEST_SHARE;
   GRANT USAGE ON SCHEMA DB.SCHEMA TO SHARE TEST_SHARE;
   GRANT SELECT ON TABLE DB.SHARE.TABLE TO SHARE TEST_SHARE;
   

3. シェアオブジェクトに共有先アカウントを指定する

   ALTER SHARE TEST_SHARE ADD ACCOUNTS=TEST_ORG.TEST_ACCOUNT;
   

4. コンシューマーアカウントで、シェアオブジェクトからデータベースを作る（展開）

   CREATE DATABASE TEST_SHARE_DB FROM SHARE TEST_ORG.TEST_ACCOUNT.TEST_SHARE
   

ダイレクトシェアの問題点

しかし、ダイレクトシェアには、クラウドプロバイダーまたはリージョンが異なると共有できないという問題がありました。

利用可否	プロバイダーアカウント	コンシューマーアカウント
○	AWS 日本リージョン	AWS 日本リージョン
×	AWS 日本リージョン	AWS USリージョン
×	AWS 日本リージョン	Azure 日本リージョン

どうしても共有したい場合は、コンシューマーと同じクラウドプロバイダー・リージョンにアカウントを開設し、シェアオブジェクトとデータを手動で複製した後に共有する必要がありました。

リスティングの登場

このようなクロスプロバイダー・クロスリージョンにおけるダイレクトシェアの問題を解決するために、リスティング機能が導入されました。リスティングは、シェアオブジェクトをラップする機能で、シェアオブジェクトの複製作業を自動で行います。これにより、コンシューマーの需要に対する手動作業が不要になりました。

全てのデータが売買できる世界へ

ダイレクトシェアとリスティングの機能により、データプロバイダーは一切操作を行う必要がなくなりました。これによって、マーケットプレイスでデータを自動的に販売することが可能になりました。

シェアオブジェクトの問題点

しかし、シェアオブジェクトには「データ処理プロセス」を格納できないというデメリットがありました。例えば、Pythonストアドプロシージャを使ってGA4からデータを取り込むプロセスなどは、会社によって異なるということはなく共通化できるはずですが、そういったデータ処理プロセスを共有する方法はありませんでした。

全てのデータ・データ処理プロセスが売買できる世界へ

Snowflake Native Appsの登場

２０２３年６月シェアオブジェクトの問題点を解決するために、Snowflake Native Appsが登場しました。
Snowflake Native Appsの実体はApplication Packageオブジェクトです。これは進化したシェアオブジェクトと言えます。プロバイダーアカウントで「データ処理プロセス」を「梱包」して、コンシューマーアカウントで「展開」する入れ物です。シェアオブジェクトの代わりにApplication Packageオブジェクトをリスティングに載せることで、マーケットでPythonストアドプロシージャなどを配布する事ができます。

Secure Data ShareとSnowflake Native Appsの比較

コマンドが異なるだけでほぼ同じように動作することがわかると思います。

特徴	Secure Data Share	Snowflake Native Apps
シェア方法	シェアオブジェクト＋リスティング	App Packageオブジェクト＋リスティング
格納できるオブジェクト	テーブル、ビュー、SQL UDF	テーブル、ビュー、任意のUDF、任意のファイル(ステージ)、任意のストアドプロシージャ
入れ物	SHARE	APPLICATION PACKAGE
中身	DATABASE	APPLICATION
梱包コマンド	CREATE SHARE <name>	CREATE APPLICATION PACKAGE <name>
展開コマンド	CREATE DATABASE FROM SHARE <name>	CREATE APPLICATION FROM APPLICATION PACKAGE <name>

表: Secure Data ShareとSnowflake Native Appsの対応表

Application Packageオブジェクトとシェアオブジェクトの違い

Application Packageオブジェクトをインストールすると、Applicationオブジェクトが展開されます。シェアオブジェクトによって展開されるデータベースオブジェクトとApplicationオブジェクトの主な違いは以下の通りです。

1. 必ず1つのステージを持つ。ステージは必ず特定の構造（ルートにmanifest.ymlを持ち、これが1つのセットアップスクリプト(setup.sql)を指す）
2. 展開時にセットアップスクリプトが実行可能
3. Appというタブに表示されるStreamlitオブジェクトを指定可能
4. Application内で独自のロールを定義出来る。

Snowflake Native Appsの問題点

しかし、Snowflake Native Appsにも課題がありました。それは既存のデータ処理プロセスの資産を再利用できなかったことです。Snowflake Native Appsではデータ処理プロセスの実装として、SQL、PythonまたはJavaのみが利用可能でした。一方、現実のデータ処理プロセスはRustやJavascript、Rなどで書かれている場合があり、なかなか既存のデータ処理プロセスの共有・移行は進まなかったのです。

拡張するSnowflake Native Apps

そのような問題がありましたが、2024年のData Cloud Summitでその問題点を解決するための機能群が発表されました。

Snowpark Container Serviceとの統合（Public Preview）

Snowflake Native AppsとSnowpark Container Serviceが統合されました。
この統合により、任意のUIや任意の言語で書かれたデータ処理プロセスをSnowflakeに展開することが可能になりました。

Snowflake Trail（Public Preview）

Snowflake内のデータ処理プロセスが複雑化するにつれ、コスト管理や説明可能性のための可観測性が重要になってきています。Snowflake TrailはEvent TableやOpen Telemetryを用いたログの集約などを行います。

Snowflakeは、データの共有からデータ処理プロセスの共有へと、その世界観を毎年進化させつづけています。

PR

RAKUDEJI株式会社は、世界で一番Snowflakeに詳しい会社を目指し、Snowflakeに特化したサービスを提供しています。
豊富な経験と知見を活かし、貴社のデータ活用を安全かつ効果的に加速させるお手伝いをいたします。Snowflake,Streamlit,AIに関するお困りごとやご相談がございましたら、ぜひRAKUDEJI株式会社の公式サイトからお気軽にお問い合わせください。
また、Snowflakeに世界一詳しくなりたいエンジニアも採用中です！まずはカジュアル面談からどうぞ！