Delta Lake および Apache Iceberg 向けの Unity Catalog マネージドテーブル
Unity Catalog マネージドテーブルは、Databricks における Delta Lake および Apache Iceberg のデフォルトかつ推奨されるテーブルタイプです。Unity Catalog は、すべての読み取り、書き込み、ストレージ、および最適化の責任を管理します。外部またはフォーリン Delta Lake テーブルを Unity Catalog マネージドテーブルに変換するを参照してください。
マネージドテーブルのデータファイルは、それらを含むスキーマまたはカタログに格納されます。 「Unity Catalog で管理されたストレージの場所を指定する」を参照してください。
外部テーブルやフォーリンテーブルと比較して、マネージドテーブルは保存やクエリーのコストが低く、自動的にメンテナンスと最適化が行われ、オープンなAPIsを通じて外部クライアントからアクセス可能です。
マネージドテーブルは、 Databricksでサポートされているすべての言語と製品で操作できます。 マネージドテーブルを作成、更新、削除、またはクエリするには、特定の権限が必要です。 Unity Catalog での特権の管理を参照してください。
このページでは、Unity Catalog マネージドテーブルについてのみ説明します。レガシーHive metastoreのマネージドテーブルについては、レガシーHive metastoreのデータベースオブジェクトを参照してください。
Unity Catalogマネージドテーブルの利点
Unity Catalog マネージドテーブルは、ストレージコストとクエリー速度を最適化し、Delta LakeおよびApache Icebergのサードパーティツールとの相互運用を可能にします。データマネジメントとパフォーマンスを簡素化するために、これらのマネージドテーブルは、ファイルサイズの圧縮やインテリジェントな統計情報収集などのAIを活用したテクノロジーを使用しています。
マネージドテーブルは、Delta LakeおよびApache Icebergクライアントからのアクセスを可能にすることで相互運用性をサポートします。外部 システムを用いたDatabricksデータのアクセスを参照してください。
以下の機能はUnity Catalog マネージドテーブルに固有のものであり、外部テーブルやフォーリンテーブルでは利用できません。
機能 | 利点 | 構成 |
|---|---|---|
テーブル間でのマルチステートメントトランザクション、より高速なクエリープランニング、強制可能なスキーマおよび制約の変更、外部エンジンからの安全な書き込みを可能にします。 | defaultではオフになっています。オンにするには、 | |
AI を使用してデータ Layout とコンピュートを自動的に最適化し、手動でのメンテナンス操作を不要にします。Databricks では、ストレージとコンピュートのコストを削減するために、すべてのマネージドテーブルに対して予測的最適化を有効にすることをお勧めします。 | 2024 年 11 月 11 日以降に作成されたアカウントでは、defaultで有効になっています。Databricks は、既存のアカウントに対して順次これを有効にしています。設定方法については、「予測的最適化を有効にする」を参照してください。 | |
ACID 保証を備えた単一のアトミックな commit として、1 つ以上のテーブルにまたがる複数の SQL ステートメントを実行します。すべての変更は同時に成功するか、同時にロールバックされます。ストアドプロシージャおよびSQLスクリプトに使用します。 | defaultではオフになっています。トランザクションモードを選択するには、「トランザクションモード」を参照してください。 マネージド Apache Iceberg テーブルへの書き込みは プライベート プレビュー です。 | |
予測的最適化が有効なテーブルでは、クエリー パターンの変化に応じてクラスタリング キーが自動的に選択および更新され、パフォーマンスの向上とコストの削減が図られます。 | defaultではオフになっています。設定方法については、「リキッドクラスタリングを有効にする」を参照してください。 | |
メタデータのキャッシング | トランザクションメタデータのインメモリキャッシュは、クラウド上に保存されたトランザクションlogへのリクエストを最小限に抑えることで、クエリーのパフォーマンスを向上させます。 | デフォルトで有効になっています。設定変更不可。 |
| defaultではオフになっています。 ベータ版。Databricks Runtime 18.2以降が必要です。 | |
マネージドテーブルを削除すると、Databricksはリカバリ期間（defaultで7日間）が経過した後にクラウドストレージ内のデータファイルを削除し、ストレージコストを削減します。外部テーブルの場合、ストレージバケットからファイルを自分で削除する必要があります。 | デフォルトで有効になっています。リカバリ期間はカタログまたはスキーマ レベルで設定できます。マネージドテーブルの削除を参照してください。 |
外部システムを使ってDatabricksのデータにアクセスする
マネージドテーブルは、Delta LakeとApache Icebergのクライアントからのアクセスを許可することで、相互運用性をサポートしています。
オープンAPIsとクレデンシャルベンディングにより、Unity Catalogは、Trino、DuckDB、Apache Spark、Daft、DremioのようなIceberg RESTカタログ統合エンジンなどの外部エンジンがマネージドテーブルにアクセスすることを可能にします。オープンAPIsをサポートしていない外部クライアントの場合は、任意のDelta LakeまたはApache Icebergクライアントを使用してマネージドテーブルを読み取るために、互換 Modeを使用できます。OpenSharing は、オープンソースプロトコルであり、外部パートナーやプラットフォームとのセキュアなガバナンスされたデータ共有を可能にします。
サポートされている外部エンジンの一覧については、 「統合」セクションを参照してください。一覧に含まれていない場合は、お使いのエンジンのドキュメントをご確認ください。
以下のオープンAPIにより、外部システムがUnity Catalogマネージドテーブルにアクセスできるようになります:
- Unity REST API は、Delta LakeクライアントがマネージドDelta Lakeテーブルへの読み取り、書き込み、作成アクセス権を持っています。
- Iceberg REST Catalog (IRC) は、Apache Iceberg クライアントに対して、管理対象の Apache Iceberg テーブルへの読み取り、書き込み、作成アクセスを提供し、Apache Iceberg 読み取りが有効な Delta Lake テーブルへの読み取り専用アクセスを提供します。
どちらのAPIs資格情報販売をサポートしており、これにより、要求元のDatabricksプリンシパルの権限を継承する一時的なスコープ付き資格情報が提供されるため、ガバナンスとセキュリティ制御が維持されます。
OpenSharing は、外部パートナーやプラットフォームに対して安全かつ管理されたデータアクセスを可能にするオープンソースプロトコルです。OpenSharing を使用して、パートナーに一時的な読み取りアクセス権のみを付与できます。
マネージドテーブルへのすべての読み取りと書き込みでは、テーブル名とカタログ名、およびスキーマ名が存在する場合にはそれらの名前を使用する必要があります。 たとえば、 catalog_name.schema_name.table_name 。Unity Catalogマネージドテーブルへのパスベースのアクセスは、 Unity Catalogアクセス制御をバイパスし、マネージドテーブルの機能が適切に動作しないため、サポートされていません (互換Modeを除く)。
マネージドテーブルを作成する
マネージドテーブルを作成するには、次のものが必要です。
USE SCHEMAテーブルの親スキーマ上。USE CATALOGテーブルの親カタログ。CREATE TABLEテーブルの親スキーマ上。
次の構文を使用して、空のマネージドテーブルを作成します。プレースホルダーの値を置き換えてください：
<catalog-name>：テーブルを格納するカタログの名前。<schema-name>: テーブルを含むスキーマの名前。<table-name>：テーブルの名前。<column-specification>: 各列の名前とデータ型。
- SQL
- Python
-- Create a managed Delta table
CREATE TABLE <catalog-name>.<schema-name>.<table-name>
(
<column-specification>
);
-- Create a managed Iceberg table
CREATE TABLE <catalog-name>.<schema-name>.<table-name>
(
<column-specification>
)
USING iceberg;
マネージド Delta Lake テーブルを saveAsTable() を使用して作成します：
from pyspark.sql.types import StructType, StructField, StringType
schema = StructType([StructField("<column-name>", StringType())])
spark.createDataFrame([], schema).write \
.saveAsTable("<catalog-name>.<schema-name>.<table-name>")
または、生成された列やテーブルプロパティなどのDelta固有のオプションには、DeltaTableBuilder APIを使用します。
from delta.tables import DeltaTable
DeltaTable.create(spark) \
.tableName("<catalog-name>.<schema-name>.<table-name>") \
.addColumn("<column-name>", "<data-type>") \
.property("<key>", "<value>") \
.execute()
マネージド Apache Iceberg テーブルを作成する：
from pyspark.sql.types import StructType, StructField, StringType
schema = StructType([StructField("<column-name>", StringType())])
spark.createDataFrame([], schema).write \
.format("iceberg") \
.saveAsTable("<catalog-name>.<schema-name>.<table-name>")
読み書きのパフォーマンスを維持するために、Databricksは定期的に管理されたApache Icebergテーブルメタデータの最適化操作を実行します。このタスクはサーバーレスコンピュートで行われ、Apache Icebergテーブルに対して MODIFY 権限を持っています。この操作はテーブルのメタデータにのみ書き込み、コンピュートはジョブの間のみテーブルの権限を維持します。
Apache Iceberg テーブルを作成するには、USING icebergを明示的に指定します。そうでない場合は、Databricks はデフォルトで Delta Lake テーブルを作成します。
マネージドテーブルは、クエリ結果から作成することも、 DataFrame 書き込み操作から作成することもできます。 次の記事では、 Databricksでマネージドテーブルを作成するために使用できる多くのパターンの一部を示しています。
既存のマネージドテーブルのコピーを作成するには、クローンを使用します。マネージド Delta Lake テーブルでは、ディープクローンとシャロークローンがサポートされています。マネージド Apache Iceberg テーブルは、ディープクローンのみをサポートします。Databricks でのテーブルのクローン作成とマネージド Iceberg テーブルのクローン作成をご覧ください。
マネージドテーブルをドロップする
マネージドテーブルを削除するには、次のものが必要です。
MANAGEテーブル上に表示されるか、テーブルの所有者である必要があります。USE SCHEMAテーブルの親スキーマ上。USE CATALOGテーブルの親カタログ。
マネージドテーブルを削除するには、次のコマンドを実行します。
- SQL
- Python
DROP TABLE IF EXISTS catalog_name.schema_name.table_name;
spark.sql("DROP TABLE IF EXISTS catalog_name.schema_name.table_name")
または、Databricks Runtime 18.2以降では、spark.catalog.dropTable()を使用します:
spark.catalog.dropTable("catalog_name.schema_name.table_name", ifExists=True)
Unity Catalogは、誤って削除されたマネージドテーブルを復元するために、UNDROP TABLEコマンドをサポートしています。デフォルトでは、テーブルはドロップ後7日間復元可能です。リカバリ期間が終了した後、Databricks はお使いのクラウドテナントから基になるデータファイルを48時間以内に削除します。
復旧期間を構成する
パブリックプレビュー
構成可能な復旧期間は、パブリックプレビューです。
カタログまたはスキーマレベルで、削除されたマネージドテーブルの復元可能期間を構成できます。回復期間が両方のレベルで設定されている場合、そのスキーマ内のテーブルではスキーマレベルの設定が優先されます。
回復期間を設定するには、カタログまたはスキーマに対する MANAGE 権限または所有権が必要です。この設定は、構成後にドロップされたテーブルにのみ適用されます。既に削除されたテーブルには影響しません。
復旧期間は0時間（復旧を無効にする）、または7日から30日の間で設定できます。期間を長くすると重要なデータの誤った削除を防ぐことができます。一方、期間を短くすると、テーブルの作成と削除を頻繁に行う ETL パイプラインにおいて、削除されたデータをより早く消去してストレージコストを節約できます。0に設定されている場合、削除されたテーブルをUNDROPで復元することはできません。Databricks は、削除（ドロップ）から 48 時間以内にクラウドストレージからデータファイルを削除します。
復旧期間を指定するには、RETAIN DROPPED TO 句とともに ALTER CATALOG または ALTER SCHEMA を使用します。
- SQL
- Python
-- Set a 30-day recovery period on a catalog
ALTER CATALOG my_catalog RETAIN DROPPED TO 30 DAYS;
-- Set a 7-day recovery period on a schema (overrides the catalog setting)
ALTER SCHEMA my_catalog.my_schema RETAIN DROPPED TO 7 DAYS;
spark.sql("ALTER CATALOG my_catalog RETAIN DROPPED TO 30 DAYS")
spark.sql("ALTER SCHEMA my_catalog.my_schema RETAIN DROPPED TO 7 DAYS")
RETAIN DROPPED FOR句を使用してカタログまたはスキーマを作成する際に、リカバリ期間を設定することもできます。
- SQL
- Python
CREATE CATALOG my_catalog RETAIN DROPPED FOR 30 DAYS;
CREATE SCHEMA my_catalog.my_schema RETAIN DROPPED FOR 7 DAYS;
spark.sql("CREATE CATALOG my_catalog RETAIN DROPPED FOR 30 DAYS")
spark.sql("CREATE SCHEMA my_catalog.my_schema RETAIN DROPPED FOR 7 DAYS")
現在の復旧期間を確認するには、DESCRIBE EXTENDEDを実行します。出力にはRecovery Period Hours行が含まれます。
- SQL
- Python
DESCRIBE CATALOG EXTENDED my_catalog;
DESCRIBE SCHEMA EXTENDED my_catalog.my_schema;
spark.sql("DESCRIBE CATALOG EXTENDED my_catalog").show()
spark.sql("DESCRIBE SCHEMA EXTENDED my_catalog.my_schema").show()