2025年10月23日

レイクハウスをアップグレードする：Unity Catalog マネージドテーブルへの変換ガイド

UC 外部テーブルから UC マネージドテーブルに変換してクエリを高速化し、コストを節約する

• Unity Catalog (UC) の外部テーブルを UC マネージドテーブルに、ダウンタイムを最小限に抑え、テーブル構成を維持し、テーブル履歴を保持しながらシームレスに変換する方法を学びます。
• Unity Catalog マネージドテーブルを使用して、クエリパフォーマンスを 20 倍向上させ、コストを 50% 以上削減し、高度な機能を活用します。
• データの物理的な場所を管理し、一括変換を実行し、ロールバックを処理し、移行を計画する方法を見つけます。

新しい SET MANAGED コマンドは、ダウンタイムを最小限に抑え、同時書き込みを処理し、テーブル構成を維持し、可能な場合はテーブル履歴を保持しながら、UC 外部テーブルを UC マネージドテーブルに変換するためのシームレスなメカニズムを提供します。この記事では、ベストプラクティスを共有し、この一般提供 (GA) コマンドの使用方法について段階的なガイドを提供します。

UC マネージドテーブルに変換する理由

Unity Catalog を信頼できる情報源として使用すると、マネージドテーブルは、相互運用性とポータビリティを維持しながら、パフォーマンス、ガバナンス、使いやすさを強化する独自の機能を提供します。

主な利点:

クエリパフォーマンスを 20 倍向上させ、ストレージコストを 50% 以上削減できる自動最適化 (詳細はこちら)。
削除されたデータの自動クリーンアップによるデータ管理の合理化によりコストを節約し、UNDROP もサポートします。
データリネージ、きめ細かなアクセス制御、および Unity Catalog によるすべての読み書きの監視による安全なテーブルアクセスによる強化されたガバナンス。
自動行削除 (Auto-TTL) や行レベルの取り込み (Zerobus ingest) などの将来の機能の基盤。
相互運用性: 変換されたテーブルは、任意のサードパーティクライアントからの読み取りをサポートします (詳細はこちら)。

SET MANAGED 変換コマンドはどのように役立ちますか？

SET MANAGED コマンドにより、外部テーブルからマネージドテーブルへの変換が容易になります。

機能	SET MANAGED コマンドの利点
ダウンタイムの最小化	Databricks Runtime 16.1 以降を使用してテーブルをオンラインで利用可能にし、書き込みのダウンタイムをわずか数分に最小限に抑えます (または、Databricks Runtime 15.4 以前では読み取りの場合)。
ID の保持	テーブル名、権限、タグ、およびすべてのテーブルの設定、およびテーブル履歴 (Delta テーブルの場合) はすべて保持されます。
同時実行性の処理	SET MANAGED コマンドは、変換中に発生する可能性のある同時書き込みを安全に処理します。
フェイルセーフとしての「元に戻す」	UNSET MANAGED という別のコマンドにより、安全網として、変換されたテーブルを 14 日以内に UC 外部テーブルに戻すことができます。

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

変換のための実践者のための段階的なガイド

SET MANAGED コマンドにより、テーブル変換が簡単になります。段階的なガイドで、外部テーブルからマネージドテーブルへのスムーズな移行を確保するための重要なヒントを概説しました。

ステップ 1: 変換する外部テーブルを選択する

まず、少数の Unity Catalog 外部テーブルを選択して UC マネージドに変換し、チームがプロセス、前提条件、および変換後の手順に慣れるようにします。

たとえば、Databricks クライアントによって排他的に読み書きされる少数のテーブルでこのコマンドを最初に試すことができます (「段階的なジャーニーの計画」セクションをさらに参照)。

ステップ 2: 事前チェックリスト

テーブルの読み書きクライアントのエコシステムが変更に対応できることを確認します。選択した各 UC 外部テーブルとその関連ワークロードについて、次のことを行う必要があります。

名前ベースのアクセスを使用するように更新する: ジョブ、ノートブック、クエリを確認し、パスベースのアクセス (例: SELECT * FROM delta.'s3://path/to/table') を使用するのではなく、3 部構成の名前 (カタログ.スキーマ.テーブル) を使用してテーブルにアクセスしていることを確認します。Databricks Labs は、IDE ターミナルから次の Databricks Labs UCX lint-local-code を実行して、ローカルマシンのディレクトリコード (.py または .sql ファイル) を分析することで、パスベースの参照を見つけるのに役立つ UCX ツールを開発しました。
1. テスト123
2. パスベースのリダイレクトは、名前ベースのアクセスへの更新が不可能な場合にレガシーコードを処理するためにも利用できます
メンテナンスジョブをすべてキャンセルする: 競合を防ぐため、変換プロセス中にテーブルで OPTIMIZE、ZORDER、または CLUSTER BY ジョブが実行中またはスケジュールされていないことを確認します (DESCRIBE HISTORY を使用して確認できます)。変換後、Predictive Optimization が最適化ジョブを自動的に処理します。
[オプション] Databricks Runtime バージョンをアップグレードする: テーブルを読み書きするすべての Databricks クラスターは、Delta テーブルの完全なテーブル履歴を保持するために、理想的には Databricks Runtime 15.4 LTS 以降を使用する必要があります。Databricks Runtime 16.1 以降では、リーダーのダウンタイムを完全に排除できます。

