Unity Catalog管理テーブル、外部エンジンからの作成・読み書きに対応

DatabricksはUnityカタログ管理対象Deltaテーブルの外部アクセスをパブリックプレビューにし、外部エンジンが中央ガバナンスと自動最適化を維持したまま作成、読み取り、書き込みできるようにしました。

要点

• Apache Spark、Flink、Starburst、DuckDB、StreamNativeがカタログへのコミット経由で管理対象Deltaテーブルを扱います。
• メタデータ、認証情報の払い出し、確定調整の公開APIをUC OSSにも実装します。
• 既存外部テーブルはデータ再書き込みなしの変更テーブルSET管理対象で更新できます。

今回のブログ記事で語られていること

従来、複数エンジンから同じデータへアクセスするチームは外部テーブルを選ぶことが多く、管理対象テーブルのPredictive Optimizationやガバナンス保証とのトレードオフがありました。外部アクセスのパブリックプレビューでは、外部エンジンがUC管理対象Deltaテーブルを作成、バッチ/ストリームで書き込み、読み取りできます。Unityカタログが権限とテーブル状態の唯一の情報源になり、clientがクラウド保管へ直接確定するのではなくカタログへのコミットが書き込みを調整します。

認証情報の払い出しはUnityカタログ権限に基づく有効期間と権限範囲を限定した認証情報を発行し、UnityカタログDelta APIは作成・読み取り・書き込みの版管理された契約を提供します。これらはオープンソースUnityカタログプロジェクトにも実装されるため、Databricks UCだけでなくセルフホスト型 UC OSSへもエンジンを接続できます。Delta KernelはDeltaプロトコルを各エンジンが再実装せず、読み取り、書き込み、確定するライブラリです。DuckDBはこのKernelを使い、v1.5.1からUC管理対象Deltaテーブルを直接読み取り/書き込みします。

管理対象テーブル側ではPredictive Optimizationがストレージのクリーンアップ、クエリ統計、Liquid Clusteringの列選択を行い、公式記事は最大50%のストレージコスト削減と20倍のクエリ高速化を挙げています。複数エンジンから使う場合もUnity Catalogがアクセスポリシーを一元管理し、エンジン横断のABACで行フィルタリングと列マスキングを適用します。既存の外部テーブルはデータを書き直さずALTER TABLE <table> SET MANAGEDで移行できますが、パブリックプレビューであるため、対応エンジンとバージョン、書き込み競合、ストリーミングの挙動、失敗時の復旧、権限の対応付けを検証する必要があります。

今回のブログ記事が関係する人

オープンなレイクハウスを運用する基盤チーム、Spark・Flink・DuckDB・Starburstを併用するデータエンジニア、Unityカタログのセキュリティ管理者に関係します。

結局、今回のブログ記事をどう読むべきか

一つの管理対象のコピーへ複数エンジンを書き込ませつつ、カタログを確定とポリシーの中心にする更新です。外部エンジンの自由度だけでなく、認証情報の有効期間時間、ABACの一貫性、transaction隔離、ロールバック、オブザーバビリティをプレビューで重点確認する必要があります。