自動機能有効化
プレビュー
自動機能有効化機能はパブリックプレビュー版として提供されています。登録するには、このフォームにアカウント ID を記入してください。 登録後は、コードの変更や追加の設定は一切不要です。
自動機能有効化 (AFE) は、 Unity Catalog自動的にアップグレードします コードの変更や手動ALTER TABLEステートメントを必要とせずに、一般的に利用可能な推奨機能を使用するようにします。 AFEは、新機能を有効にする前に、クライアントとの互換性も検証します。
AFEは以下のメリットを提供します。
- 特に数千ものテーブルを含むカタログを扱っている場合、ワークスペース内の各テーブルと機能の組み合わせごとに個別の互換性要件を検証するために必要な管理作業を削減できます。
- マネージドテーブルの最新のパフォーマンスと信頼性の向上を自動的に取得します。
- アップグレードを安全に実施する。AFEは、ワークロードの互換性を確認した後にのみ機能を有効にします。
AFEの仕組み
AFEはUnity Catalogアクセスパターンをテーブルレベルとスキーマレベルの両方で監視し、50日間の観測期間を使用して、機能を有効にする前にアクセスパターンが互換性があることを確認します。 AFE はサーバレス コンピュートを使用してバックグラウンドでテーブルをアップグレードします。
スキーマとテーブル
AFEの動作は、スキーマとテーブルがAFEを有効にする前に存在していたかどうかによって異なります。この表にはさらに詳しい情報が記載されています。
スキーマ | テーブル | AFEの挙動 |
|---|---|---|
新規 | 新規 | AFEは作成時にスキーマレベルのデフォルト値を設定するため、テーブルは観察期間なしにサポートされているすべての機能を即座に継承します。 |
既存 | 新規 | AFEは、検証済みのワークロードのみが50日間の観測期間内にスキーマ内のすべてのテーブルにアクセスした場合に、その機能を有効にします。それ以外の場合、検証されていない単一のワークロードがスキーマ内のいずれかのテーブルにアクセスした場合、AFE はスキーマ内の新しいテーブルの機能を有効にしません。検証済みのワークロードを参照してください。 |
既存 | 既存 | AFEは、以下のすべての条件が満たされた場合に機能を有効にします。
|
検証済みワークロード
ワークロードが特定の機能に対して検証済みとみなされるのは、そのワークロードが、 Databricks Runtimeバージョンが当該機能の最小必要バージョン以上であるDatabricksコンテナーからテーブルにアクセスした場合です。
以下のワークロードは未検証とみなされます。
- 外部クライアントおよびFlinkやPrestoなどのサードパーティサービス。Unity Catalog統合機能を参照してください。
- Databricks Serviceにおいて、Zerobusのように、標準的なDatabricks Runtimeアクセスパターンを回避する、直接的またはカーネルレベルのテーブルアクセス機能。 Zerobus Ingestコネクタの概要を参照してください。
スキーマ内のいずれかのテーブルが、50日間の観測期間内に、その機能の最小必要バージョンを下回るDatabricks Runtimeバージョン、または外部クライアントによってアクセスされた場合、AFEはそのスキーマ内のどのテーブルに対しても、対応する機能を有効にしません。
サポートされている機能
AFEは、以下の機能を自動的に有効にする場合があります。
機能 | その機能 | 互換性のある最小Databricks Runtimeバージョン |
|---|---|---|
変更データフィードによる増分処理のために非表示の行 ID を維持します。 | 14.1 | |
データを書き換えることなく、列の名前変更や削除を行うことができます。 | 15.3 | |
Delta Lakeがより多くの ライターをサポートし、大規模または頻繁に更新されるテーブルでの書き込み競合を軽減します。 | 13.3 | |
Unity Catalogでコミットを一元化してマルチテーブル トランザクションを有効にし、外部書き込みの相互運用性を向上させ、エンジン全体でのガバナンス ポリシーを有効にします。 | 16.4 |
機能の利用可否は地域によって異なる場合があります。
要件
- サーバーレス コンピュートはお住まいの地域で利用できる必要があります。
- テーブルはDelta LakeまたはApache Iceberg形式のUnity Catalogマネージドテーブルである必要があります。
有効になっている機能を確認する
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 Catalogをバイパスしてファイルパスで直接テーブルにアクセスするワークロードは、AFEでは追跡されません。ワークロードでパスベースのアクセスを使用している場合は、互換性についてアカウントチームにご相談ください。
- 外部テーブルは通常、 Unity Catalogをバイパスし、外部クライアントからの未検証のワークロードを使用してファイル パスによってアクセスされます。 Unity Catalog ではこれらのアクセスパターンを確実に追跡できないため、外部テーブルは AFE から除外されます。 「外部テーブルの操作」を参照してください。