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ではオフになっています。トランザクションモードを選択するには、「トランザクションモード」を参照してください。 | |
予測的最適化が有効なテーブルでは、クエリー パターンの変化に応じてクラスタリング キーが自動的に選択および更新され、パフォーマンスの向上とコストの削減が図られます。 | 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 table using Iceberg
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 を使用してマネージドテーブルのメタデータを最適化する操作を定期的に実行します。このタスクはServerlessコンピュートを使用して実行され、テーブルに対する MODIFY 権限を持っています。この操作はテーブルのメタデータにのみ書き込みを行い、コンピュートはジョブの実行期間中のみテーブルに対する権限を維持します。
Apache Iceberg テーブルを作成するには、USING icebergを明示的に指定します。そうでない場合は、Databricks はデフォルトで Delta Lake テーブルを作成します。
マネージドテーブルは、クエリ結果から作成することも、 DataFrame 書き込み操作から作成することもできます。 次の記事では、 Databricksでマネージドテーブルを作成するために使用できる多くのパターンの一部を示しています。
既存のマネージドテーブルのコピーを作成するには、cloneを使用します。マネージド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 supports the UNDROP TABLE command to recover accidentally dropped マネージドテーブル.By default, tables are recoverable for 7 days after being dropped.After the recovery period ends, an asynchronous purge process deletes the underlying data files from your クラウド テナント.
復旧期間を構成する
パブリックプレビュー
構成可能な復旧期間は、パブリックプレビューです。
カタログまたはスキーマレベルで、削除されたマネージドテーブルの復元可能期間を構成できます。回復期間が両方のレベルで設定されている場合、そのスキーマ内のテーブルではスキーマレベルの設定が優先されます。
回復期間を設定するには、カタログまたはスキーマに対する MANAGE 権限または所有権が必要です。この設定は、構成後にドロップされたテーブルにのみ適用されます。既に削除されたテーブルには影響しません。
復旧期間は、復旧を無効にする0時間、または7〜30日間に設定できます。期間を長くすると、重要なデータの誤削除に対する保護になり、期間を短くすると、頻繁にテーブルを作成および削除するETLパイプラインにおいて、削除されたデータがより早く削除されてストレージコストを削減できます。0に設定した場合、削除されたテーブルは UNDROP で復元できません。削除後、非同期のパージプロセスによりクラウドストレージからデータファイルが削除されます。
復旧期間を指定するには、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()