AWS har udgivet retningslinjer for Multi‑Dataset Topics i Amazon QuickSight med et klart fokus: Chat‑dreven, AI‑genereret SQL guidet af et semantisk lag. Ifølge AWS får teams to veje til tværgående spørgsmål – enten via definerede relationer eller ved at lade en generativ motor skrive SQL ved kørselstid baseret på semantisk kontekst (AWS‑blog). Det flytter arbejdet for BI‑ og datahold: mindre pre‑join, mere metadata og styring.
AWS præciserer, at Topics her er den nye oplevelse – ikke legacy (kilde). Tilgangen bruger en lagdelt Semantic Guidance Stack og åbner for bl.a. outer joins, unions og subqueries uden at være låst til en på forhånd tegnet relationsgraf (kilde). Fleksibelt – men det kræver driftsdisciplin.
Hvad et Topic betyder her – og hvorfor det rykker
I QuickSight er et Topic et semantisk anker, hvor forretningsbegreber og felter samles til naturligt sprog‑spørgsmål. AWS understreger, at der er tale om den nye Topics‑oplevelse (kilde). De fleste reelle spørgsmål spænder over flere tabeller – fx net revenue pr. produktkategori, som kræver både et sales fact, et returns fact og en product dimension (kilde).
Før i tiden betød det pre‑join
Tidligere krævede broer mellem tabeller, at en dataingeniør for‑joinede til ét samlet datasæt, før analytikere kunne stille spørgsmål i QuickSight (kilde). Deterministisk, ja, men tungt. Hver ny vinkel kunne betyde en ny pipeline eller dataset‑variant.
Nu flytter man svarlogik fra struktur til semantik. Det gør præcise beskrivelser og målrettet test til førsteprioritet.
To veje til multi‑dataset i QuickSight
AWS beskriver to modes: defined relationships og Chat‑dreven AI‑SQL (kilde).
I defined‑relationships bygger QuickSight en logisk join‑graf. Den er et DAG med op til 12 datasæt, og eksekveringen er deterministisk, fordi stien er foruddefineret. Det passer til miljøer med stærk styring og krav om én vej igennem tabellerne (companion‑indlæg).
AI‑styret SQL ved kørselstid
I den anden tilgang giver man motoren kontekst: dataset‑instruktioner, topic‑instruktioner, felt‑synonymer og feltbeskrivelser. Relationer behøver ikke være defineret på forhånd. Når en bruger spørger, vælger modellen datasæt, kolonner, join‑type og aggregering – og skriver SQL’en på stedet (kilde).
Det åbner for operationer, der er svære i en låst graf: outer joins, unions, subqueries, self‑joins, cross‑grain‑sammenligninger og betingede joins (kilde). Intention over struktur – kræver til gengæld klare hegnspæle.
Semantic Guidance Stack – lagene der styrer sproget
AWS beskriver en lagdelt ramme: dataset‑instruktioner (hvad tabellen rummer, hvornår den skal bruges, nøgler og grænser), topic‑instruktioner (domænepræmisser og nomenklatur), plus feltbeskrivelser og synonymer. Lagene er brugsanvisningen for SQL‑generatoren (kilde). Kvaliteten står og falder med præcisionen i beskrivelserne.
Hvordan motoren udnytter laget
Når en bruger spørger, bruger modellen felternes beskrivelser og synonymer, læser dataset‑instruktioner og vælger strategi: hvilke datasæt, hvilke kolonner, hvilken join‑type, og hvordan der aggregeres. Fordi planen skrives ved kørselstid, er valgmulighederne brede – det er her fleksibiliteten kommer fra (kilde).
Det løser ikke alt. Det kræver tydelige guardrails og løbende validering.
Otte best practices – og hvad der virker i hverdagen
AWS’ indlæg rummer otte konkrete råd med eksempler og anti‑mønstre. Kernegreb: skriv klare feltbeskrivelser; angiv synonymer for forretningsord og forkortelser; brug dataset‑instruktioner til at pege modellen mod de rigtige tabeller i normale scenarier; og definer rolle‑dimensioner (fx “date som order_date vs. ship_date”), så modellen kan vælge rigtigt (kilde).
Tag lavthængende gevinster først: Prioriter felter, der dækker størstedelen af spørgsmålene, og giv dem fyldige beskrivelser samt få, skarpe synonymer. Beskriv rolle‑dimensioner eksplicit, så tid, geografi eller valuta ikke blandes.
Retail‑eksemplet i praksis
AWS’ walkthrough bruger en retail‑case: net revenue pr. produktkategori kræver et sales fact, et returns fact og en product dimension (kilde). I et Topic for Chat vil instruktioner forklare, at net revenue ≈ gross sales minus returns, at returns mappes per order_line eller per item, og at kategorisering findes i product dimension. Felter som “nettoomsætning”, “retur”, “kategori” får beskrivelser og synonymer – også hvis brugere blander sprog.
De beskrivelser styrer, om modellen vælger et left outer join fra sales til returns (så solgte linjer uden retur bevares), eller en subquery, hvis returdata først skal aggregeres.
-- Aggreger returns per order_line før join
WITH r AS (
SELECT order_line_id, SUM(return_amount) AS return_amt
FROM returns
GROUP BY order_line_id
)
SELECT p.product_category,
SUM(s.sales_amount) - COALESCE(SUM(r.return_amt), 0) AS net_revenue
FROM sales s
LEFT JOIN r ON s.order_line_id = r.order_line_id
JOIN product p ON s.product_id = p.product_id
GROUP BY p.product_category;
Kanoniske testcases til pilot
Gør piloten målbar. Brug 2–3 faste spørgsmål med kendt facit og klare acceptkriterier:
- Net revenue pr. kategori for seneste hele måned. Reference: deterministisk SQL eller eksisterende rapport. Accept: samme tal og fordeling; afvigelser undersøges og dokumenteres.
- Return rate pr. produktlinje top‑10. Reference: håndskrevet query i et udviklingsmiljø. Accept: samme top‑10 i samme rækkefølge.
- Order‑til‑levering lead time pr. land. Reference: valideret dashboard. Accept: median og percentiler matcher reference inden for et snævert tolerance‑vindue.
Mål samtidig: korrekthed mod reference, p95 svartid pr. spørgsmål, timeout‑politik og estimeret cost‑per‑query. Fastlæg threshold‑værdier i pilotplanen og stop løbende forespørgsler, der overskrider dem. Ingen tal fra AWS i blogindlægget på disse mål – det er et reporting gap, som må afdækkes i egen drift eller via AWS‑kontakt (kilde).
Antimønstre og faldgruber
AWS advarer mod bred eller vag semantik. “Bruges til rapportering” hjælper ikke modellen. Manglende datakvalitetskontrol skaber også problemer: nulls, duplikater og many‑to‑many‑relationer giver uforudsigelige aggregater (kilde).
En særlig risiko er join‑eksplosioner. Uden en låst DAG kan modellen sammensætte legitime, men dyre planer. Det koster både ventetid og penge. Guidance‑laget skal derfor også begrænse – ikke kun åbne – mulighederne.
Hvornår vælge AI‑guidance, relationships eller hybrid
Beslutningsrammen i AWS’ materiale er enkel: Ved stærke governance‑krav, behov for reproducerbarhed og et kendt sæt rapportspørgsmål giver defined relationships mest ro. Op til 12 datasæt i en DAG, deterministiske stier (companion‑indlæg).
Til eksplorativt arbejde, ad‑hoc‑spørgsmål og power users er den AI‑styrede tilgang oplagt. I praksis lander mange i en hybrid: En styret kerne til rapportering, flankeret af Topics med fleksibel Chat til udforskning og prototyper.
Hvad skal på plads ved implementering
Tre ting går igen i praksis. 1) En metadata‑proces: Hvem skriver dataset‑instruktioner, hvem ejer feltbeskrivelser, og hvordan prioriteres de vigtigste felter. 2) Test: AI‑genereret SQL valideres mod forventede resultater og smoke‑tests på tværs af nøglespørgsmål. 3) Performance‑monitorering og fallback: Sæt timeouts, kost‑alarmer og en kendt vej til deterministiske queries i defined‑mode.
Governance og audit – reproducerbarhed når AI skriver SQL
Når Chat‑laget vælger joins dynamisk, skal resultater kunne genskabes. Minimum: log prompt, version af Topic‑metadata, genereret SQL, kørselstid og ressourceforbrug.
Indfør en letvægts PR‑workflow for semantisk metadata – som kode:
- Skabelon for felter: navn, datatype, rolle (fx order_date vs. ship_date), beskrivelse, synonymer, kilde, kvalitetssignaler.
- Ejer og reviewers: dataejer samt mindst én forretningsrepræsentant.
- Versionsmærkning: semantisk version på Topic og datasets, med “effective date”.
- Review‑SLA: fx to arbejdsdage til godkendelse, ellers auto‑eskalation.
- Rollback: enkel gendannelse til forrige version, dokumentér årsag.
Auditlog, som bør gemmes for hver Chat‑forespørgsel:
- Bruger og prompt (med anonymisering hvor påkrævet).
- Topic‑version og dataset‑versioner anvendt.
- Genereret SQL og valgte datasæt/kolonner.
- Kørselstid, p95/p99, ressourceforbrug og omkostningsestimat.
- Eventuelle fejl og fallback‑sti, hvis brugt.
Tekniske begrænsninger og åbne spørgsmål
Der er huller i AWS’ blogpost, som kræver opfølgning: ingen konkrete latency‑tal for runtime‑generering, ingen estimater for cost‑impact, og ingen detaljer om samspil med SPICE eller prissætning (kilde). Det samme gælder skalerbarhed: Hvad sker der ved mange samtidige Chat‑forespørgsler mod store datasæt? Er der anbefalinger til caching eller materialisering? Og hvad med fejltilfælde – hvordan ser en robust fallback ud, hvis AI‑SQL fejler eller returnerer inkonsistens? Her er behov for mere teknisk dokumentation eller kundeerfaringer.
Hvad er out‑of‑the‑box – og hvad kræver engineering
Kort skelnen, så projektet planlægges realistisk:
- Out‑of‑the‑box fra AWS: to modes (defined relationships og AI‑guidance), den lagdelte guidance‑model og at AI kan generere SQL ved kørselstid inkl. støtte til flere join‑typer samt subqueries (kilde).
- Kræver engineering: proces for metadata‑forfatning og review; driftsovervågning af svartid og cost; adgangskontrol der sikrer, at AI‑SQL respekterer rettigheder; styring af query‑kompleksitet (budgetter og timeouts); og en implementeret fallback til deterministiske queries i defined‑mode.
Rådene her er preskriptive for at få en pilot i luften; AWS dokumenterer rammerne, ikke jeres praksis.
En konkret startplan
Start smalt. Vælg et domæne med høj værdi og moderat kompleksitet, fx salg/retur i retail. Kortlæg 30–50 felter, prioriter top‑20, og skriv korte, præcise beskrivelser plus 2–3 synonymer per felt. Tilføj dataset‑instruktioner til de mest brugte kombinationer: hvornår vælges hvilken tabel, og hvilken join‑retning er standard.
Opsæt en valideringsplan med kanoniske spørgsmål, hvor facit kendes. Mål korrekthed, svartid og omkostning pr. forespørgsel. Iterér metadata ugentligt i piloten.
Hvad det betyder for roller og workflows
Arbejdet flytter sig. Dataarkitekter modellerer stadig, men bruger mere tid på semantiske instruktioner og rolle‑dimensioner. BI‑ingeniører sætter tests, overvågning og fallback‑stier op. Produktledere får hurtigere første svar – men bør budgettere metadata‑vedligehold som en løbende opgave.
Fejltyperne ændrer sig også: færre hårdkodede join‑fejl i ETL, flere misforståelser i beskrivelser. Det kan styres med tydelig guidance og faste review‑ritualer.
Det lille tradeoff – kontrol mod fleksibilitet
Defined‑mode giver determinisme, men begrænser join‑typer og kompleksitet. Den AI‑styrede tilgang giver fart og bredde, men kræver disciplin i guidance‑laget og en plan for at måle og stoppe dyre eller forkerte forespørgsler. Hybrid er ofte den kloge midte.
Er området tungt reguleret, så brug defined‑relationships som standard og frilæg kun enkelte exploratory‑Topics. Skifter domænet hurtigt, så investér i guidance‑laget og automatisér tests.
Konklusion og næste skridt
QuickSights Multi‑Dataset Topics med Chat‑dreven SQL løfter logikken op i semantikken. AWS’ Semantic Guidance Stack giver en ramme, og de otte best practices peger mod styrbare metadata (kilde). Der er åbne spørgsmål om performance, cost, skalerbarhed og audit, som kræver mere data fra AWS eller referencekunder.
Indtil da: Start småt, beskriv de vigtigste felter godt, test AI‑SQL som var det kode, mål effekt og omkostning. Brug relationships hvor determinisme kræves, og AI‑guidance hvor fleksibilitet og time‑to‑insight er vigtigst.
Ressourcer
- AWS blog: Multi‑dataset Topic best practices for Amazon Quick Chat
- Companion‑indlæg: Data modeling best practices for Amazon QuickSight multi‑dataset relationships
- Tjekliste til pilot: afklar domæne, prioriter felter, skriv instruktioner, sæt tests, mål latency og cost, planlæg fallback
