自動アップグレード
プレビュー
既存スキーマの自動アップグレードはパブリックプレビュー版として提供されています。登録するには、このフォームにアカウント ID を記入してください。 登録後は、コードの変更や追加の設定は一切不要です。
新しいスキーマへの自動アップグレードは一般的に利用可能です。
Unity Catalogマネージドテーブルの場合、 Databricksコード変更や手動のALTER TABLEステートメントを必要とせずに、一般に利用可能な推奨機能を使用するように自動的にアップグレードします。 自動アップグレードでは、新機能を有効にする前に、クライアントの互換性も確認されます。
自動アップグレードには、以下の利点があります。
- ワークスペース内の各テーブルと機能の組み合わせごとに、個別の互換性要件を検証するために必要な管理作業を削減します。これは、数千ものテーブルを含むカタログを扱っている場合に特に役立ちます。
- マネージドテーブルの最新のパフォーマンスと信頼性の向上を自動的に実現します。
- テーブルを安全にアップグレードしましょう。自動アップグレードでは、ワークロードの互換性を確認した後にのみ機能が有効になります。
自動アップグレードの仕組み
自動アップグレードでは、 Unity Catalogアクセスパターンをテーブルレベルとスキーマレベルの両方で監視し、監視ウィンドウを使用して、機能を有効にする前にアクセスパターンが互換性があることを確認します。 パブリックプレビュー版の機能については50日間、一般公開版の機能については100日間の観察期間が設けられています。
自動アップグレードでは、サーバレス コンピュートを使用してバックグラウンドでテーブルをアップグレードします。
スキーマとテーブル
自動アップグレードの動作は、自動アップグレードを有効にする前にスキーマとテーブルが存在していたかどうかによって異なります。以下の表に詳細を示します。
スキーマ | テーブル | 挙動 |
|---|---|---|
新規 | 新規 | 自動アップグレードでは、作成時にスキーマレベルのデフォルト値が設定されるため、テーブルは監視期間なしにサポートされているすべての機能を即座に継承します。 |
既存 | 新規 | 自動アップグレードは、監視期間内に検証済みのワークロードのみがテーブルにアクセスした場合に、その機能を有効にします。それ以外の場合、検証されていないワークロードが1つでもテーブルにアクセスした場合、自動アップグレードはそのテーブルを無視します。検証済みのワークロードを参照してください。 |
既存 | 既存 | 自動アップグレードは、以下のすべての条件が満たされた場合に機能を有効にします。
|
検証済みワークロード
ワークロードが特定の機能に対して検証済みとみなされるのは、そのワークロードが、 Databricks Runtimeバージョンが当該機能の最小必要バージョン以上であるDatabricksコンテナーからテーブルにアクセスした場合です。
自動アップグレードでは、以下のワークロードは未検証とみなされます。
- 外部クライアントおよびFlinkやPrestoなどのサードパーティサービス。Unity Catalog統合機能を参照してください。
- Databricks Serviceにおいて、Zerobusのように、標準的なDatabricks Runtimeアクセスパターンを回避する、直接的またはカーネルレベルのテーブルアクセス機能。 Zerobus Ingestコネクタの概要を参照してください。
スキーマ内のいずれかのテーブルが、監視期間内に、その機能の最小必要バージョンよりも低いバージョンのDatabricks Runtime、または外部クライアントによってアクセスされた場合、自動アップグレードでは、そのスキーマ内のどのテーブルに対しても、対応する機能が有効になりません。
サポートされている機能
自動アップグレードにより、一般提供されている機能が自動的に有効になります。ただし、パブリックプレビューに登録しない限り、アップグレードによってパブリックプレビューの機能が有効になることはありません。
自動アップグレードでは、以下の機能がサポートされます。
機能 | その機能 | リリース状況 | 互換性のある最小Databricks Runtimeバージョン |
|---|---|---|---|
変更データフィードによる増分処理のために非表示の行 ID を維持します。 | 一般的に、新しいスキーマ内の新しいテーブルで利用可能です。既存スキーマ内のすべてのテーブルのパブリックプレビュー。 | 14.1 | |
Delta Lakeより多くの ライターをサポートし、大規模なテーブルや頻繁に更新されるテーブルでの書き込み競合を軽減します。 | 一般的に、新しいスキーマ内の新しいテーブルで利用可能です。既存スキーマ内のすべてのテーブルのパブリックプレビュー。 | 13.3 | |
頻繁にクエリされる列に基づいてテーブルデータを自動的に整理し、手動でパーティショニングすることなくクエリのパフォーマンスを向上させます。 | 一般的に、新しいスキーマ内の新しいテーブルで利用可能です。既存スキーマ内の新規テーブルのパブリックプレビュー。この機能の自動アップグレードでは、既存のテーブルは無視されます。 | 13.3 | |
Unity Catalogでコミットを一元化して、複数テーブルのトランザクションを許可し、外部書き込みの相互運用性を向上させ、エンジン全体でのガバナンス ポリシーを許可します。 | すべてのスキーマのすべてのテーブルのパブリックプレビュー。 | 16.4 | |
データを書き換えることなく、列の名前変更や削除を行うことができます。 | すべてのスキーマのすべてのテーブルのパブリックプレビュー。 | 15.3 |
機能の利用可否は地域によって異なる場合があります。
要件
- サーバーレス コンピュートはお住まいの地域で利用できる必要があります。
- テーブルはDelta LakeまたはApache Iceberg形式のUnity Catalogマネージドテーブルである必要があります。
有効になっている機能を確認する
自動アップグレードによってテーブルの機能が有効になったかどうかを確認するには、カタログエクスプローラーの 履歴 タブでSET TBLPROPERTIES操作を探すか、 DESCRIBE HISTORY <table_name>使用します。自動アップグレードによって操作が実行された場合、ユーザー名フィールドにはユーザー名の代わりにハッシュ値（例： 4d137f29-62が表示されます。「カタログエクスプローラーとは？」を参照してください。テーブル履歴を表示する。
自動アップグレードによって新しいスキーマ内のテーブルの機能が有効になった後、カタログエクスプローラーの プロパティ タブでスキーマのデフォルト設定を確認してください。例えば、行追跡が有効になっているスキーマでは、 catalog.schema.enableRowTracking: "true"のようなプロパティが表示されます。既存のスキーマには、自動アップグレードの可観測性プロパティがありません。
推奨機能の管理
管理者は、さまざまな制御機能を使用して、アップグレードの動作と操作を管理できます。
変更を元に戻す
テーブルのデータとメタデータを、この機能が有効になる前のバージョンに戻すには、 RESTORE使用します。
RESTORE TABLE <table_name> TO VERSION AS OF <version>;
RESTORE TABLE <table_name> TO TIMESTAMP AS OF <timestamp>;
テーブルの履歴と復元に関する詳細については、 「テーブルを以前の状態に復元する」を参照してください。
テーブルの機能をオフにする
個々のテーブルの機能を無効にするには：
ALTER TABLE <table_name> DROP FEATURE <feature_name>
自動アップグレードでは、手動で無効にした機能は再び有効になりません。
制限事項
- Delta Lake Sharingによって共有されるテーブル（Databricks-to-OpenおよびDatabricks-to-Databricksの両方）は、自動アップグレードの対象外となります。Delta Sharingとは何かをご覧ください。
- 自動アップグレードには、アカウント内のすべてのテーブルにわたって機能をオフにするバッチ ロールバック メカニズムがありません。 自動アップグレードの管理に関する推奨機能を参照してください。
- マテリアライズドビューとストリーミングテーブルはサポートされていません。
- Unity Catalogを迂回し、パスによってテーブルに直接アクセスするワークロードは、自動アップグレードの対象外となります。 ワークロードでパスベースのアクセスを使用している場合は、互換性についてアカウントチームにご相談ください。
- 外部テーブルは通常、 Unity Catalogをバイパスし、外部クライアントからの未検証のワークロードを使用してファイル パスによってアクセスされます。 Unity Catalogはこれらのアクセスパターンを確実に追跡できないため、外部テーブルは自動アップグレードの対象外となります。外部テーブルの操作を参照してください。