自動アップグレード：レイクハウステーブル向けのベストプラクティス機能

Unity Catalog (UC) の管理テーブルが、自動的に改善されるようになりました。自動アップグレード（Auto Upgrades）は、レイクハウスにおけるこの種のものとしては初の機能です。クライアントの互換性を自動的に検証し、テーブルの準備が整った瞬間に、手動での作業を一切必要とせずに Row Tracking などのベストプラクティス機能を適用します。

オープンテーブルフォーマットは急速に進化しており、多くの新しいテーブル機能が導入されています。しかし、これまでは新しいテーブル機能を採用するには、対象となるテーブルを特定し、クライアントの互換性を検証し、数千ものテーブルに対して ALTER TABLE を実行する必要がありました。ほとんどのチームにはそのような時間が割けないため、これらの機能がもたらすパフォーマンスの向上、信頼性、相互運用性、コスト削減といったメリットを享受できていません。Auto Upgrades はそのギャップを埋め、制御性も維持します。すべての変更はテーブルごとに元に戻すことができます。

精神的な負担を軽減してくれるものは何でも大歓迎です。すべてのテーブルのすべての新機能についていくのは大変なので、Auto Upgrades が私の代わりにメンテナンスを処理してくれるのを楽しみにしています！ —Audrey Boslego, Data Platform Engineering Manager

Auto Upgrades の仕組み

Auto Upgrades は、既存のテーブルへのアクセス方法を観察し、すべてのワークロードの準備が整っていることを検証した上で、ユーザーに代わって機能を適用します。

1. 観察（Observe）：既存のすべての UC 管理テーブルについて、Auto Upgrades はローリング観察ウィンドウを通じて、そのテーブルにアクセスしているクライアントを観察します。

2. 検証（Verify）：各機能について、Auto Upgrades は同じ観察ウィンドウにおいて以下の条件がすべて満たされていることを確認します。

• 観察ウィンドウ中にテーブルにアクセスしたすべての Databricks クライアントが、その機能をサポートする Databricks Runtime バージョンを使用していること
• テーブル自体がアクティブであること（完全にアイドル状態のテーブルはスキップされます）
• （現時点では）観察ウィンドウ中に外部クライアントがテーブルにアクセスしていないこと

3. アップグレード（Upgrade）：テーブルが条件を満たすと、Auto Upgrades は軽量なバックグラウンドジョブを通じて ALTER TABLE を実行し、安全に機能を適用します。

新しいテーブルへの拡張：スキーマ内のすべての既存テーブルが機能と互換性があることが検証されると、Auto Upgrades はそれをスキーマのデフォルトに設定します。これにより、そのスキーマで新しく作成されるテーブルは自動的にその機能を継承します。作成時に明示的に設定したテーブルプロパティは、常に優先されます。

将来的には、Auto Upgrades は外部クライアントによってアクセスされるテーブルに対しても、特定の機能との互換性を検出することで、機能を有効にすることを目指しています。私たちは、これらのクライアントの互換性を検出するための適切なメタデータを提供する標準規格について、コミュニティと協力して取り組んでいます。

手動アップグレードよりも徹底的

慎重な手動アップグレードには、適切な機能の選択、それらが本番環境に対応していることの確認、すべてのクライアントがそれらをサポートしていることの検証、そしてロールバック方法の確保など、多大な労力が必要です。Auto Upgrades は、これと同じ徹底した検証をすべてのテーブルに自動的に適用します。

✅ GA（一般提供）のみ、パフォーマンスやコストへの重大な悪影響なし。 機能が Auto Upgrades の対象となるのは、一般提供（GA）に達しており、パフォーマンスを著しく低下させたりコストを増加させたりしない場合に限られます。多くの機能はパフォーマンスを向上させるかコストを削減しますが、悪化させるものは一つもありません。

