Data quality-ramverk: Great Expectations + dbt tests i CI/CD

Den dyraste datan är den som ser rätt ut men är fel. Ett tyst fel som sprider sig till en styrelserapport kostar förtroende som tar månader att bygga upp igen. Därför bygger jag datakvalitet som en automatisk grind i stället för en manuell kontroll någon hinner med ibland. Här beskriver jag hur jag kombinerar dbt tests och Great Expectations i ett CI/CD-flöde som fångar fel innan de når någon människa.

Innan jag går in på verktygen vill jag understryka varför det här är värt besväret. De flesta organisationer jag möter har någon gång skickat ut en rapport med fel siffror, och nästan alla minns hur det kändes. Det är sällan ett dramatiskt haveri, snarare en tabell som tyst räknat fel i några veckor innan någon råkar upptäcka det. Skadan är inte bara den felaktiga siffran utan det förtroende som går förlorat: efteråt ifrågasätts även de siffror som faktiskt stämmer. Datakvalitet handlar därför ytterst om förtroende, och förtroende är dyrt att bygga upp och billigt att rasera.

Två verktyg som kompletterar varandra

dbt tests är inbyggda och billiga. De passar för regler som hör ihop med transformationerna: nycklar ska vara unika, kolumner ska inte vara tomma, värden ska ligga i en känd mängd. Great Expectations är kraftfullare och uttrycksrikare och passar för djupare kontroller på rådata och statistiska förväntningar.

Jag ser dem inte som konkurrenter. dbt tests är min första försvarslinje nära transformationerna, medan Great Expectations får ta de mer komplexa kontrollerna jag inte vill trycka in i en yml-fil.

Vad jag faktiskt testar

• Strukturella regler: unika nycklar, obligatoriska kolumner och giltiga relationer.
• Domänregler: belopp som inte får vara negativa, datum som måste ligga i rimliga intervall.
• Volymregler: antalet rader per dag ska ligga inom ett förväntat spann, så att en halverad inläsning larmar.

Volymtesterna är de som oftast räddar mig. Ett fel som halverar en inläsning syns sällan i en stickprovskontroll, men det syns direkt mot en förväntan på radantal.

Att bygga in den här typen av kontroller är en naturlig del av vårt arbete med dataplattform. Jag ser det som lika självklart som att en applikation har enhetstester.

Köra det i CI/CD

Poängen är att testerna körs automatiskt. Jag kopplar dem till pipelinen så att en förändring i transformationerna kör hela testsviten innan den får gå vidare. Ett brutet test stoppar bygget, precis som ett misslyckat enhetstest i vanlig mjukvara. Då blir kvalitet en del av flödet i stället för en eftertanke.

Larm som någon faktiskt ser

Tester utan larm är bortkastade. Jag ser till att ett misslyckat test landar där teamet redan tittar, oftast i deras chattverktyg, med tillräckligt sammanhang för att förstå vad som gått fel. Larm som ingen läser är värre än inga larm, eftersom de skapar falsk trygghet.

Anomalidetektering bortom fasta regler

Fasta tester fångar det du redan vet kan gå fel, men de missar det oväntade. Därför kompletterar jag dem ibland med enklare anomalidetektering som larmar när något avviker statistiskt från det normala, även utan en uttrycklig regel. Om en kolumn som brukar ha tio procent tomma värden plötsligt har sextio, eller om en daglig summa avviker kraftigt från den senaste månadens mönster, vill jag veta det även om ingen skrivit ett test för just det. Den här typen av bredare bevakning fångar problem som ingen förutsåg, vilket är just de incidenter som annars blir dyrast. Jag håller det dock enkelt i början, för överkänslig anomalidetektering skapar brus och larmtrötthet.

Att äga kvaliteten över tid

Ett kvalitetsramverk är inte ett projekt som blir färdigt, utan något som lever och måste vårdas. Verksamheten förändras, nya källor tillkommer och gamla antaganden slutar gälla. Jag ser därför till att det finns en tydlig ägare till datakvaliteten, någon som ansvarar för att larm faktiskt åtgärdas och att testsviten utvecklas i takt med verksamheten. Utan en sådan ägare förfaller även det bästa ramverket, larm börjar ignoreras och förtroendet eroderar tyst. Jag brukar också föra en enkel logg över de incidenter som faktiskt inträffat och vilket test som hade fångat dem, dels för att lära, dels för att kunna visa värdet av arbetet för dem som håller i budgeten.

Börja smått

Jag försöker inte täcka allt på dag ett. Jag börjar med de tester som hade fångat de senaste verkliga incidenterna och bygger ut därifrån. Varje gång något går fel som inte fångades lägger jag till ett test, precis som med buggar i kod. Över tid blir sviten ett skydd som speglar verksamhetens faktiska risker. Vill du se hur det gått för andra finns exempel i vår casebook.

Relaterat

• ETL vs ELT vs Reverse ETL: Modern data stack för svenska bolag
• BI-val: Looker vs Power BI vs Metabase vs Lightdash
• Semantic layer 2026: dbt Semantic Layer vs Cube vs LookML

Vill du ta det vidare?

Om dina dashboards någon gång visat fel siffror och du vill att det aldrig ska hända igen, hör av dig via kontaktsidan. Jag hjälper dig bygga grindar som fångar felen innan de når någon.