概要
本記事では、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 をデータ共有のプロトコルとして活用する事例を発表しており、これが今回の検討のきっかけの１つとなっています。
さらに、Snowflake 上での Apache Iceberg 機能の検証を行う機会を得たことから、新機能を活用した Databricks 利用者向けのデータ共有方法を検討しました。Snowflake 上での Apache Iceberg 機能について以下の記事で紹介しています。
Databricks のテーブルを Snowflake で共有する方法
Databricks のテーブルを Snowflake で共有するにあたって、現実的なアプローチとして以下の 3 つが考えられます。
なお、3 の「Databricks から Snowflake 標準テーブルへデータ同期」手法は、開発・運用コストが高いため優先度が低いと判断し、ここでは主に 1 と 2 に焦点を当てます。
- Delta Lake ディレクトリを外部カタログ Iceberg テーブルとして登録
- UniForm 対応テーブルを外部カタログ Iceberg テーブルとして登録
- Databricks から Snowflake 標準テーブルへデータを同期
検証の結果、1 の手法は Databricks への認証情報登録が Snowflake 側で不要であり、Databricks・ストレージ・Snowflake が疎結合となるため、開発や運用がシンプルになるという利点があります。それぞれの詳細手順は以下の記事をご参照ください。
- Databricks の Delta Lake ディレクトリを Snowflake にて Secure Data Sharing する方法 #Databricks - Qiita
- Databricks の UniForm が有効なテーブルを Snowflake にて Secure Data Sharing する方法 #Databricks - Qiita
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 の自動最適化機能（予測最適化など）は無効化を忘れないようご注意ください。
5. 異なるリージョン間でのデータ共有
Databricks と Snowflake が異なるリージョンに導入されている場合、Snowflake 側のリージョンに合わせたストレージを新たに構築し、DEEP CLONE を用いてデータを反映する方法が推奨されます。
DEEP CLONE を利用すると、シンプルな構文で増分データだけを転送できるため、効率的なデータ同期が実現可能です。
出所：Databricks上でテーブルをクローンする | Databricks Documentation
以上の内容を踏まえ、Databricks と Snowflake を組み合わせたデータ共有環境の構築を検討する際の参考になれば幸いです。