✅ 包括的な観察ウィンドウ。 すべてのデータワークロードが毎日実行されるわけではありません。月次のバッチジョブ、四半期ごとのレポート、アドホックな分析などは、実行されるまでに数週間かかる場合があります。Databricks は、ロングテールを捉えるために 100 日間のウィンドウを採用し、決定を下す前にテーブルが実際にどのように使用されているかの全体像を完全に把握します。

✅ 厳格な互換性検証。 アクセスするすべてのクライアントがその機能をサポートするまで、機能を有効にすることはありません。サポートされていないクライアントが 1 つでもある場合は、既存のテーブルと、新しいテーブルを管理するスキーマのデフォルト設定の両方について、適用を保留します。

✅ 検証できない場合は処理を行わない。 Auto Upgrades は、完全に検証できるテーブルに対してのみ動作します。外部クライアントがアクセスしたテーブルは対象外となり、30 日以上アクティブでないテーブルはスキップされます。

✅ ユーザーの決定を尊重。 Auto Upgrades によって有効にされたすべての機能は、いつでもテーブルごとに無効化または削除できます。テーブルで機能を一度無効にすると、Auto Upgrades が後からそれを再度有効にすることはありません。

Auto Upgrades がもたらすメリット

Auto Upgrades は、実績のあるベストプラクティス機能を UC 管理テーブルにもたらします。これには、ほとんどのチームが望んでいながらも、手動での作業が必要なために有効にできていなかった機能が含まれます。

Auto Upgrades が実行されると、テーブルは徐々に以下のようになります：

より高速でコスト効率の高いテーブル。 テーブルのクエリが高速化し、保存コストや変更コストが削減されます。

• スキーマのデフォルトとして設定されている新しいテーブルに Automatic Liquid Clustering が適用され、実際に実行されるクエリに応じてデータレイアウトを最適化し、ワークロードの進化に適応します。そのため、ZORDER や手動のクラスタリングキーは不要になります。
• Deletion Vectors は、データファイル全体を書き換える代わりに、行を削除済みまたは更新済みとしてマークするため、削除や更新がより高速かつ低コストで実行されます。
• Column Mapping により、データを書き換えることなく、列の名前変更や削除を即座に行うことができます。
• Parquet V2 はデータをより効率的に圧縮し、ストレージコストを削減してスキャンを高速化します。

エンジン間のオープンな相互運用性。 テーブルがより多くのフォーマットやエンジンに対応し、それらすべてに対して Unity Catalog でのガバナンスが適用されます。

• Catalog Commits により、UC はエンジン間で管理テーブルを調整するシステムになります。これにより、外部エンジンから UC 管理テーブルへの書き込みが可能になり、外部エンジンへの ABAC ポリシーの適用や、複数テーブル、複数ステートメントのトランザクションが可能になります。
• Row Tracking は一意の行レベルの識別子を追加し、Iceberg と Delta 全体で Automatic Change Data Feed、Vector Search、Lakebase への道を開きます。また、マテリアライズドビュー（Materialized Views）をビュー全体で再計算するのではなく、段階的に（インクリメンタルに）リフレッシュできるようにし、リフレッシュコストを大幅に削減します。

負荷がかかった状態での信頼性の向上。 テーブルが成長し、書き込み量が増加しても、テーブルの安定性が維持されます。

• Checkpoint V2 は、よりスケーラブルなフォーマットでテーブルのメタデータを維持し、多数の同時書き込みが発生する状況でのコミット失敗を減らします。

Auto Upgrades は今後も拡張を続け、より多くの機能をカバーし、マテリアライズドビュー（Materialized Views）やストリーミングテーブル（Streaming Tables）などの追加の UC 管理テーブルタイプをサポートする予定です。

包括的なオブザーバビリティ（可観測性）

Auto Upgrades が追加するすべての機能は、ユーザーが開始した変更と区別できる形で、テーブルの DESCRIBE HISTORY 出力および Catalog Explorer の履歴タブに表示されます。詳細については、有効化された機能の観察を参照してください。

