データ共有サービス比較：Snowflake Secure Data Sharing と Databricks Delta Sharing

1. はじめに

近年、組織内外やマルチクラウド間でのデータ共有ニーズは飛躍的に高まっています。特に、Snowflake Secure Data Sharing（SSDS） と Databricks マネージド Delta Sharing（DDS） は、エンタープライズ向けマネージドデータ共有サービスとして注目を集めています。

Snowflakeが切り拓いた「セキュアかつリアルタイムな企業間データシェアリング」のビジョンは、組織の垣根を超えた協業を加速させる新時代の扉を開きました。データを物理的にコピーすることなく、瞬時に共有できるSecure Data Sharing機能により、企業は余分なETL作業やセキュリティリスクを低減しながら、社内外とのコラボレーションやデータ連携をスムーズに実現できるようになりました。

またDatabricksもデータ共有サービスとして、オープンスタンダードのDelta Sharingを提供したことで、データの自由な流通と共同分析がさらに広がり、業界全体が”データ経済圏”へと進化を遂げつつあります。

SSDS、DDSいずれも自社でサーバー構築・運用を行うことなく、両社が提供するマネージドサービスによりデータ共有を実現できますが、その設計思想、ネットワークアーキテクチャ、運用要件には大きな違いがあります。
これらの違いや強みを理解した上で、それぞれを活用することで、より良いデータ共有基盤の構築が可能となり、データ活用の更なる高度化を目指していけるのではないかと考えています。

図1: Snowflake Secure Data Sharingのアーキテクチャ（Snowflake公式ドキュメントより）


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

図2: Databricks Delta Sharingのアーキテクチャ（Databricks公式ドキュメントより）


https://docs.databricks.com/aws/ja/delta-sharing/

2. データ共有サービスの概要と比較

さて、この2つのデータ共有サービスは業界のデータ活用を進める上で非常に重要なサービスと考えています。
Snowflakeというプラットフォームを前提としたデータ共有サービスであるSSDS、オープンソースのDelta Sharingを元にDatabricksが拡張し、データ共有サービスとして提供するDDS。
この2つのサービスをどのように比較すればよいか、非常に頭を悩みましたが、それぞれの思想を理解しつつ、できる限りフラットな目線で評価をしたいと思います、

さて、この記事を書くにあたり、共通的な呼称を最初に定義したいと思います。

ユーザー呼称

• データの提供側、提供元、送信元：Provider
• データの利用側、利用先、受信側：Consumer

閉域化の呼称
プラットフォームにより呼称が異なりますので、本記事では、閉域化に関する呼称はAWSの呼称である、「VPC」や「PrivateLink」で表現します。AzureやGCPをご利用の方は、AWSのサービスに対応するそれぞれのプラットフォームのサービスに置き換えて読んでください。

これらの定義した用語を使いつつ、それぞれのデータ共有サービスの特徴をつかんでいきたいと思います。

2.1 SSDS：Snowflake Secure Data Sharing

Snowflakeがマネージドサービスとして提供するデータ共有機能、Secure Data Sharing（SSDS） は、Snowflakeアカウント間（S2S）に限定されるものの、Snowflakeプラットフォーム内の閉域ネットワークを介してリアルタイムかつメタデータ参照型のセキュア共有を実現します。
Snowflake は「クライアントの種類や接続方式を問わず、同一のクエリエンジン最適化がバックグラウンドで一貫提供される」ため、ユーザーはどのリージョンの共有オブジェクトであっても同じパフォーマンス恩恵を受けられます。
またSSDSには関連する機能が多くあり、本記事では基本的にはSSDSとクロスクラウドデータ共有機能を持つListingにフォーカスを当てています。

Data Exchange: 特定のSnowflakeアカウント（社内部門や外部パートナーなど）をメンバーとして招待し、そのグループ内でデータをカタログ化・公開・管理するコラボレーションハブ機能。

Listing: Data ExchangeやMarketplaceで公開するデータ製品のメタデータを一覧化し、利用者に発見・申込を促すカタログ表示とクロスクラウド自動フルフィルメント機能。

Secure Data Sharing: 任意のSnowflakeアカウント間でテーブルやビューをコピー不要にリアルタイム共有する基盤機能。RBACや行レベルセキュリティでアクセス制御を行い、MarketplaceやData Exchangeに依存しない汎用的な共有手段。

