オープンテーブルフォーマットとオープンカタログの収束：カタログコミットが一般提供開始

カタログコミットは、DeltaをIcebergのカタログ中心モデルに合わせることで、レイクハウスの統合に向けた大きな一歩を踏み出します。カタログコミットにより、カタログはDeltaテーブルの調整システムとなり、エンジン間のテーブル検出、アクセス、および状態を仲介します。

本日、UCマネージドテーブルのカタログコミットの一般提供開始を発表できることを嬉しく思います。これは、UCマネージドテーブルの相互運用性を拡張し、UCのガバナンス機能を強化し、複数ステートメント、複数テーブルトランザクションなどの新機能をアンロックする、主要なプラットフォームアップグレードです。

このブログでは、以下の点について説明します…

• DeltaとUnity Catalogの共同進化の方法
• カタログコミットが解決する問題
• カタログコミットの仕組み
• Unity Catalogマネージドテーブルでカタログコミットを有効にする方法

Delta LakeとUnity Catalogの進化

Delta Lakeが作成されたとき、レイクハウスはまずオープンなクラウドストレージで信頼性の高いトランザクションを必要としました。当時、カタログは最新のデータワークロードを調整するように設計されていなかったため、Deltaは革新的なアーキテクチャ上の選択を行いました。それは、ACID保証をデータレイクファイルシステムに直接もたらすことでした。この基盤がレイクハウスを可能にしました。

レイクハウスがより多くのチーム、エンジン、AIワークロードの記録システムになるにつれて、これらの異なるアセット全体で統合されたガバナンスの必要性が重要になりました。Unity Catalogは、その欠けていたガバナンスレイヤーを提供しました。クラウド、フォーマット、エンジン全体でデータとAIアセットを検出、保護、監査、およびアクセスを調整するための単一の場所です。

together, Delta Lake and Unity Catalog formed the foundation of the modern lakehouse. However, they operated side by side - Delta managing transactional state at the storage layer, and Unity Catalog governing access at the catalog layer. This architecture was sufficient early on, but as organizations scaled across more engines and workloads, this design led to new coordination challenges.

今日のテーブルとカタログ間の調整における課題

Deltaの元のファイルシステム中心のアーキテクチャは、データレイクにトランザクションをもたらす上で強力でしたが、カタログが一貫して多数のエンジン間でテーブルID、アクセス、および状態を調整する必要がある世界のために設計されたものではありませんでした。組織がデータにますます高い要求を課すにつれて、カタログ調整の欠如は3つの永続的な課題を露呈しました。

1. 「スプリットブレイン」問題：外部エンジンがオブジェクトストレージ内のDeltaテーブルに直接書き込むと、スキーマなどのカタログメタデータが実際のテーブル状態とサイレントに乖離します。
2. マルチエンジン、マルチエージェントアクセスのスプロール：各エンジン、ツール、エージェントはテーブルに異なる方法でアクセスでき、テーブル検出の断片化、監査の一貫性の欠如、およびシステム全体での行または列レベルの制御の標準化された強制の欠如につながります。
3. 複数テーブルトランザクションの調整：オープンレイクハウスアーキテクチャは歴史的に複数のテーブルにまたがるアトミック書き込みをサポートしていなかったため、組織はトランザクションワークロード専用にレガシーデータウェアハウスを維持する必要がありました。

課題1：「スプリットブレイン」問題 – ガバナンスカタログとテーブルの同期を保つ

現在、カタログはDeltaエンジンの読み取りまたは書き込みパス上にありません。そのため、Apache Flinkのようなエンジンがストレージレイヤーに直接書き込むことによってテーブルにスキーマ変更を加えたい場合、カタログはその変更を認識せず、「スプリットブレイン」状態が発生し、カタログメタデータと実際のテーブル状態が乖離します。これは、サイレントなメタデータドリフトや下流パイプラインの障害を引き起こす可能性があります。

課題2：マルチエンジン、マルチエージェントアクセスのスプロール

現代の組織は、データを分析し、パイプラインを構築し、AIを強化するために、多くのエンジンとツールを使用しています。歴史的に、これらのシステムは静的パスを使用してオブジェクトストレージから直接データにアクセスしてきました。これにより、ワークロードが物理ストレージに強く結合され、テーブルの検出が困難になります。さらに、各エンジンはストレージレイヤーから直接Deltaテーブルを読み取るため、通常は粗い権限しかサポートしないため、すべてのエンジンで一貫した行/列レベルのガバナンスを強制することは非常に困難です。同様に、各エンジンからのアクティビティをキャプチャするための整合性の取れたアクセスレイヤーがないため、データアクセスの監査は断片的であり、管理者はデータが実際にどのように使用されているかについて一貫性のないビューを持つ可能性があります。

組織は、データを検出、ガバナンス、および監査するための中心的な場所を必要としています。AIエージェントがエンタープライズデータの主要なコンシューマーとして出現するにつれて、この必要性はさらに緊急になっています。

課題3：複数テーブルにわたるトランザクションの調整

データウェアハウスのワークロードでは、アトミックに売上と在庫テーブルを更新して、下流のリーダーが常に一貫したビューを表示できるようにするなど、複数テーブルトランザクションが必要になることがよくあります。しかし、Delta Lakeの歴史的なファイルシステム中心の設計では、トランザクションは個々のテーブルに限定されていました。その結果、多くの組織がレイクハウスアーキテクチャに統合したいと考えていても、これらのワークロード専用にレガシーデータウェアハウスを維持する必要がありました。

カタログコミットはオープンレイクハウスの次の進化です

