メインコンテンツまでスキップ

外部テーブルから Unity Catalog マネージドテーブルに変換する

備考

プレビュー

この機能はパブリック プレビュー段階であり、現時点では参加している顧客のみが利用できます。 プレビューに参加するには、 こちらのフォームに必要事項をご記入の上、お申し込みください。

このページでは、SET MANAGED コマンドを使用して、 で外部テーブルをUnity Catalog マネージドテーブルに変換する方法について説明します。Databricks

SET MANAGED の概要

機能により、 SET MANAGEDで外部テーブルをUnity Catalog マネージドテーブルに簡単に変換できます。Databricksこれにより、手動で DEEP CLONE を実行した後で外部テーブルを削除するという複雑さを回避できます。このプロセスでは、大幅なダウンタイムが発生し、テーブルの履歴と設定が失われる可能性があります。

SET MANAGED機能の利点は次のとおりです。

  • リーダーとライターのダウンタイムを最小限に抑えます。
  • 変換中の並列書き込みの処理。
  • テーブル履歴の保持。
  • 同じテーブル構成 (同じ名前、設定、アクセス許可、ビューなど) を保持します。
  • 変換されたマネージドテーブルを外部テーブルにロールバックする機能。

前提 条件

テーブル規則機能を使用するには、次のものが必要です。

  • 外部テーブルに対するすべてのリーダーとライターは、名前ベースのアクセスを使用する必要があります。例えば:

    SQL
    SELECT * FROM catalog_name.schema_name.table_name;

    パスベースのアクセスはサポートされておらず、テーブルが変換された後で失敗します。例えば:

    SQL
    SELECT * FROM delta.`protocol://path/to/table`;
  • コマンド SET MANAGED または UNSET MANAGEDを実行するには、Databricks Runtime 17.0 以降を使用する必要があります。

  • Databricks のリーダーとライターは、Databricks Runtime 15.4 LTS 以降を使用する必要があります。リーダーまたはライターが 14.3 LTS 以下を使用している場合は、「 Databricks Runtime 14.3 LTS 以前のリーダーとライターの代替オプション」を参照してください。

  • 外部 (非Databricks) クライアントは、 Unity Catalog マネージドテーブルへの読み取りをサポートする必要があります。 Delta クライアントを使用したテーブルの読み取りを参照してください。

  • UniForm テーブル プロパティが有効になっている外部テーブルで非アクティブ化します。

    SQL
    ALTER TABLE catalog.schema.my_external_table
    UNSET TBLTBLPROPERTIES('delta.universalFormat.enabledFormats'= '');

    テーブルを変換した後、UniForm を再度有効にできます。

    SQL
    ALTER TABLE table_name SET TBLPROPERTIES (
    'delta.enableIcebergCompatV2' = 'true'
    'delta.universalFormat.enabledFormats' = 'iceberg');
important

競合を回避するには、テーブルで操作されている既存の OPTIMIZE コマンドジョブ (リキッドクラスタリング、コンパクション、 ZORDER) をキャンセルし、外部テーブルをマネージドテーブルに変換する間はジョブをスケジュールしないでください。

external からマネージドテーブルへの変換

important

SET MANAGED コマンドは、Databricks Runtime 17.0 以降で使用できます。

UC 外部テーブルを Unity Catalog マネージドに変換するには、次のコマンドを実行します。

SQL
ALTER TABLE catalog.schema.my_external_table SET MANAGED;

データのコピー中にコマンドが中断された場合は、コマンドを再開でき、中断したところから続行されます。

警告

Databricks では、同じテーブルで複数の SET MANAGED コマンドを同時に実行しないことをお勧めします。これにより、テーブルの状態に一貫性がなくなる可能性があります。

テーブルが変換されたら、次のことを行う必要があります。

  • テーブルで UniForm を無効にしていた場合は、再度有効にする必要があります。
  • 外部テーブルを使用して、すべてのストリーミングジョブ (読み取りまたは書き込み) を再起動します。
  • リーダーとライターがマネージドテーブルで作業していることを確認します。

予測的最適化は、手動で無効にした場合を除き、自動的に有効になります。 「予測的最適化が有効になっているかどうかを確認する」を参照してください。

チェック規則

外部テーブルがマネージドテーブルに変換されたことを確認できます。

SQL
DESCRIBE EXTENDED catalog_name.schema_name.table_name

テーブルが変換されている場合、col_nameの下のTypedata_typeの下にMANAGEDと表示されます。

Databricks Runtime 14.3 LTS 以前のリーダーとライターの代替オプション

Databricks では、テーブル履歴を保持する機能など、 SET MANAGED コマンドを利用するために、すべてのリーダーとライターを Databricks Runtime 15.4 LTS 以降にアップグレードすることをお勧めします。