また、データ共有機能の一つである Snowflake Reader Account（SRA） は、外部組織向けに提供することで、Snowflakeアカウントを持たない任意のConsumerへデータ共有が可能です。これによりConsumerのクライアント環境（BI ツール、SQL クライアント等）から直接SRAへ接続する事ができます。Providerは、データ共有と合わせて、コンピュートリソースも提供するため、Consumer側はSRAへ接続するだけで、大規模な集計等を高速に実行する事ができます。一方でSRAには次のような特徴と制約がありますので理解しておきましょう。

Reader Account（SRA）の特徴

• パフォーマンス：クエリエンジン最適化（パーティションプルーニング、キャッシュなど）が適用され、外部クライアント側でもSnowflakeの高速なクエリエンジンの利用が可能。
• コスト負担：クエリ実行にかかるコンピュートクレジットはProvider側で消費し、Consumer側は追加コストなしでクエリが可能。（Consumerに相当額を負担させるかはビジネス要件次第）
• ネットワーク統合：Reader Account を特定のプライベート接続に紐づけ、閉域環境からアクセス可能。自社アカウントと分離し、SRAのみConsumer側と閉域接続が可能
• 操作制約：データ変更を伴う DML（INSERT/UPDATE/DELETE）や DDL（CREATE/ALTER/DROP）は実行不可。ただし、Providerが定義したビューや UDF、Streamlit アプリの呼び出しを伴う読み取りクエリは可能。
• オブジェクト制約：Providerが提供したオブジェクト以外の追加・削除操作は不可。（参照データを元にした二次加工やConsumerデータとの組み込みはできない）

つまり、SRAの提供とは、「データ共有＋コンピュートリソースのポータブルサービス」であり、自社契約下の共有元アカウントとは切り離した独立環境をConsumer側へ提供することを指します。

補足：本記事造語「S2C（Snowflake-to-Consumer）」とは

SRAの「データ共有＋コンピュートリソースのポータブルサービス」は、ConsumerへSnowflake機能を提供する（Snowflake-to-Consumer＝S2C）こととなります。それによりConsumerの様々なクライアント環境（Python、SQLクライアント、BIツールなど）がSnowflakeへ接続し、直接データを取得できる外部共有方式を実現します。
Provider側がConsumerへ包括的なサポートを行うことで、Consumer側の基盤構築や運用負担を軽減できるため、データ活用ビジネスにおける適用可能性が広いサービスと考えています。またセキュリティ要件をSRA単独で最適化できるため、共有元のセキュリティ要件を実装した環境への都度組み込みと比べ、組織外のConsumerとの接続や、その配下の様々なクライアント環境との接続には個別のセキュリティ要件への対応がよりしやすくなります。

2.2 DDS：Databricks Delta Sharing

Databricksがマネージドサービスとして提供するDelta Sharing（DDS） は、Databricksワークスペース間でのD2D共有に加え、D2O（Databricks-to-Open=外部クライアント向け共有） をサポートします。OSS版 Delta Sharing（ODS） とは異なり、Databricksがサーバー運用とセキュリティを一元管理します。
D2D間の認可、認証を通じて、データ共有オブジェクトに対するアクセスパスが提供され、データをコピーすることなく、オブジェクトへダイレクトにアクセスします。
そのため、共有オブジェクトへのアクセス経路について、ProviderとConsumerのネットワーク経路に準じるため、必要に応じたIPアクセスリストやストレージファイアウォール、プライベート接続など、ネットワーク・セキュリティ設定の実施する必要があります。このような設計・運用負担はあるものの、透明性のある通信経路設計が実現できます。

Databricks Delta Sharingの概念は公式動画（英語）が分かりやすいので参考にしてください。

詳細解説動画：Simplified Delta Sharing With Network Security

補足：「D2O（Databricks-to-Open Delta Sharing）」とは

Databricksがマネージド提供する Delta Sharingサービスを通じて、Databricks外のクライアント（Python/Pandas SDK、Spark、SQLクライアント、Power BIなど = Open Source Client）がDelta Sharingクライアントライブラリ経由で直接データを取得できる外部共有方式を指します。
OSS版 Delta Sharingとは異なり、Databricksプラットフォームがサーバー運用とセキュリティを一元管理します。
D2Oでは、Delta Lakeの主要な機能とサポートしており、クライアントがSparkクラスタのような並列分散環境であれば、大規模データも高速に処理することができます。一方で、BIツールのようなシングルコンピュート環境では、その環境リソース（CPU、メモリ）が制約になるケースがあります。そのようなケースにおいてはデータコピー処理やクライアントキャッシュが現実的な選択肢となる場合もあります。

