PDQ 3.2 — Vad som förändras för din modell

Version: 3.2 Utgivningsdatum: 1 december 2025

Versionsnumren följer nu det AME API-kontrakt som en komponent kräver. Den här versionen lägger till två nya byggmål, gör om normaliseringsmodellen, genererar styrning ur samma metadata som bygger tabellerna, och registrerar varje kvalitetskontroll och varje sats för sig.

Läs den här sidan innan du uppgraderar, och därefter komponentnoteringarna för detaljerna: Config UI · Data Operations Console · Active Metadata Engine (AME) · INGEST · DLS · DWA

Höjdpunkter i versionen

Datapipeline

• Två nya byggmål: Databricks på Delta och Unity Catalog, samt PostgreSQL — published, core och publish.
• Profilering körs nu efter att en fil landat; filen lämnas vidare i stället för att stanna vid organiserad.
• En misslyckad revisionslogg görs om och parkeras sedan — en misslyckad laddning är synlig, inte tyst frånvarande.
• Varje kvalitetskontroll registrerar sitt eget utfall; en batch rapporterar inte längre bara sin sista kontroll.

Datastyrning

• Villkor, kommentarer och klassificeringstaggar kommer ur samma metadata som bygger tabellerna.
• Klassificering av känsliga data genereras per plattform — en maskeringspolicy på Snowflake, dynamisk datamaskering i T-SQL-familjen, SECURITY LABEL på PostgreSQL, och SET TAGS på Databricks, som inte genererar någon mask.
• Domäntaggar följer ärvda affärsnycklar nedåt genom normaliseringshierarkin.
• Varje sats bär med sig sitt jobb, sitt steg och sin körning in i målets egen frågehistorik.

Datahantering

• Hierarkiska källor normaliseras annorlunda: en tabell per objekt, barn viks in i sin förälder.
• Tekniska kolumner har __-prefix och skyddas från versalisering och aliasering; en __checksum per tabell.
• BOOLEAN är en stödd källdatatyp; affärsnycklar i core får åter vara NULL.
• Kolumnnamngivning är konfigurerbar, och nyckelordningen bevaras hela vägen.

Versionshantering

Förut: oberoende kalendertaggar

Varje komponent bar sin egen datumbaserade tagg — generatorn och lyssnaren på release/v25.10.1, arbetaren på release/v25.6.2, filflyttaren på release/v25.10.4. Ingenting i taggen sa vilket backend-API komponenten talade, så kompatibilitet fastställdes genom att läsa versionsnoteringar, eller genom att driftsätta och se vad som hände.

Nu: ett nummer, knutet till AME-kontraktet

Varje komponent i den här versionen bär samma nummer: 3.2. Numret anger vilket AME API-kontrakt komponenten talar — 3.2-linjen kräver v3-API-familjen, med generering på objektnivå på /api/v3.2. En komponent och en backend är kompatibla när deras nummer stämmer överens, och det går nu att läsa ut ur versionen ensam.

Varför det ändrades

Versionshanteringen finns för att göra AME-kompatibilitet besvarbar utan att läsa någonting. En 3.2-komponent kommer inte att köra mot en backend som bara har v2 — det anges nu av versionen i stället för att upptäckas vid körning, och det är därför att lyfta backend till v3 är första steget i varje uppgradering.

Där ett kontrakt fortfarande kan variera inom huvudversionen förhandlar generatorn i stället för att anta: sourcefile-datakontraktet prövas på v3.2, sedan v3.1, sedan v3, där en 404 faller vidare till nästa version och en 422 stoppar omedelbart. Arbetarens interna byggsträng är separat och oförändrad — den identifierar bygget, inte kontraktet.

Byggmål

Databricks

• Published läser med read_files() över abfss:// och Unity Catalog-volymer — ingen namngiven stage, ingen COPY.
• Delta GENERATED ALWAYS AS IDENTITY i stället för sekvenser; MERGE i stället för UPDATE…FROM.
• VARIANT-kolumner stöds, med LATERAL VIEW över VARIANT.
• Klassificering via SET TAGS. Databricks genererar ingen mask — en känslig kolumn taggas, den maskeras inte, så upprätthållandet måste komma från katalogpolicy.
• Inga framtvingade UNIQUE, PK eller FK — de mallarna är medvetet utelämnade. Planera kvalitetskontroller därefter.

PostgreSQL

• Modellerad efter SQL Server-paketet: relationell, framtvingade villkor, sekvenser, inga lagrade procedurer.
• Källfiler läses genom en pg_lake-FOREIGN TABLE över objektlagret, skapad en gång i Published-definitionen och återanvänd av laddare och publicerare.
• JSON-navigering använder inbyggda jsonb-operatorer: ->, ->>, #>>, jsonb_path_query_first.
• Skiftlägesokänslig kolumnhantering och citerade alias, vilket krävs när repositoryt självt är Postgres.