ステップ 3: 変換コマンドを実行する

次の変換コマンドを使用して変換を実行します。

注: UniForm が有効になっているテーブルの場合は、SET MANAGED TRUNCATE UNIFORM HISTORY を使用します。

ステップ 4: 結果を確認する

コマンドが完了したら、テーブルのメタデータをチェックして、変換が成功したことを確認します。

このコマンドの出力で、「Type」プロパティが「MANAGED」と表示されるはずです。これは、Catalog Explorer の「このテーブルについて」セクションでも確認できます。

ステップ 5: 変換後の整理

変換が成功したら、次の最終ステップを完了して、スムーズな移行を確保します。

一時停止している場合は、テーブルを使用するストリーミング読み取りまたは書き込みジョブを再起動します
新しくマネージドされたテーブルで、すべての読み書きクライアントが期待どおりに動作していることを確認するために、主要なクエリを実行して機能テストを実行します

Predictive Optimization がテーブルで有効になっていることを確認して、自動メンテナンスのメリットを享受し始めてください（自動リキッドクラスタリングのために CLUSTER by AUTO を有効にすることもできますし、有効になっているかどうかを確認することもできます）。

段階的な移行の計画

すべてのテーブルを UC マネージドに正常に変換することは、旅のようなものです。段階的なアプローチを採用し、事前に計画を立てることで、スムーズな移行を確保できます。

Databricks のみで利用可能なテーブルの変換: Databricks クライアントのみで読み書きされているテーブルの変換を優先してください。「Databricks の読み書きのみ」と「Databricks 以外の読み書き」を特定するのに役立つ実験的なツール、Access Insights を使用できます。
サポートされている外部ツールでのテーブルの変換: UC マネージドテーブルからの読み取りをネイティブにサポートしているサードパーティツールにアクセスされているテーブルを特定し、次にこれらのテーブルを変換します。サードパーティのアクセスは、変換後も引き続き機能します。
複雑なケースは最後に対処: サポートされていないレガシーツールでアクセスされているテーブルについては、読み取りのために互換性モードのようなソリューションの使用を計画してください。サードパーティの書き込みが必要な場合は、これらのテーブルを再作成し、プレビュープレビューでこれらの UC マネージドテーブルへの書き込みを有効にします。

その他の考慮事項

変換コマンドに関する以下の詳細は、事前に知っておくと役立つ場合があります。

ロールバックの制限時間: ロールバックのセーフティネットを使用するには、変換後 14 日以内に UC マネージドテーブルで UNSET MANAGED を実行する必要があります。それ以降は、ストレージコストを節約するために元の外部データは永久に削除されます。
タイムトラベルのニュアンス: クライアントを 15.4 LTS 以降にアップグレードすると役立ちます。Databricks Runtime 14.3 LTS 以前を実行しているクラスターを使用している場合、またはロールバックするために UNSET MANAGED コマンドを使用する場合、変換後にタイムスタンプではなくバージョン番号で履歴コミットにのみタイムトラベルできます。
ライターのダウンタイムを最小限に抑える: コマンドはダウンタイムを最小限に抑えるように設計されています。テーブルの場所が新しいマネージド場所に切り替わる最終段階では、ライターは短い停止（1〜5分と推定）を経験する可能性があります。
一時的な Delta Sharing の中断: 変換中は Delta Sharing が一時的に中断されますが、プロセスが完了すると正常に機能するようになります。

プロのヒント: バルク変換によるスケーリング

特定のスキーマ内で数百または数千の Unity Catalog 外部テーブルをバルクで変換するには、次の簡単な SQL スクリプトを使用できます。

注: このスクリプトはライブ変更を実行します。本番環境で実行する前に、開発環境で十分にテストすることを強くお勧めします。

データの物理的な場所を制御する

Unified Catalog (UC) マネージドテーブル は、顧客管理のストレージに常駐し、オープンカタログ API を介してアクセスできます。データの物理的な格納方法をより細かく制御したい場合、またはデータを分離したい場合は、カタログまたはスキーマレベルでマネージドストレージの場所を定義できます。そのカタログまたはスキーマで作成された新しいマネージドテーブルは、その指定された場所に自動的に整理されます。

既存の外部テーブルについては、マネージドストレージの場所を設定し、SET MANAGED コマンドを使用して UC マネージドテーブルに変換できます。変換中、システムは定義されたマネージド場所を尊重し、クラウドストレージ内のデータの物理的なレイアウトを制御できます。この機能は現在プライベートプレビューで提供されていますので、今すぐアクセスするにはアカウントチームにお問い合わせください。

今日から外部テーブルからマネージドテーブルへの変換

パブリックプレビューからわずか数か月で、数百もの顧客が SET MANAGED を使用して数千ものテーブルを正常に変換しました。

ここで説明されているすべてが現在 GA となっています。今すぐ試して、Unity Catalog マネージドテーブルのパフォーマンス、ガバナンス、およびシンプルさを解き放ちましょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事