次の方法で共有

自動機能の有効化

Important

自動機能の有効化は パブリック プレビュー段階です。 登録するには、 アカウント ID を使用してこのフォーム に入力します。 登録後にコードの変更や追加の構成は必要ありません。

自動機能有効化 (AFE) では、コードの変更や手動の ALTER TABLE ステートメントを必要とせずに、一般公開されている推奨機能を使用するように Unity カタログのマネージド テーブルが自動的にアップグレードされます。 また、AFE は、新しい機能を有効にする前に、クライアントが互換性があることを確認します。

AFE には、次の利点があります。

  • ワークスペース内の各テーブルと機能の組み合わせの個々の互換性要件を検証するために必要な管理作業を減らします(特に、数千のテーブルを含むカタログがある場合)。
  • マネージド テーブルの最新のパフォーマンスと信頼性の向上を自動的に取得します。
  • アップグレードを安全に実装します。 AFE は、ワークロードの互換性を検証した後にのみ機能をオンにします。

AFE のしくみ

AFE は、テーブル レベルとスキーマ レベルの両方で Unity カタログのアクセス パターンを監視し、50 日間の監視ウィンドウを使用して、機能を有効にする前にアクセス パターンに互換性があることを確認します。 AFE では、サーバーレス コンピューティングを使用してバックグラウンドでテーブルをアップグレードします。

スキーマとテーブル

AFE の動作は、AFE が有効になる前にスキーマとテーブルが存在するかどうかによって異なります。 この表の詳細は次のとおりです。

Schema テーブル AFE の動作
新規 新規 AFE では作成時にスキーマ レベルの既定値が設定されるため、テーブルは、監視期間なしでサポートされているすべての機能をすぐに継承します。
Existing 新規 検証済みのワークロードのみが 50 日間の監視ウィンドウ内のスキーマ内のすべてのテーブルにアクセスした場合、AFE によって機能が有効になります。 それ以外の場合、検証されていない 1 つのワークロードがスキーマ内のテーブルにアクセスした場合、AFE はスキーマ内の新しいテーブルの機能を有効にしません。 検証済みのワークロードを参照してください。
Existing Existing AFE は、次のすべてが当てはまる場合に機能をオンにします。
  • 検証済みのワークロードのみが、50 日間の監視ウィンドウ内のテーブルにアクセスしました。 検証済みのワークロードを参照してください。
  • テーブルの最初に記録されたアクセスは、50 日間の監視ウィンドウの前に発生しました。
  • テーブルは過去 30 日以内にアクセスされました。 AFE は非アクティブなテーブルをスキップします。

検証済みワークロード

ワークロードは、Databricks Runtime バージョンが機能の最低限必要なバージョン以上の Databricks クラスターからテーブルにアクセスした場合、特定の機能について検証済みと見なされます。

次のワークロードは未確認と見なされます。

  • 外部クライアントと、Flink や Presto などのサード パーティのサービス。 Unity カタログの統合を参照してください。
  • Azure Databricksは、標準のDatabricksランタイムアクセスパターンをバイパスする、Zerobusなどの直接またはカーネルレベルのテーブルアクセスを使用したサービスを提供しています。 Zerobus 取り込みコネクタの概要を参照してください。

Databricks Runtime バージョンが機能の最低限必要なバージョンより下にあるか、外部クライアントによって、スキーマ内のテーブルが 50 日間の監視ウィンドウ内でアクセスされた場合、AFE は、そのスキーマ内のどのテーブルでも対応する機能を有効にしません。

サポートされている機能

AFE では、次の機能が自動的に有効になる場合があります。

特徴 動作内容 互換性のある Databricks ランタイムの最小バージョン
行の追跡 変更データ フィードを使用した増分処理用の非表示の行 ID を保持します。 14.1
列マッピング データを書き換えずに列の名前を変更および削除できます。 15.3
チェックポイント V2 Delta Lake でより多くの同時実行ライターをサポートし、大きなテーブルまたは頻繁に更新されるテーブルでの書き込みの競合を減らすことができます。 13.3
カタログ管理のコミット Unity カタログのコミットを一元化して、マルチテーブル トランザクションを有効にし、外部書き込みの相互運用性を向上させ、エンジン間のガバナンス ポリシーを有効にします。 16.4

機能の可用性は、リージョンによって異なる場合があります。

必要条件

  • サーバーレス コンピューティングは、お使いのリージョンで使用できる必要があります。
  • テーブルは、Delta Lake または Apache Iceberg 形式の Unity カタログ マネージド テーブルである必要があります。

有効な機能を観察する

AFE でテーブルの機能が有効になっているかどうかを確認するには、カタログ エクスプローラーの [SET TBLPROPERTIES] タブで操作を探すか、DESCRIBE HISTORY <table_name>を使用します。 AFE が操作を実行した場合、ユーザー名フィールドには、 4d137f29-62などのユーザー名の代わりにハッシュ値が表示されます。 「 カタログ エクスプローラーとは」 と 「テーブル履歴の表示」を参照してください。

AFE で新しいスキーマのテーブルの機能を有効にした後、カタログ エクスプローラーの [プロパティ ] タブでスキーマの既定値を表示します。 たとえば、行追跡が有効になっているスキーマには、 catalog.schema.enableRowTracking: "true"などのプロパティが表示されます。 既存のスキーマには AFE 監視プロパティがありません。

AFE の推奨機能を管理する

管理者は、さまざまなコントロールを使用して AFE の動作と操作を管理できます。

変更を元に戻す

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>

手動で機能をオフにしても、AFE は機能を再びオンにしません。

制限事項

  • Delta Lake Sharing によって共有されるテーブル (Databricks-to-Open と Databricks-to-Databricks の両方) は、AFE から除外されます。 「Delta Sharing とは」を参照してください。
  • AFE には、アカウント内のすべてのテーブルで機能を無効にするバッチ ロールバック メカニズムはありません。 AFE の推奨機能の管理を参照してください。
  • 具体化されたビューとストリーミング テーブルはサポートされていません。
  • Unity カタログをバイパスし、ファイル パスによってテーブルに直接アクセスするワークロードは、AFE では追跡されません。 ワークロードでパスベースのアクセスを使用している場合は、アカウント チームに連絡して互換性について話し合ってください。
    • 外部テーブルは通常、ファイル パスによってアクセスされ、Unity カタログをバイパスし、外部クライアントから検証されていないワークロードを使用します。 Unity カタログではこれらのアクセス パターンを確実に追跡できないため、外部テーブルは AFE から除外されます。 「外部テーブルを操作する」を参照してください。
  • Last updated on