Objektlagring är inte längre Azure-formad

OBJECTSTOREURL ersätter AZUREBLOBACCOUNTURL och är schemaneutral: abfss://, s3://, gs://, dbfs:/, wasbs:// och absoluta sökvägar som /Volumes/… används ordagrant, och en bar värd får https://. PUBLISHEROBJECTSTOREURL låter publiceringslagret peka på ett annat schema än Published och Base. Det gamla namnet fungerar fortfarande; om båda är satta vinner det nya.

Modellen

Hierarkiska källor normaliseras annorlunda

• En tabell skapas per objekt; en nivås barn viks in i sin förälder och barnbarn kastas.
• Roten beter sig nu som förväntat för LIST-strukturer, och self-nivån ingår i utdata.
• Föräldrasökvägar matchas på sökvägssegment i stället för en delsträngs-LIKE, så likartat namngivna nivåer matchar inte längre varandra.
• Fältnycklar som delar namn över olika nivåer avdupliceras.

Kolumner är förutsägbara igen

• Tekniska kolumner har __-prefix och behandlas som skyddade, så versalisering och aliasering skriver inte längre om dem.
• En __checksum per tabell, placerad sist, endast på tabellnivå — den genererades tidigare på flera nivåer.
• Kolumnsorteringen är korrigerad i genererade skript; nyckelordningen bevaras hela vägen; load_date propageras.
• Namngivningen är konfigurerbar — proper, pascal, camel, init eller upper, med mellanrum och prefix. levelAlias prefixar nästlade fält; fält på rotnivå förblir oprefixade.

BOOLEAN är nu en källdatatyp

Mappas till BOOLEAN på Snowflake och Databricks, BIT på SQL Server, Synapse och Fabric. Källor som tidigare tvingades till en annan typ kommer att ändra form — kontrollera varje källa som bär true/false-värden innan du genererar om.

Laddning

Core-laddning

• RelValidFrom ingår i dygnsspanns- och inkrementmönstren, med null-standardvärde tillagt.
• Ett portabelt lägsta-datum-standardvärde ersätter den icke-portabla GREATEST — Fabric behåller GREATEST.
• X_HasUpdate-grindning per attribut: ett attribut skrivs bara över när en källrad faktiskt landade i deltafönstret. Att propagera NULL förblir det avsedda sättet att "rensa värdet".
• Inkrementella core-laddningar på Snowflake använder MERGE igen.

Publicering och schemadrift

• v3.2-publiceraren är ombyggd: schemadrift hanteras via MERGE, primärnycklar på publiceringstabeller med __fileKey inkluderad, och versionsbaserad ALTER-generering.
• method=cleanup tillagd; method=overwrite släpper nu tabellen först — den förhindrade tidigare att tabellen skapades.
• CREATE OR REPLACE är begränsad till vanliga tabeller, inte Iceberg-tabeller.
• Kategorier läggs till på publicerade tabeller och refererar endast föräldratabellen.

Strukturell och dekorativ DDL är nu åtskilda

DEVELOPMENT-vägen genererar endast strukturella kolumnändringar — CREATE TABLE IF NOT EXISTS och ALTER ADD/DROP COLUMN. Kommentarer samt unik- och främmandenyckel-DDL är endast definitionsmässiga, och dubblerade körbara satser avdupliceras i revisionsspåret. Affärsnycklar i core får också åter vara NULL; befintliga tabeller skapade med NOT NULL migreras inte automatiskt.

Styrning

Villkor

• Unika villkor från affärsnycklar — inline där plattformen kräver det, ALTER ADD i övriga fall.
• Främmande nycklar från relationsmetadata, barn → förälder, avduplicerade.
• Primärnycklar på publiceringstabeller.
• Alla tre är på som standard.

Dokumenterad vid födseln

• Kolumn- och tabellkommentarer genereras inuti CREATE TABLE på Snowflake och Databricks.
• Landningstabeller i staging bär fasta tekniska beskrivningar på rowId, fileName, VARIANT-kolumnen och loadedTs.
• Apostrofer i beskrivningar escapas på varje kommentarsväg — de bröt tidigare satsen.

Klassificering

• Kategoritaggar via TAG_NAME, standardkategori.
• Taggning av känsliga data via SENSITIVE_TAG_NAME och SENSITIVE_TAG_VALUE.
• På Databricks genererat som enbart SET TAGS — det finns ingen genererad mask.

Domäntaggar följer nu de nycklar de hör till