Databricks Runtime 14.3 以前のリーダーまたはライターがいる場合でも、 SET MANAGED コマンドを引き続き使用できます。ただし、マネージドテーブルに変換した後は、タイムスタンプで過去のコミットにタイムトラベルすることはできません。これはバージョンごとにのみ実行できます。14 日間のウィンドウで外部テーブルにロールバックすると、変換前に行われた過去のコミットへのタイムトラベルが再度有効になります。

すべての場合(DBRバージョンに関係なく)、タイムスタンプによるUC外部へのロールバックは、変換が完了してからロールバックを試みる前までの間に、変換されたUCマネージドテーブルに対して行われたコミットに対しては機能しません。

SQL
ALTER TABLE <table_name> DROP FEATURE inCommitTimestamp;

外部テーブルへのロールバック

important

UNSET MANAGED コマンドは、Databricks Runtime 17.0 以降で使用できます。

外部テーブルをマネージドテーブルに変換した後、14 日以内であればロールバックできます。

ロールバックする場合、変換とロールバックの間に外部ロケーションに対して行われたコミットは、バージョンごとにタイムトラベル可能ですが、タイムスタンプではタイムトラベルできません。 ロールバックの 7 日後、管理された場所のデータは削除されます。

外部テーブルにロールバックするには、次のコマンドを実行します。

SQL
ALTER TABLE catalog.schema.my_managed_table UNSET MANAGED

ロールバック・コマンドが中断された場合は、SET MANAGED コマンドと同様に、ロールバック・コマンドを再実行して再試行できます。

ロールバックの確認

コンバージョンがロールバックされたことを確認できます。

SQL
DESCRIBE EXTENDED catalog_name.schema_name.table_name

テーブルが変換されている場合、col_nameの下のTypedata_typeの下に EXTERNAL と表示されます。

また、変換と同様に、外部テーブルにロールバックした後でストリーミングジョブを再起動する必要もあります。

ダウンタイムとデータコピー時間

ダウンタイムは、変換中にリーダーまたはライターがテーブルにアクセスするときに発生する可能性があります。ただし、'ディープクローン' コマンドと比較すると、 SET MANAGED コマンドはリーダーのダウンタイムを最小化または排除し、ライターのダウンタイムを最小限に抑えます。 Databricks Runtime 16.1 以降のリーダーでは、2 番目のデータ コピー ステップでダウンタイムは発生しません。リーダーとライターは、テーブル・データとデルタ・ログがコピーされる最初のステップでは影響を受けません。

2 番目の手順では、 Unity Catalog 外部ロケーションへの書き込みがブロックされ、最初のデータ コピー中に外部ロケーションに対して行われたコミットは移動されます。 この 2 番目のデータ コピー手順では、Databricks Runtime 15.4 LTS 以前のライターとリーダーにダウンタイムが発生します。

この後、リーダーとライターは Unity Catalog 管理場所に移動し、新しいマネージドテーブルの場所が Unity Catalogに登録されます。 Databricks Runtime 16.1 以降を使用しているリーダーは、ダウンタイムが発生しないのと同等のエクスペリエンスが発生します。

推定ダウンタイムは次のとおりです。

テーブルサイズ

推奨されるクラスタリング サイズ

データ・コピーの時間

リーダーとライターのダウンタイム

100 GB 以下

32 コア / DBSQL スモール

~6分以内

~1-2分以下

1 TB

64 コア / DBSQL ミディアム

~30分

~1-2分

10 TB

256 コア / DBSQL x-Large

~1.5時間

~1-5分

この推定値は、0.5 から 2 GB/CPU コア/分のスループット レートを前提としています。

注記

ダウンタイムは異なる場合があり、規則のパフォーマンスは、ファイルサイズ、ファイル数、コミット数などの要因によって異なります。

既知の制限事項

external からマネージドテーブルへの変換には、次の制限があります。

  • パスベースのクライアントとストリーミング クライアント : パスベースの読み取りクライアントとストリーミング クライアントは更新をサイレントに停止できるため、変換後もこれらが引き続き機能することを確認してください。また、変換後にストリーミングジョブを再起動する必要もあります。

  • ロールバック後のテーブル履歴の制約 : Databricks Runtime 15.4 LTS 以降のリーダー/ライターの場合、変換後でロールバック前に行われたコミットのテーブル履歴は、バージョンごとにタイムトラベルできますが、タイムスタンプではタイムトラベルできません。

  • 複数のクラウド リージョン : Unity Catalog メタストア、カタログ、またはスキーマのデフォルト管理場所が、変換される外部テーブルのストレージ場所とは異なるクラウド リージョンにある場合、リージョン間のデータ転送コストが追加で発生する可能性があります。 クラウド プロバイダーは、Databricks の管理外でこれらの料金を課します。

    スキーマ、カタログ、およびメタストアの場所を確認するには、次のコマンドを使用します。

    SQL
    DESC SCHEMA EXTENDED <catalog_name>.<schema_name>;

    DESC SCHEMA EXTENDED <catalog_name>;

    SELECT * FROM system.information_schema.metastores;