2026年9月29日

あなたのデータ、あなたのストレージ、あなたのルール：Unity Catalogマネージドテーブル保存のための2026年版ガイド

管理テーブルのデータは、お客様自身が管理する場所にある、所有するクラウドストレージに保存されます。

Unity Catalogの管理テーブルは、メタストア、カタログ、またはスキーマの管理ストレージの場所によって設定されたパスにある、お客様自身が所有するクラウドストレージにデータを保存します。
組織の変化に伴い、チームが、自分たちが選択したわけではない引き継いだ場所にデータが残されたままになってしまうことがあります。SET MANAGED LOCATIONを使用すると、新しいテーブルが配置される場所を変更できます。また、外部テーブルを変換することで、そのデータが設定した場所に移動します。
単一の場所であっても、コンプライアンスやコスト配分のための個別のストレージであっても、管理テーブルのデータが保存される場所を常にコントロールできます。

Unity Catalogの管理テーブルを使用すると、組織で個別のストレージが必要な場合に、データの配置をコントロールできます。他のデータプラットフォームとは異なり、Databricksのテーブルデータは、S3バケット、ADLSコンテナ、GCSバケットなど、お客様が所有するクラウドストレージアカウント内に保持されます。

Unity Catalogの管理テーブルは、テーブル管理を自動化します。Unity Catalogの管理テーブルをIcebergまたはDeltaフォーマットのどちらで保存しても、Databricksはお客様が選択した場所でデータのレイアウト、チューニング、クリーンアップを自動的に処理し、テーブルの変更に応じて最適化を自動的に適用します。

このブログでは、管理テーブルのストレージモデルの仕組みと、Databricksの管理ストレージの場所を選択または変更する方法について説明します。

テーブルはお客様が所有するストレージに保持されます

独自のクラウドストレージを使用する場合、管理テーブルのデータはお客様が所有するクラウドアカウントに保存されます。そのストレージの所有権を維持し、データがどのように整理されているかを可視化できます。独自のバケットポリシーの検査、監査、適用や、データの場所のコントロールが可能です。

プロバイダーが管理するストレージや独自のデータフォーマットでテーブルを保持する、他のプラットフォームの管理テーブルやネイティブテーブルのサービスとは異なり、Databricksではデータはお客様自身のアカウント内に保持されます。

オープンな設計

データを独自のクラウドアカウントに保持することは、Databricksの管理テーブルがオープンである理由のほんの一部にすぎません。Unity Catalogは、IcebergとDelta全体で完全に管理された読み取りおよび書き込みアクセスを提供し、オープンスタンダードを使用して他のユーザーが所有するオープンフォーマットのテーブルとフェデレーションする機能を備え、お客様がデータの所有者になれる業界唯一の主要なカタログです。

Apache Spark™、Flink、Trino、Kafka Connect、Snowflakeなどの外部ツールは、Iceberg REST CatalogおよびUnity CatalogのオープンAPIを介して、管理テーブルの読み取りと書き込みを行うことができます。オープンAPIと認証情報の自動払い出し（credential vending）により安全なアクセスが可能になり、外部ツールはデータを複製することなく、ガバナンスが適用されたデータとやり取りできます。これにより、アーキテクチャがシンプルになり、分析やAIのワークロード全体で「信頼できる唯一の情報源（Single Source of Truth）」が実現します。

独自のストレージを使用する場合、Unity Catalogがファイルへのアクセスを管理している間も、クラウドアカウント内のファイルには引き続きアクセスできます。

データの保存場所をコントロール可能

Databricksの管理テーブルを使用すると、管理テーブルのデータの保存先を決定できます。メタストア、カタログ、またはスキーマレベルで管理ストレージの場所を一度設定すると、その配下にあるすべてのテーブルがそれを継承します。最も具体的なレベルが優先されます。スキーマの場所はカタログの場所よりも優先され、カタログの場所はメタストアの場所よりも優先されます。広範なデフォルトを設定し、チームやドメインが独自のストレージを必要とする場所でそれを上書きできます。