• コスト負担：ストレージへのアクセスのみとなるため、コスト負担はほぼなし
• オブジェクト制約：テーブル・ビューのみ共有可能
• パフォーマンス：D2Oの場合、Sparkエンジンなどの並列エンジン以外はクライアントリソース次第

詳細解説動画よりD2D/D2Oアーキテクチャ：

2.3 データ共有基盤の評価フレームワーク

データ共有基盤を比較・選定する際の評価フレームワークとして、地理的要件、ネットワークとセキュリティ、運用面を元に総合的に判断することが重要と考えています。

このフレームワークをもとに、次章以降で一つずつ解説をしていきたいと思います。それらを元に自社の要件（利用リージョン数、セキュリティレベル、組織規模）を照らし合わせていただければと思います。

2.4 地理別機能比較およびセキュリティ要件マトリクス

表1.地理的要件について、組織の展開範囲やレイテンシ要件に応じて、データ共有基盤を「同一クラウド同一リージョン」「同一クラウド別リージョン」「別クラウド」の３パターンで比較します。またこれらの地理的要件と表2.ネットワーク＆セキュリティ＋運用フェーズとも関連性が高いため、以下マトリクスは、両サービスの主要機能・性能・コスト・運用負荷を定量的かつ実践的にまとめたものです。

ポイント解説

• 同一クラウド同一リージョン：両者ともコピーレスかつリアルタイム更新。SSDSはSnowflake管轄内通信、DDSはVPC間通信。
• 同一クラウド別リージョン：SSDSは自動レプリケーションと更新ラグ発生、DDSはバックボーン経由でリアルタイムかつストレージ直接アクセス＝ゼロコピーではあるが若干のネットワークレイテンシあり。
• 別クラウド間：SSDSは自動レプリケーションと更新ラグ発生、DDSはインターネット間通信でリアルタイムにストレージ直接アクセス≒ゼロコピー（データ転送によるエグレス料金は別途発生）ではあるが、若干のネットワークレイテンシあり。
• Snowflakeのマルチクラウドデータ共有の定義：自動レプリケーション＋更新ラグはあるが、S2Sでどのクラウドでも高速なSnowflakeクエリエンジンで実行可能（コピーレスではなく、コストも発生）。更新ラグについてはデータ量に依存する傾向があり、小規模なデータや差分更新であれば数分～十数分程度の場合もありますが、初期連携時および大規模なデータ更新時には相応の時間が掛かりますので、実際に検証いただくのが望ましいと考えています。
• Databricksのオープンデータ共有の定義：Delta SharingというOSSを中心にクラウド、リージョン、クライアントを問わず、データ共有が可能（コピーレスだが、エグレスコストと性能面では要検証）。なお、エグレスコストはデータ量および転送頻度によるため、コスト面は検証する必要があります。またCloudflare R2などエグレス料金ゼロのサービスもありますのでそれらのサービスを組み合わせることでコストを抑えることが可能です。
  性能面についてはネットワークレイテンシの影響が大きい場合はコピーするのが現実的な対応となる場合があります。

2.5 対応共有オブジェクト比較

表3.対応オブジェクトはデータ共有においてどのオブジェクトが共有できるかは重要な観点の一つです。SnowflakeはS2S前提のクローズドな印象がある一方、DatabricksもD2Dでしか共有できないオブジェクトが多く、「オープンな共有プロトコルであること」、「ベンダーロックされないこと」という点では、Databricksに依存した機能も多いあるため、フラットに評価する必要があると考えています。

ODSやD2Oについては基本的にDelta形式のデータ共有のみとなっていますが、D2DはDatabricksによる大幅な拡張がなされており、D2DはS2Sと比べ、より多くのオブジェクトタイプをシェアする事が可能です。（D2Oの対象はDelta形式のテーブルと書かれていることが多く、実態が確認できていないものもあるため、もし誤りがあったらご指摘ください。）
D2Dでは、モデルやノートブックのデータ共有が行えるため、データコラボレーションやData Clean Roomにおいて、より深いビジネスロジックやサービスの共有ができる点に魅力を感じます。これらについてSnowflake側も追随していくことが重要になってくると考えています。

2.6 データアクセス制御（SSDS ／ DDS）

さて、表2.セキュリティの要素の一つとして、データアクセス制御があります。これらについても考察をしたいと思いますが、結論から先に申し上げるとSSDSとDDSはデータアクセス制御において基本機能に大きな差はないと考えられます。

2.7 選択指針フローチャート

これまでの情報をもとにデータ共有基盤をどのように選択していくのが良いかをまとめたいと思います。

Step 1: プラットフォーム起点

• Snowflake 環境同士 → S2S
• Databricks 環境同士 → D2D

