Databricks の Deep Clone・Shallow Clone・CTAS は何が違う？

はじめに

こんにちは、KCCS デジタルプラットフォーム部の丁です。

Databricks では、既存のテーブルをコピーして新しいテーブルを作成する方法として、主に次の3つがあります。

• Deep Clone
• Shallow Clone
• CTAS（CREATE TABLE AS SELECT）

どれも「新しいテーブルを作成する」という点では共通していますが、

• Data File はコピーされるのか
• DESCRIBE HISTORYではどのような結果になるのか
• 元テーブル削除後はどのような挙動になるのか

など、実際の違いは意外と分かりづらいと感じました。

そこで今回は、同じテーブルを使って実際に検証してみます。

検証環境

本記事で紹介する内容は、プレビュー版の機能を用いた検証結果です。
今後のリリースにより仕様や挙動が変更される可能性があります。

• Databricks
• Unity Catalog
• Delta Table

注意

Cloneは Delta Table を対象とした機能です。
Materialized View や Streaming Table に対しては Clone はサポートされていません。

まずは検証用のテーブルを作成します。

CREATE OR REPLACE TABLE demo.customer AS

SELECT
    1 AS id,
    'Matsumura' AS name

UNION ALL

SELECT
    2,
    'Hayashi';

テーブルの内容を確認します。

SELECT *
FROM demo.customer;

続いて、DESCRIBE DETAIL を実行し、コピー元テーブルの情報を確認します。

DESCRIBE DETAIL demo.customer;

今回の検証では、次の結果となりました。

項目	値
numFiles	2
sizeInBytes	2142

今回の検証で使用したテーブルは、2個のData File（合計 2142 Bytes）で構成されていることが確認できました。

この結果をもとに、以降では Deep Clone や Shallow Clone 実行時に、Data File がどのように扱われるのかを確認していきます。

今回比較する3つの方法

今回は次の3つを比較します。

• Deep Clone
• Shallow Clone
• CTAS（CREATE TABLE AS SELECT）

それぞれについて、

• Data File がコピーされるか
• Metadata がどのように扱われるか
• DESCRIBE HISTORY の結果
• 元テーブル削除後の挙動
• 主な利用シーン

を順番に確認していきます。

Deep Clone

まずは Deep Clone を作成します。

CREATE OR REPLACE TABLE demo.customer_deep
DEEP CLONE demo.customer;

作成後、内容を確認します。

SELECT *
FROM demo.customer_deep;

元テーブルと同じデータが作成されていることが確認できました。

Data File はコピーされているのか？

Databricks の公式ドキュメントでは、Deep Clone は Data File と Metadata の両方をコピーすると説明されています。

Reference

実際に DESCRIBE HISTORY を確認してみます。

DESCRIBE HISTORY demo.customer_deep;

DESCRIBE HISTORY を実行すると、テーブルに対して実行された操作履歴が表形式で表示されます。今回は、Data File のコピー有無を確認するため、operationMetrics に記録された numCopiedFiles を確認します。

numCopiedFiles = 2

参考までに、今回出力された operationMetrics の詳細を以下に示します。

今回の検証では、元テーブルは2つのData Fileで構成されていました。Deep Clone後、DESCRIBE HISTORYのoperationMetricsではnumCopiedFiles=2と記録されていました。コピー元と同数のData Fileがコピーされたことから、Data Fileが複製されたことを確認できます。

今回の結果も、Databricks の公式ドキュメントの説明と一致しています。

元テーブルを削除するとどうなる？

続いて、元テーブルを削除してみます。

DROP TABLE demo.customer;

その後、Deep Clone を確認します。

SELECT *
FROM demo.customer_deep;

結果は、問題なく参照できました。

Deep Clone は Data File をコピーしているため、元テーブルを削除した後も独立したテーブルとして利用できることが確認できました。

Shallow Clone

続いて、Shallow Clone を試してみます。

まず元テーブルを作り直します。

CREATE OR REPLACE TABLE demo.customer AS

SELECT
    1 AS id,
    'Matsumura' AS name

UNION ALL

SELECT
    2,
    'Hayashi';

Shallow Clone を作成します。

CREATE OR REPLACE TABLE demo.customer_shallow
SHALLOW CLONE demo.customer;

内容を確認します。

SELECT *
FROM demo.customer_shallow;

元テーブルと同じデータが作成されていることが確認できました。

Data File はコピーされているのか？

Databricks の公式ドキュメントでは、Shallow Clone は underlying data files をコピーせずに作成される と説明されています。

Reference

実際に DESCRIBE HISTORY を確認してみます。

DESCRIBE HISTORY demo.customer_shallow;

DESCRIBE HISTORY を実行すると、テーブルに対して実行された操作履歴が表形式で表示されます。今回は、Shallow Clone 実行時の Data File の扱いを確認するため、operationMetrics の numCopiedFiles に着目します。

numCopiedFiles = 0

Deep Clone では numCopiedFiles = 2 でしたが、Shallow Clone では 0 でした。

今回の結果も、公式ドキュメントの説明と一致しています。

元テーブルを削除するとどうなる？

Databricks の公式ドキュメント（Hive metastore の挙動）では、次のように説明されています。

Shallow clones reference data files in the source directory.