そのコントロールは、セットアップ時に固定されるものではありません。組織の変更に伴い、ALTER CATALOG または ALTER SCHEMA ... SET MANAGED LOCATION が新しいテーブルやボリュームを新しい場所に向けることができます。その間、すでに書き込まれたものはすべて元の場所に残ります。

個別のストレージが必要な場合の高度なコントロール

ほとんどのチームは、カタログやスキーマを通じてデータを論理的に整理しており、基盤となるファイルが物理的にどこにあるかを気にする必要はありません。カタログやスキーマが継承する管理ストレージの場所だけで十分だからです。Unity Catalogにおけるロールベースおよび属性ベースのアクセス制御を組み合わせることで、このアプローチは標準的なGDPRのデータ分離要件を満たします。

しかし、組織によっては、物理ストレージ自体にまで及ぶ境界線を必要とする場合があります。事業部門が管理やクラウドコスト配分のために個別のストレージを必要とする場合や、地域や規制のルールによって特定のデータが物理的にどこに存在すべきかが規定されている場合もあります。そのような場合、特定のカタログやスキーマに独自の管理ストレージの場所を指定することで、データの物理的な配置を、それを必要とする境界線に合わせることができます。

管理テーブルへの変換時にデータの保存先を選択する

外部テーブルを管理テーブルに変換すると、データは、そのカタログまたはスキーマが現在解決している管理ストレージの場所に保存されます。その外部テーブルがすでにアドホックまたは非標準的な場所にある場合、管理テーブルを別の場所、つまり現在そのドメインに使用しているストレージに配置したい場合があります。

変換中、Databricksはテーブルのデータとトランザクションログを設定した管理ストレージの場所にコピーするため、管理テーブルは選択した場所に保存されます。

まとめ

管理テーブルは、データを自身が所有するストレージに保持したまま、テーブルのメンテナンスを自動化します。これは、プロバイダーが管理するストレージにテーブルデータを保持する他の管理プラットフォームとは異なります。メタストア、カタログ、またはスキーマレベルで配置をコントロールし、新しいテーブルの保存先を変更し、外部テーブルを管理テーブルに変換する際に場所を選択できます。データはオープンフォーマットのままであり、Iceberg REST CatalogおよびUnity CatalogのオープンAPIを介してアクセスできます。

管理ストレージの場所を設定または変更する準備ができたら、管理ストレージに関するドキュメントで詳細を確認してください。

機能	Databricks Unity Catalog	他のプラットフォーム
お客様所有のストレージに保存されるデータ	✅ はい	独自の形式が多い
オープンテーブルフォーマット（IcebergおよびDelta）	✅ はい	フォーマットにより異なる
行および列レベルのガバナンスを備えた外部ツールの読み取り/書き込みアクセス	✅ Iceberg REST CatalogまたはUnity CatalogのオープンAPI経由	制限あり
カタログ/スキーマレベルでストレージの場所をコントロール可能	✅ SET MANAGED LOCATION	一般的ではない

用語の定義

これらの用語の多くは同じいくつかの単語を再利用しているため、混同しやすくなっています。この投稿におけるそれぞれの意味は以下の通りです。