両プラットフォームを併用している場合は、目的ごとに最適な方式（S2C／D2O）を選択してください。

Step 2: 外部クライアント多様性

• SQL クライアント中心 → S2C Reader Account／D2O Spark エンジン
• Python／BI ツールなど多数環境 → S2C Reader Account／D2O（Token＋短命 URL）

同じプラットフォームを使用していない場合は、クライアントからの接続環境として提供

Step 3: セキュリティ要件

• 一般的なセキュリティレベル（IP制限や認可認証など制御） → SSDS／DDS
• 高度なセキュリティレベル（高度コンプライアンス） → SSDS 同一リージョン限／DDS Private化

Snowflakeの場合、S2Sの経路そのものはSnowflakeマネージドですが、2.4で触れた通り、リージョン違いの場合、Snowflake管轄のその通信経路はドキュメントに明示的に書かれていません。

私の推測とはなりますが、CSPのバックボーン回線やインターネット間通信を利用しており、厳密な閉域通信やNon Public通信とは言えない可能性があります。（間違っていたらご指摘いただきたい。）
このSecure Data Sharingのクロスクラウド・クロスリージョンの経路詳細はぜひ開示して欲しいと思います。

一方で、閉域化が必要なケースは限られた法的要件によることが多く、ネットワークの接続制限やアクセス制御、監査要件などを適切に実装すれば、インターネット間通信であってもセキュリティ要件は満たせる事が多いため、必要性は十分に評価する必要があります。

Step 4: 運用リソース

どのパターンでもそこまで運用負荷は高くないと考えていますが、閉域間連携の場合、そもそものセキュリティ要件が高度な場合はあります。
組織で許容できる運用負荷とセキュリティ要件とのバランスを取り、判断してください。

実際の導入にあたっては、まずはS2S／D2Dから始めてみて経験と実績を積みつつ、ビジネス要件と組織要件などを鑑みて、段階的にステップアップするのが良いと考えています。

それでは、これらのステップを進めるにあたり、それぞれのデータ共有サービスに関する具体的な仕様を理解していきましょう。

3. SSDS: Snowflakeマネージド S2S+S2Cデータ共有の詳細

3.1 完全マネージドサービス

Snowflake Secure Data Sharing（SSDS）は、完全プラットフォーム委任によるデータ共有を実現します。
弊社もSSDSを用いたビジネスデータ連携において多数の実績があり、Snowflake同士のS2Sという制約はあるものの、SSDSにより、セキュアかつ安全なデータ共有を簡単に実現できます。

Snowflake公式ドキュメントよりS2Sのデータ共有図

Reader Account環境を利用したS2C共有

• コスト負担：Reader Account でのクエリ実行にかかるコンピュートクレジットはProviderアカウントが消費し、Consumerは追加コストなしでクエリを実行可能。
• 操作制限：Reader Accountはデータの変更を伴う DML（INSERT/UPDATE/DELETE）や DDL（CREATE/ALTER/DROP） が実行できません。ただし、SnowsightというSnowflakeのUIも利用可能であり、ワークスペース機能が利用できるため、SQLやノートブックの実行、Streamlit による読み取りクエリも作成可能です。
• オブジェクト固定：Providerが提供したオブジェクト以外の追加・削除操作は不可。
• ネットワーク統合：必要に応じて Reader Account を特定のプライベート接続に紐づけることで、Consumerの閉域環境から安全にアクセス可能。
• パフォーマンス：Reader Account でも Snowflake クエリエンジン最適化（パーティションプルーニング、キャッシュなど）が適用され、外部クライアントと同等の高速クエリ応答を実現。

Snowflake公式ドキュメントよりSRAのデータ共有図

3.2 認証・アクセス制御

認証方式

公式ドキュメントではこの詳細が書かれていませんが、内部のRBAC制御が引き継がれるため、公開するアカウント間の認証を行ったうえで、外部アカウントの接続に対してRBAC制御を行っていると推測されます。（間違っていたらご指摘いただきたい。）

アクセス制御機能

• RBAC：ロールベースでのデータベース・スキーマ・テーブル単位制御
• Row Access Policy：動的セキュアビューによる行レベル制御
• Dynamic Data Masking：列レベルでのリアルタイムマスキング
• 共有時自動継承：Share時に定義済みポリシーがConsumer側にも自動適用

3.3 ネットワーク経路と運用

ネットワーク経路については、Snowflakeに委任されており、同一リージョン以外は具体的な接続経路が公式ドキュメントに記載がないため、推測となります。

3.4 SSDS環境の運用管理要件

