概要

本記事では、Snowflake の Secure Data Sharing 機能を活用した Databricks ユーザー向けのベストプラクティスを紹介します。
2025年3月17日現在、Databricks 上の Delta Lake ディレクトリを Snowflake の外部カタログ Iceberg テーブルとして登録し、Snowflake を介してデータ共有する方法が、シンプルさや運用のしやすさの面で最も有力なアプローチです。ただし、Snowflake 側で将来的に機能拡張が行われる可能性があるため、その動向には注意が必要です。

主なアプローチとそれぞれの懸念事項を以下の表にまとめました。

方法番号	手法	懸念事項
1	Delta Lake ディレクトリを外部カタログ Iceberg テーブルとして登録	Snowflake において、将来的に実装されるその他の Iceberg テーブルの機能と差異が生じる可能性がある。
2	UniForm 対応テーブルを外部カタログ Iceberg テーブルとして登録	Databricks 側での認証情報管理が必要となり、UniForm 対応テーブル運用時のオペレーション負荷が増大する。
3	Databricks から Snowflake 標準テーブルへデータを同期	データ連携用のシステム開発・運用コストが大きくなる。

本記事では、こうした背景や各手法の特徴を整理したうえで、具体的に活用可能なテクニックを詳しく解説します。これにより、Snowflake の Secure Data Sharing を最大限に活用したい Databricks ユーザーが、より適切な方法を選択できるようになることを目指します。

検討の背景

Databricks 上のデータを他組織に提供する際、受け手が Snowflake ユーザーであれば、Secure Data Sharing を活用することで低コストかつ効率的なデータ利活用が可能と考えました。2024年9月12日に日本で開催された「SNOWFLAKE WORLD TOUR TOKYO」にて、Spark ユーザーである AEON 社が、Snowflake をデータ共有のプロトコルとして活用する事例を発表しており、これが今回の検討のきっかけの１つとなっています。

出所：データ連携をチートせよ。～イオンが目指すコネクティビティデータ基盤～ / Aeon's goal of creating a connectivity data platform - Speaker Deck

さらに、Snowflake 上での Apache Iceberg 機能の検証を行う機会を得たことから、新機能を活用した Databricks 利用者向けのデータ共有方法を検討しました。Snowflake 上での Apache Iceberg 機能について以下の記事で紹介しています。

Snowflake における Apache Iceberg の機能の完全ガイド： Apache Iceberg on Snowflake 活用の第一歩 #Spark - Qiita

Databricks のテーブルを Snowflake で共有する方法

Databricks のテーブルを Snowflake で共有するにあたって、現実的なアプローチとして以下の 3 つが考えられます。
なお、3 の「Databricks から Snowflake 標準テーブルへデータ同期」手法は、開発・運用コストが高いため優先度が低いと判断し、ここでは主に 1 と 2 に焦点を当てます。

Delta Lake ディレクトリを外部カタログ Iceberg テーブルとして登録
UniForm 対応テーブルを外部カタログ Iceberg テーブルとして登録
Databricks から Snowflake 標準テーブルへデータを同期

検証の結果、1 の手法は Databricks への認証情報登録が Snowflake 側で不要であり、Databricks・ストレージ・Snowflake が疎結合となるため、開発や運用がシンプルになるという利点があります。それぞれの詳細手順は以下の記事をご参照ください。

Delta Lake ディレクトリを利用したデータ共有時のテクニック

1. 外部カタログ Iceberg テーブル作成時の制限

Snowflake のドキュメントには以下の制限事項が記載されています。
とくに、2025年3月17日時点で Databricks の一部環境ではデフォルト有効となっている「削除ベクトル機能」は、Snowflake 側では現状利用できない場合があるため注意が必要です。

出所：CREATE ICEBERG TABLE （オブジェクトストレージ内のDeltaファイル） | Snowflake Documentation

以下のDalta Lakeフィーチャーは現在サポートされていません。行追跡、削除ベクターファイル、変更データファイル、変更メタデータ、 DataChange 、 CDC 、プロトコル進化。

出所：CREATE ICEBERG TABLE （オブジェクトストレージ内のDeltaファイル） | Snowflake Documentation

2. AUTO REFRESH の活用と手動実行の選択肢

Delta Lake ディレクトリから作成する外部 Iceberg テーブルは、メタデータの自動更新機能（AUTO REFRESH）をサポートしています。
ただし、Databricks 側の処理で管理が可能なため、Snowflake 側でのメタデータ更新コストを抑える目的で、ALTER ICEBERG TABLE … REFRESH による手動実行を選択することも検討できます。

出所：CREATE ICEBERG TABLE (Delta files in object storage) | Snowflake Documentation

3. TIMESTAMP 型から TIMESTAMP_NTZ 型への変更

Databricks と外部システムを連携する際、TIMESTAMP 型にまつわる仕様の違いから問題が発生する場合があります。
そのため、Snowflake 連携用のテーブルとして TIMESTAMP 型を TIMESTAMP_NTZ 型へ変更することを検討してください。
ただし、TIMESTAMP_NTZ 型を運用に導入するにあたっては、チームやシステム全体での取り扱いを整理する必要があります。

出所：Apache Iceberg™ テーブルのデータ型 | Snowflake Documentation

4. 圧縮形式とファイルサイズの最適化

Snowflake のマイクロパーティション仕様に最適化した Parquet ファイル出力方法などは、以下の記事で紹介しています。
Iceberg テーブルにおいてもパフォーマンス面で必要があれば、同様の最適化を検討してください。その際、Databricks の自動最適化機能（予測最適化など）は無効化を忘れないようご注意ください。

Databricks から Snowflake のマイクロパーティションに近い仕様の Parquet ファイルを出力する方法 #Spark - Qiita

5. 異なるリージョン間でのデータ共有

Databricks と Snowflake が異なるリージョンに導入されている場合、Snowflake 側のリージョンに合わせたストレージを新たに構築し、DEEP CLONE を用いてデータを反映する方法が推奨されます。
DEEP CLONE を利用すると、シンプルな構文で増分データだけを転送できるため、効率的なデータ同期が実現可能です。

出所：Databricks上でテーブルをクローンする | Databricks Documentation

以上の内容を踏まえ、Databricks と Snowflake を組み合わせたデータ共有環境の構築を検討する際の参考になれば幸いです。