På en normaliserad barntabell inkluderar fieldDomain-taggar nu också domänerna för affärsnycklar som ärvts från förfädernivåer. De nyckelkolumnerna bars redan över till barntabellen, så deras taggar hör hemma där — tidigare taggades endast fält deklarerade på tabellens egen nivå.

Förfäder gås igenom närmast först och fyller endast luckor: en domän deklarerad på tabellens egen nivå vinner alltid, varje alias genereras en gång, och endast nyckelfält ärvs. Publiceringsdefinitioner för barntabeller kommer därför att bära ytterligare taggsatser för nyckelkolumner som tidigare lämnades otaggade.

Datakvalitet

Exekveringsposter per kontroll

• Varje kontroll nycklas på (qpi, runDttm) och registrerar sitt eget tillstånd och resultat genom sina egna start- och slutanrop.
• Batchstatusen speglade tidigare endast den sista kontrollen i batchen.
• runDttm hämtas ur meddelandet och skrivs tillbaka på det, så en omkörd batch återanvänder samma körningsnyckel och start/slut förblir idempotenta.
• Vid slutförande rullar API:et MDQpi.LastRunTm framåt — det finns ingen separat skrivning av senaste körning.

Ett misslyckat test är inte en trasig kontroll

• En kontroll vars SQL kördes men vars testfall misslyckades registreras som Completed med resultState=fail, och rapporteras.
• En kontroll vars SQL kastade fel registreras som Failed med det verkliga felet och stackspårningen, och batchen görs om.
• Rapporthuvudet speglar kontrollernas utfall, inte omkörningsbeslutet.
• validate() kastar nu fel vid varje misslyckande — ingen SQL, inga rader, databasfel — i stället för att returnera ett partiellt resultat.

En kvalitetskörning är nu läsbar som data snarare än som ett enda godkänt/underkänt. Du kan se vilka kontroller som misslyckades, skilja en regel som fångade något från en kontroll som själv var trasig, och lita på att en omkörning inte skapar en andra körningspost. Definitioner skrivs inte längre av arbetaren — den ändpunkten är reserverad för att redigera dem.

Spårbarhet

Arbetsenheten följer med SQL:en

Varje sats arbetaren skickar bär nu med sig det jobb den tillhör — app, arbetarversion, typ (dwa / dm / qpi), jobb, steg, körning, kö, omförsök, plus stegets egna objekt-, attribut- och relationsidentifierare. Ingenting behöver konfigureras. Ett statiskt QUERY_TAG- eller APP-värde som redan är satt bevaras, det kastas inte.

Mål	Inbyggd funktion taggen landar i
Snowflake	QUERY_TAG, som JSON
Databricks	user_agent_entry
PostgreSQL	application_name (gräns på 63 byte)
SQL Server / Synapse / Fabric	ODBC APP → program_name
Alla mål	Inledande sqlcommenter-kommentar

Varför detta betyder mer än felsökning

En fråga i målets egen historik kan nu kopplas tillbaka till den pipelinekörning som utfärdade den. Det är den kopplingsnyckel som kostnadsfördelning har saknat: förbrukning registrerad av plattformen på ena sidan, deklarationen som orsakade den på andra.

Kommentaren genereras i sqlcommenter-form — sorterade, procentkodade key='value'-par som databasobservabilitetsverktyg redan känner igen. Den leder i stället för att avsluta, eftersom satser delas på ; / GO; / EXECUTE IMMEDIATE och en avslutande kommentar skulle fästa sig vid nästa sats.

Landning

Profilering körs som standard

• Efter en lyckad organisering med godkänd revisionslogg postas filen till modify-kön och lämnas vidare.
• Den postas dessutom till profile-kön när targetData.enableProfiler är 1 — standard när fältet saknas. Sätt den till 0 för att undanta en källa.
• Det vidarebefordrade meddelandet kopierar det inkommande och skriver endast över det revisionsloggen löste ut; omförsök nollställs så att nästa arbetare startar med en färsk budget.

En misslyckad laddning är nu synlig

• Revisionsloggning i landningszonen görs om fem gånger, varefter meddelandet skjuts till <zone>-parked-kön och misslyckande rapporteras.
• Parkerade meddelanden görs inte om automatiskt — övervaka de köerna.
• Ett meddelande utan objectUrl rapporterar misslyckande; det rapporterade tidigare framgång.
• Revisionsloggning är nu begränsad till landningszonen.

Händelsetider är ordnade, och objectUrl är en sökväg