必要スキルセット

• Snowflake 管理
  Secure Data Sharing 設定

想定チーム構成

• データエンジニア：2–3名
  （SSDS 設定、共有パイプライン開発・運用）

4. DDS : Databricksマネージド D2D+D2Oデータ共有

4.1 マネージドサービスとしての特徴

DDSはUnity Catalog統合マネージドサービスとして、Databricksが内蔵Delta Sharingサーバー（Delta Sharing サービス）を完全管理します。Provider、ConsumerそれぞれのNW設計に基づいた通信経路での通信となるため、透明性のある通信経路設計が可能となります。
その分、自社での多層的なセキュリティ防御として、IPアクセスリストやストレージ層のFW制御などが必要となります。
弊社もDDSを用いたビジネスデータ連携に取り組んでおり、セキュアかつ安全なデータ共有を簡単に実現できると考えています。ただし、Snowflakeの委任型データ共有と異なり、データ共有先の企業側でネットワークやセキュリティ部門の確認の際に詳細な確認が必要となるケースもあるため、仕様を把握し、事前に実装内容の認識合わせをしておくことが重要です。

4.1.1 Databricksマネージドサービスとしての共通領域

– Delta Sharing サーバー運用・保守、プロトコル実装・アップデート
– Unity Catalog 統合認証・権限管理（Share/Recipient/Privileges）
– サービス可用性保証・災害復旧

4.1.2 自社管理領域（最小限の管理）

• Unity Catalog設定（Share・Recipient・権限）
• ネットワークアクセス経路（VPC・専用線など　※必要性があれば）
• ネットワークアクセス制御（IPアクセスリスト・ファイアウォール）
• 認証トークン管理（D2O時のみ）

4.2 共有方式別の特徴

D2D機能補足

• Databricks プラットフォーム内通信により低レイテンシ
• 共有されたテーブルでは、Consumer側でパーティションプルーニングやファイルプルーニングによる最適化が適用される
• Unity Catalog統合により、ガバナンス・監査・アクセス制御がシームレスに動作
• 履歴共有（WITH HISTORY）により、タイムトラベルクエリとストリーミング読み取りが可能
• コピーレス共有のため、同一クラウド同一リージョン以外はネットワークレイテンシの影響あり

D2O機能補足

• 外部クライアントとクラウドストレージ間のネットワーク転送が発生
• Sparkクライアント（Delta Sharing Spark connector 3.1+）では、パーティションプルーニングとファイルプルーニングが利用可能
• 非Sparkクライアント（Pandas SDK、BIツールなど）では、基本的なメタデータ利用のみ
• 非Sparkクライアントでは、パフォーマンスの充分な検証を行い、必要に応じた個別コピー
• プレサインドURLによる短期間での安全なデータアクセス
• コピーレス共有のため、同一クラウド同一リージョン以外はネットワークレイテンシの影響あり

アクセス制御機能（Databricks Unity Catalog）

• Unity Catalog RBAC：カタログ／スキーマ／テーブル／ビュー／マテリアライズドビュー／モデル／ノートブック単位でのロールベース制御
• Row-Level Security：動的ポリシーを定義し、ビューやテーブルに対して行レベルでアクセスをフィルタリング
• Dynamic Data Masking：列単位でのマスクポリシーを定義し、ユーザー属性に応じてリアルタイムにマスキング適用
• Share-Time Policy Propagation：D2D/D2O 共有時に定義済みポリシーをコンシューマーワークスペースへ自動適用

2.6で詳細に比較しているとおり、DatabricksもSnowflakeと同等の高度なアクセス制御機能を備えています。

4.3 ネットワーク経路と運用

注: Secure Cluster Connectivity（SCC）は企業のセキュリティポリシーにより選択する設定であり、
Public/Privateいずれの構成でも使用可能です。SCC有効時はクラスターに公開IPが割り当てられません。

Public通信の特徴

• 最小限のネットワーク設定で導入快速
• IPアクセスリストおよびストレージFWでアクセス制御
• クライアント環境による追加承認は不要

Private通信の特徴

• VPC内完結の通信でゼロトラスト実装
• Secure Cluster Connectivityでプラットフォーム外部からの直接アクセスを遮断
• Private DNS・証明書管理・VPN 承認など運用工数増大

データ共有フロー

• Unity Catalog間で共有オブジェクトの認可（認可）
• Delta Sharing Server間で認証とアクセスパスの提供（認証／アクセスリスト制御）
• アクセスパスに従い、ストレージへ直接アクセス（ストレージFW制御）
  上記による三層防御の構成となっており、非常にセキュアな構成となっています。

