DWA (Data Warehouse Automation) – v3 Versionsnoteringar

Version: 3.2 Ersätter: release/v25.6.2

3.2-motorn serialiserar måljobb, registrerar varje kvalitetskontroll för sig, och taggar varje sats den skickar med det jobb som utfärdade den. Se Vad förändras i 3.2 — avsnitten Datakvalitet och Spårbarhet täcker resonemanget bakom dessa ändringar.

🚀 Funktioner

• Serialisering av måljobb. Redis-låsbaserad serialisering av jobb (lock:<loadstep>) med reservköer för väntande jobb förhindrar konflikter vid samtidig målexekvering.
• Kvalitetsschemaläggning och spårning. QPI-motorn för kvalitetskontroller byggdes om med kadensmedveten schemaläggning (daily, hourly, monthly, adhoc), oberoende exekveringsspårning per kontroll, inbyggd frågetaggning (QUERY_TAG, sqlcommenter) och OpenLineage-händelser för föräldrajobb.
• 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.
• Ett misslyckat test skiljs från 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. validate() kastar nu fel vid varje misslyckande i stället för att returnera ett partiellt resultat.
• Orkestrering och hygien. Filutlösare uppgraderades med Redis SHA256-deduplicering, och åldersmedvetna städpass för containrar lades till för fastnade och avslutade arbetaruppgifter.

🐛 Buggfixar

• Exekvering och resultathantering. setBatch-hanteringen av tomma resultatmängder släpper nu DML-räknarrader med nollidentitet, och inställningar för databasdrivrutinen gjordes valfria för att förhindra startkrascher mot mål utan ODBC.
• Uppgiftssekvensering och grindning. Grindningen av laddningsordning (identify_tasks_to_inititate) skrevs om så att beroende uppgifter blockeras när tidigare schemalagda ordningar är ofullständiga.
• Tillståndsåterställning. Omstartshanteringen fixades, och kvarvarande state- och information-nycklar rensas innan uppgifter köas om, för att förhindra att inaktuell feltext propagerar in i nästa körning.
• Köstabilitet. Redis-köoperationer härdades med StrictRedis-keepalives och hälsokontroller, och loggningsbruset från containerstädningen tystades.

Uppgraderingsnoteringar

1. 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ö.
2. Frågetaggning kräver ingen konfiguration. Ett statiskt QUERY_TAG- eller APP-värde som redan är satt bevaras, det kastas inte. Taggen landar i QUERY_TAG på Snowflake, user_agent_entry på Databricks, application_name på PostgreSQL och ODBC-APP på SQL Server, Synapse och Fabric, med en inledande sqlcommenter-kommentar på alla mål.
3. Kvalitetsdefinitioner skrivs inte längre av arbetaren — den ändpunkten är reserverad för att redigera dem.