自動アップグレード
Databricks は、コードの変更や手動の ALTER TABLE ステートメントを必要とせずに、Unity Catalog マネージドテーブルを自動的にアップグレードして、一般提供されている推奨機能を使用するようにします。自動アップグレードは、新機能を有効にする前に、クライアントに互換性があることを確認します。
自動アップグレードには、以下の利点があります。
- ワークスペース内の各テーブルと機能の組み合わせごとに、個別の互換性要件を検証するために必要な管理作業を削減します。これは、数千ものテーブルを含むカタログを扱っている場合に特に役立ちます。
- マネージドテーブルの最新のパフォーマンスと信頼性の向上を自動的に実現します。
- テーブルを安全にアップグレードしましょう。自動アップグレードでは、ワークロードの互換性を確認した後にのみ機能が有効になります。
これらの機能に関連する利点の詳細については、「自動アップグレード：lakehouse テーブルのベストプラクティス機能」を参照してください。
自動アップグレードの仕組み
自動アップグレードは、Unity Catalog マネージドテーブルのアクセスパターンを監視し、監視期間を使用して、アクセスパターンに互換性があることを検証してから、機能を有効にします。監視期間は、パブリックプレビューでのアップグレードでは50日間、一般提供されているアップグレードでは100日間です。サポートされている機能を参照してください。
自動アップグレードは、Serverless コンピュートを使用してバックグラウンドでテーブルをアップグレードします。このプロセスに料金はかかりません。
スキーマとテーブル
自動アップグレードの動作は、機能がリリースされた時点でスキーマが新しいか、すでに存在していたかによって異なります。新しいテーブルを作成すると、そのスキーマのdefaultプロパティから機能が継承されます。次の表に各ケースを示します:
スキーマ | テーブル | 挙動 |
|---|---|---|
新規 | 新規 | 自動アップグレードは、作成時にスキーマレベルのdefaultを設定するため、テーブルはサポートされているすべての機能をすぐに継承します。 |
既存 | 新規 | 自動アップグレードは、以前の監視期間中にそのスキーマ内のすべてのテーブルが検証済みワークロードによってアクセスされた場合にのみ、機能を有効にします。それ以外の場合、単一の未検証ワークロードがスキーマ内のいずれかのテーブルにアクセスした場合、自動アップグレードは新しいテーブルを無視します。検証済みのワークロードを参照してください。 |
既存 | 既存 | 自動アップグレードは、以下のすべての条件が満たされた場合に機能を有効にします。
|
検証済みワークロード
ワークロードが特定の機能に対して検証済みとみなされるのは、そのワークロードが、 Databricks Runtimeバージョンが当該機能の最小必要バージョン以上であるDatabricksコンテナーからテーブルにアクセスした場合です。
自動アップグレードでは、以下のワークロードは未検証とみなされます。
- 外部クライアントおよびFlinkやPrestoなどのサードパーティサービス。Unity Catalog統合機能を参照してください。
- Databricks Runtime の標準アクセスパターンをバイパスする、Zerobus など、直接テーブルにアクセスできる Databricks サービス。「Zerobus Ingest コネクタの概要」を参照してください。
スキーマ内のいずれかのテーブルが、監視期間内に、その機能の最小必要バージョンよりも低いバージョンのDatabricks Runtime、または外部クライアントによってアクセスされた場合、自動アップグレードでは、そのスキーマ内のどのテーブルに対しても、対応する機能が有効になりません。
サポートされている機能
自動アップグレードは、以下のテーブルに記載されている、一般提供されている機能の一部に適用されます。機能の可用性はリージョンによって異なる場合があります。
自動リキッドクラスタリングは、新しいテーブルにのみ適用されます。他の機能とは異なり、テーブルを作成するときにdefaultで追加され、既存のテーブルには適用されません。
一般提供されているアップグレード付き機能
以下の機能は一般提供されており、自動アップグレードによって指定されたテーブルタイプに適用されます。自動アップグレードシステムも一般提供されています。
各機能はリリース日から段階的に展開され、約6か月以内にすべての顧客に提供されます。
機能 | テーブルタイプ | 互換性のある最小Databricks Runtimeバージョン | その機能 | リリース日 |
|---|---|---|---|---|
- すべての新規テーブル | 15.4 LTS | 手動パーティション分割なしで、頻繁に クエリー される列に基づいてテーブルデータを自動的に整理し、クエリー パフォーマンスを向上させます。自動アップグレードは、この機能を既存のテーブルには適用しません。 | 2026年5月22日 | |
- すべての新規テーブル - 既存のテーブル | 13.3 LTS | より多くの並列書き込みユーザーをサポートし、大規模なテーブルや頻繁に更新されるテーブルでの書き込みの競合を削減します。 | 新しいスキーマ内の新しいテーブルの場合、2026年5月19日 既存のスキーマ内のすべてのテーブルの場合、2026年7月13日 | |
- すべての新規テーブル - 既存のテーブル | 14.1 | 増分処理のために隠された行IDを維持します。行トラッキングが有効な場合、追加の設定なしで自動チェンジデータフィードが利用可能です。AUTO CDC APIsを参照してください。 | 新しいスキーマの新しいテーブルの場合、2026年7月25日。 既存のスキーマ内のすべてのテーブルの場合、2026年7月13日 | |
— 新しいスキーマの新しいテーブル | 16.4 LTS | Unity Catalogでコミットを一元化して、複数テーブルのトランザクションを許可し、外部書き込みの相互運用性を向上させ、エンジン全体でのガバナンス ポリシーを許可します。 | 2026年7月13日 | |
— 新しいスキーマの新しいテーブル | 18.1 | 高度なParquetエンコーディング、データページヘッダー、および | 2026年6月25日 |
パブリックプレビューでアップグレードされる機能
以下の機能は一般提供されていますが、それらの自動アップグレードはパブリックプレビュー段階であり、登録が必要です。
プレビュー
以下の機能の自動アップグレードは、パブリック プレビューです。登録するには、このフォームにアカウント ID を入力してください。登録後にコードの変更や追加の設定は不要です。
これらの機能に対する自動アップグレードは、パブリックプレビューに登録している場合にのみ適用され、登録後すぐに有効になります。
機能 | テーブルタイプ | 互換性のある最小Databricks Runtimeバージョン | その機能 |
|---|---|---|---|
- 既存のスキーマ内のすべてのテーブル | 16.4 LTS | Unity Catalogでコミットを一元化して、複数テーブルのトランザクションを許可し、外部書き込みの相互運用性を向上させ、エンジン全体でのガバナンス ポリシーを許可します。 | |
- すべてのテーブル | 15.4 LTS | データを書き換えることなく、列の名前変更や削除を行うことができます。 | |
- 既存のスキーマ内のすべてのテーブル | 18.1 | 高度なParquetエンコーディング、データページヘッダー、および |
要件
- サーバーレス コンピュートはお住まいの地域で利用できる必要があります。
- テーブルは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 の両方）は、自動アップグレードの対象外です。「オープン共有とは何ですか？」をご覧ください。
- 自動アップグレードには、アカウント内のすべてのテーブルで機能をオフにするバッチロールバックメカニズムはありません。自動アップグレード推奨機能を管理するを参照してください。
- マテリアライズドビューとストリーミングテーブルはサポートされていません。
- Unity Catalogを迂回し、パスによってテーブルに直接アクセスするワークロードは、自動アップグレードの対象外となります。 ワークロードでパスベースのアクセスを使用している場合は、互換性についてアカウントチームにご相談ください。
- 外部テーブル は自動アップグレードの対象外です。外部テーブル は通常、ファイルパスを介して Unity Catalog をバイパスしてアクセスされ、Unity Catalog はこれらのアクセスパターンを確実に追跡できません。「外部テーブル の操作」を参照してください。
よくある質問
以下は、自動アップグレードに関する一般的な質問への回答です。
Unity Catalog マネージドテーブルの自動アップグレードとは何ですか？
このページの上部にあるはじめにを参照してください。
自動アップグレードはどのように互換性を確認しますか？
検証済みワークロードを参照してください。
自動アップグレードにより、テーブルは自動的に変更されますか？
はい。機能がテーブルに安全であることが確認されると、Databricks は軽量なバックグラウンド ジョブ によってそれを適用します。個々のテーブルの機能を引き続きオフにできます。
テーブルで機能をオフにした場合、後で自動アップグレードによって再びオンにできますか？
いいえ。自動アップグレードによって追加された機能を無効にした後、自動アップグレードはそのテーブルに対してその機能を再度有効にすることはありません。
自動アップグレードは既存のテーブルを変更しますか？
はい。ただし、監視ウィンドウで、テーブルにアクセスしたすべてのクライアントがその機能をサポートしていることを確認した後でのみです。自動リキッドクラスタリングは例外です。既存のテーブルのデータ Layout を変更するため、新規作成されたテーブルにのみ適用され、既存のテーブルには適用されません。
自動アップグレードは予測的最適化とどう違うのですか？
予測的最適化は、コンパクションや vacuum などの操作を通じてデータ Layout を維持し、自動リキッドクラスタリングを使用するオプションがあります。自動アップグレードにより、行追跡やチェックポイント V2 などの新しいテーブル機能が有効になります。この2つは補完的な関係にあります。一方はテーブルを適切に維持し、もう一方はテーブルを最新の状態に保ちます。自動リキッドクラスタリングは、自動アップグレードを通じて新しいテーブルに適用されます。Unity Catalog マネージドテーブルの予測的最適化を参照してください。
自動アップグレードは、テーブルが安全にアップグレードできることをどのように確認しますか？
自動アップグレードは、パフォーマンスを大幅に低下させたりコストを増加させたりしない、一般提供されている機能のみを有効にします。自動アップグレードは、観測期間を待機し、すべてのアクセスするクライアントに互換性があることを要求し、完全に検証できないテーブルをスキップし、テーブル上の任意の機能をいつでもオフにできるようにします。
テーブルが変更された場合、それが自動アップグレードによるものだとどのように判断できますか？
自動アップグレードによって行われたすべての変更は、テーブルのDESCRIBE HISTORY出力とカタログエクスプローラーの History tabに表示され、ユーザー自身の変更とは明確に区別されます。アカウント全体の可視性のために、system.storage.table_auto_upgrade_operations_historyをクエリーして、任意のテーブルに機能が追加された時期を確認してください。テーブル履歴の表示を参照してください。
自動アップグレードにより、外部ツールまたはオープンソースツールが読み取るテーブルが壊れますか？
いいえ。外部クライアントまたはオープンソースクライアントによってアクセスされるテーブルは対象外です。自動アップグレードは、テーブルにアクセスするすべてのクライアントがその機能をサポートしていることを確認できる場合のみ機能します。
どのテーブルが自動アップグレードの対象となりますか？
テーブルがアップグレードされるまでどのくらいかかりますか？いつ変更が表示されますか？
自動アップグレードは、監視期間を使用して、月次バッチジョブ、四半期レポート、アドホック分析などの頻度の低いワークロードを、実行する前に把握します。テーブルの互換性が検証されると、その機能はすぐにバックグラウンドジョブを通じて適用されます。機能が初めてロールアウトされるとき、顧客やテーブル全体で段階的にロールアウトされるため、互換性のあるワークロードを持つテーブルに到達するまでに約6か月かかることがあります。
Databricksでテーブル機能を自動的に有効にするには、どうすればよいですか？
操作は不要です。自動アップグレードは、設定なしで対象となるテーブルを評価してアップグレードします。
アカウント全体、スキーマ、カタログ、またはワークスペースの自動アップグレードをオフにできますか？
自動アップグレードを完全にオフにすることはできませんが、テーブル上の個々の機能をいつでもオフにできます。これを行うと、自動アップグレードによってそのテーブルのその機能が再度有効にされることはありません。
自動アップグレードに費用はかかりますか？
自動アップグレードプロセス（バックグラウンドのALTER TABLE操作）には料金はかかりません。
自動アップグレードによって適用される機能に費用はかかりますか？
一般的に、大幅にコストを増加させる機能は自動アップグレードから除外されます。削除ベクトルやParquet v2などのいくつかの適用された機能は、ストレージとコンピュートのコストを削減します。行追跡は、すべての行に一意の識別子を割り当てるため、非常に大きなテーブルでわずかな1回限りの初期コストを発生させますが、フル再計算の代わりに増分更新を有効にすることで、マテリアライズドビューのコスト削減にも役立ちます。
今後、自動アップグレードで展開される機能はどのように追跡できますか？
サポートされている機能を確認して、どの機能がパブリックプレビュー段階であり、どの機能がまもなくすべての顧客に展開されるかを確認してください。新しい機能がリリースされたときに通知を受け取るには、DatabricksリリースノートページでRSSフィードを設定してください。また、今後の予定を確認することもできます。