つまり、Shallow Clone はソーステーブルの Data File を利用する仕組みです。

Reference

今回は Unity Catalog の Managed Table 環境で、この挙動を確認してみます。

まず、元テーブルを削除します。

DROP TABLE demo.customer;

その後、Shallow Clone を確認します。

SELECT *
FROM demo.customer_shallow;

結果は……

問題なく参照できました。

※Databricks のドキュメントでは保護機能により削除がブロックされることが想定されています。今回の結果は、その想定とは異なる挙動でした。

最初は操作を間違えたのかと思いました。

そこで、元テーブルが本当に削除されているか確認します。

SHOW TABLES IN demo;

customer が表示されないことから、元テーブルは確かに削除されていることが確認できました。

さらに、Shallow Clone の情報を確認します。

DESCRIBE DETAIL demo.customer_shallow;

Shallow Clone 自体は正常に存在していることも確認できました。

今回の検証から分かったこと

今回の検証環境は Unity Catalog の Managed Table です。

今回の検証では、次の2点を確認できました。

• DESCRIBE HISTORY の operationMetrics では、numCopiedFiles = 0 となっていた
• DROP TABLE 実行後も Shallow Clone は引き続き参照できた

補足

今回の検証環境では、元テーブルを DROP TABLE した後も Shallow Clone を参照できました。
ただし、この挙動は Unity Catalog のバージョンやワークスペース／メタストアの設定 によって異なる可能性があります。

Databricks のドキュメントでは、通常は保護機能によって削除がブロックされると記載されていますが、今回の環境ではその保護は適用されていませんでした。
また、Unity Catalog の Managed Table は DROP TABLE 後も一定期間（約7日間）データが保持され、UNDROP TABLE が可能です。そのため、この保持期間中は Shallow Clone から元データへアクセスできる挙動となることがあります。

CTAS（CREATE TABLE AS SELECT）

最後に、CTAS（CREATE TABLE AS SELECT）を試してみます。

CTAS は Clone と混同されることがありますが、実際には SELECT の結果から新しいテーブルを作成する SQL です。

まずは元テーブルを作成します。

CREATE OR REPLACE TABLE demo.customer AS

SELECT
    1 AS id,
    'Matsumura' AS name

UNION ALL

SELECT
    2,
    'Hayashi';

続いて、CTAS を実行します。

CREATE OR REPLACE TABLE demo.customer_ctas AS

SELECT *
FROM demo.customer;

内容を確認します。

SELECT *
FROM demo.customer_ctas;

元テーブルと同じデータが作成されていることが確認できました。

DESCRIBE HISTORY を確認する

CTAS についても、DESCRIBE HISTORY を確認してみます。

DESCRIBE HISTORY demo.customer_ctas;

また、operationMetrics に記録されている内容も、これまで確認した Deep Clone および Shallow Clone の結果とは異なっていました。

Clone のような CLONE Operation ではなく、

Operation は CREATE TABLE AS SELECT と記録されており、numCopiedFiles は記録されていませんでした。

つまり、

CTAS は Clone ではなく、

SELECT の実行結果から新しいテーブルを作成している

ことが分かります。

元テーブルを削除するとどうなる？

続いて、元テーブルを削除します。

DROP TABLE demo.customer;

その後、CTAS で作成したテーブルを確認します。

SELECT *
FROM demo.customer_ctas;

結果は……

問題なく参照できました。

CTAS は SELECT の結果から新しいテーブルを作成するため、元テーブルを削除した後も影響を受けません。

Deep Clone・Shallow Clone・CTAS を比較してみる

今回の検証結果をまとめると、次のようになりました。

項目	Deep Clone	Shallow Clone	CTAS
Data File をコピー	✅	❌	新しく作成
Metadata をコピー	✅	✅	❌
numCopiedFiles	2	0	-
元テーブル削除後	参照可能	（今回の環境では）参照可能	参照可能
主な用途	Data File もコピーされるため、バックアップや環境移行に適しています。	Data File をコピーしないため、ストレージ容量を抑えながら検証環境を作成する用途に適しています。	SELECT の結果から新しいテーブルを作成できるため、ETL や集計テーブルの作成に適しています。

※ 上記は今回の検証結果から考えられる利用例です。実際の利用方法は、データ量や運用要件、環境によって異なる場合があります。

まとめ

今回は、Deep Clone・Shallow Clone・CTAS の違いを実際に検証しました。

検証の結果、次のことを確認できました。

• Deep Clone は Data File をコピーする
• Shallow Clone は Data File をコピーしない
• CTAS は Clone ではなく、SELECT の結果から新しいテーブルを作成する

また、今回の Unity Catalog の Managed Table 環境では、DROP TABLE 実行後も Shallow Clone を参照できることを確認できました。

実際に DESCRIBE HISTORY や DESCRIBE DETAIL を確認しながら検証することで、それぞれの違いや挙動をより理解しやすくなると思います。

今後の検証

今回は基本的な挙動に絞って比較しました。

部分複製（WHERE句）、Time Travel（VERSION AS OF / TIMESTAMP AS OF）、UPDATE / DELETE 時の挙動については、今後検証していきたいと思います。

参考資料

• Clone a table

• Shallow clone for Unity Catalog tables

• CREATE TABLE CLONE

• CREATE TABLE AS SELECT