管理テーブル：Unity Catalogがデータとライフサイクルを管理するテーブル。LOCATION句なしで作成します。
管理ストレージの場所：メタストア、カタログ、またはスキーマの管理テーブルとボリュームが書き込まれるクラウドストレージのパス。SET MANAGED LOCATION句を使用して設定します。
外部ロケーション：クラウドパスとストレージ認証情報をペアリングして、そのパスへのアクセスを制御する Unity Catalog オブジェクト。外部ロケーションは外部テーブルと管理ストレージの両方を制御し、カタログレベルまたはスキーマレベルの管理ストレージロケーションはその内部に配置されます。
顧客所有のストレージ： 基盤となるクラウドストレージが顧客自身のクラウドアカウント内にあるストレージオプション。これは Databricks におけるテーブルの大部分を占めています。
デフォルトストレージ：ユーザーが独自のバケットを用意する代わりに、Databricks が基盤となるクラウドストレージをプロビジョニングする代替ストレージオプション。
ALTER CATALOG / ALTER SCHEMA … SET MANAGED LOCATION：カタログまたはスキーマの新しい管理テーブルおよびボリュームが書き込まれる場所を変更するコマンド。既存のテーブルは影響を受けません。
外部から管理への変換（ALTER TABLE … SET MANAGED）：外部テーブルを管理テーブルに変換するコマンド。変換中、データとトランザクションログは現在の管理ストレージロケーションにコピーされます。

FAQs

1. Unity Catalog は管理テーブルのデータをどこに保存しますか？Databricks 所有のストレージですか、それとも私自身のクラウドアカウントですか？

お客様自身のアカウント内です。管理テーブルのデータは、メタストア、カタログ、またはスキーマに設定した管理ストレージロケーションにある、お客様自身のアカウントのクラウドストレージ（S3、ADLS、GCS など）に書き込まれます。Databricks はテーブルのレイアウトとライフサイクルを管理しますが、基盤となるファイルは Databricks が管理するアカウントではなく、お客様が所有し Unity Catalog に登録したバケットまたはコンテナに保存されます。

2. Unity Catalog の管理テーブルを使用すると、Databricks にロックインされますか？

いいえ。管理テーブルは Iceberg や Delta などのオープンなテーブルフォーマットを使用し、お客様が所有するクラウドストレージに保存されます。外部エンジンは Iceberg REST Catalog や Unity Catalog のオープン API を介してこれらに書き込みや読み取りを行えるため、データが独自のインターフェースに閉じ込められることはありません。ストレージの所有権は維持され、データはオープンフォーマットのままであり、アクセスはオープンスタンダードを介して行われます。管理テーブルはロックインではありません。管理テーブルを使用する場合でも、外部テーブルを使用する場合と同様に、Databricks への移行や Databricks からの移行が容易であり、どちらの場合もデータを物理的に同じ場所に保持できます。

3. コンプライアンスやデータレジデンシーのために、特定のデータを別のストレージに保管することはできますか？

はい。必要に応じて、特定のカタログやスキーマに他とは別の独自の管理ストレージロケーションを割り当てることができます。これにより、異なる国や規制制度のデータを個別のストレージに保管したり、特定のチームや事業部門にストレージコストを割り当てたりすることができます。

4. Databricks 以外のエンジンやツールから、管理テーブルへの書き込みや読み取りを行うことはできますか？

はい。管理テーブルは Iceberg REST Catalog や Unity Catalog のオープン API を介して読み書き可能なため、Apache Spark、Trino、Flink などの外部エンジンからアクセスできます。Unity Catalog がストレージアクセスのガバナンスを処理するため、これらをバイパスすることによって発生する可能性のあるデータの破損を防ぎます。また、パスベースのリダイレクトや互換モード（Compatibility Mode）を介した、直接的なパスベースのアクセスも利用可能です。

5. 管理テーブルのデータの保存場所を設定した後に変更することはできますか？

はい。組織の再編、新しいバケット、新しいリージョンなど、物理的な分離を必要とする組織の変更が発生した場合はいつでも、ALTER CATALOG … SET MANAGED LOCATION または ALTER SCHEMA … SET MANAGED LOCATION を使用して新しいテーブルを別の場所に向けることができます。既存のテーブルはそのままの場所に残り、新しいテーブルは新しい場所に保存されます。外部テーブルを管理テーブルに変換すると、そのデータは設定した場所にコピーされるため、同じステップの一部としてデータを適切な場所に移動できます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事