W przykładzie Denodo agent AI łączy dane z Amazon Aurora, Amazon Redshift i lokalnej instancji PostgreSQL podczas zapytania. Przykład AtScale kieruje każde zapytanie do jednego silnika hurtowni danych, Amazon Redshift Serverless, a dane operacyjne z Aurora replikuje do niej wcześniej. Obie architektury opisano w tutorialach AWS opublikowanych 20 października 2026 roku; wybór zależy przede wszystkim od tego, gdzie znajdują się dane i czy agent musi łączyć źródła na żywo.
Wspólna ścieżka agenta, różne granice zapytań
W obu przykładach agent zbudowany przy użyciu Strands Agents działa w Amazon Bedrock AgentCore i łączy się z warstwą semantyczną przez Model Context Protocol (MCP). Warstwa semantyczna udostępnia agentowi uporządkowane pojęcia biznesowe i reguły dostępu, zamiast pozostawiać ich interpretację wyłącznie promptowi modelu.
Najważniejsza różnica dotyczy miejsca wykonania zapytania. W przykładzie Denodo Virtual DataPort pobiera i łączy wyniki z trzech rozproszonych źródeł. W przykładzie AtScale zapytanie trafia do jednego silnika hurtowni; dane analityczne są tam skonsolidowane, a dane operacyjne z Aurora trafiają do niej przez replikację upstream.
| Wymiar | Przykład Denodo | Przykład AtScale |
| Źródła i wykonanie zapytań | Amazon Aurora, Amazon Redshift i lokalny PostgreSQL; Virtual DataPort planuje zapytanie federacyjne i łączy wyniki. | Dane analityczne Customer 360 w Amazon Redshift Serverless; każde zapytanie jest rozwiązywane w jednym silniku hurtowni, a dane operacyjne z Aurora są replikowane wcześniej. |
| Model semantyczny | Widoki bazowe, widok pochodny, osobny widok miar i znaczniki w Denodo Virtual DataPort; zapytania używają VQL. | Obiekty SML zapisane w YAML, obejmujące m.in. wymiary, fakty, miary, obliczenia, perspektywy i zabezpieczenia wierszy; model jest wersjonowany w Git. |
| Przykład kontroli dostępu | Global Security Policies maskują oznaczone pola ssn i card_num dla roli marketing_user; hr_user widzi je bez maskowania. | Kontrola oparta na rolach, zabezpieczenia wierszy i perspektywy; perspektywa marketing_user pomija przykładowe pola ssn i card_num. |
| Połączenie agenta | Serwer MCP Denodo łączy agenta z Virtual DataPort; AgentCore Gateway i Identity przekazują tożsamość w wymianie tokenu On-Behalf-Of. | Serwer MCP AtScale łączy agenta z modelem; AgentCore Gateway i Identity obsługują ścieżkę poświadczeń, a AtScale rozpoznaje rolę wywołującego. |
Modelowanie: widoki albo obiekty wymiarowe
Denodo opisuje dane za pomocą widoków: bazowe odwzorowują źródła, pochodny łączy dane na poziomie klienta, a osobny widok miar udostępnia wielokrotnego użytku definicje wskaźników. W przykładzie powstaje sześć widoków bazowych. Zapytania są wyrażane w VQL, a Virtual DataPort planuje ich wykonanie w źródłach i łączenie wyników.
AtScale opiera model Customer 360 na wymiarach i faktach. Definicje w Semantic Modeling Language (SML) obejmują też miary, obliczenia, perspektywy i reguły bezpieczeństwa wierszy; pliki YAML są wersjonowane w Git. Taki układ pasuje do przykładu, w którym analityka znajduje się w jednej hurtowni, a model wymiarowy określa biznesowe znaczenie danych udostępnianych agentowi.
Dostęp do danych i ślad audytowy
W przykładzie Denodo Global Security Policies maskują oznaczone numery ubezpieczenia społecznego (ssn) i karty (card_num) dla marketing_user, podczas gdy hr_user widzi te pola bez maskowania. Opisany przez AWS ślad audytowy obejmuje zapytanie VQL, przypisaną rolę, plan federacyjny i zastosowane reguły.
AtScale pokazuje kontrolę opartą na rolach, zabezpieczenia wierszy oraz perspektywy ograniczające widoczne elementy modelu. Perspektywa marketingowa pomija wymienione pola wrażliwe. Ilustracyjny rekord audytowy zawiera zarówno zapytanie wymiarowe utworzone przez model językowy, jak i SQL przetłumaczony dla Redshift. Uwzględnia też tożsamość, zastosowane polityki, użycie agregacji i liczbę zwróconych wierszy.
Który wzorzec pasuje do rozmieszczenia danych?
Jeśli agent ma odpowiadać na pytania wymagające bieżącego łączenia danych z chmury i lokalnych systemów, przykład Denodo pokazuje taką federację w czasie zapytania. Nie wymaga ona w tym tutorialu uprzedniego utworzenia wspólnej tabeli przez proces ETL.
Jeśli organizacja utrzymuje już skonsolidowaną hurtownię analityczną i może replikować do niej dane operacyjne, przykład AtScale pokazuje model, w którym każde zapytanie wykonuje jeden silnik. To wybór wynikający z opisanych granic architektury, a nie ogólny werdykt o wydajności lub bezpieczeństwie produktów.