カタログコミットは、Deltaテーブルがカタログと統合するためのオープンスタンダードであり、カタログにテーブルアクセスを調整し、最新のテーブル状態を追跡する責任を負わせます。DeltaとIcebergの両方がカタログ中心になったため、顧客はテーブルがテーブル検出とガバナンスの標準化されたモデルを持っていることに依存できます。カタログコミット仕様の詳細については、Deltaプロトコルをお読みになり、カタログコミットのUnity Catalogの参照実装をご覧ください。

Databricksでは、UCマネージドDeltaテーブルでカタログコミットを有効にできます。有効にすると、Unity Catalogはすべてのテーブルアクセスを仲介し、どのエンジンに対しても一貫した検出と承認モデルを作成します。これにより、組織はエステート全体でガバナンスを真に集中させることができます。

カタログコミットは、長年のスプリットブレイン、マルチエンジンプロール、およびマルチテーブル調整の課題を解決します。

1. スプリットブレイン問題の解消：すべてのエンジンが同じAPIを介してテーブルにアクセスするため、テーブルの状態とカタログは同期したままになり、サイレントなメタデータドリフトのリスクがなくなります。

Unity CatalogマネージドDeltaテーブルに書き込む外部エンジンのアンロック

「歴史的に、ガバナンスされたレイクハウスにストリーミングデータを取り込むことは、カタログメタデータを帯域外で調整し、何もドリフトしないことを願うことを意味していました。カタログコミットは、そのギャップを完全に解消します。StreamNativeのネイティブKafkaサービス（Kafkaのディスクレス、リーダーレスアーキテクチャ用のUrsa搭載）により、データはUnity Catalogを介して直接ストリーミングおよびコミットされるため、すべてのレコードはガバナンスされた行として着地し、どのエンジンからでも即座にクエリ可能になります。」— Sijie Guo, Co-Founder & CEO, StreamNative

2. マルチエンジンアクセスのスプロールの解決：すべてのエンジンとエージェントが標準化されたカタログAPIを介してテーブルを解決するため、組織はストレージパスをハードコードしたり、粗いファイルシステムレベルの権限を管理したりする必要がなくなります。

すべてのエンジンに対する一貫した強化されたガバナンスのアンロック

3. レイクハウスでの従来のデータウェアハウスワークロードの有効化：DatabricksエンジンとUnity Catalogは、複数のテーブルにまたがるアトミック書き込みを調整できます。これにより、レイクハウスに複数テーブルACIDセマンティクスがもたらされ、従来のデータウェアハウスワークロードがアンロックされます。

Databricksでの複数テーブルトランザクションの実行のアンロック

“トランザクションと、SQLスクリプティングやストアドプロシージャなどの新しいSQL機能が組み合わさることで、最も重要なデータウェアハウジングワークロードをDatabricksに自信を持って移行できるようになります。これらのワークロードは、ビジネス全体に不可欠な分析の基盤となっており、レイクハウス上で堅牢なトランザクション保証が得られることは、ゲームチェンジャーです。” — Gal Doron, Head of Data, AnyClip

さらに、UC管理テーブルでカタログコミットを有効にすると、以下もアンロックされます。

• 包括的な監査可能性：Unity Catalogはテーブルメタデータとアクセスポリシーを一元化し、チームが低レベルのストレージログだけに依存するのではなく、一貫したカタログインターフェイスを通じて権限とテーブルの所有権を検査できるようにします。
• 自動化されたテーブル最適化：Unity Catalogは、すべてのテーブルアクセスへの可視性を活用して、Liquid ClusteringとPredictive Optimizationを通じて、特定のクエリパターンに合わせて組織のデータを最適にレイアウトします。
• パフォーマンス向上のための基盤：Unity Catalogは、エンジンがクラウドストレージからメタデータを取得する必要なく、テーブルレベルのメタデータをエンジンに直接通知できるため、メタデータ遅延の主要な原因が解消されます。

これらの機能が組み合わさることで、カタログコミットを備えたUC管理テーブルは、最新のレイクハウスにとって最もオープンで、ガバナンスが効き、パフォーマンスの高い基盤となります。

今すぐテーブルでカタログコミットを有効にする

Databricksのカタログコミットは本日一般提供を開始しました！Unity Catalog管理テーブルでカタログコミットを有効にすることで、以下の機能がアンロックされます。

1. 相互運用性の向上：外部エンジンからUC管理Deltaテーブルへの書き込み
2. より強力なガバナンス：すべてのエンジンにわたる一貫した強化されたガバナンスをアンロック
3. 新機能：複数ステートメント、複数テーブルトランザクション

取り込みからゴールドレベルの消費まで、UC管理テーブルを読み書きするDatabricks製品は、現在カタログコミットをサポートしています。これらには、Streaming Tables、Delta Sharing、Zerobus、Lakeflow Connect、AI Gateway、MLflow、およびLakeflow Job Triggersが含まれます。同様に、カタログコミットは現在、エコシステム全体でサポートされています。これには、Delta Spark、Delta Flink、Starburst Trino、DuckDB、およびStreamNativeが含まれます。

また、プロトコルレベルの詳細を抽象化する共有ライブラリであるDelta Kernelと統合することで、どのエンジンでも簡単にカタログコミットをサポートできます。Delta Kernelを使用すると、コネクタは簡単なバージョンアップグレードで最新のDelta機能を簡単にサポートできます。

カタログコミットが有効になったUC管理Deltaテーブルの作成は簡単です。Databricks Runtime 16.4+を使用して、以下を実行します。

既存のUC管理Deltaテーブルをカタログコミットを有効にするためにアップグレードするには、Databricks Runtime 18.0+を使用し、以下を実行します。

カタログコミットで始めましょう。そして、オープンレイクハウス構築に関する当社の取り組みについて詳しくは、Data and AI Summitにご参加ください！

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