詳細解説動画

4.4 運用管理要件

DDS Public に必要なスキル

• Databricks 管理：Unity Catalog 設定・トラブルシュート
• ネットワーク：IP リスト・FW 設定
• 認証トークン：Bearer Token／OIDC 管理
• 監査ログ：クラウド＆Unity Catalog ログ統合

DDS Private に追加必要なスキル

• プライベート接続：PrivateLink／VNet Endpoints 設計・承認
• DNS／証明書：Private DNS 設定・TLS 管理
• ネットワーク運用：VPC Flow Logs 監視／VPN／専用線管理
• セキュリティ：エンドポイント承認フロー・専用線契約

4.5 Databricks Data Sharing & Collaboration 最新アップデート（2025/6-2025/8）

Databricks Delta Sharingにおける直近のアップデート計画

6月に開催された、Databricks AI Summit（DAIS）以降、Delta Sharingに関する多数の重要アップデートが発表されています。
現時点では、まだ一般提供（GA）していない機能もありますが、これらの機能はDeltaSharingの実装の簡素化やユースケースの拡大に大きな影響を及ぼすものと考えています。

https://www.databricks.com/blog/whats-new-data-sharing-and-collaboration-summer-2025

特に、Network Gateway・Iceberg対応のアップデートにより、運用負荷を軽減したデータ連携が実現できるようになったと考えています。

Network Gateway：ストレージFW設定を劇的に簡素化（3層防御のデータ層をDDSへ委任）
この「Network Gateway」により、4.3章におけるストレージFW制御をDatabricksに委任することが可能となります。
これらに伴い、認可・認証・アクセス制御の三層防御を引き続き自社運用するか、Databricksにアクセス制御となるストレージFW管理を委任するか、自社のセキュリティ要件に従い、検討する事が可能となります。

Apache Iceberg完全互換：SnowflakeともIcebergテーブル化によりデータ共有が可能となるマルチプラットフォーム共有を促進
つまり、Snowflake↔Databricks間でのIceberg経由のシームレス共有です。これにより両プラットフォームユーザーは、データコピー・形式変換なしで相互のデータ資産を活用でき、真のハイブリッドデータ戦略が現実のものとなるのではないかと考えています。
データ共有と少し話が反れますが、Snowflake/Databricksのハイブリッドデータ基盤において、Lakehouse Federationにより、Snowflakeのデータを参照することは可能ですが、データ転送時間の課題や双方のプラットフォームのコンピュートコストが二重に掛かります。
Icebergテーブル化はプラットフォームロックインからの開放と併用プラットフォーム間のコンピュートコスト最適化およびIceberg化によるストレージコスト最適化の観点で、どの企業でも今後取り組んでいくテーマになると考えています。

• Clean Rooms進化：これは今回のアップデート以前からの機能ですが、Delta Sharingを中核としたコピーレスなDCRにより、テーブルやIcebergやノートブックなど多様なオブジェクトを統合することが可能です。またLakehouse Federationにより、Snowflakeのデータも取り込めるなど、マルチプラットフォーム、マルチオブジェクトなデータクリーンルームになっていると感じており、構築にはDatabricksへの総合的な理解度を求められますが、活用用途は広いと考えています。
  

5. 実践的選択指針

データ共有はステップ論はありつつも、要件に応じた適用となるため、最適な選択を行っていきましょう。

5.1 実装パターン

ステップ1: 社内・グループ会社間連携

• 対象: 社内部門間、関連会社間
• 選択: SSDS（S2S）または DDS（D2D）

ステップ2: 社外マネージドサービス間連携①

• 対象: 外部パートナーの Snowflake/Databricks 環境間
• 選択: SSDS（S2S）または DDS（D2D）on DDS Public

ステップ3: 社外マネージドサービス間連携②

• 対象: 外部組織の多様なクライアント環境
• 選択: SSDS Reader Account（S2C） または DDS（D2O）on DDS Public

ステップ4: 機密データ・コンプライアンス対応（完全閉域）

• 対象: 規制要件、最高レベルセキュリティが必要な環境
• 選択: SSDS（同一リージョン限） または DDS Private（完全閉域）

5.2 アクションステップ

1. 要件整理: 共有対象・セキュリティレベル・パートナー環境を確認
2. 適切ステップ選択: 上記4パターンから適切な方式を決定
3. PoC 実施: 選択したパターンで小規模検証
4. 運用開始: 検証完了次第、本格運用に移行
5. 必要時拡張: ビジネス成長に応じて上位ステップへ移行

