Für einen KI-Agenten, der Daten aus mehreren verteilten Quellen zur Laufzeit zusammenführen muss, zeigt Denodo den passenden Architekturansatz. AtScale veranschaulicht dagegen Abfragen in einem einzelnen Data Warehouse, in das operative Daten zuvor repliziert werden. AWS veröffentlichte beide technischen Tutorials am 20. Oktober 2026.
Was die beiden Beispiele verbindet
Beide Tutorials setzen einen mit Strands Agents erstellten Agenten auf Amazon Bedrock AgentCore ein. Über das Model Context Protocol (MCP) greift er auf die jeweilige semantische Schicht zu. Als Basismodell nennen die Beispiele Claude Sonnet 4.6.
Der entscheidende Unterschied liegt darin, wo die Abfrage ausgeführt wird. Denodos Virtual DataPort plant Abfragen über mehrere Quellen und führt Ergebnisse zusammen. AtScale übersetzt eine dimensionale Abfrage in SQL für eine einzelne Warehouse-Engine. Im AtScale-Beispiel ist das Amazon Redshift Serverless.
| Vergleichspunkt | Denodo-Beispiel | AtScale-Beispiel |
| Datenquellen und Abfrage | Amazon Aurora, Amazon Redshift und ein PostgreSQL-System vor Ort werden zur Abfragezeit föderiert. Virtual DataPort plant die Abfrage und kombiniert Zwischenergebnisse. | Die analytischen Customer-360-Daten liegen in Amazon Redshift Serverless; jede Abfrage wird von einer Warehouse-Engine verarbeitet. Operative Daten aus Aurora werden vorgelagert repliziert. |
| Semantisches Modell | Basissichten, eine abgeleitete Kundenansicht und eine separate Kennzahlensicht in Virtual DataPort; Abfragen verwenden VQL. | YAML-Objekte in der Semantic Modeling Language (SML), darunter Datensätze, Dimensionen, Fakten, Kennzahlen und Berechnungen; die Modelle werden in Git versioniert. |
| Zugriff im Beispiel | Eine globale Sicherheitsrichtlinie maskiert markierte ssn- und card_num-Felder für marketing_user; hr_user sieht sie unmaskiert. | Rollenbasierte Rechte, Zeilensicherheit und Perspektiven steuern den Zugriff. Die Marketing-Perspektive lässt ssn- und card_num-Felder im Beispielmodell weg. |
| Verbindung zum Agenten | Der Denodo-MCP-Server verbindet den Agenten mit Virtual DataPort. AgentCore Gateway und Identity reichen die Benutzeridentität über einen On-Behalf-Of-Tokenaustausch weiter. | Der AtScale-MCP-Server verbindet den Agenten mit dem Modell. AgentCore Gateway und Identity verwalten den Zugang; die AtScale-Engine löst die Rolle des Aufrufenden auf. |
| Im Tutorial beschriebene Bereitstellung | Denodo Agora als verwalteter Dienst oder eine selbst verwaltete Installation auf Amazon EC2 oder Amazon EKS. | Selbst verwaltete Installation auf Amazon EKS mit Helm-Chart und K8S Blueprints. |
Verteilte Daten oder ein zentrales Warehouse?
Denodos Beispiel bindet Daten aus Amazon Aurora, Amazon Redshift und einer PostgreSQL-Installation vor Ort zur Abfragezeit ein. Virtual DataPort plant die föderierte Abfrage, verlagert Arbeitsschritte zu den Quellen und setzt die Ergebnisse zusammen. Das passt zu einer Architektur, in der Antworten Informationen aus getrennten Systemen kombinieren müssen, ohne sie zuvor in einem gemeinsamen analytischen Warehouse zusammenzuführen.
AtScale zeigt eine andere Datenorganisation: Die analytischen Customer-360-Daten befinden sich in Amazon Redshift Serverless. Operative Daten aus Aurora werden vor der Abfrage dorthin repliziert. Die Abfrage selbst bleibt damit innerhalb einer Warehouse-Engine. Für die Architekturentscheidung ist deshalb wichtig, ob die benötigten Daten bereits zentral vorliegen oder ob ein Replikationsweg eingerichtet und gepflegt werden soll.
Wie die semantischen Modelle Geschäftslogik abbilden
Denodo strukturiert sein Beispiel mit sechs Basissichten, einer abgeleiteten Kundenansicht und einer gesonderten Kennzahlensicht. Die Abfragen verwenden VQL. Diese Aufteilung hält Quellzuordnungen und wiederverwendbare Geschäftskennzahlen als eigene Modellobjekte fest.
AtScale beschreibt ein dimensionales Modell mit SML-Objekten für Datensätze, Dimensionen, Hierarchien, Fakten, Kennzahlen, Berechnungen, Perspektiven und Zeilensicherheit. Die YAML-Modelle werden in Git versioniert. In beiden Beispielen liegen Geschäftsdefinitionen und Zugriffsregeln in der semantischen Schicht, statt allein im Prompt des Sprachmodells.
Identität, Zugriffsregeln und Audit
Die Sicherheitsbeispiele setzen unterschiedliche Schwerpunkte. Denodo maskiert markierte Sozialversicherungs- und Kartennummernfelder für die Rolle marketing_user; die Rolle hr_user sieht diese Felder im Beispiel unmaskiert. AtScale kombiniert rollenbasierte Zugriffskontrolle und Zeilensicherheit mit Perspektiven. Die Marketing-Perspektive blendet die entsprechenden Felder aus dem dargestellten Modell aus.
Der AtScale-Beispiel-Auditdatensatz enthält sowohl die vom Sprachmodell erzeugte dimensionale SQL-Abfrage als auch die für Redshift übersetzte SQL-Abfrage. Denodos beschriebenes Audit hebt die VQL-Anfrage, die zugeordnete Rolle, den föderierten Abfrageplan und die ausgewerteten Richtlinien hervor.
Welche Architektur passt zur vorhandenen Datenlage?
Müssen Agentenantworten Daten aus Cloud-Diensten und lokalen Systemen zur Laufzeit verbinden, entspricht Denodos gezeigte Föderation dieser Datenlage. Liegen die Analysedaten bereits in einem Warehouse oder können operative Daten dorthin repliziert werden, entspricht AtScales Einzel-Warehouse-Muster eher dem Aufbau. Diese Entscheidung folgt aus den jeweiligen Abfragegrenzen der Beispiele; sie ist kein allgemeines Leistungsurteil über die Produkte.
