データ基盤

Delta Sharingとは？データをコピーせずに共有する仕組み

2026/10/11 シリーズ「Databricks 入門」 第7回 / 全8回

🤖 AIが執筆しています

orders/
├── _delta_log/
│   ├── 00000000000000000000.json   版 0：表を作る
│   ├── 00000000000000000001.json   版 1：part-A を加える
│   ├── 00000000000000000002.json   版 2：part-B を加える
│   └── 00000000000000000003.json   版 3：part-A を除き、part-C を加える
├── part-A.parquet   1回目の注文（顧客 C-00017 の注文を含む）
├── part-B.parquet   2回目の注文
└── part-C.parquet   part-A から C-00017 の注文を除いた写し

Delta Sharing とは：ファイルを直接読ませるプロトコル

公開されている仕様によれば、Delta Sharing は、クラウドのデータの一部へのアクセスを安全に共有する、単純な REST のプロトコルである。大きなデータを確実に運ぶ仕事は、S3 などのクラウドのストレージに任せる³。

仕様には、三つの単位が出てくる³。

• 共有（share）： 受信者に渡す単位で、中にスキーマ（表をまとめる入れ物）があり、その中に表がある。受信者は、自分に渡された共有の中のものをすべて読める。
• 受信者（recipient）： 共有された表を読むためのトークンを持つ主体。
• 共有サーバー： このプロトコルを実装したサーバー。Databricks には共有サーバーが組み込まれている²。

REST の API は、共有、スキーマ、表を一覧するもの、表の版や列の定義を返すもの、表のデータを読むためのものに分かれ、どれもトークンで認証する³。表を読む API に対して、共有サーバーは、データファイルごとに期限付きの URL（署名付き URL）を返す³。署名付き URL は、それを知っている人に、ストレージの一つのファイルを一定の時間だけ読ませる仕組みで、主要なクラウドのストレージがみな備えている⁵。Databricks の著者による論文は、URL の期限の既定を 1 時間にしたと書いている⁵。

受信者の側では、Databricks を使っていなくても、オープンソースのコネクター（接続用のライブラリ）を使って、Spark や pandas、Power BI などから共有された表を読める²。

表の更新と過去の版

提供者が表を変えると、その変更は、受信者の次の読み取りにほぼ同時に現れる²。受信者の手元にコピーが無いので、コピーを最新に保つ処理も要らない。

提供者は、表の履歴も含めて共有できる。履歴を含めて共有した表では、受信者は過去の版を指定して読むタイムトラベルや、変更を少しずつ読むストリーミングを使える²。文書によれば、Databricks Runtime（Databricks の実行環境）16.2 以降で表を共有すると、履歴を含めるのが既定で、スキーマごと共有すると版によらず履歴を含めるのが既定になる⁴。

履歴を含めると、受信者が読めるものが増える。仕様では、受信者が版を指定すると、共有サーバーはその版のファイルを返す。これは履歴を含めて共有した表でだけ使える³。そのため、履歴付きで共有された表では、受信者は、行を消す前の版を指定するだけで、消した行が残る古いファイルの署名付き URL を受け取れる。モデルの表なら、版 2 を指定すると、顧客 C-00017 の注文を含む part-A の URL が返る。消した行を相手に見せたくないなら、履歴を含めずに共有するか、表から外れたファイルを残しておく保持期間が過ぎたあと、part-A を VACUUM で消す必要がある。

受信者が読むものの範囲：URL とディレクトリの資格情報

仕様には、受信者がファイルを読む方法が二つある³。一つはモデルの絵のように、ファイルごとの署名付き URL を受け取る方法である。もう一つは、表のディレクトリ全体を読める一時的なクラウドの資格情報（AWS なら期限付きのアクセスキー）を受け取り、受信者がログもデータファイルも自分で読む方法である。後者は URL を一つずつ受け取る手間を省く方法で、Databricks の文書は、Databricks どうしの共有では元の表を直接読むのと同等の速さになると書く⁶。仕様では、サーバーが二つの方法を示し、どちらで読むかは受信者のクライアントが選べる³。

