何年もの間、まとまりのあるデータプラットフォームという理想は、同じ厳しい現実に直面してきました。それは、データがあらゆる場所に存在しているということです。データは、Snowflake、AWS Glue、Microsoft OneLake、Databricks Unity Catalog、Apache Polaris™、さらには誰が構築したのか誰も正確には覚えていない自社開発のRESTカタログなど、さまざまな場所に存在しています...すべてのプラットフォームには、独自のルール、独自のメタデータ、独自の引力がありました。そして、新しいシステムが導入されるたびに、共通のプラットフォームとデータの距離は広がっていきました。
解決策は、すべてを1か所に移動することではありません。そのような時代はすでに終わっています。解決策は、メタデータハブという1つのレイヤーを通じてすべてを接続することです。
「1つのプラットフォームを選ぶだけ」というアプローチの問題点
これまでの常識は統合でした。1つのクラウドを選びます。1つのカタログを選びます。データを移行すれば、それで完了でした。しかし、データランドスケープはそのようなビジョンを超えて進化しています。データを移行することは、AIのコンテキストにおいては逆効果です。企業買収によって新しいプラットフォームが導入されます。チームは使い慣れたツールを基盤に構築を行います。規制要件により、地理的な分離が求められます。複数のカタログやマルチクラウドを使用することは「間違い」ではありません。それは、ほとんどの企業が直面している現実です。
つまり、非常に広範な規模でメタデータの断片化が起きているということです。Snowflake内にどのようなデータがあるかは把握しているかもしれません。しかし、Glueカタログに何があるかご存じでしょうか。Unityワークスペースについてはどうでしょうか。OneLakeインスタンスについてはいかがでしょうか。データをコピーすることなく、これらすべてを横断してクエリを実行できるでしょうか。単一のポリシーでそれらをガバナンスできるでしょうか。データエステートに含まれるすべてのものをリアルタイムで確認できるでしょうか。
ほとんどの組織にとって、正直な答えは「いいえ」です。だからこそ、Snowflakeはメタデータハブとしての相互運用性に注力しています。
メタデータハブの真の姿
メタデータハブは、覇権を争う新たなカタログではありません。メタデータハブは、データエステート全体のメタデータを集約およびフェデレーションし、クエリ可能な単一のインターフェイスにまとめます。データの移行を強制するのではなく、データに関する理解を統合します。これにより、どのシステムにデータが保持されているかにかかわらず、すべてのユーザーが構造、セマンティクス、リネージ、品質、所有権を統一されたウィンドウで確認できるようになります。
Snowflake Horizon Catalogは接続レイヤーとして機能します。既存のカタログの上位に位置し、可視性と制御を提供する単一のプレーンとして、それらのカタログをさらに有用なものにします。
メタデータハブは、次の3つの基本的なアイデアに基づいています。
1.設計段階からオープン
Apache Iceberg™エコシステムは、データの世界では珍しい、真のオープンスタンダードを確立しました。IcebergのテーブルフォーマットとIceberg REST Catalog（IRC）仕様により、あらゆるシステムが参加できる共有プロトコルが作成されます。Snowflake、AWS、Databricksをはじめとする業界全体が、このプロトコルを支持しています。Snowflakeは、すべてのHorizon Catalogに組み込まれたApache Polarisインスタンスを通じて、Iceberg REST Catalog（IRC）を公開および利用しています。これはシームレスかつ完全に統合されており、これらの相互運用性機能を活用するために追加の構成は必要ありません。
IcebergとIRC仕様は、業界が基盤として構築できるオープンプロトコルを確立します。AWS、Databricks、その他多くの企業がその標準に賛同しています。さらに、オープンカタログのあり方を前進させるため、現在トップレベルプロジェクトとなっているApache Polaris™に投資しました。すべてのHorizon CatalogにPolarisを組み込むことで、レイクハウスのための真にオープンなカタログ基盤を提供します。
相互運用性は差別化要因ではなく、ベースラインです。Icebergに対応するあらゆるシステムは、カスタムコネクタ、独自のブリッジ、ベンダーによる制限なしに、データを交換し、メタデータを共有し、より広範なデータエステートに参加できます。サイロは発生しない。
2.ネイティブかつ双方向
読み取り専用アクセスは回避策にすぎません。ネイティブな参加でしょうか。それこそがコラボレーティブなアーキテクチャであり、求められているものです。
SnowflakeのIRC統合はさらにその先を行きます。Horizon CatalogがAWS Glue、Databricks Unity Catalog1、Polaris、またはその他のサポート対象プラットフォームなどのサポート対象カタログに接続する場合、ネイティブかつ双方向に接続します。コピーやリフレクションをクエリするのではありません。データをネイティブな形式で、完全な忠実度を保ちながら直接読み書きします。AWS GlueやDatabricks Unityは、Snowflakeが行うすべての変更を認識します。Snowflakeは、他のプラットフォームがネイティブに書き込んでいるデータを即座にクエリできます。カタログエントリはライブであり、同期間隔を設定するオプションがあります（通常は30秒を推奨します）。IRC経由でUnity Catalogを取り込む次の例を考えてみましょう。
CREATE DATABASE my_unity_linked_db
LINKED_CATALOG = (
CATALOG = 'my_unity_catalog_int',
SYNC_INTERVAL_SECONDS = 30-- controls namespace/table discovery polling
)
CATALOG_CASE_SENSITIVITY = CASE_INSENSITIVE;これにより、Unity Catalogソースの読み取りと書き込みの両方が可能になります。真のクロスプラットフォーム参加です。単なるアクセスではありません。
3.完全な可視性
3つ目の柱は、接続性を制御に変えます。Horizon Catalogをメタデータハブとして使用することで、データエステート全体の単一のリアルタイムインベントリを取得できます。すべてのプラットフォーム、データが存在するすべての場所にある、すべてのテーブル、すべてのデータベース、すべてのカタログが含まれます。
完全な可視性は、あれば便利なものではありません。他のすべての前提条件です。これは、単なる基本的なディスカバリ以上の意味を持ちます。接続しているメタデータをセマンティック定義で強化し、ビジネスロジックをメタデータレイヤーに直接組み込むことができます。このレイヤーはガバナンスの基盤となります。見えないデータにポリシーを適用することはできません。観測できない境界を越えてリネージを追跡することはできません。測定できないワークロードのコストを最適化することはできません。
これはすでに起きています。先見の明のある組織は、今日すでにこれを基盤として構築を進めています。本番環境チームは、SnowflakeからAWS Glue、Databricks Unity Catalog、Apache Polarisなど、複数のカタログにまたがるワークロードを同時に実行し、一貫した運用モデルに統合しています。これは実験ではなく、彼らのアーキテクチャです。
さまざまな業界の組織は、シングルプラットフォームに統合するのではなく、複数のプラットフォームにまたがる相互運用性ファーストのアプローチを採用しています。このフェデレーションは、共通のデータ言語としてのIcebergと、統合されたビューを提供するメタデータハブに依存しています。Snowflake Horizon Catalogは、この不可欠なメタデータハブとして機能する独自の地位を確立しています。
これにより実現できること
データをコピーしないクロスプラットフォームクエリAWS Glueテーブル、Databricks Unity Catalogテーブル、およびSnowflakeマネージドテーブルを単一のクエリで結合します。ETLは不要。レプリケーションの遅延もありません。重複するストレージコストも発生しません。
このアーキテクチャは、ベンダーロックインの排除を強化します。
メタデータが統合されると、断片化された状態では不可能だった一連の機能が可能になります。
データエステート全体にわたるガバナンスは絶対に不可欠です。アクセスポリシー、データマスキング、分類ルールを1か所から適用できます。データ品質ルールを定義し、リネージの完全な可視性を確保することで、データエステート全体の品質を監視できます。問題が発生した場合は、データソースがどれほど多様であっても、Horizonによる統合環境のもと、根本原因を追跡し、上流および下流への影響を把握して、Snowflake Cortex AIで直接修復できます。プラットフォームだけでなく、エステート全体をガバナンスします。
エステート全体を理解するAIメタデータハブは、人間のユーザーに役立つだけではありません。AIにも役立ちます。Cortex AIがデータエステート全体の統合されたメタデータにアクセスできるようになると、テーブルの関係、セマンティック定義、リネージ、品質シグナル、アクセスパターンなど、ビジネスの完全なコンテキストに基づいて機能します。これにより、自然言語クエリの精度が向上し、検索結果がより関連性の高いものになります。また、AIエージェントは単一のサイロに閉じこもるのではなく、カタログをまたいで推論できるようになります。メタデータが豊富でつながりが強いほど、Cortexはよりスマートになります。断片化はAIからコンテキストを奪います。メタデータハブは、真の価値を提供するために必要なすべての情報をAIに供給します。
リアルタイムのコスト配分すべてのカタログ統合にわたって、どのワークロードがリソースを消費しているかを正確に把握し、プラットフォーム、チーム、またはワークロードのタイプ別にコストを分類します。完全な可視性により最適化を図ります。
断片化のないエコシステムチームが最も生産性を発揮できるツールを使用できるようにします。どこにあるテーブルであっても、広範なテーブルやアナリティクスにわたる対話型AIにはSnowflakeを、EMRにはAWS Glueを、そして必要に応じてDatabricksを使用します。メタデータハブはこれらをまとめ、チームが選択したプラットフォームに関係なく、すべてのデータを実用的なものにします。
これを可能にするアーキテクチャ
メタデータハブのアーキテクチャは、基本的に3つのレイヤーで構成されています。
カタログレイヤーでは、既存のカタログが独自のメタデータに対して引き続き権威を持ちます。何かを置き換えるわけではありません。データを実用的なものにするために、データを移行または移動する必要はありません。
接続レイヤーでは、IRC統合により、カタログとコンピュートエンジン間のライブな双方向リンクが作成されます。SnowflakeのIRC統合は、このレイヤーのリファレンス実装です。Horizonはそれだけにとどまりません。統合されたメタデータハブに参加する、外部ソースへの多様なコネクタも用意されています。
コントロールレイヤーは、接続されているすべてのカタログ全体で同時に機能する、検出、ガバナンス、リネージ、オブザーバビリティのためのインターフェイスです。
その結果、カタログを置き換える移行コストをかけることなく、単一のカタログよりも優れた機能を持つシステムが実現します。
今後の展望
データ業界は、より優れたサイロの構築に10年を費やしてきました。より高速なレイク。よりスマートなウェアハウス。より高機能なカタログ。それぞれが真の進歩でしたが、同時に断片化を助長するものでもありました。
Snowflake Horizon Catalogをメタデータハブとして使用することは、その断片化を資産に変えるアーキテクチャです。マルチプラットフォームという現実と戦うのではなく、それを受け入れ、その上に一貫性のあるレイヤーを構築することで、各プラットフォームを単独で使用するよりも価値のあるものにします。
今問うべきは、このアーキテクチャが可能かどうかではありません。組織がSnowflake Horizon Catalogをメタデータハブとして導入し、断片化されたメタデータをまとまりのあるデータエステートに変える準備ができているかどうか、そしてそれを実現した後に何ができるようになるかということです。
1 Databricksは現在、双方向アクセスをサポートしていません。詳細については、こちらのブログ記事をご覧ください。
