Delta テーブルのドロップまたは置き換え
Azure Databricks は、Unity Catalog または Hive メタストアに登録されているテーブルをドロップし、置き換えるための SQL 標準 DDL コマンドをサポートしています。 この記事では、Delta テーブルのドロップと置き換えの例と、構成された環境と目的の結果に応じた構文の推奨事項について説明します。
テーブルをドロップするタイミング
テーブルを完全に削除し、同じ場所に新しいテーブルを作成するつもりがない場合は、DROP TABLE を使ってメタストアからテーブルを削除するようにします。 次に例を示します。
DROP TABLE table_name
DROP TABLE のセマンティクスは、テーブルの種類と、テーブルが Unity Catalog またはレガシ Hive メタストアのどちらに登録されているかに応じて異なります。
| テーブルの種類です。 | メタストア | Behavior |
|---|---|---|
| マネージド | Unity Catalog | テーブルがメタストアから削除され、基になるデータが削除対象としてマークされます。 7 日間は、Unity Catalog マネージド テーブルのデータを UNDROP できます。 |
| マネージド | Hive | テーブルがメタストアから削除され、基となるデータが削除されます。 |
| 外部 | Unity Catalog | テーブルはメタストアから削除されますが、基となるデータは残ります。 URI アクセス特権は、データが含まれる外部の場所によって管理されるようになりました。 |
| 外部 | Hive | テーブルはメタストアから削除されますが、基となるデータは残ります。 URI アクセス権限は変更されません。 |
DROP TABLE セマンティクスはテーブルの種類によって異なり、Unity Catalog は内部テーブル ID を使って Delta テーブルの履歴を保持します。 ただし、操作が完了すると、以前に登録されたテーブル名には、メタストアからのデータとテーブル履歴へのアクティブなリンクがなくなるという共通の結果がすべてのテーブルに共有されます。
「DROP TABLE」を参照してください。
Note
Databricks では、運用環境パイプラインまたはシステムに対して同じ名前を使ってテーブルをドロップして再作成するパターンは推奨していません。このパターンの場合、同時実行操作で予期しない結果が生じる可能性があります。 「同時実行操作でデータを置き換える」を参照してください。
テーブルを置き換えるタイミング
Databricks では、ターゲット テーブルを新しいデータで完全に上書きするユース ケースには、CREATE OR REPLACE TABLE ステートメントを使うことを推奨しています。 たとえば、Parquet ディレクトリのすべてのデータで Delta テーブルを上書きするには、次のコマンドを実行します。
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`
アトミックなデータ置換中はテーブルの履歴が維持されるので、同時実行トランザクションは参照されるソース テーブルのバージョンを検証できます。そのため、予期しない動作や結果を引き起こすことなく、必要に応じて同時実行トランザクションを失敗させたり、調整したりすることができます。