StrategyがMCPアクセスを既定提供

このウォークスルーは、同じCustomer 360パターンを異なるセマンティックレイヤーで扱ったシリーズの過去2回の記事を踏まえている。1回目はStardogのオントロジーベースのレイヤー、2回目はDenodoのデータ仮想化プラットフォームだった。今回は3回目としてStrategy Mosaicに置き換える。Mosaicのディメンショナルモデルは、Strategyのメトリック式構文を通じて属性・階層・ファクト・メトリックを構成する。共通のC360スキーマはStardogのC360 Knowledge Kitを改変したものなので、シリーズを追う読者は同じエンティティとキーが別のセマンティックレイヤーで回答されるのを見ることになる。

Mosaicはクエリ時にエンジン間で行をフェデレーションしない。ソースごとに1つのクエリを計画してネイティブSQLをプッシュダウンし、モデル連携で宣言した共通属性に基づいて中間結果セットをMosaicエンジン内で結合する。代表的な自動登録の問い合わせでは、Amazon Auroraがトランザクショナルなプロファイル結合を実行し、Amazon Redshiftがファクト集計を実行し、Mosaicが共通の顧客IDで結果を統合する。ドメインの所有権がモデル境界に従うと述べており、CRMチームがCustomerを、データシステムチームがPurchaseを所有し、どちらも自らのソースを引き渡さない。

注目すべき詳細は、Mosaicが1つの定義から4つのネイティブプロトコルを提供することだ。AIエージェント向けのMCP、SQLクライアント向けのTrino経由のJDBC/ODBC、Power BIとExcel向けのXMLA、カスタムアプリケーション向けのRESTである。ライブプッシュダウンとインメモリ実行の選択肢も説明し、エージェントのトラフィックは反復的でバースト的であるため、メモリからの提供によってクエリごとに変動するウェアハウス支出を固定のMosaic容量に変えられると指摘している。