アカウント全体の可視性を確保するため、システムテーブルにクエリを実行して、テーブル、機能、タイムスタンプごとにすべての Auto Upgrades イベントを表示できるようになります。たとえば、特定のテーブルのすべての機能に対して発生したすべての自動アップグレード操作を表示するには、次のようにします。

はじめに

Auto Upgrades は UC 管理テーブルで動作します。そのため、開始するために最も効果的なステップは、テーブルがこのタイプのテーブルに変換されていることを確認することです。

どのテーブルが Unity Catalog によって管理されているかわからない場合は、Catalog Explorer でテーブルタイプを確認するか、テーブルに対して DESCRIBE EXTENDED を実行してください。

テーブルを一括で監査するために、Auto Upgrades システムテーブルを使用して、どのテーブルでどの機能がいつ有効にされたかを確認することもできます。

取り込みたい外部テーブルがある場合は、1回の SET MANAGED で変換することができ、その後は自動アップグレードが処理を引き継ぎます。

自動アップグレードの仕組み、有効になる機能、およびそのアクティビティを監視する方法の詳細については、ドキュメントを参照してください。

自動アップグレードにより、管理テーブルは自動的に管理されます。 Databricksが新しい機能を提供するにつれて、面倒な ALTER TABLE の繰り返しや、互換性の監査、移行プロジェクトを行うことなく、テーブルは継続的に改善されます。より高速で、信頼性が高く、相互運用性に優れたテーブルを自動的に利用できるようになります。

よくある質問

自動アップグレードでは、テーブルを安全にアップグレードできることをどのように確認していますか？

自動アップグレードは、パフォーマンスを実質的に低下させたりコストを増加させたりしない、一般提供（GA）機能のみを適用します。100日間の観察期間を設け、アクセスするすべてのクライアントに互換性があることを確認し、完全に検証できないテーブルはスキップします。また、テーブルごとにいつでも任意の機能を無効にすることができます。

テーブルが変更された場合、それが自動アップグレードによるものかどうかをどのように判断できますか？

自動アップグレードによるすべての変更は、テーブルの DESCRIBE HISTORY 出力とカタログエクスプローラーの履歴タブに表示され、ユーザー自身による変更とは明確に区別してマークされます。アカウント全体での可視性を確保するために、system.storage.table_auto_upgrade_operations_history をクエリすることでも、いつどのテーブルに機能が追加されたかを確認できます。

自動アップグレードによって、外部ツールやOSSツールが読み取るテーブルが破損することはありますか？

いいえ。外部クライアントやOSSクライアントからアクセスされるテーブルは、現時点では対象外です。自動アップグレードは、テーブルにアクセスするすべてのクライアントがその機能をサポートしていることを検証できた場合にのみ実行されます。将来的には、自動アップグレードがそれらのクライアントの互換性を確認できるようになり次第、外部アクセスやOSSアクセスを持つテーブルも対象に含めるよう拡張する予定です。

自動アップグレードに費用はかかりますか？DBUやストレージの請求額は上がりますか？

現在のゲート付きパブリックプレビューでは、Databricksは自動アップグレード自体（バックグラウンドでの ALTER TABLE 処理）に対して課金しておらず、今後も無料で提供し続けたいと考えています。最新の情報については、自動アップグレードのドキュメントをご確認ください。

テーブルがアップグレードされるまでどのくらいかかりますか？変更はいつ反映されますか？

自動アップグレードは、実行前に頻度の低いワークロード（月次のバッチジョブ、四半期ごとのレポート、アドホック分析など）を把握するために、100日間の観察期間を設けています。テーブルの互換性が検証されると、その後すぐにバックグラウンドジョブを通じて機能が適用されます。また、機能が初めてリリースされる際は、お客様やテーブルの割合に応じて段階的に展開されるため、互換性のあるワークロードを持つテーブルに適用されるまでに最大3〜5か月かかる場合があることにご注意ください。

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