オープンな相互運用性：お客様の選択肢を広げる
本ブログの読者には直感的に明らかかもしれませんが、まずはオープンな相互運用性の定義から始めます。オープンな相互運用性とは、オープンに公開された標準ベースのインターフェイスを通じてガバナンスの効いたデータにセキュアにアクセスできるよう、組織のデータプラットフォームを設計する機能です。これにより、独自のロックインを軽減し、より幅広いエコシステムの互換性を実現します。
オープンな相互運用性は、組織とデータとの関係を変革します。これにより、組織はデータに対する主体性を持ち、面倒な移行やデータ移動を伴うことなく、各ワークロードに最適なエンジンやツールを自由に選択できるようになります。この定義は、SnowflakeがApache Iceberg™およびApache Polaris™において最高クラスのエクスペリエンスを提供するうえでの中核となっています。その結果、お客様はSnowflakeやその他の環境でIcebergテーブルをプラットフォーム化し、Snowflakeのカタログへの移行を強制されることなく、これらのテーブルに対して制限なく読み取りと書き込みを実行できるようになります。
Databricks Unity Catalogも相互運用性を主張していますが、詳しく検証すると、オープンな相互運用性の最も基本的な要件を満たしていないことがわかります。それは、任意のIcebergテーブルに対して読み取りまたは書き込みを実行できること、そして特定のツールへのロックインを回避するオープンなセキュリティメカニズムを使用してそれを実行できること、という要件です。
任意のIcebergテーブルに対する読み取りと書き込み
テーブルのカタログ選択は、アーキテクチャにおいて最も重要な決定事項です。これにより、対象のテーブルや他のテーブルで実行できる操作が決まり、選択肢が広がるか、あるいは制限されることになります。ここで、真の相互運用性が重要になります。真の相互運用性には、コミュニティ主導のオープンな標準を通じた、インバウンドとアウトバウンド両方のフェデレーションが必要です。インバウンドフェデレーションとは、カタログ外部のエンジンがIcebergテーブルに読み取りおよび書き込みを行えることを意味します。一方、アウトバウンドフェデレーションとは、別のカタログでマネージド状態にあるIcebergテーブルに対して読み取りまたは書き込みを行えることを意味します。
相互運用性の要件を満たさないUnity Catalog
本記事の執筆時点において、Unity Catalogはインバウンドという一方向でのみ包括的な相互運用性をサポートしています。インバウンドアクセスの場合、外部エンジンはUnity CatalogのIceberg REST Catalogエンドポイントに接続してテーブルにアクセスできます。アウトバウンドアクセスの場合は、状況が根本的に異なります。Snowflake Horizonなどの外部カタログからIcebergテーブルにアクセスする場合、DatabricksはIceberg REST Catalog APIを使用しません。代わりに、JDBCを使用してmetadata.jsonパスを取得するSnowflake Catalog SDKを使用し、事前設定されたIAM認証情報を使用して基盤となるストレージに直接アクセスします（ドキュメント）。さらに、これは読み取り操作でのみ機能します。外部カタログでマネージド状態にあるIcebergテーブルは明示的に読み取り専用のままであり、外部のIcebergテーブルへの書き込みはサポートされていません（ドキュメント）。
これがデータに対する主体性の確保に与える影響は、否定できません。DatabricksとUnity Catalogでワークロードをプラットフォーム化する場合、事実上、データエステート全体をUnity Catalogに移行することが求められます。これは相互運用性の基本的な要件を損なうものであり、Unity Catalogが市場で最も「相互運用性の高いカタログ」であるという彼ら自身の主張とも矛盾します。
SnowflakeのHorizonカタログは、これとは根本的に異なります。Apache Polarisを基盤として構築されたSnowflake Horizonカタログは、Iceberg REST Catalogプロトコルのエンドツーエンドの実装を提供します。HorizonはSnowflakeのネイティブなガバナンスレイヤーであり、Snowflakeが管理またはアクセスするIcebergテーブル全体にわたって、読み取りや書き込みの操作を制限することなく、分類、アクセスポリシー、リネージ、品質、およびカタログ管理が一貫して適用されます。さらに、Snowflakeのデータを扱うデータチームは、プラットフォームやテーブルのタイプに縛られた部分的なビューではなく、エステート全体にわたって機密データがどこに存在するかを示す包括的な全体像を把握できます。これが機能するのは、HorizonカタログがCatalog Linked Databasesと呼ばれる機能を介してUnity Catalogなどの外部カタログに接続し、そのカタログのIceberg REST Catalogエンドポイントを直接呼び出して、特定のクエリに対するアクセス権をカタログから取得するためです。新しいIAMロールや長期的な認証情報の交渉、あるいは新しいセキュリティメカニズムの管理のために、プラットフォームチームにチケットを提出する必要はありません。
オープンなセキュリティが相互運用性にとって重要である理由
Iceberg REST Catalogは、カタログ同士がセキュアに通信する方法を定義しています。この機能はVended Credentialsと呼ばれます。Vended Credentialsは、特定の操作のためにソースカタログによって委任される短期的なトークンです。これにより、カタログがテーブルとセキュリティ態勢の信頼できる唯一の情報源となるメカニズムが提供されます。しかし、これはIceberg REST Catalogの仕様で定義されているものの、カタログにその実装を義務付ける要件はありません。Vended Credentialsの代替となるのは、IAMロールやアクセスキーのような長期的な認証情報を介した広範なアクセスです。これらのアプローチは、セキュリティ態勢に複雑さと潜在的なリスクをもたらします。第一に、これらは特定のクエリや、実際には特定のテーブルにスコープが限定されていません。第二に、ソースカタログとIAMレイヤーの両方でポリシーを重複させる必要があり、Iceberg REST仕様で推奨されているセキュアでオープンな相互運用性の基盤が損なわれます。
Snowflake Horizonカタログは、インバウンドとアウトバウンド両方のフェデレーションに対してVended Credentialsを包括的に実装しており、Snowflakeでマネージド状態にあるIcebergテーブルにアクセスするあらゆるエンジン向けに、Icebergテーブルとアクセスポリシーを管理するための単一の管理画面を提供します。実際には、Horizonカタログでアクセスポリシーを定義すれば、追加の作業なしで、任意のエンジンでそのポリシーを適用できることを意味します。これまではオブジェクトレベル（カタログ、名前空間、テーブル）で機能していましたが、新たに導入されたScan Plan API（プライベートプレビュー中）により、互換性のあるエンジンに対するきめ細かい行および列レベルのアクセス制御へとガバナンスが拡張されます。執筆時点では、Unity Catalogは外部カタログによって発行された認証情報を使用しないため、ソースカタログのアクセスポリシーを尊重しません。
詳細な比較：最も相互運用性の高いカタログの選択は?あなたの選択
| 機能 | Snowflake Horizon | Databricks UC | この違いがもたらす影響 |
|---|---|---|---|
| Iceberg REST Catalogの認証情報発行の実装 | 🟢 双方向：クエリごとのVended Credentials：インバウンドおよびアウトバウンドフェデレーション | 🟡 インバウンドのみ。アウトバウンド接続ではIRCを使用しません。1 | Unity Catalogは、長期的なIAM認証情報を要求することで不要なセキュリティリスクをもたらし、Unity Catalogのマネージドではないテーブルに対してJDBC接続経由でクエリをルーティングすることで、クエリあたりのコストを増加させる可能性があります。 |
| 外部カタログテーブルへの読み取りと書き込み | 🟢 Iceberg REST Catalog経由での外部カタログテーブルに対する包括的なDML | 🟡 Lakehouse Federationは読み取り専用です。外部カタログテーブルに対するINSERT、UPDATE、DELETE、MERGEは実行できません。2 | Unity Catalogでは、すべてのテーブルを移行するか、操作を読み取り専用に制限する必要があるため、価値実現までの時間が遅れ、AIワークフローの有効性が低下する可能性があります。 |
| SnowflakeおよびSnowflake以外の（外部）エンジンをまたいでクエリを実行する際のABACの適用 | 🟢 行および列のマスキングと行アクセスポリシー：Spark向けに一般提供開始。Scan Plan APIを通じてIceberg REST互換の任意のエンジンに拡張予定（まもなくパブリックプレビュー開始。詳細についてはアカウントチームにお問い合わせください） | 🟡 外部Icebergエンジン向けにはベータ版です。本番環境には対応していません。3 | セキュリティポリシーはSnowflakeでは一般提供されていますが、Databricksではプレビュー段階です。 |
| レプリケーションとディザスタリカバリ | 🟢 Snowflakeのマネージドテーブルを包括的にサポート。 | 🟡 行フィルターや列マスクを持つテーブルはレプリケーションから除外され、RPOの達成を妨げます。マネージドDRは制限付きのプレビュー版であり、有料のアドオンです。4 | Unity Catalogでは、レプリケーションおよびディザスタリカバリの対象とするために、テーブルからアクセスポリシーを削除する必要に迫られます。 |
Unity CatalogなしでのDatabricksの使用
上記の制限はUnity Catalogに適用されますが、Databricksのコンピュートは、Snowflake HorizonなどのIceberg REST（IRC）APIをサポートする外部カタログを使用して、包括的な読み取り/書き込み機能を引き続き実現できます。お客様は、Unity Catalogを有効にせずにDatabricks Sparkクラスターを構成することで、これを実現できます。この構成では、クラスターはIRC準拠の任意のカタログに対する包括的な読み取り/書き込みアクセスを維持し、各クエリはアクセスポリシーを尊重します。ただし、クラスターでUnity Catalogを有効にするとこの機能が制限されるため、これがDatabricksプラットフォーム全体ではなく、Unity Catalog固有の制限であることが確認できます。Sparkセッション変数を使用してIcebergに接続することは、オープンソースのSparkでサポートされています。この方法を利用する場合、Unity Catalogのカタログ統合モデルの外部で動作させていくことにご注意ください。
真のデータ主体性の確立
真のデータ主体性は、選択の自由の上に成り立っています。それは、強制的な移行やサイロ化されたセキュリティモデルの負担なしに、独自のワークロードに対し最適なエンジンとツールを選択できる自由です。相互運用性は単なる技術仕様ではなく、お客様第一のアーキテクチャへのコミットメントです。
カタログを選択する際、この違いはオープンスタンダードの実装に出ます。相互運用性をインバウンド接続のみに制限するカタログでは、希望するコンピュートエンジンか望んでいるガバナンスモデルかのどちらかの選択を迫られます。逆に、Snowflake Horizonに組み込まれているような、Iceberg REST Catalogプロトコルのエンドツーエンドの実装では、選択したエンジンに関係なくセキュリティ態勢を尊重する双方向アクセスが可能になります。
データリーダーにとって、目標は明確です。アーキテクチャ上の決定によって、将来の選択肢を狭めるのではなく、確実に広げることです。オープンなセキュリティと双方向の相互運用性を最優先事項として扱うカタログを優先することをお勧めします。真にオープンなアプローチを採用することで、データが単一のプロバイダーにロックインされた依存関係ではなく、自身で制御できる戦略的資産であり続けることを保証できます。
この記事では、パブリックプレビュー中であり変更される可能性のある機能について言及しています。プレビュー機能は、本番環境での使用には適さない場合があります。現在の機能の提供状況については、Snowflakeのドキュメントをご覧ください。
- Vended Credentialsによるインバウンドおよびアウトバウンドフェデレーション
- 外部マネージドテーブルの書き込みサポート
Apache IcebergおよびApache Polarisは、Apache Software Foundationの商標です
- 「外部Icebergテーブルでの認証情報の提供はサポートされていません」docs.databricks.com/aws/en/external-access/iceberg
- 「外部フェデレーテッドHiveメタストア、およびLakehouse Federationを通じてアクセスされるすべての外部テーブルは読み取り専用です」docs.databricks.com/aws/en/tables/foreign
- 「クロスエンジンの属性ベースのアクセス制御（ABAC）がベータ版となり、Unity CatalogはIceberg REST Catalog Scan APIを使用するIcebergクライアントに属性ベースのアクセス制御を拡張します」databricks.com/blog/unity-catalog-and-next-era-apache-icebergtm
- 「行フィルターや列マスクが設定されたテーブル、およびABACタグが付けられたリソースは、システムテーブルでレプリケーション失敗としてフラグが立てられます。フェイルオーバーグループのスコープから当該リソースを削除するまで、これらの失敗によってRPOが遅延します」docs.databricks.com/aws/en/admin/managed-disaster-recovery（2026年6月19日更新）