データ共有については、ビジネス起点である日突然に実装の機会がやって来ることがあります。そのため、ステップ1などは事前に自社内で検証しておくことを推奨します。

6. Snowflake／Databricksのデータ共有機能への提言

これまでの説明でそれぞれのデータ共有サービスの特徴は理解できたかと思いますので、ここからはそれぞれのプラットフォームに対し、このような機能があると良いという私なりの意見を述べさせてもらおうと思います。
データ共有サービスとしてユーザー目線での機能提案となるため、実装難易度などは若干目を瞑っておりますが、ご容赦いただければと思います。

6.1 Snowflake 向け機能拡張の提案

1. Sharing 時の通信経路オプション選択

   • 現状：データ共有はSnowflake管轄のネットワーク経理のみ
   • 提案：
   • Snowflake委任経路／ユーザー定義の２モードをコンソールで切替可能にし、通信経路を使い分けられるようにする。
   • 企業ネットワークポリシーに合わせた経路選択肢を提供し、設計自由度を向上。（必要に応じて採用）

2. クロスクラウド時のコピーレス化

   • 現状：異リージョン、異CSP間は自動レプリケーションが必要。
   • 提案：異CSP間であってもメタデータ参照型ゼロコピー共有を実現するオプションを追加。

Databricksでも異CSP間ゼロコピーはレイテンシ遅延がある上で提供しているため、Snowflakeも同様の選択肢を用意し、レプリケーション不要のハイブリッド運用を可能にしても良いと考えます。1と合わせることで、Delta Sharing同等の機能を提供できると考えています。

3. Shareable オブジェクトの多様化
   • 現状：テーブル／ビュー／マテリアライズドビューのみ。
   • 提案：
   • Notebook（Snowsight Notebook）や Worksheet、Streamlit アプリなどを Share オブジェクトとして列挙し、Consumer が参照可能に。
   • データ＋コード＋ドキュメントを一元的に配信・管理できるハイブリッド共有を実現。

NotebookやStreamlitについてはPythonのバージョンやライブラリ依存などの問題が生じます。それらを回避するため、Native Appsという、ある意味コンテナ化してシェアする機能もありますが、より簡便な形式があるとよいと考えています。
DatabricksではMLflowにおいて、それらのオブジェクトをシェアすることが可能となっており、Snowflakeのオーケストレーション機能の拡張とともに必然的にSSDSの対象となるのではないかと考えています。

SimplicityがSnowflakeの最大の良さと理解しており、その恩恵は弊社も最大限に享受していますが、ネットワーク経路の明確さが求められるケースもあり、それらを選択できる状態にすることが重要と考えています。

6.2 Databricks 向け機能拡張の提案

1. Azure テナント内複数 Unity Catalog サポート
   • 現状：1 Azure テナント（契約）につき、1リージョン 1Unity Catalog制約。
   • 提案：
   • 単一テナント単一リージョン内で複数Unity Catalogインスタンスを管理可能とし、ワークスペース／チーム単位でカタログ分離を実現。
   • テナント追加コスト・運用負荷を削減し、大規模組織での採用を容易化。
     　 – 補足：
   • ホールディングス体制などCSP契約が親会社管轄の場合、テナント追加が難しい
   • DatabricksもSnowflake Reader Accountのようなサブアカウント的な機能があると良いという発想

これはピンとこない方もいるかもしれませんが、SnowflakeユーザーからするとDatabricksはCSPとの依存度が強く、またUnity Catalogは強力な管理機能を有していますが中央集権的すぎる点があり、データメッシュ的な使い方やS2Cのような使い方をするにはハードルがあると考えています。
子会社やグループ会社用にテナントを全て分ければ解決可能ですが、日本に多いホールディングス制では親会社がCSPとの契約を管理している事も多く、子会社や関連会社からするとなかなか踏み込めないため、Unity Catalogが独立管理できると良いなと感じています。これはどちらの製品が良いか？というよりは組織構造との相性となるため、それぞれの製品の思想と組織構造をフィットさせていく努力も必要となります。

※AWS/GCPはあまり詳しくないため、誤りがあればご指摘ください。

2. Clean Rooms の利用コスト最適化
   • 現状：クラスター常時稼働で固定費用が発生。
   • 提案：
   • Clean Rooms 用クラスターのアイドル時自動停止機能を追加し、利用時のみ起動する従量課金モデルを導入。
     　 – 補足：DCRを常時利用しない場合、固定費が下がると使いやすい。

6.3 双方への提案