Databricks は、条件を満たす表について、資格情報による方法も使えるようにする。Databricks を使わない受信者の場合の条件は、表が Delta の表であること、最初からの履歴を含めて共有していること、パーティション（列の値で分けたファイルのまとまり）で一部だけを共有していないこと、Databricks が用意する既定のストレージを使っていないことなどである⁴。

この方法では、受信者が読めるものの範囲がさらに広がる。文書は、資格情報は表のディレクトリ全体に対するもので、データファイルとログの両方を読めると書く。そしてログには、各版のコミットの履歴、コミットした人の情報、VACUUM でまだ消えていない削除済みのデータが含まれると注意している⁴。版を指定して読む場合と違い、受信者は、ログの記録そのものと、ディレクトリに残るどのファイルも読める。

ビューを共有する：提供者の側で書き出す

配送の会社に渡したいのは、配送に要る列だけで、顧客の連絡先などは渡したくないとする。表をそのまま共有せず、必要な列だけを選ぶビューを作って共有する方法がある。ビューにはそれ自体のデータファイルが無いので、受信者は、元の表のファイルを読むか、提供者が計算した結果を受け取るかのどちらかになる。

どちらになるかは、受信者のコンピュートと、二つの会社の Databricks のアカウントの関係で決まる⁴。受信者が元のデータを直接読めない場合、提供者の側でビューを計算して、結果を一時的に書き出す（マテリアライズする）。書き出したデータは、提供者のストレージに置かれる⁴。この場合、問い合わせの絞り込みや件数の指定が提供者に伝わらず、結果をすべて書き出してから受信者に渡す⁴。渡すときは、モデルの絵と同じく、書き出したファイルの署名付き URL を使う²。

文書の表をまとめると、次のようになる²。サーバーレスは Databricks が計算資源を管理するコンピュート、クラシックは会社のクラウドのアカウントで仮想マシンを動かすコンピュートである。

受信者が Databricks を使っていなければ、ビューの結果を書き出す計算の料金は提供者が払う。モデルの受信者はこの場合にあたる。

リージョンをまたぐ共有：読まれるたびの転送料

モデルの受信者が、提供者とは別のリージョンでデータを読むとする。クラウドの事業者は、データがリージョンやクラウドの外へ出るときに転送の料金（エグレスの料金）を取る。文書は、同じリージョンの中の共有ではエグレスの料金は掛からないが、Delta Sharing は複製を作らないので、リージョンやクラウドをまたいで共有すると、提供者のクラウドの事業者がエグレスの料金を取りうると書く²。

受信者は読むたびにファイルを提供者のストレージから取り寄せるので、料金は、受信者が何回、どれだけ読むかで決まる。Databricks の著者による論文も、この方式は提供者に高く予測しにくいエグレスの料金を生みうると認め、よく読まれる提供者ほど料金が高くなると書いている⁵。

これを避ける方法として文書が挙げるのは、データを別の場所に置き直す方法である。提供者が受信者のリージョンに複製を作って同期する方法と、受信者が共有された表を自分のリージョンにコピーして同期する方法がある⁷。また、Cloudflare R2 のようにエグレスの料金を取らないストレージにデータを複製するか移す方法もあるが、ビューの共有には効かない⁷。論文は、受信者の側で複製を持てば、エグレスの料金は問い合わせの数ではなく、それよりずっと少ない受信者の数に比例すると書く⁵。OpenSharing の発表では、リージョンやクラウドをまたいで自動で複製する機能も示された⁸。

Databricks どうしの共有

受信者も Unity Catalog を使う Databricks のワークスペースを持っているなら、Databricks どうしの方式で共有できる。この方式では、受信者にトークンを渡す必要がなく、提供者がトークンを管理する必要もない²。受信者の側では、管理者が共有からカタログを作り、ほかの利用者に読む権限を与える⁶。共有から作ったカタログの中のものに与えられるのは、読む権限だけである⁶。

ノートブック、ボリューム（表の形でないファイルを入れる領域）、モデル、メトリックビューは、Databricks どうしの方式でしか共有できない²。なお、同じ Unity Catalog のメタストアにつながったワークスペースの間では、共有を使う必要はなく、Unity Catalog の権限で足りる²。

Marketplace とクリーンルーム

