目次 › 第7章 › 7-1

第7章 ガバナンスとセキュリティ / 想定学習時間:30〜40分 / 最終確認:2026年8月

7-1. マネージドテーブルと外部テーブル(作成・変更・削除・相互変換)

1. 2種類のテーブル:誰がデータを管理するか

Unity Catalog(UC)配下のテーブルは、データファイルの管理を誰が担うかによって2種類に分かれます。どちらも「メタデータ(テーブル定義・スキーマ・権限)」は UC が管理しますが、データファイルの置き場所とライフサイクルの扱いが異なります。

• マネージドテーブル(managed table):データとメタデータの両方を Unity Catalog が管理します。データファイルは、メタストア・カタログ・スキーマのいずれかに設定されたマネージドストレージロケーションに UC が自動配置します。ユーザーがパスを意識する必要はありません。Databricks が推奨する既定の形式です。
• 外部テーブル(external table):LOCATION 句で顧客が管理するクラウドストレージ上のパスを明示的に指定して作成します。UC が管理するのはメタデータだけで、データファイルのライフサイクルは顧客側の責任になります。

両者の最大の違いは DROP TABLE を実行したときの挙動です。マネージドテーブルを DROP するとメタデータとデータの両方が削除されます(一定期間内は UNDROP TABLE で復元できます)。一方、外部テーブルを DROP しても削除されるのはメタデータ(テーブル定義)だけで、ストレージ上のデータファイルはそのまま残ります。

2. 作成・変更・削除のSQL

作成時に LOCATION 句を付けるかどうかが、2種類のテーブルの分かれ目です。

-- マネージドテーブル:LOCATION を指定しない(UC が配置先を決める)
CREATE TABLE main.sales.orders (
  order_id   BIGINT,
  customer_id BIGINT,
  amount     DECIMAL(10,2),
  order_date DATE
);

-- 外部テーブル:LOCATION で顧客管理ストレージのパスを指定する
-- (事前にそのパスをカバーする外部ロケーションと
--  ストレージ資格情報が UC に登録されている必要がある)
CREATE TABLE main.sales.orders_ext (
  order_id   BIGINT,
  customer_id BIGINT,
  amount     DECIMAL(10,2),
  order_date DATE
)
LOCATION 's3://my-company-bucket/sales/orders_ext';

変更(ALTER)と削除(DROP)の構文自体は両者で共通です。挙動が変わるのは DROP のときだけです。

-- 列の追加・コメント・プロパティ変更(両タイプ共通)
ALTER TABLE main.sales.orders ADD COLUMN region STRING;
ALTER TABLE main.sales.orders SET TBLPROPERTIES ('delta.enableChangeDataFeed' = 'true');
ALTER TABLE main.sales.orders RENAME TO main.sales.orders_v2;

-- 削除
DROP TABLE main.sales.orders_v2;   -- マネージド:データも削除(UNDROP で一定期間復元可)
DROP TABLE main.sales.orders_ext;  -- 外部:定義のみ削除。s3://... のファイルは残る

3. 相互変換:ALTER TABLE ... SET MANAGED

既存のテーブルを「外部→マネージド」に切り替えたい場合、現在の Databricks では ALTER TABLE <table> SET MANAGED が正式にサポートされており、これが推奨の方法です。テーブル名・設定・権限・ビュー・テーブル履歴をそのまま保持したまま種類だけを変換でき、変換中の同時読み書きにも対応しています。逆方向(マネージド→外部)には ALTER TABLE <table> SET EXTERNAL があります。なお ALTER TABLE ... SET LOCATION は外部テーブルが参照するパスを付け替えるための操作であり、テーブルの種類を変換するものではない点に注意してください。

-- 外部テーブルをマネージドテーブルに変換する(推奨)
-- テーブル名・権限・ビュー・履歴はそのまま保持される
ALTER TABLE main.sales.orders_ext SET MANAGED;

-- 逆方向:マネージドテーブルを外部テーブルに変換する
ALTER TABLE main.sales.orders SET EXTERNAL;

コピーを伴う代替手段として、CTAS(CREATE TABLE AS SELECT)や DEEP CLONE で新しいマネージドテーブルを作る方法もあります。ただしこちらは別テーブルへのコピーであるため、テーブル名が変わる(参照の切り替えや RENAME が必要)、テーブル履歴が引き継がれない、といった扱いの違いがあります。列の絞り込み・変換を同時に行いたい場合は CTAS、プロパティなどのメタデータごと複製したい場合は DEEP CLONE、というように「新しいテーブルとして作り直したい」ケースで選びます。

-- 代替1:CTAS(列の絞り込み・変換を同時に行える。プロパティは引き継がれない)
CREATE TABLE main.sales.orders_managed AS
SELECT * FROM main.sales.orders_ext;

-- 代替2:DEEP CLONE(データに加えプロパティ等のメタデータも複製)
CREATE TABLE main.sales.orders_managed
DEEP CLONE main.sales.orders_ext;

-- 切り替え後、旧テーブルの定義を削除(外部なのでデータは残る)
DROP TABLE main.sales.orders_ext;

4. 使い分けの基準:迷ったらマネージド

使い分けの原則はシンプルです。

• Databricks 以外の外部ツールやシステムが、ストレージ上のデータファイルを直接読み書きする必要がある → 外部テーブル。パスが固定され顧客管理下にあるため、他システムとファイルパスベースで共有できます。既存のデータレイクのファイルをそのままテーブルとして登録したい場合も外部テーブルです。
• それ以外のすべてのケース → マネージドテーブル。これが Databricks の推奨です。

マネージドテーブルを推奨する大きな理由が Predictive Optimization(予測最適化)です。これは Unity Catalog のマネージドテーブルに対して、OPTIMIZE(ファイルコンパクション)や VACUUM(不要ファイル削除)などのメンテナンス操作を、利用パターンに基づき Databricks が自動で実行してくれる機能です。外部テーブルはこの対象外のため、最適化ジョブを自前でスケジュールし続ける運用負荷が残ります。ほかにも、マネージドテーブルは UC がファイル配置を完全に把握しているため、ストレージレイアウトの改善やガバナンス機能の恩恵を受けやすいという利点があります。

練習問題