Händelsetider normaliseras en gång, så tidigt som möjligt: molntider konverteras till den konfigurerade lokala tidszonen och tzinfo tas bort, medan tider tolkade ur filnamn redan är lokala och lämnas oförskjutna. Det tar bort den dubbelkonvertering som gav förskjutna tider i revisionsloggen. Tidsstämplar bär nu millisekunder, så filer som landar inom samma sekund kan ordnas.

objectUrl är nu en lagerrelativ sökväg snarare än en fullständigt kvalificerad URL, och .gz-suffixet läggs på exakt ett ställe. Allt som läser objectUrl måste själv lägga till värden.

Modellering

Mappning är visuell

• Källfält och målattribut renderas som en graf, nu standardvyläget.
• Mappningar skapas och tas bort med dra-och-släpp, med sökning, ämnesområdesfilter, visa endast mappade och bildexport.
• Ett överlägg med mappningslinjer i trädvyerna kopplar källa till mål vid hovring.
• En ytterligare Tasks-sida hanterar extra processorer för för- och efterbearbetning.

Härkomst och lösa trådar

• En härkomstgraf byggd på levande metadata: system → källfiler → modeller → exporter.
• Föräldralösa mappningar — vars målattribut eller modell bytt namn eller tagits bort — visas nu med en Remove-knapp. De var tidigare osynliga och kunde varken ses eller städas bort.
• Fältklassificeringar hanteras från Settings; Postgres kan väljas som dataplattform.

Dialogen för nyckelmappning löser nu problemet i stället för att beskriva det

Den listade tidigare dina mappningar, angav en regel och erbjöd en enda destruktiv knapp — Remove Mappings raderade ditt arbete, medan den korrekta åtgärden inte hade någon knapp alls. Den namnger nu vad som saknas, förklarar vad en affärsnyckel är, och låter dig välja källfält och trycka Map and save. Borttagning faller ner till en textlänk som namnger sin konsekvens och sitt antal, och dialogen djuplänkar till den specifika modellen med en returlänk som återställer ditt system, din källfil och din grupp.

Påverkan på ett befintligt datalager

Ändring	Vad du gör åt det
Publicerade tabellformer ändras för hierarkiska källor	Generera om definitioner och jämför dem innan du kör någon laddning
Tekniska kolumner får __-prefix, en __checksum sist	Kolumner genererade av v25.10.1 kommer inte att stämma med den nya namngivningen och ordningen
Villkorsgenerering är på som standard	Sätt ENABLE_CORE_UNIQUE / FOREIGN_KEY / PUBL_PRIMARY_KEY till 0 för att behålla tidigare utdata
Affärsnycklar i core tillåter NULL igen	Befintliga tabeller skapade med NOT NULL migreras inte automatiskt
CREATE TABLE på Snowflake och Databricks bär COMMENT	Sätt om baslinjen för varje test som jämför genererad DDL byte för byte
Domäntaggar inkluderar ärvda affärsnycklar	Publiceringsdefinitioner för barntabeller bär ytterligare taggsatser
BOOLEAN är en stödd källdatatyp	Källor som tidigare tvingades till en annan typ kommer att ändras
rundate-standardvärdet löses nu per anrop	Skicka rundate explicit om du förlitade dig på det tidigare frysta värdet

Också värt att veta

Databricks genererar inga framtvingade UNIQUE, PK eller FK — unikhet måste vara en kvalitetskontroll, inte en databasgaranti. Fältkategoriseringar kan ännu inte tas bort från gränssnittet.

Införande — gör detta, i denna ordning

1. Lyft backend till v3. 3.2-linjen kräver det: /api/v3, med /api/v3.2 för generering på objektnivå. Ingenting annat kan flytta sig förrän det är gjort.
2. Flytta varje arbetare till REDIS. Backends för SQS och Azure Storage Queue är borttagna; en driftsättning som lämnas kvar på någon av dem faller tyst igenom till en nullkö.
3. Starta modify- och profile-konsumenterna. De måste vara igång innan filflyttaren driftsätts, annars ansamlas meddelanden bakom den.
4. Generera om definitioner och jämför dem. Jämför gammal och ny genererad SQL innan du kör en laddning. Tabellformer och kolumnnamngivning har ändrats.
5. Bestäm dig om villkor och klassificering. Villkorsgenerering är på som standard. Sätt TAG_NAME, SENSITIVE_TAG_NAME och SENSITIVE_TAG_VALUE till ditt eget schema.
6. Uppdatera konsumenter av objectUrl och övervaka parkerade köer. objectUrl är en sökväg utan värd, queue:qfileready är borta, och parkerade meddelanden görs inte om automatiskt.

caution

Steg 4 och 5 är de som oftast hoppas över. Inget av dem misslyckas högljutt — en inaktuell definition laddar in i fel form, och ett standardtaggschema blir tyst det du får leva med.