Data Driven Knowledgebase

Unity Catalogが発表されたたのは4年前。ガバナンスが課題だったそうです。

「当時はレイクハウスアーキテクチャの開発に着手した頃で、多くのお客様にとってガバナンスが大きな障害となっており、データから真の価値を引き出す上で課題となっていることに気づきました。

ユーザーは、データウェアハウスでSQLを使っているだけでなく、機械学習や非構造化データの処理なども行いたいと考えていました。そして、ガバナンスはそれらの点で非常に断片化されており、セキュリティ、品質、コスト管理など、あらゆる面を正しく実現するのは非常に困難でした。」

そこで、開発の方針としてMatai氏は二つの方法を打ち立てました。

• 一つは、プラットフォームにいくつかの機能をハックして、テーブルガバナンスを少し改善し、データウェアハウスの機能に匹敵させるという方法。


• もう一つは、データワークフロー全体、つまりデータが通過するすべてのステージとユースケースを網羅する統一されたガバナンスレイヤーを設計するというもの。

開発方針として採用したのは、二つ目のデータワークフロー全体、つまりデータが通過するすべてのステージとユースケースを網羅する統一されたガバナンスレイヤーを設計するもの。

Matai氏は、Unity Catalogで統一されたガバナンスを実現するという目標を設定。ファイルとして取り込まれるデータから、機械学習モデルやダッシュボード、データ共有などにおける使用方法に至るまで、あらゆる業務において、一元的に管理し、判断を下すことが容易になるようにしました。

あらゆるユーザー、何らかの形でデータを扱うすべてのユーザーを、1つのプラットフォームに集約し、データとともに存在するさまざまな種類のアセットも統合。データウェアハウスのような構造化テーブルはもちろんのこと、非構造化データファイルも存在します。これらも同様に管理可能にしました。

Unity Catalogに同じモデルで統合されている例

• 機械学習モデル


• AIツール


• エージェント


• MCPツールなど

ダッシュボードやBIアセットも備えており、Databricksに存在しないデータもフェデレーションデータソースで管理できます。つまり、ほぼあらゆるデータベースやデータウェアハウスをUnityのデータソースとして設定し、アクセス制御やリネージなどを実行できるようになりました。

機能面でも統合されており、基本的なセキュリティとアクセス制御機能に加え、検出、リネージ、コスト管理といった機能も備えています。

冗長データの検索が容易になり、すべてのユーザーの効率性が向上したことでこのような成果も出ています。

「例えば、Cignaグループはペタバイト規模のデータをどのように管理しているかについて説明しています。一部のお客様からは、管理機能だけで年間数百万ドルのストレージコストを節約できるという声が寄せられています。」

また、その実現には、Databricksがオープンであることにこだわっていることが大きく貢献しました。

「すべての企業は様々なデータシステムを持っています。レガシーシステムもあれば、最新のスタートアップ企業から最新のシステムも入手しており、これらすべてがデータライフサイクルに関わっています。ですから、カタログ、つまりガバナンスシステムが、これら全てと連携できるようにオープンでなければ、統一されたシステムにはなれません。実現方法は様々です。 Unity CatalogはオープンAPIをベースに構築されており、以前はHiveメタストアAPIを基盤としていました。昨年はサービスをオープンソース化し、最新のデータカタログの中でも最大の統合エコシステムを構築しました。」

「上の図の左側には、Platform製品と、それと連携するオープンソースプロジェクトの一部が表示されています。Palantir、Salesforceなど、主要なオープンソースプロジェクトが連携しています。右側には、Delta Sharingと呼ばれる、データ共有を組織間で組織化するためのオープンプロトコルも開発しました。これは、他社からデータを受信できるコンピューティングの種類が限られているデータ共有を行う理由がないからです。」

Delta Sharingは、Databricks が提唱する オープン標準の安全なデータ共有プロトコルです。一言でいうと、クラウドストレージ上の Delta Lake／Parquet データをコピーせず、そのままリアルタイムに異なる組織・プラットフォームへ共有できる仕組み。