Delta Sharing の上には、相手やデータの渡し方を変えた二つの仕組みがある。Databricks Marketplace は、データ製品を公開し、見つけてもらうための場で、データの受け渡しには Delta Sharing を使う⁹。すぐに使えるデータは、申し込んで利用条件に同意するだけで受け取れる¹⁰。有料のデータの取引は Marketplace の上では行わず、提供者との間で行い、取引が済むと、データは受信者のワークスペースに読み取り専用のカタログとして現れる¹⁰。特定の相手にだけ見せるプライベートな出品もできる⁹。

クリーンルームは、複数の会社が互いの生のデータを見ずに、共同で分析するための仕組みである。ここでは共有の行き先が変わり、各社はデータを相手ではなく中央のクリーンルームにだけ共有する¹¹。相手の表の中身は見えず、表について見えるのは列の名前と型で、全員が承認したノートブックのコードだけがデータに対して動く¹¹。参加する各社は、Unity Catalog とサーバーレスを使える Databricks のワークスペースを持つ必要がある¹¹。

Lakehouse Federation：データを取り込まずに外部のデータベースを読む

ここまでは、Databricks の表を外の相手に読ませる話だった。逆に、Databricks の外にあるデータを、取り込まずに Databricks から読む仕組みが Lakehouse Federation で、外部のデータベースに問い合わせを送るクエリフェデレーションと、外部のカタログに登録された表のファイルを直接読むカタログフェデレーションの二種類がある¹²。

モデルの会社が、在庫を Databricks の外の MySQL のデータベースで管理しているとする。クエリフェデレーションでは、MySQL への接続を Unity Catalog に登録し、そのデータベースを写したカタログ（フォーリンカタログ）を作る¹³。カタログに写るのは表の定義だけで、行は取り込まれない。利用者がこのカタログの表に問い合わせると、Databricks は問い合わせを JDBC（Java からデータベースにつなぐ標準の方法）で MySQL に送り、処理を Databricks と MySQL の両方で行う¹²。

倉庫で絞り込む次の問い合わせは、条件ごと MySQL に送られる。

-- 利用者が書く問い合わせ
SELECT * FROM inv_mysql.shop.stock WHERE warehouse = 'TOKYO';
-- MySQL に送られる問い合わせ（概略）
SELECT * FROM shop.stock WHERE warehouse = 'TOKYO';

商品名で絞り込む次の問い合わせは、条件を外して MySQL に送られる。

-- 利用者が書く問い合わせ
SELECT * FROM inv_mysql.shop.stock WHERE name ILIKE 'tea%';
-- MySQL に送られる問い合わせ（概略）
SELECT * FROM shop.stock;

条件を相手のデータベースで処理させることを、プッシュダウン（押し下げ）という。押し下げられない条件があると、相手のデータベースへの問い合わせからはその条件が外れ、絞り込みは Databricks の側で行う¹⁴。商品名で絞り込む問い合わせがその例で、大文字と小文字を区別しない ILIKE の条件は MySQL に送れないので、MySQL からは表のすべての行が返ってくる¹⁴。

この仕組みでは、データのコピーは作られない。その代わり、クエリフェデレーションの表を使う問い合わせは、すべて相手のデータベースに送られる。文書は、相手のシステムが負荷に耐えられるか確かめること、相手が別のリージョンやクラウドにあれば問い合わせのたびにエグレスの料金が掛かることを注意している¹⁵。同じ箇所で文書は、業務のデータベースへの負荷とエグレスの料金を減らすために、結果を書き出しておくマテリアライズドビューに読み取りを肩代わりさせることも勧めている¹⁵。また、Databricks の問い合わせの結果のキャッシュは、フェデレーションの問い合わせには効かない¹³。既定では、一つの外部の表の結果は一本のストリームで Databricks の一つのタスクに返されるので、結果が大きすぎるとメモリが足りなくなりうる¹³。MySQL などでは、問い合わせを分けて並列に読む設定もある¹⁴。

Databricks は、取り込みのコネクター（Lakeflow Connect）が量の多いデータに対応でき、問い合わせの遅れも小さいことを理由に、取り込みを勧めている¹³。取り込みとクエリフェデレーションのどちらも選べるなら、クエリフェデレーションは、その場限りの集計や、取り込みの処理を作る前の試しに使うよう勧めている¹³。

