Icebergに必要なのは、閉鎖的な環境ではなく、オープンなカタログだ

Icebergが人気なのは、エンタープライズソフトウェアが何十年にもわたって顧客から奪い取ってきたもの、つまり「交渉力」を顧客に提供できるからです。

データが特定のベンダーのウェアハウス、カタログ、ファイル形式、権限モデル、最適化パスに閉じ込められている場合、今後のアーキテクチャに関するあらゆる決定は、そのベンダーのロードマップから始まることになります。Icebergは、この出発点を変革します。Icebergは、オブジェクトストレージに耐久性のあるテーブルレイヤーを提供し、メタデータ、スキーマの進化、スナップショット、相互運用性といった、特定のコンピューティングエンジンに依存すべきではない機能を顧客に提供します。

顧客は、新しいワークロードが発生したり、より優れたエンジンが利用可能になったりするたびに基盤を再構築することなく、データがオープンでアクセス可能かつ利用可能な状態を維持することを望んでいます。オープンテーブルフォーマットの意義はまさにそこにあります。Icebergはデータスタックにおけるすべての問題を解決するわけではありませんが、重要な問題の一つを解決します。それは、クラウドオブジェクトストレージの上にベンダーニュートラルなテーブルレイヤーを顧客に提供するという点です。この約束がプラットフォームの他の部分との連携において維持されるかどうかは、実装の詳細によって決まります。

レイクハウスのためのERPの教訓

企業ソフトウェアの統合を経験した人なら、この状況はよくわかるはずです。ERPスイートは標準化によるシンプルさを約束しました。財務、調達、人事、サプライチェーン、分析、そして最初の5つのシステムで会社の半分を担うようになったため必要になった統合レイヤー、という流れでした。売り文句は一貫性でした。しかし、結果は往々にして依存関係を生み出すものでした。

ベンダーがプロセスモデル、データモデル、権限、ワークフロー、統合、レポート作成画面を所有するようになると、「選択」は技術的には顧客が持つものの、時間と費用のかかる移行プロジェクトを行わない限り、実際には行使できないものとなりました。ベンダーを離れるコストは、アーキテクチャの一部となってしまったのです。

レイクハウスは、より現代的な名詞を使ってそのパターンを繰り返すことができます。ロックインは、従来のウェアハウスモデルよりも巧妙である可能性があり、そのため、最初は見落としやすく、後から解消するのが難しくなります。もはやストレージ形式や実行エンジンに存在する必要はありません。カタログや制御プレーンに存在することができます。顧客はオブジェクトストレージ内のファイルを所有しているかもしれませんが、組織全体でそれらのファイルを使用可能、管理、高性能、安全にするためには、依然として1つのベンダーに運用面で依存している可能性があります。

Icebergカタログが契約となる

実際には、カタログとは、オープンな表形式がエンタープライズシステムへと発展する場所です。

Icebergはテーブルを定義できますが、カタログはテーブルに関する作業契約を定義します。つまり、誰がテーブルを閲覧できるか、どのバージョンが信頼できるか、スキーマがどのように変更されるか、ポリシーがどのように適用されるか、エンジンがどのように連携するか、そして複数のチームが同時に同じデータを読み書き、最適化、管理しようとした場合に何が起こるか、といったことです。

アーキテクチャが真価を発揮するのはまさにこの点です。別のエンジンが技術的にファイルを読み取れるという主張ではなく、そのエンジンが企業が実際に依存している要素、つまり一貫性のあるアクセス権限、最新のメタデータ、安全な書き込み、予測可能なパフォーマンス、運用サポートを損なうことなく、参加できるかどうかが重要なのです。

他のエンジンを対等な参加者として受け入れるカタログは、Icebergを強化します。一方、他のすべてのエンジンを他人の家に招かれた客のように感じさせるカタログは、Icebergを弱体化させます。

リアルタイムAIがリスクを高める

データアプリケーションの運用化が進むにつれて、この点はますます重要になってきます。従来の分析では、作業が往々にして事後的なものであったため、遅延、重複、プラットフォーム固有のワークフローを許容することができました。ソースシステムよりも遅れて更新されるダッシュボードは煩わしいものの、通常は許容範囲内でした。しかし、AIアプリケーションやリアルタイム運用システムは動作が異なります。ビジネスが変化する中で、最新のデータ、低遅延アクセス、トランザクション更新、検索、ベクトル、分析コンテキストが必要となります。

こうしたワークロードにとって、オープンストレージは必要不可欠ではあるものの、それだけでは十分ではありません。顧客はワークロードを処理できる実行エンジンを必要とし、独自の制御レイヤーの背後にデータを閉じ込めないオープンモデルを必要としています。だからこそ、カタログの問題はガバナンス上の些細な問題ではないのです。それは、どのようなアプリケーションを構築できるか、新しいエンジンをどれだけ迅速に導入できるか、そしてAIシステムがすべての導入を新たな統合プロジェクトに変えることなく適切なデータにアクセスできるかどうかといった、重要な問題に影響を与えるのです。

次のレイクハウスの戦いは支配権を巡る

オープンデータでは、顧客がアプリケーションに必要なアーキテクチャを自由に利用できるようにすべきです。リアルタイムAIや運用アプリケーションの場合、それは、あらゆるアクセスパスを特定のベンダーのカタログに強制することなく、最新のデータ、低遅延、高並行性、検索機能、ベクトル、トランザクション更新を可能にすることを意味します。データアーキテクチャは、特定の独自カタログが事実上の記録システムとなっているからといって、あらゆるアクセスパスをそのカタログに強制するべきではありません。

Icebergはロックインをカタログという上位のプラットフォームに移すためのものではなく、ロックインを緩和するためのものだったはずです。

レイクハウス市場の次の段階は、Icebergを支持する企業だけで決まるわけではありません。支持はもはや当然の条件です。より重要なのは、Icebergが普及した後、顧客の自由を誰が守るかという点です。