オープンソースプロジェクトやBIツールとDelta Sharingの連携から着手し、現在では、SAPなどの大手ソフトウェアプロバイダーが、Delta Sharingをベースにデータ配信しています。また、主要なデータベンダーがDelta Sharingをサポートするマーケットプレイスも存在します。

Snowflakeや他のオープンカタログを例に、統一ガバナンスにならない理由をMatai氏は伝えました。

「なぜこれらのサービスが統合ガバナンスを実現できないと言えるのでしょうか？いくつか例を挙げましょう。

例えば、Snowflakeにはオープンカタログがありますが、それとは別に内部カタログも存在します。データセットごとにどちらを使用するかを選択する必要があります。あるいは、それらの間でデータを同期する必要がありますが、その場合、情報が古くなってしまう可能性があります。内部カタログを使用すると、ガバナンス機能は向上しますが、Snowflakeエンジンからしか書き込みできません。つまり、すべてのETLジョブ、つまりデータを作成するジョブは、その1つのエンジンで実行する必要があるため、非常に制限が厳しくなります。

一方、オープンカタログを使用する場合、他のエンジン（ファブリックなど）から書き込みを行う場合、パフォーマンスとガバナンス機能が低下します。これは、実質的に単一のカタログが存在しないもう一つの例です。複数のエンジンがあり、それらの間には統合がありますが、管理方法は全く異なります。つまり、統一されたガバナンスではありません。

他のクラウドベンダーも複数のカタログを提供しています。また、これらのカタログの多くは、実際には表形式データのみを対象としています。非構造化データ、AI、BI、その他データを扱うあらゆる機能はカバーしていません。」

「統一ガバナンスにならない」主な理由

1. カタログが複数存在
   
   
   
   
   • 内部カタログとオープンカタログでポリシー体系が二重化し、単一の権限制御ポイントがない。
   
   
   
   


2. エンジン依存による分断
   
   
   
   
   • 内部カタログは Snowflake エンジン専用、オープンカタログは外部エンジン中心という住み分けが必要になり、ガバナンス適用範囲がエンジンごとに分かれる。
   
   
   
   


3. 同期遅延・整合性崩壊のリスク
   
   
   
   
   • 2 つのカタログ間でデータやメタデータを同期する運用が発生し、最新ポリシーの反映遅れや整合性欠落が起こり得る。
   
   
   
   


4. 管理 UI／API の異質性
   
   
   
   
   • カタログごとに異なる設定画面・API を使うため、統一ポリシーの一括運用や監査が難しい。
   
   
   
   


5. データタイプのカバレッジ不足
   
   
   
   
   • 既存カタログは主に表形式データを対象としており、非構造化データや AI/BI アセットには統一ポリシーを適用できない。
   
   
   
   


6. ガバナンス vs パフォーマンスのトレードオフ
   
   
   
   
   • 外部エンジンから書き込む場合はガバナンスを緩めざるを得ず、内部カタログに寄せると性能・柔軟性が犠牲になる──ポリシー徹底と実運用性能の両立が難しい。
   
   
   
   

Snowflake でも、ベンダ中立のオープンカタログでも、「エンジン・ポリシー・データ型が一つの平面に揃わない」かぎり、真の意味での統一ガバナンス（単一点管理・リアルタイム監査・全データタイプ横断制御）は実現しにくいといいます。

「お客様とお話をさせていただいた際、非常に明確なご意見をいただきました。データとAIを横断した統合ガバナンス、オープンで複数のエンジンをサポートするガバナンスを求めているということです。そうでなければ、企業内の統合ガバナンスは実現できません。あらゆるフォーマットに対応し、ビジネスを理解し、単にデータセットを用意する以上のものを理解するガバナンスです。社内で実際に何が起こっているのかを分析する質の高いリネージ分析などが可能になります。これこそが、Unity Catalogで実現したい私たちの目標です。」