もう一つのカタログフェデレーションは、Hive メタストアや AWS Glue のような外部のカタログに登録された表を、Unity Catalog から、オブジェクトストレージの上のファイルとして直接読む¹²。処理は Databricks のコンピュートだけで行うので、文書は、クエリフェデレーションより費用と性能の面で有利だとしている¹²。

コピーとサイロ：基本原則 2 と 3

Databricks が示す6つの基本原則には、データのサイロを無くし、データの移動を最小にするという原則 2 がある。原則は、データセットのコピーを作り、業務の処理がそれぞれのコピーに頼るようにしてはならないと書き、外部の相手とデータを共有するときは、データに安全に直接アクセスできる仕組みを使うよう求める¹⁶。

原則は、コピーとサイロを区別している。単独のコピーや使い捨てのコピーは、それ自体は害がなく、試行のために必要なこともある。しかし、下流の業務のデータ製品がそのコピーに頼るようになると、コピーはサイロになる¹⁶。原則によれば、コピーを元と同期させる処理を作っても、同期が一貫して保たれることは少なく、データの品質は落ちていく¹⁶。

配送の会社が、共有された表を一度読んで試しに集計した結果は、単独のコピーである。配送の会社が、毎晩の処理で表を自社のストレージにコピーし、それを配送の計画の元にするなら、そのコピーはサイロになりうる。リージョンをまたぐ費用を避けて置く複製も、元と同期させるコピーである。文書は、提供者が持つ複製と、受信者が自分のリージョンに持つ複製の両方を挙げる⁷。受信者の複製を下流の業務が頼る元にすれば、原則 2 のいうサイロの条件に近づく。

原則 3 は、セルフサービスによる価値の創造を求め、データを製品として提供し、利用者が中央のチームに頼まずに見つけて使えるようにすることを挙げる¹⁶。Unity Catalog を使う Databricks のワークスペースでは、共有されたデータも、Marketplace で得たデータも、外部のデータベースを写したフォーリンカタログも、Unity Catalog の中のカタログとして現れ、権限を与えられた利用者がそこから使う。モデルの受信者のように Databricks を使わない場合は、受け取ったファイルの情報から自分の道具で読む。

外から見た Delta Sharing と Lakehouse Federation

2023 年に AWIN で、データの提供者として Delta Sharing と Snowflake のデータ共有を 2 週間試した Poole は、自社の要件の性能を Snowflake で得るにはデータを Snowflake の側に移す必要があったと書き、使いやすさなども理由に Delta Sharing を選んだ¹⁷。

Snowflake の文書では、データをコピーせずに直接共有できるのは同じリージョンの Snowflake のアカウントの間だけで、リージョンをまたぐには、出品（listing）に cross-cloud auto-fulfillment の機能を付けて使う¹⁸。Snowflake を使わない相手には、提供者が費用を持つ読み取り用のアカウントを作る¹⁸。

フェデレーションについては、フェデレーションの製品を出す Dremio に勤める Merced が、その立場を明かしたうえで、限界を挙げている¹⁹。フェデレーションの問い合わせは、最も遅い押し下げの部分より速くはならず、取引のために作られた業務のデータベースは、分析のための表全体の読み取りには向かない¹⁹。また、業務のデータベースは過去を上書きするので、フェデレーションでは過去の状態を読めない¹⁹。Databricks の Sciortino と Sharma も、フェデレーションの表への問い合わせはどれも結局は相手のシステムに届くので、量が少なく頻度が低ければ問題ないが、相手のシステムの処理の制限、余計なエグレス、性能の低下を招きうると書き、多くの場合は取り込みのほうが拡張しやすいとしている²⁰。一方、クラウドの費用の管理の製品を出す Flexera のブログ（もとは Chaos Genius の記事）は、取り込みに掛かる時間を省き、保存の費用を抑え、分析を常に最新に保てることをフェデレーションの利点に挙げている。ただし同じ記事は、相手のシステムの負荷や通信の遅れを限界として挙げている²¹。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。