Delta テーブルを削除または置換する
Databricks では、Unity Catalog または Hive metastoreに登録されているテーブルを削除および置換するための SQL 標準 DDL コマンドがサポートされています。 この記事では、Delta テーブルの削除と置換の例と、構成された環境と目的の結果に応じた構文の推奨事項について説明します。
テーブルを削除するタイミング
DROP TABLE
を使用してメタストアからテーブルを削除するのは、テーブルを完全に削除する必要があり、同じ場所に新しいテーブルを作成する予定がない場合です。例えば:
DROP TABLE table_name
DROP TABLE
は、テーブルの種類と、テーブルが Unity Catalog に登録されているか、レガシ Hive metastoreに登録されているかによってセマンティクスが異なります。
テーブル型 |
メタストア |
挙動 |
---|---|---|
マネージド |
Unity Catalog |
テーブルがメタストアから削除され、基になるデータに削除のマークが付けられます。 Unity Catalog マネージド テーブルのデータは 7 日間 |
マネージド |
Hive |
テーブルがメタストアから削除され、基になるデータが削除されます。 |
外部 |
Unity Catalog |
テーブルはメタストアから削除されますが、基になるデータは残ります。 URI アクセス権限は、データを含む外部ロケーションによって管理されるようになりました。 |
外部 |
Hive |
テーブルはメタストアから削除されますが、基になるデータは残ります。 URI アクセス権限は変更されません。 |
DROP TABLE
セマンティクスはテーブルの種類によって異なり、Unity Catalog では内部テーブル ID を使用して Delta テーブルの履歴が保持されます。 ただし、すべてのテーブルは、操作の完了後、以前に登録されたテーブル名にメタストアのデータとテーブル履歴へのアクティブなリンクがなくなるという共通の結果を共有します。
DROP TABLEを参照してください。
注:
Databricks では、本番運用パイプラインまたはシステムに対して同じ名前を使用してテーブルを削除してから再作成するパターンは、並列操作で予期しない結果が生じる可能性があるため、お勧めしません。 並列演算によるデータの置換を参照してください。
テーブルを置換するタイミング
Databricks では、ターゲット テーブルを新しいデータで完全に上書きするユース ケースで CREATE OR REPLACE TABLE
ステートメントを使用することをお勧めします。 たとえば、Delta テーブルを Parquet ディレクトリのすべてのデータで上書きするには、次のコマンドを実行します。
CREATE OR REPLACE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`
CREATE OR REPLACE TABLE
は、使用中のテーブルの種類やメタストアに関係なく、同じセマンティクスを持ちます。 CREATE OR REPLACE TABLE
の重要な利点は次のとおりです。
表の内容は置き換えられますが、表の ID は維持されます。
テーブルの履歴は保持され、
RESTORE
コマンドを使用してテーブルを以前のバージョンに戻すことができます。操作は 1 つのトランザクションであるため、テーブルが存在しない時間はありません。
テーブルから読み取る並列クエリは、中断することなく続行できます。 置換前と置換後のバージョンがテーブル履歴にまだ存在するため、並列クエリは必要に応じてテーブルのいずれかのバージョンを参照できます。
CREATE TABLE [USING]を参照してください。
並列処理によるデータの置換
並列操作で使用される可能性のあるテーブル内のデータを完全に置き換える場合は、 CREATE OR REPLACE TABLE
を使用する必要があります。
次のアンチパターンは使用しないでください。
-- This is an anti-pattern. Avoid doing this!
DROP TABLE IF EXISTS table_name;
CREATE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`;
この推奨事項の理由は、マネージド テーブルと外部テーブルのどちらを使用しているか、および Unity Catalog を使用しているかどうかによって異なりますが、すべての Delta テーブルの種類でこのパターンを使用すると、エラー、レコードの削除、または結果の破損が発生する可能性があります。
代わりに、Databricks では、次の例のように、常に CREATE OR REPLACE TABLE
を使用することをお勧めします。
CREATE OR REPLACE TABLE table_name
AS SELECT * FROM parquet.`/path/to/files`
テーブル履歴はアトミック データの置換中に保持されるため、並列トランザクションは参照されるソース テーブルのバージョンを検証できるため、予期しない動作や結果を引き起こすことなく、必要に応じて並列トランザクションを失敗または調整できます。