AWSがAtScaleで意味レイヤー構築

これは、同じCustomer 360の要求を保ちながらその下のセマンティックレイヤーを入れ替えてきた連載の3回目だ。最初がStardogのナレッジグラフ、次がDenodoのデータ仮想化、今回はAtScaleのディメンショナルモデルである。違いはアーキテクチャにある。StardogとDenodoはクエリ時にエンジンをまたいでフェデレーションするのに対し、AtScaleはディメンショナルクエリをネイティブなウェアハウスSQLとして計画し、クエリごとに1つのエンジンへ push する。この手順では、分析用C360データはすべてAmazon Redshift Serverless上にあり、Amazon Aurora PostgreSQLが運用上のシステム・オブ・レコードとして維持され、レプリケーション経路が分析用コピーを最新に保つ。

トレードオフは記事中で明示されている。1つのエンジンに統合すると、先の2つのレイヤーが行うライブのクロスエンジンフェデレーションはできなくなるが、AtScaleのプランナーと自律的な集約管理を単一エンジンの実行モデルに対して働かせられる。これはエージェント駆動のワークロードにとって重要で、人間のアナリストより多くのクエリを発行する。一致するクエリはファクトテーブルを再スキャンせず、ウェアハウス内の事前構築済みサマリーテーブルにルーティングされる。

ガバナンスは消費者間で同一だと位置づけられている。呼び出し元がMCP経由のエージェント、XMLA経由のExcel、JDBC経由のノートブックのいずれであっても、1つの行セキュリティオブジェクト、1つのパースペクティブ、1つのロールバインディング群が適用される。連載の過去2回は、LLMが書いたクエリとウェアハウスが実行したクエリの両方を1つの記録に残していなかったが、今回はそれを監査上の利点として提示している。