• 現状：IcebergはS2S/D2D間のみ
• 提案：Icebergを通じて、S2D/D2Sのデータ共有を可能とする

Snowflake、Databricksの両方が対応しているIcebergについては、今後プラットフォームをまたいだデータ共有オブジェクトになって欲しいと考えています。
データ共有から少し話が反れますが、Snowflake、Databricks間でのデータ連携である、DatabricksのLakehouse Federationによる接続の場合、大規模データでは転送時間の課題や2つのプラットフォームの二重コストの課題が出る事もあります。
この解決策として、Iceberg化により、双方のクエリエンジンで実行できるようにすることはコンピュートコストおよびパフォーマンスの観点でも効果的な解決策となってきています。

これをさらに進め、Icebergを2つのプラットフォーム間でデータ共有できるようになれば、データ共有のオープン性をさらに高める事になり、その際にODSのIcebergネイティブ対応を行い、それをSnowflakeが利用して、S2D/D2Sを実装するのが良いのではないかと考えています。

どちらも利用している弊社としては双方の機能がより良く進化し、我々のデータ活用が一層高度化できることが最大の喜びであり、更なる発展を期待しての提言となります。

7. まとめと結論

1. SSDS はプラットフォーム完結型で運用負荷を最小化し、Snowflake間の迅速なデータ共有に最適化されており、同一リージョン以外はデータコピーと更新ラグはあるものの運用のシンプルさとどのリージョンでもSnowflakeのクエリエンジンにより高速な参照が出来るのは非常に大きな魅力。またS2Cによる外部顧客へのサービス提供もビジネス的な可能性が十分にあると感じます。
2. DDS はマネージドかつ柔軟なハイブリッドモデルで、D2Dでの高効率共有とD2Oでの多様クライアント対応を両立。特にData+Code+Model統合共有はSnowflakeにない強み。またクロスクラウド/クロスリージョンでのデータ共有ではレイテンシ考慮は必要だがゼロコピーを実現しており、OTFとしてのIcebergの対応も強みと考えます。
3. 選択の要点：自社要件とリスク許容度に応じ、S2S/S2C/D2D/D2Oのいずれかで PoC を実施し、段階的にスケールアップする運用戦略を推奨。

両社のプラットフォームを採用するユーザーはどちらも非常に多く、一方的に寄せるというのは結果として効率性の低下やビジネス機会の損失を生む可能性もあります。
我々もDatabricksで生成したデータをS2Sでデータ共有したり、またその逆にSnowflakeからDelta Table化してD2Dでデータ共有を行う事例もあります。
我々がハイブリッドなデータ基盤を構築しているがゆえの考えかもしれませんが、一元的なデータ共有基盤構築そのものに価値を感じる事は少なく、2つのデータ共有方式を使い分けながら、よりスピーディによりセキュアに、ビジネスに貢献するデータ共有を一つでも多く生み出すことが最も重要な価値と考えています。提案させてもらったようにS2D/D2Sができるとさらに多くのビジネス価値を生み出すデータ共有がより簡単に実装できると考えています。
そのためにも、この2つのプラットフォームが成長し続けてくれることが何よりも重要と考えています。両方の営業担当者から「二股の浮気者！」と怒られそうな気もしていますが、双方の製品と数年間付き合ってきたエンジニアとしての愛情表現と思い、ご容赦いただければと思います。

本記事を書くにあたり、思想の異なる２つのプラットフォームを比較するのは難易度が高く、私自身迷うことや詳細な仕様を調べていくなかで、私の認識が誤っている事に気付く事も多かった次第です。そのような中で様々な方にご多忙の中、査読やアドバイスなどの貴重なご支援を賜り、記事の品質を高める事ができたと考えています。双方のプラットフォームとの関係性の深いお立場の方も多いため、お名前を伏せさせていただきますが、この場を借りて御礼申し上げます。

本記事がデータ基盤を運用される、同じような悩みを抱える皆様の一助となれば幸いです。またここは違うんじゃないか？などのご指摘やご意見は遠慮なく、私のXアカウントのDM等でご連絡いただければと思います。

最後に、このような知見を共有したり、実践的なノウハウが学べる、それぞれの日本コミュニティを紹介させていただければと思います。

いずれも活発に活動しており、私もコミュニティに参加し、定期的にイベントへ参加をしております。
まだ参加されていない方は、これを機会にぜひご参加いただければと思います。

SnowVillage

https://usergroups.snowflake.com/snowvillage/

JEDAI
Discord

https://discord.com/invite/wuVk6UkC

ここまで読んでいただいてありがとうございました。
それではまた次の記事でお会いしましょう。